Making slow progress!

Yesterday I had my first asphma annoyance for around two years. Apparently the trees are trying to kill me! Well technically their pollen is...

Anyhoo I'm back on form today so thought I'd update things as they stand.

The grid class is looking better today. I had time to think about what I wanted to do and so managed to get it all straight in my head. The initial design document is done too so I even have a concrete end goal.

The grid itself will be a 5 * 5 affair. I may have to extend it based on if the battles turn out to be too easy. I also have a symbol weighting function that causes less of a certain type of symbol to appear based on how hard or easy things need to be.

Annoyingly, while writing this, I realise that I need to make allowances for special attacks when you get pick-ups that allow it and also when the bosses and harder enemies have their own special attacks.

Looks like another session at the lunch table where I refine the design document to add this information in.

Pro Tip: Make sure you add in all of the functionality and gameplay mechanics to your design document! Even if your game is tiny and you think it doesn't need a design document. It does!!

Back to the grind!

Ok so today, in order to get myself motivated for my next Indie project, I am starting a developer diary. As with all diaries. The trick is to simply do it. So hare goes.

Yesterday I decided to dedicate my lunch hour to actually starting a new game project. I need these distractions to keep me sane from the day to day of bug fixing and implementing other peoples ideas.

I have a basic concept that I am going to take to fruition and I've given myself three months to get a working game out there. I will be roping in the help of my good friend Jamie. He will act as impromptu game tester and critic. He's annoyingly good at finding bugs too.

So what's the plan for lunch today? Well first off a can of the old brown nectar (cola) followed by an hour of creating a simple grid system that can draw a set of pieces in a 5 * 5 grid. This grid will take up the bottom half of the screen when in the battle phase of the game. The top half of the screen (this is portrait mode currently) will display the scenario of the battle.

I will likely start this today and then get it finished this evening when I get back home. I'll add in some screenshots too if I can.

IOS Upgrades and Cocos2D

I've started converting some of my iphone ideas to cocos2d. I'm hoping that they will be simple enough to make the transition quick and painless. Of course we all know that converting stuff to objective C is never painless.

So far I have a couple of solid projects to do but, I'm starting with a few nice casino style games.

Yadddaaaaaaa!

Creating my first app

I've been fairly busy lately, what with learning to program for the iPhone and all that. I finally have my app idea ready and work on finishing it is progressing nicely. The only issue at present is that I still have programmer art.

I hope to get a few shots of the game up on the net soon. I just want to make sure that I am far enough along that I don't get my idea nicked. Hopefully people will like it but, you can never tell and it is quite frightening to have your work judged by others.

Once I have finished the game I will be doing a full postmortem of the project so that others can hopefully learn from my triumphs and failures along the way.

IPhones and IPods

Now that I have a mac I have been starting to learn how to code for the IPhone. This turned out to be a lot simpler than I first thought. The SDK is easy to get into and I found a great little book that talks you through creating a first real application for the platform.

I'm hoping to get a few apps out there soon, so that I can start to earn a little cash and move onto the self employed road. It's not going to be easy but, I'm really starting to hate working for the man. Not that my boss is annoying or anything. I just hate being at someone elses mercy.

Currently the only thing stopping me is that bills need to be paid and I need to atart seeing an income before I can confidently hang up the old day job hat.

Here's to hopes and dreams.

Quaternian Cameras and rotation

I have just had one of the most annoying coding sessions in recent days. It all started when I wanted to create a simple quaternian free roaming camera. Everything seemed to be working ok until I wanted to rotate the camera and have it move in the direction I had just rotated to.

Immediately the camera began moving on the exact opposite angle. So if I rotated the camera 90 degrees up, the camera direction vector would point 90 degrees down. Looking at the movement code showed no errors so what the heck was going on!

I finally decided that unless I was going mad.The error had to be with the camera direction vector itself. The direction was being set to view.forward and so I couldn't figure out how that could return an exact mirrored direction to the one that the camera was facing. It was only by chance that I noticed the direction was set not from the original matrix but from the inverted matrix. When I took the direction from the non inverted view matrix. suddenly my camera worked correctly.

The only puzzle now is why every example of a quaternian camera I've ever seen, seems to use the inverted view. Given I'm only ever adding the position to the normalized movement vector. I know that inverting the direction on that would definitely result in the camera moving in the wrong direction and at a mirrored angle.

Are other cameras using the inverted view and then simply un-inverting it again. Are they doing more math on the direction to change it from inverted to uninverted? Are they using an imaginary target and then creating a lookat matrix to that? Isn't all of that that silly? Doesn't taking the uninverted version in the first place (which will always point into the view) simply make more sense? What the heck am I missing?

XNA Community games

Work is now progressing at a nice pace on my community game. I have a solid theme set and now know what I want to include. It's good to be able to just code the parts of the game and not have to try to work out what to put in it anymore.

Today I am working on the shop section, where the player buys upgrades. I am going to put all of this into a diary so that I can take you through the entire process when the game is finished. For obvious reasons, I will not be doing this now as I have had ideas stolen in the past. It is never nice to see someone rip your idea as their own.

I hope to have some nice screens soon. I want to make sure that I am far enough along first though.

Back from Limbo

Ok so I haven't posted in a while as I have sadly been pretty busy. I have also been doing very little work on my game. My new laptop arrived though, so I can finally seperate my coding from my location. This should mean I get to do far more code and that means more blog diaries.

Stay tuned.

Collision detection and level design

Today I decided to add some collision detection to my game engine. I've based this on a sample, taken from a tutorial game, at the microsoft site. It is basically a box/ray collision detection system and I have simply expanded it to include sphere collisions. This fits into my plan for a simply physics engine that sits on top of the collision.

Later this week I'm going to be adding some basic visibility testing so that sections of the level are not drawn if they are simply not visible to the player.

That's it for this post. It's 4am in the morning and I'm pretty tired

GUI musings

Today I decided to flesh out my engines GUI system. I've decided to write all of the functionality pretty much from scratch. Partly to learn about game GUIs and partly to ensure that I can modify it without having to worry about how it affects others or any licensing issues.

Design wise I've decided to go with a GUIManager class. It handles the input listening, enabling/disabling and general drawing functionality. I want the gui system to be flexible enough to use for any 2D display, from basic information and control windows, to hud elements. This means that it has to know when to and when not to intercept the game controls. I can do this with a simply toggle switch, which will stop the listen function from being called. Crucially the control will still be drawn and the game can still manually update the values in the control (think health bars, energy readouts etc. etc.).

The first control I created is a simply bitmap background. This get's drawn before anything else and all other controls appear on top of it. I am also considering having this control able to contain the game output. Due to post processing, the game is effectively rendered to a readily available full screen texture anyway. Of course you can specify which region the bitmap takes up, so it's already possible to render two different player views and add then split screen to the display :)

This was the simplest control to write as it just blaps a texture to the screen using the rectangle specified. It doesn't care at all what the image is.

The next control I tackled was a bitmap button. This control allows me to use my art assets as buttons. I can assign images for idle, highlighted and pressed. In practice, you don't see the pressed image for more than a few milliseconds as this is usually what triggers a state/screen transition. To go along with this I implemented a simply button group system. This is based on the code provided in the microsoft tutorials but, with some heavy modification. The button group contains a list of buttons that have been assigned to it. It will draw all of these buttons but, only passes user input messages to the active button. User movement messages are used to step backwards and forwards through the list of buttons. Crucially a button group can contain other button groups and (provided you remember to map the controls correctly) stepping between them is hastle free. I currently have the top level group use the bumpers to step through the groups and the groups use the up/down on analogue or d-pad to move through their controls.

Finally today I created a toggle button. This turned out to be harder than I thought. Not because it was difficult to code mind you. It was made harder, due to my own short sightedness, when I created the button group class. I had hard coded the button group to only understand what GUIBitmapButtons were! I ended up having to go through the entire class and change each reference to a generic GUIWidget. I then had to expand the next and previous functions to cast the button to the correct type before using it. I thought about making the GUIWidget class encapsulate more of the basic functionality so that I didn't need to cast anything. This would ruin my interface system though, as I currently use a list of interface types to store all of the currently active widgets.

I may post a more complete description of my gui system for anyone who want's to role their own. I find that it's the best way to understand what's going on and to learn new things. You never know what you will come up with when you try to create a feature or function you haven't tackled before.

Re-Visiting My Engine

The above screenshot is a pleasant suprise to me.

It's now the early hours of Sunday and I'm doing a quick stock take of my exisiting engine code. I'm suprised to see that I have so far cobbled together a rather nice set of functionality. It's even more suprising, because the functionality is largely based on the tutorials and samples that are on the creators club site.

Upon firing up my engine for the first time in months. I was greeted with a fully functional menu system. You can use an XBox 360 controller (I had an old wired one that came with my core system) to move up and down the menu. Each item highlights and changes colour when selected.

I have implemented this system by using a series of self contained screen objects. Each screen is responsible for it's own content. They can utilise any of the classes of the engine to provide the visual or functional items.

I had created an interface that forces each screen to provide a known set of functions, namely load, unload, draw and update. This allows me to use delegates if necessary and also has allowed me to have a screen manager that simply loads or unloads each screen as necessary. The entire system relies on some global managers being initialised before any screens are drawn though. These sub-systems (as I'm now calling them) are the input manager, gui manager, the screen manager, the content manager and of course the game loop itself.

I currently have three screens implemented. The first is the obligatory kudos screen. This is the one that contains the logo images and does the usual skip to next logo, fade in/out and a simply ping sound effect.

The next screen creates a menu that links all of the actual game parts together. These are the continue functionality, the start new game functionality (which effectively just resets all states for the game to their defaults), the options functionality and the quit. So far only quit and start do anything useful.

All of this is a lot more than I thought I had. It means that I now have to start thinking about what I need to do next. All I know for the moment is that the game will have a mission based system, where the player (and later their squad of hand picked helpers) will go out and perform various tasks. To this end, I will need at least the following:-

* Mission generator.

* Map generator.

I know that I like the sound of having the game generate random levels. The only issue being that the levels need to remain the same throughout a single game, even if the player has sved and quit in the mean time.

Well, it's getting late and I need to sleep too!

Indie Development for the Masses

With the introduction of XNA by microsoft, I finally decided to get back into the indie development scene. Currently I don't have the funding to quit the old day job but, I am fortunate enough to be able to work from home most of the time.

I've always loved the Zombie game genre, so decided that I may as well create a simply zombie survival game. This will be my first independent i.e. solely me involved, piece of gaming fun.

It hasn't taken me long to knock up the start of a pretty decent 3D engine. So this blog will effectively be a diary of the trials and tribulations I go through as I create my zombie game and hopefully many more games to come. I should mention that I already work in the games industry so I know a fair bit about creating AAA standard titles.

Obviously as a one man band, I'm going to have to aim as close to that standard as possible without ending up taking years to make the game. To this end I have given myself 6 months to come up with a complete game. By complete I mean that all of the game logic and functionality will be complete, even if the visual and sonic aspects are a work in progress.

Well "Onward and upward" I guess the saying is.

Incidentally. If anyone want's to follow along, I am using the following stuff to create my game. All of it is free and should be readily available to you. I've deliberately chosen to go the free route so that any profit I make (unlikely yes I know) can be plowed back into my anorexic wallet.

1. XNA Game Studio version 2.0
2. An optional creators club licence (so that I can use my xbox 360 to run the game).
3. XSI6 Mod tool.
4. Visual C# Express 7.0 (XNA currently doesn't support the 2008 version).

That's pretty much it. I have a standard PC with an NVidia card 8800GTS and a core 2 duo chip.