Physics System in place

I have now implemented a simple physics system that controls gravity and wind resistance. To allow easy integration, I have also changed Sprites and EffectInstances to be subclasses of the new physicsobject. This means that I can associate and of the existing visual components of a game with a physics engine to automate certain animation aspects.

I am now in the process of creating subclasses of the effect and effectinstance classes to create particle emitters that I can put in place and forget about for the duration of the scene. To prevent the games looking too boring, I am adding variance to the attributes of the particles, so there appears a certain randomness to their size, shape, trajectory and life.

I was originally going to create the particle instances as direct descendants of the physicsobject, but after some thought, I think it would be better to implement them directly into the special effects system. However, I may create a secondary particle system that is based on the sprite system. This would allow for collisions and interaction with the game objects, but as I do not need this right now, I will leave it for now.

Wrestling with the dialog

I have just managed to complete the code for the Dialog class. It wasn't quite as simple as I thought it was going to be.

In a sudden flash of inspiration, I decided to give the dialog class the ability to appear on screen using transitions. These are sliding, fading or a combination of both. However, these were not my first issues...

I often use particle effects on my cursor to make it look 'pretty'. Unfortunately, these were being masked by the new dialogs, so I have to create a new type of effect called a PersistantEffect. these effects are not paused by the system, and as they are drawn over everything else, except the cursor, they are drawn on top of the dialogs. Like I said, that was issue number one.

Issue number two was the fact that I cause the game to pause when a dialog is  displayed. This had the adverse effect of pausing all triggers. Again, this was overcome with the new PersistantTriggers, which operate the entire time a scene is active.

The next issue was the sliding effect. When I created the GUI Subsystem, I never imagined that I would need to move the controls on screen. I had a number of approaches for this, and my first was to rewrite part of the GUI, however, I did not want to mess about with something that I knew worked. So the next thing is to get the dialog to control the movement of the GUIElements. As it turned out, this solution was quite simple, it was just the exploration of 'how' to do this that frazzled my brain.

In order for the dialogs to interact with the Scene, I have also added a new event handler: OnDialogReturn. This has one parameter passed back to it, the return code of the dialog. It is also to inspect the fields of the dialog in this handler, if required, as the dialog is removed from memory after this event is triggered.

So, the upshot is: I now have a dialog system that utilises the existing GUISubsystem, handling the GUI events in exactly the same way as the main scene. he dialog can appear to slide into the screen (and out after the dialog is closed) or fade in and fade out, or a combination of both of these transitions. However, some graphical care has to be taken when using the fade transition.

It's quite amazing at how much I am adding to the framework, when all I am working on is a simple puzzle game. but I'm sure that the additions i am making will only help in the future.

Framework additions

I've been working on a new game recently, basically to put the game framework really through its paces. Most of it has been holding up really well. I have however, come across a few issues that I have had to address.

Firstly, I had not implemented a way in which to display a dialog on the game screen. The framework is based on a series of 'scenes', but it was not easy to display a dialog over these scenes, so I am currently addressing this.

I also noticed that all of my coding had failed to take into the account of the triggers that I created for timed events. In particular, a particle effect I use to trace the movement of the cursor. I have now changed this to use the triggers and have realised that the code is much simpler and more efficient. I also have more control to the frequency of the particle creation.

I do plan to implement a proper particle system, based on the special effects classes in the framework. This will allow the easy creation of particles with various properties, such as blending type, movement, gravity, spawn rate, fading and shrinking. At the moment, I create each particle emitter by subclassing the effect and effectInstance classes, so I will look at subclassing these and allowing them to be integrated into the existing effects routines.

Anyway, I have been going on about my framework, so here is a breakdown of the classes in the framework and what they are for:

Type Scene

This is the container object for each scene within the game. To make this useful, this class must be extended with the event handlers overridden. It handles the automatic processing of the game loop, events and drawing.

Type SceneSound

This is the new sound object used within the scene.

By using thes SceneSound, rather than the TSound, we can control multiple instances of the playing sound And it will also respond To the Pause And Resume of the Scene Object.

Type Sprite

This is the sprite object used within the scene. Sprites are not created directly, but with the NewSprite method of the Scene object. Although the Sprite object can be used as is, it is also possible to subclass it to allow some automated processing, such as animation.

Type Trigger

Triggers are used to create timed events to be triggered during the game.

Triggers are not created directly, but with the NewTrigger method of the Scene object.

Type EffectInstance

This is the base object for all special effects instances. On it's own, this type can do nothing, so it must be subclassed.

Type Effect

This is the base object for all special effects. On it's own, this type can do nothing, so it must be subclassed.

Type GUISystem

This object, although not directly accessed by the programmer, controls all aspects of the in-game GUI system. This system is skinnable and can therefore be easily customised for individual projects. This is NOT a replacement for GUI systems like MaxGUI, the GUISystem in the framework was created for in-game menus.

Type GUIElement

This is the base object for all GUI elements. On it's own, this type can do nothing, so it must be extended.

Type GUIButton Extends GUIElement

This is the standard push button Object used by the GUI system. This object can have three images to show state and three sounds to trigger on mouse over, down and up events.

Type GUIToggle Extends GUIButton

The Toggle Button object acts like a normal button, but with the added advantage of being sticky, when set down. This is also useful as a check box in options menus. In a group, it can be used to simulate a radio button.

Type GUILabel Extends GUIElement

A static text label for displaying information.

Type GUILives Extends GUIElement

This object displays a number of images to indicate the number of lives left in the game.

This could also be used for other information, such as missiles or ammunition. The images used to display the information can be automatically animated, if desired.

Type GUITextField Extends GUIElement

This object will allow users to enter simple, single line textual information to the game.

Type GUIEvent

This is the parameter passed to the OnEvent method. This contains the ID of the object that triggered the event, as well as what action was performed.

I have a few other classes that I am planning to implement in the near future:

Type ParticleEffect Extends Effect

As I said before, I would like to implement a particle system to the framework. I often find myself using particle effects, so it would be beneficial to create a class that can automate this process.

Type Dialog

Again, I have already talked about this. This class with display a dialog over the top of a Scene to allow the display of information, or request a user response. I plan to make this pause the scene in the background, so it would be ideal for a Pause dialog or in game options menu.

Type DeltaSprite Extends Sprite

I haven't really had to consider delta timing in any of my projects yet, but I can see that it could be very useful for some games. I therefore plan to implement this soon, so that I have it in place when I need it. The DeltaSprite will not need as much processing from the scene object as it would handle movement and animation automatically, as well as the real-time velocity of the sprite.

It starts...

I have noticed that a lot of programmers seem to have personal blogs to record their progress with projects. This allows them to maintain a certain detachment from the business side of things, as well as blogging thoughts and ideas that may, or may not, make it into final products.

So that is what I have decided to do.

I also thought that today would be a good day to start mine as it is my birthday (Happy birthday me!).

For those who don't know me, I am the lead developer and designer of Krazy Pengwin Software. This is my own company which will focus on casual games for Mac and Windows, although I will be working and releasing other types of programs from time to time.

At present, I have two games released, both of which are freeware retro-remakes. The first is a remake of an old Oric game I used to play a lot called Mr Wimpy. The second was done as someone who saw Mr Wimpy said I should try to recreate the very unPC game Mr Wong's Loopy Laundry. Both of these are available to download from my site (http://www.krazy-pengwin.co.uk).

Currently I am working on a new game, which is based on the old Lights Out handheld game from the 80's. I have brought it up to date and added a few new features. I will post more about this in the future.

I also have in test a Rune Log program for people who use the Norse runes for divination. this is currently being beta tested. Again, I will post more about this later.

My primary programming tools are BlitzMax, from Blitz Research, and RealBasic from RealSoftware, so there will no doubt be plenty of references to these products. for the record, I am in no way attached or affiliated with these companies, so anything I say about them is based on my own opinions and observations.

Well, that's about it for the first entry. I hope you like what you read and find some of my musings helpful.