A new version of the game (1.2) has been released! You can find it at the same links as before. No new levels have been included yet, but now it comes with level packs and a level pack editor, as well as automatic updates (you'll probably notice them when I release new levels...).
I'm still looking for level editors, so if anyone's interested just drop me a line in this thread or here.
It features 16 levels, springs (used to link platforms together) and an improved level editor. Have a try and please leave feedback!
Also, if you want to make some new levels (since my level design skills are pretty bad), you're welcome to share them (you can find a level editor guide here)
I noticed the same bug with bullets (though never got stuck at any level)... I'd suggest you to add some inertia to player spaceship, in order to make the game slightly more smooth and faster
I agree with claudeb about keeping different libraries.
Generally, one of the rules you should use in programming to avoid messing up everything is to split big problems into their smaller components: so you should split the problem "game" into its components - "graphics engine", "physics engine", "mathematics library", "content", ...
Still, as helfox said, in small games having everything mixed up might be pretty easy (and sometimes even easier than having everything split up). I personally prefer to write everything all together only if I want to quickly develop a little game (see Ballrunner - one night of coding, only a source file (geom.h and geom_graphics.h already existed) and a veeeery small game)
I'm not exactly what you'd call a "veteran developer", but I'll try to answer anyway.
As a C++ programmer, I tend to place 'common' stuff into headers - for example, in a RPG game, the map and player classes are not placed in the main source file but in some separate headers. That allows me to re-use them much more easily than copying and pasting that stuff in a new file.
What's more, you can let the engine load game content from external files (the easiest way to do this IMO is to parse plain text files). Still talking about RPGs, you could load monster types, maps and whole campaigns/stories from external files. You could take a look at Battle for Wesnoth's excellent way to do this: they have a whole markup language (WML) through which they interpret configuration files to load all game content (including many game rules).
I can (and I will) fix the readme file - that won't take me too much time.
Coming to the loading time, it won't be fixed, unfortunately. The animation loading system, up to now, requires each animation object to have inside all objects representing frames that compose the animation. For example, the object that describes the idle animation of the base male contains all the 8 frames of the idle animation. Each of this frames is loaded at game startup. Since we have many clothes, weapons and units, each with at least 8 frames (units and clothes can have even 300 frames), we have a very large amount of frames to load, which results in a long loading time.
I have no idea, at the moment, about how to change/fix this (without changing the whole game structure, which would take me much more time and work than I can give to game developing)
A new version of the game (1.2) has been released! You can find it at the same links as before. No new levels have been included yet, but now it comes with level packs and a level pack editor, as well as automatic updates (you'll probably notice them when I release new levels...).
I'm still looking for level editors, so if anyone's interested just drop me a line in this thread or here.
Version 1.0 is out!
It features 16 levels, springs (used to link platforms together) and an improved level editor. Have a try and please leave feedback!
Also, if you want to make some new levels (since my level design skills are pretty bad), you're welcome to share them (you can find a level editor guide here)
I noticed the same bug with bullets (though never got stuck at any level)... I'd suggest you to add some inertia to player spaceship, in order to make the game slightly more smooth and faster
Yeah... Sounds like a good idea... I might have a try at putting together some kind of game as soon as I get some time
@Blarget2: it'd be really funny... Do you already have some ideas? (btw, it's Buch, not Bush... :) )
Did it... I think the attribution instructions field wasn't there yet when I uploaded this... Or was it? by the way, there they are :)
I agree with claudeb about keeping different libraries.
Generally, one of the rules you should use in programming to avoid messing up everything is to split big problems into their smaller components: so you should split the problem "game" into its components - "graphics engine", "physics engine", "mathematics library", "content", ...
Still, as helfox said, in small games having everything mixed up might be pretty easy (and sometimes even easier than having everything split up). I personally prefer to write everything all together only if I want to quickly develop a little game (see Ballrunner - one night of coding, only a source file (geom.h and geom_graphics.h already existed) and a veeeery small game)
I'd suggest to add mumu's two orange/yellow side circles as a variation... they look pretty good
I'm not exactly what you'd call a "veteran developer", but I'll try to answer anyway.
As a C++ programmer, I tend to place 'common' stuff into headers - for example, in a RPG game, the map and player classes are not placed in the main source file but in some separate headers. That allows me to re-use them much more easily than copying and pasting that stuff in a new file.
What's more, you can let the engine load game content from external files (the easiest way to do this IMO is to parse plain text files). Still talking about RPGs, you could load monster types, maps and whole campaigns/stories from external files. You could take a look at Battle for Wesnoth's excellent way to do this: they have a whole markup language (WML) through which they interpret configuration files to load all game content (including many game rules).
I can (and I will) fix the readme file - that won't take me too much time.
Coming to the loading time, it won't be fixed, unfortunately. The animation loading system, up to now, requires each animation object to have inside all objects representing frames that compose the animation. For example, the object that describes the idle animation of the base male contains all the 8 frames of the idle animation. Each of this frames is loaded at game startup. Since we have many clothes, weapons and units, each with at least 8 frames (units and clothes can have even 300 frames), we have a very large amount of frames to load, which results in a long loading time.
I have no idea, at the moment, about how to change/fix this (without changing the whole game structure, which would take me much more time and work than I can give to game developing)
Pages