Today I worked more on collision detection. I couldn't quite get it working, so I posted a StackOverflow question and pretty much continued attempting different functions all of class. Nothing has worked so far, but I'll continue trying and see if I can figure out the source of the problem. Once I can fix this bug, I can get back to feature adding!
Unfortunately I don't have any good step-by-step tutorials for today, but once I get collision detection working I'll be sure to add that in. Some of the recommendations for collision detection I've heard of are quadtrees and other Javascript libraries such as three.js. I haven't really used three.js however, because that's mainly for 3d rendering in Javascript.
EDIT (5/16): I finally got collision detection working! It wasn't anything to do with using the right algorithm, rather I had been passing an integer into my method instead of an array. It works great now! I'm now going to get started on velocities.
I also helped Aki on the tutorial today, so here's a link to his blog.
Friday, May 15, 2015
Thursday, May 14, 2015
Really Getting Into Socket.io! (5/14)
So, half of this was done yesterday. But I decided to bunch it all up into one blog post today, because it's quite a bit of progress and there's a lot of cool stuff going on, so I thought I might as well put it together!
Yesterday and today, I've completed quite a bit of small milestones for my game project. They're not really huge features, but basic things that are required for every game. Surprisingly, a lot of them were pretty tough to get working. Sure, I had the amazing tutorial from yesterday, but the main issue is that I'm working on a multiplayer game. Therefore, a LOT more server interactions are going to have to be made. Anyways, that all aside, the features added include the following:
-You can now move! That's right, using W, A, S and D, or the arrow keys, your little character will move on screen.
-Other players can see you moving! And you can see them too. This is done via NodeJS. Here's how I did it:
I essentially have my game refresh at a rate of 60 frames per second, like most games. Obviously, if you can't achieve that framerate it's fine, but it might not look as good. On each of these updates, the socket emits a current player position. That position is then sent to the server, who bounces it back to all of the clients so that they can all update other players' positions. In essence, this is done like the following:
-You can shoot tiny pellets with the space key! And other players can see them! My whole concept of pellet travel is the exact same as above, but speed of the pellets is [obviously] faster than speed of the players. I want it to be kind of like Galaga in that sense. Interaction with these should be coming soon, that takes collision calculations which I'm going to get started on tonight.
Some features planned for this week:
-A changelog [I like the idea of live-updating things]
-Collision detection
-A background map
Yesterday and today, I've completed quite a bit of small milestones for my game project. They're not really huge features, but basic things that are required for every game. Surprisingly, a lot of them were pretty tough to get working. Sure, I had the amazing tutorial from yesterday, but the main issue is that I'm working on a multiplayer game. Therefore, a LOT more server interactions are going to have to be made. Anyways, that all aside, the features added include the following:
-You can now move! That's right, using W, A, S and D, or the arrow keys, your little character will move on screen.
-Other players can see you moving! And you can see them too. This is done via NodeJS. Here's how I did it:
I essentially have my game refresh at a rate of 60 frames per second, like most games. Obviously, if you can't achieve that framerate it's fine, but it might not look as good. On each of these updates, the socket emits a current player position. That position is then sent to the server, who bounces it back to all of the clients so that they can all update other players' positions. In essence, this is done like the following:
-You can shoot tiny pellets with the space key! And other players can see them! My whole concept of pellet travel is the exact same as above, but speed of the pellets is [obviously] faster than speed of the players. I want it to be kind of like Galaga in that sense. Interaction with these should be coming soon, that takes collision calculations which I'm going to get started on tonight.
Some features planned for this week:
-A changelog [I like the idea of live-updating things]
-Collision detection
-A background map
Wednesday, May 13, 2015
Helping Aki Fix The App (5/13)
Today I helped Aki fix the app from the tutorial. See Aki's post for details.
Tuesday, May 12, 2015
Temporary Project-Hop [Still Working on Android!] (5/12/15)
Today I temporarily hopped to a new interesting project. Aki had shown me a game earlier that used HTML5's canvas element to make an easy-to-understand and simplistic MMO. From what I saw, I knew already that they were using Node.js and Javascript to communicate with a server. An idea popped into my head, and that was that I should try my skills at creating a Node.js-based game for the browser.
For the record, I'm still working daily on my Android project, and I haven't forgotten about it. I'm just adding this to my list of side-projects.
I started doing some research on the Canvas element, and found that it was pretty simple to use, but there's not a whole lot of documentation about it. Then, I found an article on creating a basic game using the canvas element, by a Mozilla developer. Although it's not exactly the concept of what I'm doing, I'm going to look at it to get an idea of what I'm going to try to do.
I then made a basic landing page using Bootstrap, and I started working on an "Upgrades Store".
After just an hour or so, my landing page started to look pretty nice. I'd be happy to show an example, I just don't want to upload any images yet since I think my game idea is pretty nice :)
It got even better when I started handling user connections, and mentioned their names. Since I'm on a Mac, it even featured Emoji support:
I then went ahead and setup multiple server support, like so:
I can't wait to get players to load tomorrow! I think it's going to be an interesting concept. I'm also going to work more on my Android project tomorrow. Unfortunately I couldn't do so tonight because I need to use multiple devices to test and have access to the internet while doing so.
For the record, I'm still working daily on my Android project, and I haven't forgotten about it. I'm just adding this to my list of side-projects.
I started doing some research on the Canvas element, and found that it was pretty simple to use, but there's not a whole lot of documentation about it. Then, I found an article on creating a basic game using the canvas element, by a Mozilla developer. Although it's not exactly the concept of what I'm doing, I'm going to look at it to get an idea of what I'm going to try to do.
I then made a basic landing page using Bootstrap, and I started working on an "Upgrades Store".
After just an hour or so, my landing page started to look pretty nice. I'd be happy to show an example, I just don't want to upload any images yet since I think my game idea is pretty nice :)
It got even better when I started handling user connections, and mentioned their names. Since I'm on a Mac, it even featured Emoji support:
I then went ahead and setup multiple server support, like so:
I can't wait to get players to load tomorrow! I think it's going to be an interesting concept. I'm also going to work more on my Android project tomorrow. Unfortunately I couldn't do so tonight because I need to use multiple devices to test and have access to the internet while doing so.
Monday, May 11, 2015
Continuing Work on Android (5/11)
Today I finalized my server for my Android app. Once again, involving socket.io. However, I came into the issue that each client needs a specific ID. So, after some thought, I made it such that each client listens from the socket only on a very specific ID event. That way, the client will only listen to information pertaining to what it needs to know, without having to listen to information from a lot of other sources.
I did it by assigning a listen event to a variable, like so:
socket.on(idVariable, eventFunction);
Then, the eventFunction would be called, and we could send and receive data from the server to the client.
I did it by assigning a listen event to a variable, like so:
socket.on(idVariable, eventFunction);
Then, the eventFunction would be called, and we could send and receive data from the server to the client.
Friday, May 8, 2015
Working more with sockets and runnables (5/8/15)
Today I worked on a Runnable class for my Android app that sends data every 10 seconds. I added some methods to cancel and start it as well, but I haven't been able to test them yet. This method will allow me to continuously send data when I need to, and cancel it when I need to stop [onAppClosed, etc.]. It uses the CountDownTimer interface for Android to handle this.
I also worked a bit on planning and pulling the repo for the expo tomorrow, and doing some planning on how our internet connection, etc. will work.
I also worked a bit on planning and pulling the repo for the expo tomorrow, and doing some planning on how our internet connection, etc. will work.
Wednesday, May 6, 2015
Working more with NodeJS/SocketIO (5/5)
Today I started on one of my other projects and integrating Socket.io into it. I now have a go-to Socket.io script, as seen below.
As you can see, using the NodeJS modules http, express, and socket.io, a server is created. I then went and implemented this into my Android app like so:
And just like that (granted the Android device has an internet connection), the socket works! You can now use this as a server to send and receive data to one or multiple devices. I decided to change the event for each device, so the event is sent like 'socket.emit('deviceEvent ' + deviceId, informationHere)'. That way, the server can talk to individual Android devices. The Android code is as follows:
As you can see, using the NodeJS modules http, express, and socket.io, a server is created. I then went and implemented this into my Android app like so:
And just like that (granted the Android device has an internet connection), the socket works! You can now use this as a server to send and receive data to one or multiple devices. I decided to change the event for each device, so the event is sent like 'socket.emit('deviceEvent ' + deviceId, informationHere)'. That way, the server can talk to individual Android devices. The Android code is as follows:
Monday, May 4, 2015
Starting out with NodeJS, Socket.io, and more server-side Javascript
So, recently out-of class I've been working on quite a few projects, many of which are relating to Javascript. A lot of them have been specifically aimed at websites that are using APIs to communicate, then connecting the client-end code to NodeJS on the server-side.
So, for a quick overview:
I've been using NodeJS on my server-end to handle things such as saving files, getting data, and doing other stuff that Javascript can't. A good example of this is that I'm using a bot that connects to the SteamAPI, and I can show information about this on the client-side through sockets.
Sockets are essentially the main thing we use to connect client-side code to server-side code. I've come to learn that they're extremely helpful, as lots of time Javascript code lacks certain features due to security restrictions. I've been writing my sockets in PHP recently. Here's a small example of a socket I used in my code recently:
Client-End
Server-End
Since a lot of new things were mentioned in this post, I'll try to get more into detail about them throughout the next week.
As you can see above, the Client-End is coded in PHP, while the Server-End is coded in NodeJS. Essentially, our Server-End is listening constantly on port 5501, while our Client-End is occasionally sending data to it. We can send the data as JSON, and then later parse it on the server-end, and send more information back based on what the sent information was.
This is all good, however, I found a new library yesterday called Socket.io. It's still doing the same things, but when you see how much time it saves, it's ultimately worth the switch. I'm going to be switching all my code to Socket.io based code over the next few weeks.
Socket.io makes socket communication amazingly simple. Their example of a simple chat server showed how you could easily have socket-based communication and an entire chat server in just a few lines. I thought that was amazing, especially thinking back to our old AndroidRPG project from earlier this year - we could have saved all that time with a simple plugin. The best thing is, it's been ported to all sorts of mobile platforms, including Android, and it's pretty efficient.
I've also been working with a few more libraries:
-Progressbar.js - Truly amazing progress bars. Allows for really nice ways of showing loading of items, live item counts, etc.
-net module for NodeJS - Allows for socket connections. However, I'm currently in the process of merging to socket.io as previously stated.
-Spotify Android SDK - I'm also in the process of making a music app for Android. I use Spotify to authenticate and play music.
-Steam Web API - I'm working on a bot that is 'talking' to the Steam Web API to grab virtual item information
-Bootstrap - Quite possibly the best API I've ever dealt with. It makes all your pages look amazing, it's open source, and so many people use it.
I'm also working with several more APIs [at least 5-10 more], but my progress with them isn't as far. As you can see, I've really been working hard on API-based programming and Javascript/NodeJS in my spare time, mainly because I'm surprised at how much things they can do!
So, for a quick overview:
I've been using NodeJS on my server-end to handle things such as saving files, getting data, and doing other stuff that Javascript can't. A good example of this is that I'm using a bot that connects to the SteamAPI, and I can show information about this on the client-side through sockets.
Sockets are essentially the main thing we use to connect client-side code to server-side code. I've come to learn that they're extremely helpful, as lots of time Javascript code lacks certain features due to security restrictions. I've been writing my sockets in PHP recently. Here's a small example of a socket I used in my code recently:
Client-End
Server-End
Since a lot of new things were mentioned in this post, I'll try to get more into detail about them throughout the next week.
As you can see above, the Client-End is coded in PHP, while the Server-End is coded in NodeJS. Essentially, our Server-End is listening constantly on port 5501, while our Client-End is occasionally sending data to it. We can send the data as JSON, and then later parse it on the server-end, and send more information back based on what the sent information was.
This is all good, however, I found a new library yesterday called Socket.io. It's still doing the same things, but when you see how much time it saves, it's ultimately worth the switch. I'm going to be switching all my code to Socket.io based code over the next few weeks.
Socket.io makes socket communication amazingly simple. Their example of a simple chat server showed how you could easily have socket-based communication and an entire chat server in just a few lines. I thought that was amazing, especially thinking back to our old AndroidRPG project from earlier this year - we could have saved all that time with a simple plugin. The best thing is, it's been ported to all sorts of mobile platforms, including Android, and it's pretty efficient.
I've also been working with a few more libraries:
-Progressbar.js - Truly amazing progress bars. Allows for really nice ways of showing loading of items, live item counts, etc.
-net module for NodeJS - Allows for socket connections. However, I'm currently in the process of merging to socket.io as previously stated.
-Spotify Android SDK - I'm also in the process of making a music app for Android. I use Spotify to authenticate and play music.
-Steam Web API - I'm working on a bot that is 'talking' to the Steam Web API to grab virtual item information
-Bootstrap - Quite possibly the best API I've ever dealt with. It makes all your pages look amazing, it's open source, and so many people use it.
I'm also working with several more APIs [at least 5-10 more], but my progress with them isn't as far. As you can see, I've really been working hard on API-based programming and Javascript/NodeJS in my spare time, mainly because I'm surprised at how much things they can do!
Subscribe to:
Posts (Atom)