Please note the “1.0.0” at the top bar or at the bottom-left of the screen. Or just help yourself with one of these:
You may now call me a game developer.
Something more elaborate will follow, but for now I just have to enjoy the moment!
Bad news: Asteroids is not yet finished.
Good news: Asteroids will have lots of cool stuff in the final version!
Since my call for levels in my previous post I received a lot of uber awesome levels. I was really blasted away by the creativity of some contributions and it is very impressive to see what one can get out of such simple mechanics. It was very hard to order the levels into increasing difficulty while simultaneously trying keep the gameplay fresh and interesting. But you will get to see it soon enough…
Other than playing and sorting levels, I worked on two new features that I thought would be very interesting.
When using the online highscore, the scores get submitted to the server and the top 10 scores from the server will me displayed in-game. This is all done by using SDL_net and performing some hand crafted HTTP queries to a small PHP script on the server. The PHP script itself stores the highscore in a SQLite database which was super easy to set up.
As everything is transmitted in clear text I also added some protection to ensure only valid submissions are added to the database. I am using a shared secret for the PHP script and the game which gets appended to the submission values (name + score) and then hashed. As a hashing function I use Aaron D. Gifford’s sha256 code which should be sufficiently safe for this. What I really like about it is, that I could publish the code for both the script and the game but this would still be not enough to spam the highscore unless someone succeeds to extract the shared secret – Nice!
In the game options menu one can choose whether one wants to use this online highscore mode or only use the local highscore. The following screen shot should be pretty self explanatory:
Whether the online mode is being used or not can be seen by the highlighted “-online-” at the top of the highscore screen. In “-offline-” mode it uses the values stored in the game data path.
Also there will be bonus points given when one finishes a level fast. For this I needed a time to compare to. Inspired by the PAR time in DOOM I played through all levels and added a few seconds. I am using a quadratic function to compute the amount of bonus points, depending on time and the number of asteroids in the level. Only when the level was finished before the PAR time. Currently I am tweaking the parameters of the function to properly reward the speeders.
I decided to give points at the end of the level so that one cannot achieve higher scores by playing a level with many asteroids multiple times by committing suicide on the last remaining asteroid and therefore getting twice as many points on the level.
To make the level switching a little nicer, I am now displaying some informations about the level, such as the number, title, and the author of the current level:
Furthermore I worked on the credits screen and made new sounds by using sfxr (which is super awesome!). But I’ll write about all that another time…
All right! So here we have a new version including all fixes that people found playing the first beta. There were only few errors of which most my 12 and 15 year old cousins found (i.e. collisions were not reported when entities were warped from one side of the screen to another). On bigger glitch came from a assert statement that I added to OGLFT as there was a bug with the boundary boxes, but apart from that only little problems were found. Thanks for everyone playing the game!
I also made a level editor for them as my cousins really liked the game and wanted to make levels themselves. It took me only 2 days to create the editor such that they could start making levels on their own as I already built a small set of GUI widgets using my own IMGUI code. It felt really good writing it and didn’t expect it to be running that quick. It was very rewarding to look over their shoulders and see the fun they had creating levels.
Here are some screenshots of the editor in action:
As so many people had a lot of fun creating levels (and they seemed much more creative than I), I decided to give everyone the chance to create awesome levels that will be shipped with the final version.
To spice it a little bit up, I decided to have a small level making contest. The authors of the winning levels will be listed in the credits of the final version under the category “Level Designer” which will probably make you very a famous celebrity (at least among a handful of nerds).
All you have to do is send in levels via email to
m a r t i n @ f y s x . o r g
until February 20th 2011, 23:59 CET. I will then take a week of careful judgement and announce the winners by the end of February / beginning of March 2011. Please fill in the field “Author” when saving the levels with the name you would like to have listed in the credits.
Levels are saved as <levelname>.map in the directory of the game (windows) or in the current folder (linux). You only need to send these files to me. Multiple levels can be sent to me.
You can get the new beta which also includes the level editor. The windows binaries can be downloaded from here:
And for those Ubuntu/Debian users you get nicely made packages (for both 32- and 64-bit systems) from here:
Update: new packages that also include menu entries and should work with older versions of Ubuntu:
Previous versions of the packages (no menu entries, linked against newer boost version 1.42):
They will also download all dependencies. However you should deinstall any previous versions. You need to run ´fysxasteroidseditor´ to start the editor. Make sure you find yourself in a writable directory as the editor will place temporary and saved maps into the current folder.
So far the comments I got for the beta of my Asteroids game were very pleasing. Most people liked it and played the game a couple of times right away. Also the difficulty was more challenging for most players than I expected (with a few exceptions of notorious hardcore gamers). But what makes me most happy is that no major issues or strange crashes were reported! Also the debian package I created in an updated worked and installed all required dependencies. Yesss!
In the mean time I tried to explore the possibilities on how to pimp up the graphics to allow 3D objects flying around. As I am using Blender from time to time I thought of creating a simple Asteroid and import that into my game. However finding a texture that I could use freely and therefore I looked for alternatives. I found a very nice tutorial at http://www.davidjarvis.ca/dave/blender/tutorial-21.shtml on how to create an asteroid by using Blender. The tutorial itself is for Blender 2.44, however I thought I use the chance to play around with the beta version of the new Blender 2.5.
What I really liked about the tutorial was the use of multiple materials to get the surface of the asteroid properly and asteroid like. This had also a very nice benefit as the texture gets created by the materials and I would not have to search for an appropriate (i.e. freely available) one.
Here is a rendered version of my asteroid:
Having finished the asteroid itself I only had to get it into my game. I chose to use the existing Wavefront OBJ format as they are easily exported from most 3D content creation tools and are easy to read. However instead of writing my own version of importer I chose to use the code that was made available under the MIT open-source license (Yay!) at http://www.dhpoware.com/demos/glObjViewer.html. With it I was able to display my first 3D asteroid:
Yes… that’s the way it looked. A little … flat. All the nice material was gone. It took me some time that I manually had to bake the texture on a UV map that I would then be able to apply on the model. The result is the much more pleasing following:
As the color map was baked with the lighting information that Blender had, the asteroid only looks nice from the direction of the light, however the back does not get any shading at all. I could have added some more lights to improve the color map, however I thought I would try some shading fu and use normal mapping.
To do normal mapping I would need two things: a shader code for the fragment and vertex buffer and a normal map of the asteroid. Luckily there is also some shader code available from http://www.dhpoware.com so I only had to do a normal map for the asteroid. But also the creation of the normal map was much less of a hassle than expected. You only need to bake the normals in tangent space in Blender and off you go:
In these final versions the asteroids only have one colored textures and all the different shades of gray only come from the normal map combined with the shader. Notice the rough surface and the craters which actually are on quite flat surfaces. The model itself is the same as in the first in-game picture.
And now? Well, the asteroids do look very nice and creating now different kinds of asteroids and a space ship should not be too hard. But a bigger question would be whether I want to do this huge change of style, as the current 2D version of my game already looks very nice in my opinion.
But I am convinced that I will not only make one game so I will still have plenty of opportunities to use the code…
Oh and here is the model both in form of the .blend file for Blender and the exported .obj file along with material file, texture and normal map:
Wahoo!!! It looks like I am getting somewhere with my Asteroids clone. It took me much longer than expected that far, but I do think I learned a lot on the way. Initially I started it because I realized my game programming demons that prevented me from actually writing a game. Instead I was only talking to myself that I would program game X at some point and programmed smaller things with which I could delve in the illusion of programming games.
However you don’t make a game unless you make a game. And that’s what I did – although I have to confess something: the game is not yet finished. There are two remaining tasks that I want to work on before I would dare to call it a completed game. These tasks are testing and additional levels.
I guess the experienced game designer/programmer might smile at this point, especially at the latter part, as levels are probably one of the trickiest things to do. They have to make the player at first curious, then be challenging, but not too hard, and not too easy, oh and not boring. However I do not plan to make this game perfect and therefore I am not going to make more than, say 20 levels. So far there are 5 levels with more or less increasing difficulty except the 5th which is a bit of a steeper step. The game mechanics will stay the same for future levels and there won’t be crazy new game elements, because I do not want to finish a game and not go on an endless journey of ideas.
Right now I need to do some testing (done by YOU* !) to find problems that I haven’t found yet. I am starting to not see issues because I am already too much in the technical viewpoint and got used to a play style that probably circumvents all issues that other people might have. Therefore I need some non-biased feedback from people without knowledge about the details. I already showed the game to a few people and had the chance to watch them play and I am fairly satisfied so far.
You can download the windows version from here:
I tested it under Windows 7 (64bit), Windows Vista (32bit), and Windows XP (32bit). I do my development under linux, but creating packages for that is a bit annoying. If someone wants to run it under linux, I will gladly send you the code and help you make it run.
Update: there is now also a Debian/Ubuntu (64bit) package available here:
Here are some screenshots, to get an impression how the game looks:
I tried to keep the style more simple and not do fancy OpenGL stuff. This has two reasons: first I am so far not much of an OpenGL guru and shader ninja, and second for a game like this a more ‘classical’ style fits very well. I tried to use filtered sprites, but that made the game look like strangely cheap. I hope the following picture conveys this somehow:
Also together with the font I am using it all looks a little more retro style. I do believe that it is more important to find a fitting style than to have graphical excesses (however I totally do not mind them, rather the opposite). But for a lone-wolf production like this I have to take what I can make myself and so far I am very satisfied.
Here is a non-exhaustive list of libraries that I am using for the game (in no particular order):
The music I am using is from DJAD and is called Space Exploration. Other than that I am using various sounds from http://freesound.org that I have customized (I still have to make a proper list for the credits).
All right. So much for now.
Have a nice day!
(* all right, there are not too many people passing around here that might be inclined to test it, but I still thought I’d make it clear that you are cordially invited to test and give some comments.)
The worst possible happened: the source code an even a buggy windows version version of my asteroids clone leaked to the internet! It took me quite long to finally get it run under windows and now that hard work simply pops up in the internet… I don’t know what to say. I fear it is probably an evil German hacker, just like in the 2003 leak of the Half-life 2 source. Tough times, I’d say…
Apart from that I am actually quite happy to get it finally run on windows. On the way there I ran into quite a few obstacles. I tried to use portable tools and libraries (CMake, freetype, OpenGL, SDL, libpng, boost), however getting them compiled and correctly linked in Visual Studio Express 2008 took quite some time. I also used a few precompiler #defines that were not supported by the Microsoft compiler (e.g. used __func__ instead of __FUNCTION__). There also was a critical bug that would make my game crash under Windows but not under GNU/Linux which was caused of improper initialization of a variable. The biggest hassle in the end was however getting it compiled so that it can be run on a computer on which it wasn’t compiled as there are some dependancies on the redistributable runtime libraries of Visual C++. I hope this is solved in the uploaded binary.
When you look at the asteroids.rc file you can mess around with some variables of the game (such as ship acceleration, maximum speed, etc.) and also set the controls the way you like it (so far only keyboard). Oh and there is also a very basic console (to access it press F8) with which you can run simple commands such as the ones in the asteroids.rc file.
For those who want to have a look at it here are the official links to the “leaked” versions ;D:
Known issues so far:
*too bad 1st of april has been already 9 days ago
As I mentioned in my previous post, I decided to get a rather simple game done instead of dreaming of bigger ones. So far I think I was quite successful. I tried to reuse most of the code I already had and it was very helpful to modify my existing code towards a very clear playable game.
The game itself is already playable and I have a basic menu and basic gamelogic (you have 3 lives and once you die you’ll see the game over screen) and I can load and save levels. At first I thought of using 3d models by using the cal3d library which I already use in my research project, however I reminded myself of keeping things simple and created some nice sprites. I added PNG support by using libpng to be able to load sprites with transparency and also added simple animation of sprites. In the background the stars are moving sideways to give a slight 3d effect (looks very nice!).
What is still missing is sound and I need a few more animations (ship exploding, asteroid exploding). Additionally I do not yet count any points and some non-asteroid (maybe some powerups) would be nice to add more fun to the game.
Enough prose – here are some screenshots:
It’s been now a long time, since I decided to write a certain game and talked a lot about it with friends. However I must confess, now after a few years, I still haven’t managed to finish a game. I wrote a lot of code and both bugs and documentation is so far not the problem. Instead there are a couple of demons that slow down the process that I would like to introduce to you (you probably know them already):
Efficiency Demon: This one is always in the back of my head. It tries to convince me not to use virtual functions as they are somewhat slower than normal function calls. However this approach makes things a lot more complicated and I spent time to circumvent the usage of “the single most important feature of C++” by using probably less efficient detours. Additionally following strictly the rule: first make it run, then optimize would encourage me to take a deeper look in profilers, which would be definitely a knowledge I wish to possess. There are a couple of nice quotes to this one on the Wikipedia page on program optimization – I guess I am not the only one having this demon.
Engine Demon: Instead of tackling simply completing the game logic/event managing/input handling part, I try to generalize what I just coded and put it into a part that I call “engine”. This “engine” is some kind of container of reusable code that I will most certainly need in the future. The catch is just: I do not yet know what exactly I will be needing in the future. Actually neither whether I need the generalized case nor the specialized I wrote in the first place. There is a very well written article (write-games-not-engines) from Josh Petrie which talks about this one. This demon is sometimes called Premature Generalization.
Beauty Demon: The Beauty Demon is related to the Engine Demon. It makes you want to clean up your mess (a.k.a. code). You just hacked in some features and now you want to polish it a little. So you polish. Then you realize you should add documentation. So you add it (and look at the beautiful caller graphs that Doxygen creates automatically for you). Then you realize that you could create of this feature set a library against which you can link dynamically – oh yeah, this is great, because then you can do this for all the other games you will write and reuse it. Oh, and the build system it got a little messy. How about … Yeah, you get it. You do a lot of things which are actually very useful. However they do not complete your game.
Just-that-feature-and-then-I’m-done Demon: I coded hard. The prototype works. And I am very happy. So I relax and think: Awesome, I’ll be done soon with the whole game and I can finish the rest tomorrow. There is a huge difference between a prototype and putting it into your game. I had a few nice parts, such as an event system and entity management system and so on which worked very well on them selves. But when I actually tried to make a simple game with it, I had to rewrite a lot of it and it was a lot harder than I expected. So unless the code is not in your game don’t think anything is done! (Please note that this is not an argument against writing prototypes – they are very important because you realize what the actual problem is and what kind of difficulties you run into!)
A long time ago, I read this very inspiring article ‘How do I make games?’ A Path to Game Development.When I look back, I must admit, I skipped quite a few steps suggested there. So last week I started to abuse my “engine” to create an Asteroids clone. So far controlling the ship, destroying asteroids and getting killed works, but there are still some areas untouched (menu, game-over screen, etc.). It took me a lot longer than I expected and I currently have a lot of quirks on making things work.
So far it is not efficient, not an engine, not beautiful and there is still a lot of work to be done. But I’ll stay on that rocky road and bring it home.
Thought game development is fun? It is – but getting it done is actually quite hard!