Sometimes you wish you need less options…

Messy, innit?

But yes, you can now configure input devices from the menu. Just hit ENTER to go into program mode and wiggle your stick!

ok, a quickie then…

Just a quick post to let you know that work is moving forward on extending the RRFW and getting to run Trapped! in it. Here is a quick screenshot of the title page, showing off the menu I just ported to the framework:

You can change the graphics settings on the fly. Rather nice FPS is only 60 because the Vertical Sync option is on and it’s a windowed screen. Next up is adding the keyboard/mouse and joypad configuration menus and options. Should be fun Once that is done the question of the particle engine is next. Should we port it or wrap it? Discussions are ongoing through heated debates between me and Muttley…

Well, not really, but it sounds interesting. So far, I’m pretty pleased with the framework. I only need to streamline screen handling a bit more. But I have proper screen fades and wipes in there now which is looking pretty neat. One of these days I’m done with the front end and can begin on the game again.

Moving to Retro remakes Framework

I’ve decided to move my game from my own framework to the retro remakes framework. This framework is a work in progress, and it is missing some stuff that my game needs, but we will add that to the framework. Yes, I have been added to that Google code project. First thing to do is get a basic game working using that framework and work from there.

The framework will also enable me to release Trapped (and any future game) on more platforms, think Linux and OSX. I also been added as a committer to the project so expect some of my code to slip into the framework. What does this mean for particleMax? I’ll probably still offer a stand alone version once it is up and running in the frame work.

On a personal note: Next week we will go to Denmark for a few days. Of course we will go to Lego land So I will be off the grid for some time. This Sunday we head off to the cold north.

IDE switch, managed code, services, singletons, oh dear!

Recently I changed my development IDE from Project Studio IDE to BLIde. I’m sad to let PSI go, but as development of that IDE has stopped and I experienced weird beta behavior a change was needed. Thanks Matt for your fine IDE; it was awesome while it lasted.

So now I am exploring the world of managed code, which is rather nice. It takes away the burden of imports, includes and file management in general.

Converting my game framework to managed code is underway, and made me realize that my ‘framework’ is not really a framework, but a collection of independent systems. There is nothing wrong with that, but I want to move to a solution which will provide the basis, ready to be extended for each game I am going to make.

So, my various systems are to be converted to Services. Converting the game engine to services is a tip I took from the Retro Remakes Framework. That framework looks really nice (although in some weird way I was already doing a lot of things in a similar manner), and I wanted to start using it but as I want to remain free of where I am going with this game (distribution wise) I do not want to use their code, which is free and meant for freeware remakes. So I took that concept, and shape it to fit how I create games.

The services are implemented as singletons. This is a nice concept which also has the advantage of getting rid of a lot of Global variables and fields in game types. A singleton is a type of which only one instance can be created, and just lives ‘out there’, ready to be used by whatever piece of code.

My game needs total control over what is updated and rendered in every single state, so the concept of services updating and rendering all the time is not used. It is now possible to determine this by game state which is cool. I for instance may not want to update the particle engine when the game is in Attract state or, say, Game Over state. Also, each game state must be able to move through steps in each state. Think of the Play state going through various enter, play, die, play, die steps.

Lots of work to do, but it’s fun even though finishing the game (ah, keep dreaming) will take some more time.

Trapped dev update 22

Whilst working on some internal stuff I noticed that I was still using a separate type for the particle engine objects position and interaction with it (rotation, velocity, etc) . This is a code structure heavily used since the Blitz 2D/3D days and it kind of snuck in. I’ve gotten rid of that external type and put its code properly in the engine base object. This simplifies some code further along in the extension path which is great!

I’ve been working on a spreadsheet to draft out the game and enemy progression. How do aliens develop over the course of the game, when does which alien get introduced, what are their characteristics on each level and what bonuses / possibilities does the game offer me at which point? And what does the player need to be able to stay alive? The arms race is laid out here as well, folks. This will help me to streamline the player experience and make sure that new stuff gets introduced at the correct times in the game so the player is not overwhelmed (or underwhelmed ) and the flow of aliens is constant.

Here is an example of the sheet:

Bonus rounds at set intervals introduce new stuff to the player and offer challenges to earn other stuff. I can’t be more specific now, sorry Putting these things down makes me think about the aliens, the rules they have to follow and the general flow of the game. Also, I’m getting an idea of how many different aliens I need to fill the planned levels. oh dear.