Prototyping a Game

I love prototyping a new game. However the prototype is not where the development of the game really started. Heck I don't start coding till I already have a good idea of how all the gameplay and fun will be attained. So the prototyping in reality is the realization of the fun gameplay ideal I have in my head, or on paper. It is more the proof of concept than the idea itself, it is also not a full game.

So once I have the idea of the game in my head I tend to put it down onto paper. This is not always a set regimen either, it varies how much I write on the type of the game and most importantly my familiarity with the genre. Shooters for example I tend to write less, but platform games I will write more.

Once on paper I start deciding how I will code the game if I go ahead. This always leads me to start actually coding the game and therefore the prototype. The prototype can be simple as well, as I only really need to prove to myself that the game is viable. Sometimes the control will simply not come along nicely and I will then abandon the prototype. If as is usual the control scheme feels good, then I get all excited and need to move along as fast as possible.

This is when it is exciting as I code in the details of the game to expand the prototype and start in on making it a complete game.

Laters
Da Voodoochief

Bit of Side on action

So I was busy last night. I was also quite strict with myself and only did about 15 minutes of programming and I was happy, because I proved to myself that what I wanted to do was gonna be fairly easy and pretty fast. Then in a rare show of mental fortitude I left the coding.. and turned off my PC.

Then I went back to the design, which I also carried on while at El Pollo Loco today at lunch time :)

I know, ya thinking HOW do I do the design work while my PC is turned off, and also ho at lunchtime while out. I'll bet ya even thinking I am using a Laptop, but I am not. In fact... I am using an age old technique I have used for more than 30 years designing games.

A Pen/Pencil and paper.

Shocking isn't it. Of course this does mean that all the stuff I have written so far will need to be typed in at some point. But I have a secret weapon that is my wife, and she types ten to the dozen i can tell ya. So no worries from me on that one. I also use paper as i tend to do a lot of simple drawings to flesh out what I am writing about. Those I sometimes scan in.

This is currently what I have for me code. Once agai using CombatEva and a very odd forward shuffling motion. In this picture I am showing our Hero moving forwards (except i cannot see any movement, cos i have no visual queues at the moment (SCOTT!), that was a shout out to my artist :). He is moving across the screen and the camera is following. Except in reality I will conveyor everthing to him instead of him moving forwards. That ball ya see on the floor is CombatEvas head texture on a ball that Scott made for me. It sort of rolls around at the moment and is boring. Though Eva looks like she is about to drill it with a big footy kick, yeah!

So the game obviously will have a bit of side on action, though it will also have otehr angles to play with.

well that's all for tonight. I am gonna write something else in the design now. Cos i am too excited to go to bed and sleep (Me and me mate are going Off roading on our off road bikes tomorrow, Yeah Baby!!).

G'night all,
Da Voodoochief

Clean up that code sonny!

Although i haven't had much time for my own stuff. I have been twiddling with the code a bit here and there. One of the jobs i am doing that does not usually require a lot of hours at any time is to tidy up my code.

Tidying up the A Shooter code is quite interesting, as i do not really remember the bits of glue code i had to write to make some stuff just work right. However as i look through the code i see parts where  some gameplay elements coordinate systems are being translated into the main coordinate system (the 2d one the sprites use). This is sort of fun tidying up this annoying things.

However one must have a plan to tidy things up. Simply changing this badness for other badness is not a recommended solution to anything. Let me give you an example of one of the main things i found annoying about A Shooter code.

In A Shooter all the sprites are 2D. They have an X/Y postion and width and a height. simple enough and it shouldbe always simple. There is a question about where to do some of the Width/2 coding though. for such things as detection. Or target to fire at coordinates. so a lot of my code would look at the player and add onto the X/Y coords the half width and half height offsets to shoot at the center of the player. Again that is simple enough in and of itself. However you also need to fire from the center of the Alien itslef. Aho! another X/Y pos plus half width and half height. We have now done it twice. Well then it gets worse. You then have to detect the hit boxes against each other also doing the very same calculations. So now we are up to 4 at least. There are other systems as well that interface with all these coordinate offsets. I knew there was a simpler way, but by the time i realised it was a problem i was too far down dev road to turn back.

The simpler way is to just draw the sprite with an origin set to it's center. Though this is great for A Shooter as it used mostly Radius checks for collision, it is not so good for box detections. If you are doing box detections, then you could of course keep your origin in the top left corner and just use the width and height for you box extremies.

What does this all mean ? Well it really means you should know which way is best for your style of game. Then work out how many different times you will be doing such calculations. You could even make a nice simple function to wrap the hideous offset adds in, and that might make ya feel better.

Myself, i am going to move the origins into the middle of the enemy and player graphics, and then use offsets for what i need from there. Simply because i KNOW for sure where the thing is, i donot have to do a math quiz to figure out how close i am etc.

g'night

Game and Menus systems

I have been rewriting the way my game is put together.

It is a royal pain in the butt, though i believe it will be worth it. ya see i have a hybrid system in place that another programmer i was working with introduced into my base system. Then he never quite got to finishing it all and i did finish it, only not quite consistantly (it wasn't my vision after all). so now i have decided is the time to do the big change i want.

Simply put i want to
Separate out the Menu system from the Game system. They can converse through some nice function calling to tell each other what is happening. One of the main reasons for doing this change is that i really want my options screen to be able to appear while the game is running underneath (though paused i am sure :) ). I cannot do that the way things are in A shooter. It is work and doesnt feel like i am being very productive with the small amount of time i have. However it will make my future stuff more consistant and i believe faster to create.

I now have all the menu code ripped out and introduced a much more succinct naming system for acessing other classes etc. Getting it to compile was a pain, as i am used to C and C++ and just cos C# says it doesn't have headers, it might as well. It's all the freaking same in the end.

Anyway, time for bed for me.
G'night