Spacewars Game Jam

In my networking class last Friday our professor John Pile surprised us with a Spacewar themed game jam. The goal was to group with one other person and make a networked game similar to the 1985 version of Spacewar. I choose to group with my friend Evan Schipellite. We decided to use his game for the last assignment as a starting point. From here we both just looked at the requirements and started to code. I started to work on game-play features such as the player class while he converted the architecture to work better with our new game. After I finished creating a few classes I needed to merge them with his architecture in order to test if they worked. Evan at this point had already setup some classes to make it relatively easy to merge our work. With just a little help I was able to get everything linked up and ready to go. The player class started to work with little need for fixes. The speed and some other values weren't the best but it worked and that was good. At this point there was still much to be done and with only very little time left. I was able to squeeze in bullets and the display of health within the last few minutes but there was not time for perfection. I had initially set it up so each player would be authoritative over when they took damage from a bullet but when I looked at the clock and saw less than five minutes left I realized that sending health data over the network was not going to happen in time. So I decided to comment out the line making it authoritative and just had everyone decided the score for everyone else. At the end we had working ships that could move around in a way fairly similar to space wars, bullets that hurt enemies, a awesome star field background made by Evan and a win state. To be able to create all of these things in a somewhat working fashion in such a short period of time was a success that I could feel good about. In retrospect though it would have been good to have a little bit more planning as to what we each were going to get done and what we wanted to accomplish during the time period. While we were doing the game jam both of us had very little idea what we were going to do let alone what the other person was doing. We just looked at the list and started programming things that needed to be done.

After the game jam we decided to improve upon the game and take our own spin on Spacewar rather then trying to make an exact copy. I came up with the idea that instead of in space we could be in quick sand because this would still work for the idea of gravity in the game. We evolved the idea from there and decided to make it a group of tourist that got stuck in quicksand and the tour guide only being able to save the last one. From here I went into polishing the old game features and adding on new ones. One of the requirements for the game was to have the bullets limited to 10 per player but last forever (with screen wrap). This caused a lot more difficulties than originally intended. Having this happen wasn't to difficult but as we watched the game go on the bullets would lag behind on different player screens. If a bullet was only alive for a second than the difference was so minor that it couldn't be noticed but if it were on the screen for 10 seconds a bullet on one screen would be maybe 3 seconds behind another. This was a pretty major problem so we tried our best to fix it. First we attempted to have all the computers sync up without sending bullet information over the network. We used methods such as having a physics timer so the bullets would only update every 50 milliseconds, multiplying the elapsed time by the speed and reducing the frame rate. All of this went to no avail so in the end we made the host authoritative over bullets sending their positions with a byte ID over the network. In the end I am happy with how both versions of the game worked out.

Bounce

Developers: Jacob Ellenberg, Devon Case, Robert Bethune, Noah Drayton, Eric Teall and Stephen Baptiste.

This is a project I did for my production class. We were grouped into teams of 5 or 6 and given 6 weeks to create a mobile game. My group consisted of 2 programmers, 2 artist, and 2 designers. We decided to make our game for the Nexus 7 because it was the most commonly owned device among are group so it would be the easiest for testing.

Bounce is a physics based game so to make our lives easier we decided to use a physics engine. The other programmers, Robert Bethune, and I decided to use Box 2D as our physics engine. This worked out really well except for the fact that comers of objects sometimes did unpredictable things.

Most of the programming in this game went smoothly. Rob and I worked really well together. For the most part we met up in the labs and programmed there. We would divide up what we needed to do at the start and help each other out if one of us got stuck on anything. This worked out well for the most part but towards the end of the project when we added some extra levels the game wouldn't work on mobile. This is likely due to the amount of memory we were requiring it to hold when loading all of the levels at the beginning of the game. We did not notice that this was happening until it was too late to fix because we were testing primarily on the PC when doing finishing touches. I learned from this that it is very important to test on mobile even after making what may seam like minor changes.

Cave In

This is my final project from my graphics course I took first semester second year. When I got this project I was just starting to realize my potential so I wanted to push my self to see what I could create. I did get some help with the art, design and audio. My brother Justin Ellenberg actually produced the song in the background for me. The spider and lantern were done by my friend Paul Kubik. Evan Schipellite gave me many design ideas on how to approach this project. That being said it was still primarily my own work and I am happy with what I was able to accomplish by challenging myself on this project.

I challenged myself by looking at areas that I had not explored much before such as AI. I did not do any research on it, I instead just played around to see what I could do. I started by creating an ally that had very simple following AI that was just an if else statement that would move in a direction based on the distance away from the player. From here I decided to add a wandering behavior where the ally would move three tiles in a random direction after a random period of time. After adding this the problem of the ally going around walls to get back to the player became obvious. In order to solve this I once again just thought of my own methods. I used some hacky way of creating a path by trying to go each direction and go around the wall and just used the shortest path. This method would only work with going around two or less walls but that is all I needed for my game. Although I had fun on this project creating AI from my head I now know it would be much better to research ways of doing what I am trying to do rather than trying to reinvent the wheel. In the case of finding my ways around walls I could of researched and implemented A* and I would of had no limitations as far as the number of walls to go around. It would of also been a lot more stable than my version. I also created simple boss fight AI that was pretty much just run strait at the target (using similar AI as the ally follow behavior) and attack. The boss also switched targets about every 5 seconds to allow the player to prepare itself for its next encounter.

I also wanted to challenge myself to make this game primarily data driven. I wanted to get experience making data driven parts so that when making games in the future it would be easier for my designer to make changes. The scenes with text and movement are all ran by text files. There are commands like MOVE_TO_ALLY, TALK_TO_ALLY, ect. This allowed me to make multiple scenes without much trouble at all. I also made the menu system data driven. The way I did clickable text with this is that you could have text be clickable and you can have a target that it would go to once clicked. This made it easy to make a clean menu system. It was also somewhat necessary to do data driven menus and dialog because there was a requirement to make it work in 4 languages. This could be done without it being data driven but it would of gotten very messy very quickly. I learned that having multiple parts being data driven can make life much easier later on in a project.