[Disc] Game Designing / Building

[Robert Holland]

Hi Everyone
If you could please read this topic before reading:

view topic

I have done this design document for a game (attached to thread above) I plan to make with SAHMX and due to my lack of experience with flash and working with teams it would be great and interesting to see how everyone apporaches builing / designing games.

Thx Everyone

[Squize]

Hey Rob,

I don't think I'm best placed to answer this 'cause of the way I do things, but I'm sure the design doc and flowchart guys will follow me up and post the good way to do it

I always take the easy option and just remake old 8 bit games. There's such a vast back catalogue of games out there, all begging for a Flash makeover that you could do them for ever more.
Plus, you know the gameplay is going to work, when doing something totally original it can fall flat on it's face in terms of gameplay. And hey, I'm writing the games I grew up with, whats cooler than that ?

I always try and have a day off between projects ( Although that's blurring now. I hate having more than one thing on at a time ) and just mull over which game I want to do the most. Which will be the most fun to write, and thinking in purely nasty terms, which game will give me the routines I need for the game after ( Rather than thinking, "I'll do R-Type", I think "I'll do Ultra A / DKat, so the power-up code is in place, then to do R-Type I've just got to code the scroller" ).

On the day off I'll think about what specific routines will need doing, what parts will be a real pain ( And how to avoid them ) and then just start coding.
The more games you do, the easier it gets. You end up having a large amount of library code that you can just copy / paste between projects.

Couple of tips, that you only really learn through trail and error:

Code OOP. If you have to re-skin a game at a later date it makes life a million times easier. Also re-using code in other projects is easier if it's already laid out in a oop manner.

Deadline. Set yourself a deadline, and at the planning stage think realisticly what can be done in that time.
No game will ever be perfect, you can add to it for ever and a day, and without a deadline you will.
When I wrote X I really wanted a load of kick ass power-ups in there, but I knew it would push me over my deadline, so all the cool ideas I had went into the following game, Ultra A ( That was the sole reason for writing it,'cause I wanted ott power-ups ).

End of sermon.

Squize.

[Robert Holland]

Thank you for the sermon
I really do need to boost my code library, but I'm a bit thin on the number of games I've done but yes, OOP seems the best approach - thx
Since this is my first 'real' game will involve a lot of trial and error but hopefully I'll reach the peak of the mountain!
Oh and about deadlines, for a project of the size I proposed, do you set weekly deadlines? Or are they shorter or longer?

Thx again for your advice

[WilloughbyJackson]

Very nice advice ,Squize!

Thanks...

-pXw

[ScottTheFlashGuy]

I strongly suggest you read the thread Optimization Tips (search for it) before we start coding. It will help you greatly. Also, I won't have to go back and optimize everything later. I always, always, end up going back and adding a million "var " or something because I forgot to use those tips.

[Squize]

For the deadline, I meant for the game to go gold, not a load of seperate mile stones.
I can't see the point of letting design get in the way of actual development, and by setting mile stones you're just doing that.

If you're doing a game for a client, then you make sure the first things you do are the ones that create the most impact for them, the wow factor.
At times, just one routine can do that, or adding cool music or the main sprite.

Otherwise, just code whatever bit you fancy, in what ever order you fancy ( I like to have a title screen in place really early. I know it's weird, but it helps me set the tone of the game in my head better ) and don't think "I've got to get the collisions done by the end of the week".
More often than not you'll get stuck on them, and instead of banging your head against a wall, do something else in the game ( There's always a million things to do ). You can always come back to it, and it normally works when you've had a break from it.

I've got to be honest, I've not looked at your design doc ( I've still not set the mime types up in Firebird and I've been using it for months now ), but I'm assuming ( Hoping ) that it's a fairly simplistic game. Too many people dive in thinking cause they can do a tween that impresses their mates that GTA isn't much more effort.

Just break your game plan down into seperate chunks. Pretty much all action games follow the same pattern:

Presentation ( Titles, Game Over, hi-score input / saving )
Player movement
Player collision
Baddie movement
Baddie collision
World creation ( Level plotting, scrolling etc. )
Objective
"Glue" ( Level changing, scores, var resetting etc. ).

There's no great mystery to it

Glad you enjoyed the sermon Willoughby, although it's far from the best way to do things, just the way I work.
I figure other people are going to pipe up with their approaches too ?

Squize.

[tonypa]

I never had any plans or documents for the games. I just have some idea (usually feels absolutely great in my mind) and I write a bunch of code to make it work (usually changing the original idea into something else).

[WilloughbyJackson]

I'm practicing my design document writing style since I'm probably going to have to write some for work soon.

For personal use, I usually write out notes on what I want to do, and what functions might do it for me, what variables might work.

Then I do some sketch work, to know the number of animations I will need and the look of everything.

Recently, I've been using the code style of a former professor of mine. He would type comments about what he wanted to do BEFORE coding.

I find this useful because I can skip over steps I think aren't necessary and return to them later.

-pXw

[nGFX]

and here: my 2c ....

you can't betatest your own code !

You can (and must!) alpha-test your own code, to make sure it does what you intended it to do, and to spot all the errors you can. But in a thousand little ways, not to mention a few big ones, you will fail to notice problems that others will stumble over.

- lessons learned the hard way

[Squize]

Good point olli, beta testers are worth their weight in gold.
Make sure you have your core testers, and just use the board near the end of a project so your game can be tested on a zillion different configs.

Squize.