Tag Archives: games

OpenGL is dead! Long live OpenGL! (a.k.a. IFTPOP 0.0.2a)

Posted by on November 20, 2011 Comments Off

I think finally tracked the error that made the game crash on some computers. The culprit is OpenGL, more specifically OpenGL 1.X. Since the introduction of OpenGL 2.0 in 2004 there have been a few changes in the way how to do graphics (“it’s called shader baby!”). As my current reference of OpenGL (the OpenGL Super Bible, 5th ed.) tries to break free from the old legacy code (“fixed function pipeline”) I ended up being dependent on this new stuff.

Sorry about that. But if it does not run, you probably should get a new computer anyways.

At least some good news: errors are now nicely reported with a message box. Should your graphics card be incompatible, you will beinformed properly.

Get it from here: iftpop_0.0.2a

A new version with better graphics (OpenGL 2.X!) is coming along as I now finally fixed this error.

IFTPOP 0.0.1 for Windows

Posted by on October 17, 2011 Comments Off

All right! Windows version of the current code ready!

Grab it from here: iftpop-0.0.1

So far I am working on the controls for both camera and player movement. With the camera I am quite happy, but the player will get some more action features such as wall-jump and duck-slide, etc.

The camera starts to jitter at some point, but I do not yet know why.

Some informations about the game: it will feature some elements from racing games. And platformers. And nightmares.

Cheers,
Martin

New game: IFTPOP! first screenshot

Posted by on October 14, 2011 Comments Off

Just a small screenshot of the current state of my next game, called “IFTPOP!” (what it actually means might be revealed at some point). The code so far is based upon my previous asteroids game but with a lot of new development. Biggest change so far: integration of bullet physics.

So long,
Martin

Asteroids finished!

Posted by on May 8, 2011 Comments Off

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!

Asteroids: Beta 2 + Level Editor + Level Making Contest (update)

Posted by on February 13, 2011 2 comments

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!

Level Editor

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:

Level Making Contest

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.

Download

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.

Humble Indie Bundle 2 is out!

Posted by on December 15, 2010 Comments Off

As of yesterday the 2nd installment of the Humble Indie Bundle is out! This is the chance to get 5 super awesome games for a price you name! I already bought the first one and I totally can recommend it. Nice feature besides: you can also buy gift codes such that they make a nice Christmas present…

Here is the trailer:

Now go and buy it! It is more than worth it. Stop smoking and buy it if you have to – the games addictiveness is equally poisoning!

Asteroids Beta 1 (update)

Posted by on December 1, 2010 2 comments

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.

Things still todo…

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.

Now cut to the chase!

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:

A few words to the style…

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.

Some Credits

Here is a non-exhaustive list of libraries that I am using for the game (in no particular order):

  • SDL for OS abstraction
  • SDL_mixer for sound playback (which allows me to use ogg files quite nicely)
  • OpenGL for graphics
  • OGLFT for font rendering
  • boost (shared pointers and filesystem abstraction)
  • libpng for loading textures
  • Visual Studio Express C++ 2008 to create windows binaries
  • CMake as a build system
  • Mercurial as version control system
  • Audacity for modifying sounds
  • Gimp for everything that is 2D and consists of pixels

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.)

Braid

Posted by on September 7, 2010 Comments Off

I just finished playing the highly praised game Braid. I really enjoyed playing it, even though at some points I was very tempted to use a guide, as some of the puzzles got me too puzzled. But putting the game down for a few hours (or even some sleep), definitely helped as one easily loses creativity when playing it long. It is very interesting how the brain seems to continue to work on the puzzles, or to get used to the game mechanics, as it seemed to me much easier after a break.

Other than that I was very amazed by the atmosphere it creates, especially the music and the way the story is presented. Very simple, but one always wants to know more. The story itself is quite vague and sometimes even confusing, but fit very well  to the overall game.

Should you like solving puzzles á la Portal and not have played it, then there is no way around this gem!

Asteroids: first flying rocks

Posted by on March 24, 2010 2 comments

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:

the menu

asteroids in action

game over screen

My game development demons

Posted by on March 8, 2010 Comments Off

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!