New web site is up

I have completely failed to keep you all up to date with the latest development news from me.
A few days ago, my new games development web site went live. Even if I do say so myself, I think it's pretty cool. The entire site is coded by hand (apart from the Lightbox scripts). I prefer to create my own sites this way, so that I have total control over the content, without relying on, or being limited by, a third party content management system.
Anyway, if you want to have a look (and I know you do), then hop on over to: http://www.krazypengwin.com.
Second bit of news, probably not as impressive, but I think it is equally important, I have made some changes to the Colour Code Generator I mentioned before. It is now possible to drag and drop colours from the custom colours to the main colour button, and vice versa. It is also possible to use drag and drop to reorder the colours in the custom section. A little more important, I have added the possibility to drag and drop a colour from the application directly to the source code, and it will insert the colour, in the format selected, into your code. Not a massive change, but it could be useful and save a few seconds, rather than having to click Copy and then Paste. Some more formats have also been added, so the colours can now be formatted for the following languages: Monkey, BlitzMax, Xojo, Cocoa for OS X, Cocoa for iOS, Lazarus (and Delphi), Python, HTML, CSS and as either a list of decimal or hexadecimal values.
This little tool, along with some of the others I have written, will be available from my web site once I have written the help documentation.

Yet another in house tool created

Not been long since my last post, but I thought you all might like to know about my newest in house tool that will save me a lot of time in the future.
First of all, the reasoning behind it: both Monkey and BlitzMax have the facility to import animation strips for using with your sprites. These are images which hold all the frames of a particular animation, so that you can load them at once, rather than having to load multiple images, which is a lot slower.
The concept behind it is dead easy, each frame of the animation has the same height and width, and therefore, the image is easy to break up into the individual frames as the animation progresses. The downside of this is the time it can take to manually create an animation strip, particularly if you have a lot of frames, it is not uncommon to use 15 separate frames just for walking in a single direction. Below is an example of the animation strip I used when I created Mr Wong's Loopy Laundry:

As you can see, there are 59 frames to animate Mr Wong. I created this by hand and it took quite a time.

So, to help ease this process, I have written a small program I call Image Stitcher. I guess you could call it the sister program of Image Slicer. What it allows me to do, is import each of the frames, select the output height and width of the frames (in case I decide to enlarge or shrink them), the drawing style (scaled - maintaining aspect ration, stretched or cropped) and the number of columns in the animation strip. This is then exported as a single image, like the one above.

As you can already see, this is a massive time saver, that will hopefully save me hours of work.
As with my other tools, it was written with Xojo.

New tools

OK, time for another update (already!?).
I have been in the process of developing some in house tools that will help me write the games. I generally create tools as and when I need, or want, them. I could probably go to the App Store and find other peoples versions myself, but I figure, why pay for them, when I can write them. After all, if you are a plumber, you don't call someone in to fix the sink.

So I thought I would show them to you, just so you don't think I've been idly sitting on my arse.

These are obviously jus the icons that our amazing art department (erm... me) created. I shall go through each of these in order.

First up, the Colour Code Generator:

I don't know about you, but I hate having to work out colours and insert them into the source code, or web page. So this little tool allows me to select a colour, using the standard OS X colour selector and it will then display the colour codes in decimal and hex, as well as a source format of my choosing (at present, it will display code for Monkey/BlitzMax, HTML/CSS and Xojo/RealStudio). I can then click copy which will copy the source to the clipboard for pasting into my source code. If I already know the decimal or hex codes, I can enter them manually and it will adjust the colour accordingly. It's a small app, but quite a time saver.

Next, Database Analyser:

This is quite an old tool I wrote some time ago and it is a major headache remover when developing database applications in Xojo.

The analyser will load an SQLLite database file that has been created in the Xojo IDE and kick out the source code required for Xojo to create a new database file on the fly with the same structure. If you have designed quite a large database, this can save you, literally, hours of coding time, converting it to source code.

Font Builder:

Although the Monkey language is ideal for writing cross platform games, one of the areas where it is lacking is font and text support. In fact, it virtually has no font support. So to remedy this, Font Builder allows me to create a PNG image file of the required font and it also exports a definition file that is then loaded into Monkey (using my own custom class) and the font can then be used within the game. But, it is not limited to the standard TrueType fonts that come with a Mac, nor just to those that are downloadable. Because the Builder uses PNG images, it is also possible to create your own fonts, in colour, for your games. This can allow a much more vibrant screen display, without having to create a bunch of extra image files.

Image Slicer:

Working on my current game, I came upon a few limitations in Android that prevented me from using large images effectively. I also noticed that some of the images I was  using were pretty inefficient, memory wise, as there were large areas of transparencies in them. Image Slicer allows me to slice images in a grid pattern of my choosing. I am also able to select which slices are to be exported and which are to be ignored. This way, I can more effectively manage the memory usage of my games and also obtain a few speed enhancements.

Finally, Max Debugger:

I have shown this one before. As I do most of my coding in BBEdit, rather than the Monkey or BlitzMax IDE's, I needed a way to debug my BlitzMax games without having to fire up the IDE. Max Debugger is just that, simply a debugger for BlitzMax games.

I do plan to enhance this further at some point in the future to also act as a debugger for Monkey and to allow remote debugging for multiple platforms.

All these tools were written with RealStudio (I haven't actually upgraded to Xojo yet) and compiled as Cocoa apps.

Wow! Seems like months since I last posted anything here.

Oh, wait. I HAS been months!

So, what have I been up to in the world of programming?

Well, I have begun work on some new games under the Krazy Pengwin Games label. I'll post some more news about them soon.
I have switched game development language to Monkey. This is also by Blitz Research, in fact, it can be seen as the little brother to BlitzMax, but it has a neat little trick that BlitzMax did not. Whereas BlitzMax was cross platform, allowing me to compile to Mac, Windows and Linux, Monkey goes even further. With a single source project, I can create games for, not only the desktop operating systems, but also for Android and iOS. Monkey also supports XNA, but I'm not too interested in publishing to that platform right now. So the upshot is, the games I am working on will also be available to mobile user, firstly Android, but hopefully iOS by the end of the year.
I'm still using RealStudio (now called Xojo) for in house tools, but not much in the way of commercial applications. Once my new web site is up and running, I will be making some, if not all, of these tools available for free download.
Well, that's it for now, so just watch this space for details of new games and stuff.

Comment About Comments

After posting my last tutorial, someone made a criticism, or rather an observation, about the coding style I have been using. I will be the first to admit, they are quite right in what they said, too.

I failed to use any comments in my code. I should have commented. No matter how small the piece of code you are writing, it is always advisable to put comments in your code. This can save you a lot of time in the future, especially if you haven't worked with that piece of code for some time. Even one line of code can cause a programmer to stop and think, if it's not too clear on it's function.

So, my apologies to all. From now on, I shall ensure that I place adequate comments in the code, as well as the explanations of the code function in the blogs.

Back to work

Christmas is finally over and after a slightly extended break from coding, I am back at it.
I am revisiting an old project that I abandoned last year, Senet Collection. This time, I am using my framework, which is allowing me to concentrate more on the game, rather than the mechanics, although I have found a bug in the framework that causes labels to shift when a dialog is displayed over the top. Not sure what is causing this, but until I can find the problem, I have created a work around solution.
"What is Senet?" I hear you cry.
It is thought to be the forerunner of backgammon, as played by the ancient Egyptians. Unfortunately, the actual rules of the game have been lost in the mists of time, however, several people have attempted to work them out. In light of this, I have decided to create my computerised version with four sets of rules, as created by Gustave Jéquier, Timothy Kendall, R. C. Bell and Professor John Tait. There are other variations, but I will be sticking to the four mentioned.
Here are a couple of screen shots to wet your appetite.

Light 'Em Up Complete

I have just finished the coding of my new game: Light 'em Up.

This is based on the old hand held game Lights Out, but I have added a few extra twists.
I have a few minor things to attend to, before this one is released, but for now, here are some screen shots:

Many thanks to Matt McFarland for the awesome tune, "Street Lights". Find Matt and more amazing music at www.mattmcfarland.com

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.