Pre-planning your project

[medwayman]

You've probably seen my signature advertising the imminent arrival of my game Shapesteroids! How wrong I was...

My problem is lack of pre-planning and preparation. I found I'd missed out so many things from my various routines that I had to write additional ones to compensate. Tying the game together has been (and still is) the biggest nightmare. Again additional code was needed to patch up the numerous holes, and god knows how many new variables as a cheap fix.

I know how important pre-planning is but am always too eager to get stuck in to the coding - I wanna see things happen and quick! Never again. :angry:

All that said I have come through the worst and am getting there (I've just had a two player game and it's quite good fun) so bare with me, and soon you'll be playing Shapesteroids! Hopefully you'll think it ROCKS! Get it? Rocks...  :blink:  *Ducks to avoid volley of rotten tomatoes*

Anyway, the point of this thread is to get some good ideas from you guys as to the best way to pre-plan your project, and hopefully deter others from making the same mistakes I have.

[Digital Awakening]

That's called spagethi code and I think you know why :) This is the reason why so few actually complete a whole game. It's so easy to start coding and so hard to tie it all together in the end. Even if you plan ahead there will still be many things that you didn't plan because planning is probably even harder then completing the game. Often it's hard to imagine how everything will work and often you want to test things out first. The only way to deal with these problems is to get experience. With experience you will start to get the hang of writing more flexible code that will allow for far more changes as well as speeding these up and keeping them organized. And finally don't be afraid to rewrite large parts of your source, it can really prevent a lot of problems and actually shorten the dev time. But you do need experience to realise these things. Remember, stick with your projects until they are 100% done to learn the most out of them.

[kevin]

Anyway, the point of this thread is to get some good ideas from you guys as to the best way to pre-plan your project, and hopefully deter others from making the same mistakes I have.

   I hear ya!   :(

  Sadly, programming is one of the fields where we tend to learn by our mistakes.  We can read about it, swap theories about it, but until you've been slapped in the face by it.  Most of the theory never really sinks in.

  will post some tips later..

[Calypson]

well, I completely agree with everything you guys have said.  Another tip, as far as finishing a project goes, is to work with a devoted team.  If one person ends up slacking a bit, the determination of the other team members will get him to pick up the slack.  For any competition i've learned to work as a team, otherwise I lose determination early on into the game and don't get as much done.

I, being a visual person, approach pre-planning in quite a different way.  I start with pen and pencil.  First, I write down (in words) tons of random thoughts that are running through my head about the game.  these thoughts can be contradictory to eachother or unrelated, it doesn't really matter.  The point of it is to write it down before you forget the thought.  afterwards, you can organise the thoughts and make a few quick sketches of it.

this is an example of my thought page:  (lol, this is actually for this retro compo)

idea1.jpg

I then view the game as a finished product and start to sketch how the game would look like.  This way, all of the little details that normally wouldn't have been thought about untill way later on, get drawn in - thus making me concious of their existance.

here is an example of a sketch mockup:

mockscreen.jpg

here was the finished product:

mockishscreen.png

if your working with a team, where the artist and programmer is not the same person, its almost required to have such sketches.  This gets the point across much faster and more effective than words ever can, and it prevents later disputes in the process.  If you really want to make sure that the programmer puts all of the pieces together in the exact right way, use actual game graphics to make a mock up screens.

Here are some mockup screens of mine that never been made into a game yet:

demotiled3char.png


ightbardyOL.png

well, thats it for now.
-Dan-

[Digital Awakening]

That's some nice art and sketch Calypson. I've been using pen and paper more and more myself. I do not write down such basic things as main character etc, I keep that in my head. I think quite a lot about my games so I don't forget about them, it also makes planning easier because I work on it when and where I want.

I often make lists like for my Archon remake I have listed all the units for both sides as well as some preliminary stats and other info. I've listed the name of all the spells I'll be using in the game but only by name because it's quite easy to forget one of them. I've also done some quick sketches for the design of a few things that I've found a perfect design of like the clock you can see at the top of the game. It's quite complex so I didn't want to forget about it. Sometimes I do sketches just to see how things fits together, some layout stuff. Of course, if you are in a team it is far more important to dokument and sketch the things you plan.

[servogod85]

I like graphs and schematics instead.

Since I studied databases and my computer science preparatio was aimed toward goals that differ from video games, my approach to programming was less "artistic".


My method is the one that my professor taught me: The Jackson Method.

I won't go in depth about it but if you go to Wikipedia(www.wikipedia.org) and search for Jackson Structured Programming, it would hlp you have a more...say, organized approach to your problems.


Sal :)

By the way i used it to make my tic tac toe game, and if I knew PlayBASIC very well i could have easily completed the game in few days, considering that i work full time in a bank, so i feel that it is a powerful tool

[kevin]

This is HUGE subject, so here's a bit more mind dump.


Work With Your Tools - Not against them


- One of the biggest mistakes we can make is attempting to make our tools do something they weren't really intended to do.    I.e. No matter how many stripes you paint on an elephant, it'll never be a zebra.   In other words, Design your programs / games to suit the feature set of the language there written in.



What's a Data Structure ?

- Making games is all about managing information and lots of it. This information will represent the characters (or actors you might like to call them) without your game. This information is normally stored in Arrays and Types.   So it's important to spend some time learning about how to store and retrieving information. You don't need to be an expert, but having a rudimentary understanding will be a big foot in the right direction.

- Be prepared to learn the fundamental methods of manipulating your the character information. The most common examples that are how to Spawn/Create a new character, How to update (move) them and how to delete a character. This will allow the characters in your game to have a life cycle.   They exist, do something, and then die. Virtually every game you will ever write, will include these fundamentals.  

- Some Other topics that are well worth a bit of researching are  List management methods (stacks/ques/linked lists), Searching lists and sorting information.




I need artwork before i can make my masterpiece !

- If your just starting out, then you don't need all the art work/music first.   Even If your artistically talented (lucky you, I'm not!) then you might just slap a few 'mock up' elements together to start with.  Just enough to get an idea of how it'll all look together.   Invest your time into the mechanics of your game first.   Too often people devote hours to artwork/music, or even worse rope others into devoting hours to construct artwork, on the promise of making something great.  Only too abandon the project when they hit the first programming snag.

- If your not artistically gifted, you could perhaps use somebody else's media as place holders to construct a working demo.   You might have noticed that I routinely use artwork from XENON 2000.   Coz it's sexy and I can't draw  :)




Gimme da Codes !

  - Inevitably there will come a time when you hit a snag and need to ask for help.  Everybody needs some help from time to time.  That's what the forums are here for after all.   But this in itself can be problematic, a trap even, in particular for new programmers.  As all too often when given some example code to solve a particular problem   It's tempting to simply cut and past the solution code into their own project without having slightest clue how it works.   What's wrong with that ?.  Nothing if it suits the purpose perfectly.

   Where problems arise, if the user doesn't really understand how the supplied code works, as that's going to make debugging/adapting/ modifying it to suit their program difficult.  

   Since programming is all about Logic,  It's often better to relate a solution in terms of  logic,  then let the user implement those steps into their program.   The same applies when receiving a piece of code.  Rather than cut and paste it into your program.  Try and decipher how the logic of their solution works.   Once you know the steps the solution is taking, your then in a better position to bend the solution to fit into your program better.

   The biggest plus to this, is you Learn how to solve this problem if it occurs again.  So it becomes your knowledge and not somebody else's  
 



Demo, Demos and more Demo's

 - Don't always just settle on the first solution that comes to mind about a problem. Experimentation and analysis (trail and error :) ) can be vital to finding the right solution for any given problem.    

 - When experimenting it's best NOT to do this within your game. You can often create a mess of 'half working' solutions in your code.  You don't want that.    Instead create a separate project(s) where you can tinker around with particular ideas.  Then when/if your happy,  it's time refine the code and bring it into your project.




Just Rewrite it

 - Often the first revision (or couple of revisions) of any routine (section of code) are less than elegant, in other words while it might be functional, there generally not as flexible or perhaps optimal was what it might need to be.    Successive revisions can give us an opportunity to fine tune code over time.   Potentially weeding out things that might be problems in the future.




Don't waste time Optimizing the Input Code

   - Be careful. Optimizing can be a trap, you can easily waste valuable time, effort and more importantly motivation optimizing aspects of your program, that are not that time critical.   As it turns out, In the majority of projects, only a tiny percentage (10% or less) of your game code is really Time critical.   So if your going to optimize, don't guess. Analyze your program and see where it's really speeds the bulk of it's time. In most games, the updating the characters and character collision are often the most expensive.

  -Micro vs Method optimizing.

  Method opt's refer to applying a particular logic / approach to solving key problems. Often the overall efficiency of your program is directly related to how you've solved your programs problems.   Common bottle necks are things like Searching, Sorting & Collisions checking.  

  Micro opt's refer to tinkering with the command level functionality of your code, looking for those tiny speed ups that might win you back a equally tiny speed improvement.    

 Note:  Remember that heavily optimized code is often less desirable than  working code, as it'll more than likely be harder to manage in this state.


   

Tutorial: A Crash In Optimization

Style ?

  - When writing code, everybody has their own preferred style. There are various schools of thought on this, but if your writing code just for you, then lay it out & arrange it to suit you.  

    Even so, still try be and be consistent.   Use variable/array and function names that are meaningful to what they relate to.  The more abstract they are, the more cryptic looking a bit of code becomes.

  - Always comment your functions/code/  key ideas etc where possible through out your program.    While comments might not always be that useful while your working on a project,  they can be invaluable after you've finished or come back to a project after a long hiatus.    They simply improve the pick up and play nature of your code.

  - Meaningful & Grouped Names .  While I mentioned this before. Providing your variables/arrays and functions with meaningful, descriptive names can make programming so much easier.   In particular when your working with bigger projects  that manage many different character types.   From players, Aliens / bad guys,   through to bullets, inons and particles.   That's a lot of information to manage and you want  be sure your code is clear.  

  One nice way to group names into meaningful collections, is through using typed variables.   Which are accessible right across your program by default.    


  Picture this. Example   (we define a bunch of globals that represent the player)


 

PlayBASIC Code: [Select]

  ;  Define player variables as global 
      global Xpos,Ypos
      global speed#
      global sprite 

      Position(100,100)

Function Position(x,y)
    xpos=x
    ypos=y
EndFunction
;   etc etc
 

     


  This can made more meaningful via converting that group of related globals (imagine if you had 20 more of them ) into a typed variable.  This variable will house all these related values in the one spot.  Then each time we need to reference a particular group & value, we use it's group name (the variable name) as prefix, followed by the field.  

  Another nice feature is that if you type a field name incorrectly the compiler will throw an error.  


 

PlayBASIC Code: [Select]

  ;  Define player type fields  
      Type tPLayer
          Xpos,Ypos
          speed#, sprite 
      EndType 
     Dim Player as tPlayer

      PositionPlayer(100,100)

Function PositionPlayer(x,y)
    player.xpos=x
    player.ypos=y
EndFunction
;   etc etc
 

[Digital Awakening]

What's a Data Structure ?

- Making games is all about managing information and lots of it. This information will represent the characters (or actors yuo might call them) without your game. This information is normally stored in Arrays and Types.   So it's important to spend some time learning about how to store and retrieving information. You don't need to be an expert, but having a rudimentary understanding will be a big foot in the right direction.

Data storage really is important. Don't forget to use combinations of arrays and types, they make life easier:

Code Select Expand


psub resetunits()
  for x = 1 to 10
     unit(x).life = 100
     unit(x).mana = 100
  next x
endpsub


I need artwork before i can make my masterpiece !

- If your just starting out, then you don't need all the art work/music first. Even If your artistically talented (lucky you, I'm not!) then you might just slap a few 'mock up' elements together to start with.  Just enough to get an idea of how it'll all look together.  Invest your time into the mechanics of your game first.   Too often people devote hours to artwork/music, or even worse rope others into devoting hours to construct artwork, on the promise of making something great. Only to abandon the project when they hit a programming snag early on.  

Personally I find it much easier to code when I have the art ready. Music and sounds can always be added later. I'm not much for using placeholders although I've used some. I often make some images first and then code them in and then go back to the art again. Since I'm capable of making my own art, though I'm no expert, this is a process that works for me. I'm doing a lot of game designing as I go and having the art done allows me to see how they really fit into the picture.

What you don't need are things like character animations or art for every item you can pick up, items images really are things that can use placeholders or even colored boxes. These do not affect the code. You can still code your controlls, AI and inventory systems.

It's also very nice to see my game beeing made. Knowing that my game looks better and better for every part I add makes me more motivated to add more pieces. So basically I'm doing design, art and code at the same time. This is the way I feel comfortable to work but it won't suit everybody so find your own way.

Gimme da Codes !

   - Inevitably there will come a time when you hit a snag and need to ask for help.  Everybody needs some help from time to time.  That's what the forums are here for after all.   But this in itself can be problematic, a trap even, in particular for new programmers.  As all too often when given some example code to solve a particular problem   It's  tempting to simply cut and past the solution code into their own project without having slightest clue how it works.

This is the reason I don't post code for others. Programming is a craft, it takes time to learn and you really need to want to learn it. If you want to become a carpenter you don't start by making a piano. You learn how to use the tools and your first project may be a butter knife. That's how you should aproach programming. And asking for code never learns you how to think like a programmer.
 

Demo, Demos and more Demo's

- Don't always just settle on the first solution that comes to mind about a problem. Experimentation and analysis (trail and error :) ) can be vital to finding the right solution for any given problem.   

  - When experimenting it's best NOT to do this within your game. You can often create a mess of 'half working' solution in your code.  You don't want that.    Instead create a separate project(s) where you can tinker around with particular ideas.  Then when/if your happy, then it's time refine the code and bring it into your project.

This may be a good advice but personally I've never used it. That's why my early projects are a complete mess :D

Just Rewrite it

  - Often the first revision (or couple of revisions) of any routine(section of code) are less than elegant, in other words in might be functional but generally not as flexible or perhaps optimal was what it needs to be.    Successive revisions can give us an opportunity to fine tune code over time.

I remember in my early days of programming I could rewrite parts of my code multiple times. I remember rewriting a part like 8-10 times when I was learning how to code. What started out as lines and lines of code ended up taking only a handfull in the end.
 

Don't waste time Optimizing the Input Code

   -Micro vs Method optimizing.

I've not done that much speed optimizing in my days. I often only optimize to make code more flexible or shorter, that is making it better for me reading or using it.

I do want to point out that micro optimizing can have drastic effects on speed. For example I had this water waving code in my 3D game The Magic Land. At first I had the water updating every loop, that's 50 times/s. That's not necessary, simply by adding a counter I could regulate the water updates and by simply removing half the updates I reduced the workload by half using the same method.

Style ?

   - When writing code, everybody has their own preferred style. There are various schools of thought on this, but if your writing code just for you, then lay it out/arrange it to suit you.    Even so, still try be and be consistent.   Use variable/array and function names that are meaningful to what they relate to.  The more abstract they are, the more cryptic looking a bit of code becomes.

Oh have I done this mistake many times or what. I've been quite lazy typing variable names and I also don't like it when my lines get longer then what fits on my screen. I've learnt my lesson but I also have 1280px wide screens on both my stationary and laptop computers now :D Comments are also good but I'm still trying to get better on that part.

[medwayman]

First off I want to thank all of you for some great advice. You've put forward some great ideas I wouldn't have considered, so thanks again. :)  

That's called spagethi code and I think you know why

That description fits my code perfectly

This is the reason why so few actually complete a whole game. It's so easy to start coding and so hard to tie it all together in the end.

How true. Most of the problems don't rear their heads until later on in the project, and by then, there's so much code it can become overwhelming.

And finally don't be afraid to rewrite large parts of your source, it can really prevent a lot of problems and actually shorten the dev time.

That's something I should have done when things started to go pear-shaped. I'm at a point now where I think sticking with what I have is best, but that's only because I'm nearly there.

Sadly, programming is one of the fields where we tend to learn by our mistakes. We can read about it, swap theories about it, but until you've been slapped in the face by it. Most of the theory never really sinks in.

Exactly, as I said, I've always been aware of the importance of preparation, but it's taken this slap in the face to finally knock some sense into me.



@ Calypson

Wow, you're an amazing artist! While I can't match your skills, you've showed us how preparation can be fun. I used to enjoy drawing a lot. Perhaps it's time to break out that pencil set I got for Christmas some years back but never used.


@ Servogod85

Thanks for the link I'll have a good read of that later.


@ Kevin

Lots of good advice there thanks

I learnt to code in basic during the 80's so it's pretty much second nature to me, the trouble is I haven't really learnt much since. I tend to go looking for commands I need rather than learn what a new language has to offer. Again this all boils down to my eagerness to get coding and get results. Can you believe I've never used a type or a function! It's arrays and gosubs for me. And although these are fine for the job I'm missing out on the benefits newer commands offer. I find it very easy to learn anything I put my mind to, so how hard can it be to take some time to learn about types? Silly me.

I'm really glad I made this post, I nearly didn't. I wasn't sure if id get replies saying "My god that's obvious! Why are you asking?" or similar. Just getting it out in the open has made me stop and think. And that's not to mention the great advice you guys have offered!  

Thanks  :)

[kevin]

MedwayMan,

I learnt to code in basic during the 80's so it's pretty much second nature to me, the trouble is I haven't really learnt much since.

 Yeah, that makes two of us.   Although, growth is overrated you know :)

Can you believe I've never used a type or a function! It's arrays and gosubs for me. And although these are fine for the job I'm missing out on the benefits newer commands offer. I find it very easy to learn anything I put my mind to, so how hard can it be to take some time to learn about types? Silly me.

  If it works and your comfortable, then why fix it, if it isn't broken ?

  Types + Functions can certainly help us encapsulate and arrange our programs better in the long run.   But that's also fairly subjective, as it's equally as easy to write a rats nest,  with or without them.

[Digital Awakening]

You can write a game with only one loop and loads of if nests but that doesn't make it very programmer friendly :D

Functions can be replaced completly by gosubs but both have their advantages and functions can really uncomplicate things because they can be used in things like if statments: if userinput() = 0 then... and take variables: cooltext(x,y,"Hello Wrold!") and thus they are very reuseable.

Types aren't extremly needed though, you can always use regular variables or arrays, they do make the code easier to read and better organized.

[Draco9898]

Always try to make your code modular and re-useable: You name it. Text functions, boring tasks such as setting up FX sprites type of functions, Timers, Animation Data...The list goes on and on.
Don't try to make specific game routines modular, like say, code for makin an specific enemy do it's thing.

Types are a gift from god (for me at least.): Without these types I'd be making ugly, ugly arrays for enemies such as EnemyVars(20,200,20,10,20,3,6). You'd have to write the puppy down to disect what all the elements mean! Yuck.

[medwayman]

If it works and your comfortable, then why fix it, if it isn't broken ?

True, I've never hit a dead end just because I don't use the latest core commands. Although I do intend on writing some universally useable functions in the future.

Types + Functions can certainly help us encapsulate and arrange our programs better in the long run. But that's also fairly subjective, as it's equally as easy to write a rats nest, with or without them.

I do understand functions it's just I don't bother with them. Types are something id never looked at before although after a quick look they seem very straightforward, but I cant see any real advantage over arrays.  

Types are a gift from god (for me at least.): Without these types I'd be making ugly, ugly arrays for enemies such as EnemyVars(20,200,20,10,20,3,6). You'd have to write the puppy down to disect what all the elements mean! Yuck.

True, although I would use separate arrays for each element.

Can you believe I've never used a type or a function! It's arrays and gosubs for me.

Actually that's not true, I did write some functions for a JavaScript quiz I did last year, but as yet, not in  basic programming.

[Digital Awakening]

Types are something id never looked at before although after a quick look they seem very straightforward, but I cant see any real advantage over arrays.

If you are coding an RPG for example then types becomes very logical, mixed with an array:

hero(1).str = 12
hero(1).agi = 14
hero(1).dex = 9
...
hero(2).str = 15
...

See? It's very easy to read and write the code once you have your types :)

[medwayman]

I could be missing something here, but how is that any better/more logical than this:

hero_str(1)=12
hero_agi(1)=14
hero_dex(1)=9

hero_str(2)=12
hero_agi(2)=14
hero_dex(2)=9