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)
First of all, I have to apologize for not having been around these days, but I was busy with other business...
For the compilation problems, I tried to make it easier to check dependencies and compile the game without needing to spend too much time studying automake tools or similar (which I actually never used before) - which lead me to writing that make.sh script, which actually runs only on debian based distros.
As for non-debian based distributions, I probably had better inserting more instructions in the readme file (my fault, I know) - but running the command in the posts above should work (I will fix the readme ASAP)
Coming to the "error" shirish had, it is not a real bug, but a performance problem. The real fact is that the database loading system is not very performant - that means, it takes very long to load the whole database, first of all, because the database loading system is not very efficient, secondly because the way it is used in the game is the worst possible (it requires to load multiple times even the same objects - although I realized it much too late to change it); when I started adding content, this became a pretty annoying problem, though I didn't have time to fix it.
So, to try my game you must be veeeery patient and motivated, that's it :)
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)
First of all, I have to apologize for not having been around these days, but I was busy with other business...
For the compilation problems, I tried to make it easier to check dependencies and compile the game without needing to spend too much time studying automake tools or similar (which I actually never used before) - which lead me to writing that make.sh script, which actually runs only on debian based distros.
As for non-debian based distributions, I probably had better inserting more instructions in the readme file (my fault, I know) - but running the command in the posts above should work (I will fix the readme ASAP)
Coming to the "error" shirish had, it is not a real bug, but a performance problem. The real fact is that the database loading system is not very performant - that means, it takes very long to load the whole database, first of all, because the database loading system is not very efficient, secondly because the way it is used in the game is the worst possible (it requires to load multiple times even the same objects - although I realized it much too late to change it); when I started adding content, this became a pretty annoying problem, though I didn't have time to fix it.
So, to try my game you must be veeeery patient and motivated, that's it :)
Pages