For our game design class, Dylan Otto Krider and myself were to elaborate on an earlier program we wrote that consisted of a blue player box that could move, red enemy boxes that were stationary, and yellow boxes for food that gave you some kind of reward for eating it.
To be specific, we were supposed to add functionality to the enemy boxes so that they chase you, but not in an absurdly difficult way for the player. In addition to that, we were to add the capacity for the player to shoot, which required the inclusion of white ammo boxes because the player should have a limited amount of ammo. We also took it a step further and made the enemy boxes more volatile by taking a shot at you when your in their sight every once in a while. To make it even more difficult and to provide some decent game play mechanics, we limited the starting ammo to 3, and started the player off moving slow, with a max speed that increases as you eat food boxes.
All in all the game should last about 30 seconds if you win, and is not in any way a real game, rather a prototype for showcasing and experimenting with a method of collision detection known as “narrow-phase continuous collision detection”.
Although it doesn’t look like much now, the framework is in place for a much larger game. The real purpose of this exercise is what I will get to next, which is the concept of this thing know as narrow-phase continuous collision detection. The framework is in place so that for example there could be 10,000 enemies, 2,000 food, a scroll-able screen with a gigantic arena to battle, regenerating enemies, bouncing bullets, etc… and it would all still work. Anything that can collide in this “world” can be handled efficiently and with sophistication within this framework.
The next logical step towards making it even more efficient would be to add what is known as “broad-phase collision detection”, which is a way of dividing the screen into a grid, and determining which grid space each box resides in, more or less. There could be several. The box’s location is then organized into a hash table so that only items that are hashed to the same location are selected for kind of the “narrow-phase” detection found in this exercise. Long story short, it’s a fancy way of determining whether you need to even test for a collision or not, which is a lot of work up front, the great payoff being that your program will be doing much less work (i.e. narrow-phase collision detection) in the long run.
Programmer Side Note: A great thing about hash tables is that they are an O(1) operation to retrieve information, making this the fastest possible way to search for anything. Such a great thing. This is a coding question/concept that will pop up in a lot of job interviews, and is just good information to know if you plan on programming professionally.
The whole point of continuous collision detection is that instead if saying, “When this thing collides with that thing… do this”, we are taking a different, more mathematical approach. In this situation, at every frame, the program knows by each object’s current trajectory, when two objects will collide, not if they will collide. The program then, in short, makes sure that everything is taken care of as if the objects had collided, but in fact they never did. Time was advanced until the objects would have nearly collided, time was stopped, the objects marked for removal were removed (i.e. a bullet hit a wall and was removed), and the process was all repeated again, and again for all objects that would have collided in that frame, until we reach a full time step of one frame. This method, as taught to us by our professor, is a much more elegant, and sound method of approaching collision detection than the “if they collide” approach, for a number of reasons.
So, to get to the point, if anyone wants to play the game, or look at the code and tinker with it, the whole package can be found here:
The .zip file includes the source code for those interested (hopefully you are), native versions of the game for Windows and Mac as well as a Linux.sh file for shell freaks, and last but not least, a cross-platform runnable jar file that can be double clicked in windows or opened in the terminal in Mac or Linux by navigating to the directory where it’s located and typing “java -jar Ex8RunnableJar.jar” as follows:
We hope you either enjoy the game (as simple as it may be), or if your a programmer, you get something out of the code. It’s hard at first to survive, but it is possible to win. It may be a little difficult, but it is possible. The trick is knowing you can reverse, you can use walls to stop yourself, and you can figure out the timing of the enemies fire.
I must add though that it is slightly annoying to play over and over again to get better because whether you win or lose, there’s no options menu to restart. You just have to close the window and start it up again. But that’s life. This isn’t a real game, so no time was spent on those kinds of features. Revision 11.24.13: The game is now fully functional and we hope you have some fun with it, because we sure did.
The game controls are as follows:
UP_ARROW —————- forwards
DOWN_ARROW ———- backwards
LEFT_ARROW ————- left
RIGHT_ARROW ———- right
SPACE_BAR —————- shoot bullet
S_KEY ————————- stop
Directions: You the player are the blue box. Avoid red boxes. They are evil enemies. They can move horizontally and vertically, but not diagonally, and every ??? seconds they can shoot at you. You can move faster by eating food (yellow boxes), and get more ammo to fire by running into the white boxes. The game is won when you kill all enemies. The game is lost if an enemy touches you or shoots you. Neither you or the enemies can leave the arena, and all bullets die when they hit something, including food, walls, and ammo boxes. Happy hunting!
Some additions that might be made in the near future are a larger arena with more food, monsters, and ammo, and also monsters that come out of the wall after a certain amount of time , as well as regenerating ammo and food. A general melee on a larger scale if you will.
This program was a project for one of my classes at school, and was written in Java by myself and Dylan Otto Krider. It is a simple perspective rendering of a space ship (or whatever you’d like to imagine) looking at blocks that the user can draw with a “pencil” block. The pencil block and the spaceship are not associated, so you can draw blocks however you like, and fly through them step by step in the space ship however you like. On the left is an overhead view of the blocks, and on the right is the 3D spaceship view. We just bound a simple texture to the OpenGL blocks for the space box effect. Overall, this was a pretty fun exercise, and kind of fun to tinker with, so I’m sharing it with you. To download click HERE or go to the Downloads section in the widgets.
Here are some screenshots of the program:
If you are on windows, I’ve made it easy by making a windows .exe file for you. In Linux, or Mac, you can run the .jar file in your terminal by navigating to the folder the file is in using the ‘cd’ command and then by and using the commands below to run the jar:
Also included in the .zip file is the source code to play with if your interested. A .pdf explaining how to swap out your own textures can be found HERE. Have fun with it if you want!
Binding textures to cubes is easy, but what about realistic looking objects that are constructed of elaborate meshes? This is just the beginning of shapes and textures in computer graphics. Texture and lighting is a huge area of study in OpenGL. You could literally spend a lifetime figuring out every aspect of the OpenGL shader language. I’m just shooting for the basics now. However, over break, I hope to at least get to start using Blender to create better and more interesting textures and meshes to use.
That being said, here’s a slideshow of some different textures used. They range from useful, to just purely self-amusing, but at this point, we’re just having fun with textures, right?
Cursed2D is my first attempt at writing a game. It is written in Java, using the Slick2D and LWJGL libraries. More than anything, this game was an attempt to learn the basics of how game loops operate, how animations work, and how to use data structures to solve problems. The game starts out in a town that has been cursed. It is up to you to find the cause of the curse, defeat your enemies, and restore the town to normalcy…Or something like that. since it was written in Java, I plan to host it as an applet here on the site, and in the form of downloads for Windows, Mac, and Linux. I spent so much time figuring out how to code a game, that I forgot to write a story. So this project is kind of back to the drawing board, and most of the work to be done right now is creative work. But as of 3/17/13, progress is again being made. Thank Jesus. Hoping to have a completed trial version by summer ’13.