To port or not to port…

Some progress:

Menus, game settings, high scores and joy pad configuration (still messy though) are in and working. Screens fade over nicely from one into the other, pause mode is working, so it is time to add the player or start porting ParticlesMAX over… I think I will start with the particle engine, as the player will need the particle engine for guns, lasers and engine anyway…

Over at the forums at muttleyville, we’re been kicking around ideas for the design as how it would fit into the framework. Streamlining things a bit never hurts and so that it what we’re trying to do as well.

What does this mean for the ‘standalone’ version of ParticlesMAX? I doubt it will be updated from now on, but it will remain online for anyone who wants to use it. There have been plenty of downloads but not one comment from users so I guess it’s not widely implemented anyway. As wxMAX is not a part of the framework, the new editor will be a separate build and will be provided as a binary from the framework Google Code site. Source code will be provided of course, but it cannot be compiled unless you install wxMAX from here.

On a personal note: I have sold my PS3 to my nieces’ boyfriend and got me a PS3 Slim, in the combination pack with Uncharted 2. Now THAT is a cool game, and I don’t even suck at it… The cover system is brilliant, better than in Gears of War and without the annoying icons. Cool story, excellent game play, the cinematics and voice acting are top notch. I really am enjoying this, I might even finish it and do it all again And graphically it’s just …wow…  But don’t you just hate that Yeti?

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.