UnderwareDESIGN

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.

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.

QuoteAnyway, 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..

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)
(http://www.underwaredesign.com/screens/PlayBasic/Tutorials/Dan_Jack_Steele_Tutorial/idea1.jpg)
idea1.jpg (http://img.photobucket.com/albums/v169/calypson/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:
(http://www.underwaredesign.com/screens/PlayBasic/Tutorials/Dan_Jack_Steele_Tutorial/mockscreen.jpg)
mockscreen.jpg (http://i32.photobucket.com/albums/d38/Indigortfolio/Mock-Ups/mockscreen.jpg)

here was the finished product:
(http://www.underwaredesign.com/screens/PlayBasic/Tutorials/Dan_Jack_Steele_Tutorial/mockishscreen.png)
mockishscreen.png (http://i32.photobucket.com/albums/d38/Indigortfolio/Mock-Ups/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:
(http://www.underwaredesign.com/screens/PlayBasic/Tutorials/Dan_Jack_Steele_Tutorial/demotiled3char.png)
demotiled3char.png (http://i32.photobucket.com/albums/d38/Indigortfolio/Mock-Ups/demotiled3char.png)

(http://www.underwaredesign.com/screens/PlayBasic/Tutorials/Dan_Jack_Steele_Tutorial/fightbardyOL.png)
ightbardyOL.png (http://i32.photobucket.com/albums/d38/Indigortfolio/Mock-Ups/fightbardyOL.png)

well, thats it for now.
-Dan-

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.

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 (http://www.wikipedia.org)(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

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.


   


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)


 [pbcode]
 ;  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
[/pbcode]      


  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.  


 [pbcode]
 ;  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
[/pbcode]

Quote 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:


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


Quote 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.

Quote 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.
 

Quote 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

Quote 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.
 

Quote 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.

Quote 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.

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. :)  

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

That description fits my code perfectly

QuoteThis 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.

QuoteAnd 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.

QuoteSadly, 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  :)

MedwayMan,

QuoteI 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 :)

QuoteCan 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.

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.

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.

QuoteIf 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.

QuoteTypes + 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.  

QuoteTypes 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.

QuoteCan 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.

QuoteTypes 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 :)

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

QuoteI 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

[snapback]8279[/snapback]

Because you can define it quickly like this:

Type tHeroes
  XPos#, YPos#
  Dex, Str, Agi, Int, BattleSpd
  SpriteUsed
Endtype
Dim Heroes(25) as THeroes


Instead of this:

Dim Heroes_XPos#(25)
Dim Heroes_YPos#(25)
Dim Heroes_Dex(25)
Dim Heroes_ Str(25)
Dim Heroes_Agi(25)
Dim Heroes_Int(25)
Dim Heroes_BattleSpd(25)
Dim Heroes_SpriteUsed(25)


What if you needed to quickly add another varible? This could get sticky, quickly.

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

 Nah your right, functionally they serve much the same purpose.  Even behind the scenes it's only a tiny but different, mainly as types hold their fields in cluster.  Much like a 2D array version of your example say.   Where index 1 is the object and the second is the field your accessing.
 
ie.

[pbcode]
  Constant Hero_Status=1  
  Constant Hero_Xpos=2  
  Constant Hero_Ypos=3  
  Constant Hero_StructSize=4
  Dim Hero(NumberOfHeros, Hero_StructureSize)
 
  Syntax wise the typed version is perhaps more elegant to some.  
  Type tHero
        Status,Xpos,Ypos, etc
  EndType
  Dim Hero(NumberOfHeros) as tHero
[/pbcode]


  There's a few advantages I guess, it really depends upon your perspective.   It's a style thing if you ask me.


  *)You can copy/move types  using the CopyArrayCells command, while it's far from an elegant command. It does allow you to copy the whole thing in one line. It doesn't matter what fields it has.

  *) you can delete an entire type using ClearArrayCells.  if you pass CellArraycells a typed array, and fill any index with zeros, it'll de-allocate whatever type data was at this position, thus deleting the type.

  *) You can find free types (those who haven't been allocated yet) using the FindArrayCell() function.      



Ie. in the following example, the functions are being used to construct your own 'command set' that deals with the Heroes in your game.   This is sort of layer of code that props up what's above it.   The more robust you build the base layer, generally the easier it gets to build the game on top of it. Well, that's the theory :)

 Ideally the function set layer is used to completely abstract the arrays behind them, so rather than dealing with the array directly, you end up calling a simplified function set to control the characters.  Where you might have stuff  PostionHero, Movehero, animated etc functions.    

 There's a few benefit of this style of approach, as by abstracting the underlying arrays & data structures, our "Game Engine Code" is no longer dependant directly upon data structures or PB command sets for that matter.   Since all the required functionality of the characters is wrapped/hidden away inside the functions for us.

 This can really make the game engine code much simpler, and far less effected  by changes made to the arrays underneath.

  So imagine this type of layering,

 > Game Engine Code  

  ----->  Character function Layers

  -------------->  The arrays/low level variables each function layer encapsulates.  Ideally the game avoids using this directly


 Then in future projects, This approach could assist you via being able to simply import/grab (cut and paste) your Character Layers into a new project and just start work on the new game engine virtually immediately. Obviously it depends upon how specific the character layers are created though.  But you get the idea.



[pbcode]

Type tHero
    Status,X#,y#,Speed#,score  
EndType

Dim Hero(10) as tHero


Player1=newHero(100,200)

etc


Function NewHero(x,y)
   Index=GetFreeHero()
   If Index<>0
      Hero(index).Status=true
      Hero(index).x=x
      Hero(index).Y=Y
   endif
EndFunction  Index

Function CloneHero(SrcHero,destHero)   
; whis will clone whatever type data is at the src position
; into the dest position.  If the destination wasn't empty, it
; be cleared (de allocated) for you.
  CopyArraycells  Hero().tHero,SrcHero,1,Hero().tHero,DestHero,1,1
EndFunction


Function GetFreeHero()
; make the function get the size of this array for us
  ArraySize=GetArrayElements(hero().thero,1)
; search from index 1 to the size of the array, stepping
; forward 1 cell at a time.  If a empty cell is found
; it will return the number steps it took, not the position
   FreeIndex=FindArrayCell( hero().thero,1,1,ArraySize,0)
; If a cell was found add on the start position
  If Freeindex<>-1 then inc FreeIndex  
EndFunction FreeIndex


Function DeleteHero(Index)
; clear this cell within the array, which will force PB
; to be deallocated it.   It avoids running through and setting
; all the fields to zero or null again.
   ClearArrayCells  Hero().tHero,Index,0,1,0   
EndFunction

[/pbcode]


 Another advantage that comes to mind occurs through using functions & subs however, where it's possible to build generic functions that can operation upon, not only the parent typed array, but it's children (others types derived from it).   To do this you pass the array into a function.  Providing your passing an array that either matches the receiver or is a descendant of receiver, it can be passed.   This function can then operate upon whatever its given.    Have a look at the Linked List code i posted the other day.  It uses this approach.
 

 Now I fully realize you can do all of the above with arrays too.  Hence it's all subjective.  


 For your current implementation, you can probably utilize array passing.  And get much the same benefits.   Ie. a bit less code in places  


  Current i'm guessing there's some code that is virtually the same, but based on different arrays.   Like finding a free object (of whatever type) is one that comes to mind.  

 I.e.

[pbcode]
 Dim Hero_Status(maxHeros)
 Dim Hero_Xpos#(maxHeros)
  Etc etc

 Dim Alien_Status(maxaliens)
 Dim Alien_Xpos#(maxaliens)
  Etc etc


  Gosub FindFreeAlien
  Print FreeAlien

  Gosub FindFreeHero
  Print FreeHero



FindFreeAlien:
    FreeAlien=0
    For lp=1 to MaXAliens
       if Alien_status(lp)=false then FreeAlien=lp : Exit
   next
return

FindFreeHero:
    FreeHero=0
    For lp=1 to MaXHero
       if Hero_status(lp)=false then FreeHero=lp : Exit
   next
return
[/pbcode]


 If you had something like this, you could write a generic function that accepts any 1D array and will search for a free (set to zero) Item.. Like this

[pbcode]
Function FindFree(SearchArray())
    For lp=1 to GetArrayElements(SearchArray(),1)
       if  SearchArray(lp)=false then FreeIndex=lp : Exit
   next
EndFunction  FreeIndex
[/pbcode]

 now you can use it to scan for free Heros or Aliens, or anything else

Ie.

 FreeHero =FindFree(Hero_Status())
 FreeAlien =FindFree(Alien_Status())



Update (10th,Oct,2012): - Some of the advice given here has been superseded by modern versions of the PlayBASIC.  Today, it's generally more optimal to use TYPES because the modern versions of the PlayBASIC compiler include Type Caching features. 

Sorry for late reply – I took a break from the PC

Thanks for the tips Kevin some useful info there :)

Thanks to everyone else for your input :)  

I wasn't trying to start a rebellion against types ;)  I will use them, and who knows, maybe I'll be converted. :)

medway:
I did what you do before and I guess the main reason I switched was because hero(x).str is both easier to read and write then hero_str(x). At least on a Swedish keyboard I have to use shift to get _.

It's also nice when you want to change the size of the array. You could have a list of all cards a player has in his deck, when making a TCC etc. When the player draws a card you remove that post from the array (which is treated like a list). When it has to be shuffled you shuffle the list etc. Maybe not a great idea because you would probably just store a card ID number in a regular array and then use a different one (typed that is) to get all the info about the card. But you get the idea :)

This is one of the most interesting threads here!

I know from experience about putting a full game together. I used Amos on my old Amiga (And Amiga Basic Before that --What a nightmare), and although I started 25 programs. I really only completed 2 games and a paint program with a Map utility. ::)
The best thing to do is get yourself a pen and notepad and plan out the game first complete with a long list of graphics you will need. Then do the graphics, and then and only then do you sit down and write code. And thankfully someone took the time to write a number of examples and tutorials to work off. ;)
I am sill at the code learning stage but all the game ideas are still in my head. It will be awhile before i am sitting down and writing code.

Very good thread with lots of good points!

I can speak from professional experience as a games programmer that pre-planning is critical to any successful software development project, and especially game programming.  I half suspect that Kevin P. has a similar background as much of his advice and examples pull from industry accepted norms.

Abstracted, data driven functions, game engines, and tools are essential in any commercial endeavor that wishes to turn around and re-use the major investment made in this code for the creation of subsequent games.  While this may not be the perpsective of a hobbyist game programmer, the discipline and experience that comes out of approaching software development this way are invaluable on many levels - and who knows, your next 'hobby' game might catch the eye of some industry gaming house and suddenly you are a part of a professional team of developers on a commercial product - it happened to me...it can happen to you too!

I'm probably like most other game programmers out there and I love to SEE something exciting on the screen FAST!  It takes alot of discipline (there's that word again!) to slow down and lay down good design work on which to begin building your game engine and tools.  Fortunately I enjoy tool programming as well, so that part is not as painful as others might find it.  In the end, (and it's always hardest at the end!  read: working 16-20 hour shifts on deadline while the company has contractual financial penalties every day the gold disk is late!) it is so much easier to go back and fix bugs or tweak actor behaviors or add little goodies when you are working at a higher, data driven, abstracted layer, than having to hunt through every internal variable to fix or add something.

(steps off soapbox)...

Anyhow, this is a very worthwhile thread and kudos to all those who have contributed!

Cheers!

       Regardless of background,  there's just so many factors that stand in the way of budding game developers.  It's actually rather surprising how many are produced at all.  While the quality varies,  even the most mundane games takes a  level of commitment  to complete.  Which is probably one of the biggest factors.  Developing games for a passion is one thing, but out of obligation is something entirely different.         

       Ignoring media / skill (experience),  developers need to sort out their tool set early on  (language/mapping/animation/collision/lighting/Physics/AI etc etc ).  Identifying the base potential is important.   So we need to find what's strength and weaknesses these tools have ?   This is important for the design process, so conceptually we can design projects that fit the tool set from day one.   There's no point trying to force a square peg into a round hole.  No matter how much fun that is :)

        The temptation is to run off now and start building your final vision.  Some people can do this really well, not me however.  I find that once the tools are sorted,  it's important to flesh out your game layer.    Regardless of the language you're using, you can be assured it won't work entirely how you want it to.   So by building some base function sets, we can abstract our game code from the language underneath.    The idea is that these layer(s) of code are generic enough that we use them project to project.  Think of them as a quick start frame work that connects all the components together.    Over time this frame work will  evolve as our ideas/skills evolve. 


        Ok so that  probably sounds like a lot of work to just get to stage one,  but the idea is that we can save ourselves  time and effort by streamlining the process before we rush out and start our next behemoth.  Once we're happy,  then  start  prototyping our base ideas using our kit.   Initially this is where a lot of hiccups are discovered, these might be things with the tools, your game layer, or just unforeseen complications.  Whatever the issue, it's up to you to choose the path forward.  Be it solve them or just accept them as limitations and move on with your design.    Of the course the latter might indeed rule out some features of your game.  It's always going to be compromise.. We can't do everything !

       Once you've built a working prototype to show your design works.  Then we can start seriously looking at the building the game itself.   As the programmer, It's so tempting to hardcode all the functionality into the actual game engine  (maps/layout of characters/specials/high sores/ etc ect).   This is a huge mistake (since this makes the programmer the keyman!), Rather we want to build the game so that it can play whatever  level we want it too.     So while the programmer's) will most likely  build in custom code control enemies behavior for example through the game world.   The layout and world space should be done externally.   Sometimes this is achievable from generic tools, but you'll often need to build a simple (no frills, but functional) tool to drop characters/set times/bonsus etc etc  into worlds/levels.   This way anybody in the group (or externally)  can contribute to the content creation process.     

       Imagine your building an Arkanoid clone with 100 levels say.   Sure you could use data statements and layout them out internally in the code.  But no matter how much you love your game, this is going to get old real fast !   Hence,  if we make a simple  external editor, we can share this work across the group.    Not only that it opens up the door way for to build expansions at some latter date.   

       The point of this ramble is just to re-iterate the importance of design.    The bigger the project, the more important it becomes.     



    Note: Is a post from a similar discussion on the TGC forum.

Do any of you use todo lists? I have to admit that when I start a project, I don't ever really do any planning (that's why I have't finished a project yet) but after reading this thread I can clearly see how important it is and I have picked up some good ideas that I will try to put to use.

Are todo lists important? If you do use them, how indepth do you make them? Do you use any software for your lists or is it just a case of having pen and paper to hand to makes notes and to update your list?

recently, ive found it easy to decide on a goal i would like to accomplish for the day after ive woken up. This could be something simple like implementing a means for spawning or removing an npc to something more complex such as a specific behavior for an npc.
Then, during the day, i would pace myself so that I would be able to reach this goal. The object of this is to keep the workflow moving so it doesnt become still. If you work on something, no matter how small it is, you've still worked on it, and so you keep yourself conditioned towards completing it, and sometimes doing something small will motivate you to continue working and end up doing alot.
this doesnt mean just do all the simple easy stuff. you should still try and do the harder stuff which you might want to be holding off on, but if you take it piece by piece, eventually you find yourself not thinking about the task, but rather what you are doing.

as for planning, if I plan, I keep it simple initially and I also try to define boundaries which I should not pass, because most times i tend to overcomplicate things, and by defining limits, i know when i might be overthinking something or causeing more work than i can handle. Theres nothing wrong with planning as long as what you plan does not impede upon your ability to finish.
Sometimes it helps to think how to make something easier/simpler/less work.
Don't think about how to make something cooler, or more complicated, especially if you haven't completed anything in the past. You should be thinking about what you can do to make it easier to complete, because completion is much better than something complicated that never gets finished or get abandoned.

I too set small goals for each session - only after I complete a goal am I happy. To do more is just a bonus.

Remember, sometimes complicated looking effects can be done easily - sometimes it's just a case of fooling the viewer into thinking something more complex is occuring.

QuoteI have to admit that when I start a project, I don't ever really do any planning (that's why I have't finished a project yet)

     You're not alone.   It's a shame that such a  small % of games make it to some form of playable state, let alone completion.   While there are all kinds of reasons for this, the biggest hurdle facing anybody new programming  is acknowledging one's own limitations.    Once a person commits themselves to learning the required skills, be those programming, design, artistic whatever they lack,  then they'll start to break the tech demo cycle. 
       

QuoteAre todo lists important?

    Yes, I like to have some idea of my progress through a project.   This makes it much easier to differentiate between what's important from what's not so important at any particular time.   
   

QuoteIf you do use them, how indepth do you make them?

   Anything from some a list of random idea/concepts  through to a more elaborate documents showings the step by step mechanics of how each idea relates and how they will be implemented.   

QuoteDo you use any software for your lists or is it just a case of having pen and paper to hand to makes notes and to update your list?

   I used to keep various Note pads of documents about various projects besidde the computer when i was working on anything back in the day.

   Today this has progressed to Windows NotePad.exe  -  Although, I do find that drawings can really help me see an idea quickly,  so i haven't totally abandoned pen and paper :)

I use To-Do lists all the time. Helps you to make sure your on track and keep sight of your goal. They seemed to get longer sometimes as you go.

I use notepad too especially to keep info such as
-animation indexes
-image indexes
-variable info such as
       -Name
       -Type
       -Lower limit
       -Upper limit
-Gampad/KB button inputs and what they do

There is a muriad of things to keep track of and although some would argue that the PB IDE (Such as debugger) will give you that info , its nice to have offhand right there in front of you. Study it, know it, make it your own

If your like me, a virgin to PB(or any programming for that matter), no dought your first project with have to be re-built at some point to make it more efficient and follow better programming practices (like im doing now :-[. That's right, NO GOTO's!! (to start):P

"The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one." - Mark Twain


I follow this quote with all of my heart and it can be applied to every aspect of life, including game development.

This thread is very motivating. I definitely got a little someting out of all these posts.
I think I should read more of the posts on the forums here. Very informative. ^^

Today I was just going over in my mind how my projects have been lacking proper design, I broke out my drawing pad and a pencil.
Whats amazing is how you don't really need that much effort to draw out a sketch. But in code it can be so much more complex until you simplify.

Normally I write down all the variables I'm going to need on paper in plain english.
Certain things , for example
the player's falling speed
the player's maximimum falling speed
level boundaries in real coordinates (pixel)
the player's size
the size of sprites

how many sprites that I want
the types of sprites
sprite behaviors... and how they move..what they do

and then at a certain point I get into actually planning out each of these aspects seperately

even when I first started working on my first map editor
it was a pain to figure out exactly how I would cause the map itself to scroll and still keep
track of which tile was being clicked on

I figured that the window size itself can be a variable so that if it gets resized I can still
account for the change

so
20 tiles by 20 tiles
that's windowx=20
windowy=20

viewx
viewy
those variables kept track of how far the player had scrolled


so that when the mouse was over a tile from 1-20 in the window
the viewx and viewy got added to the calculation

that way...
if viewx was 1 and the player clicked on the 20th tile to the right (the last one) in any Y position
it didn't count map(20,y) as being clicked.
it counted map(21, y) as being clicked.
so then map(21,y)=#index of currently selected tile

...
and that seemed to work
and then I did the same things for my drawing routines..
and over the years my understanding of how tile engines work has become more advanced because
I familiarized myself with that sort of thing from day 1
^^

but even with a working 2d engine.. there's still so much that goes into game design itself.

The whole building a structure that works on a second layer of the code.. so that your almost
creating a whole new programming structure out of the platform your using.. I thought about ways to do that
several times.

i figured functions would be the best way to go about it and typed arrays.


Normally my other approach would be to create a ton of sub routines

and then a commands index.
give the commands index a text parser
read the script line for line from a script file
and then, run the sub routines in conjunction with the code.

make an array of 1000 or so externally controlled variables
and then... create a function that externally does an if comparison with #result

ie

function (variable1, variable2, command# if true, command# if false)
and then it woudl jump to a corresponding subroutine labelled by its command# with those values..

a little complicated
but its sort of like programming in assembly..

I've been learning how to structure things so that there's literally no limits with the language.
if a command doesn't exist I can create a subroutine that performs the command...
and then create a call to the subroutine
and treat the entire subroutine as a command all it's own.

^^

I think in my view of programming with Play Basic since Day 1, I have learned that everything I make should represent an object, as it is implied in Object-Oriented Design. Very rarely will I have a lone variable that is outside of a type or function.

Generally, I organize my project into appropriate tabs:
-- Startup
-- Images
-- Sounds
-- Objects
-- Object Events
-- Loop


Startup:
-- Defines the game's protocols (window length/width, framerate, max image quantity, #include, etc)

Images:
-- Holds all the images that is used for the project. However, I DO NOT refer to images by their image index. Instead, I create my own function for loading images and grabbing new images from loaded ones.
example:
CONSTANT COLOR_TRANS = RGB(253,0,253)
blue_flag = Load_T_Image("blueflag.bmp", COLOR_TRANS)
^: Now, if I ever need to refer to the image, I will use blue_flag instead of the number.

Sounds:
-- Same as images, sort of...

Objects:
-- Holds the types and Dimmed objects of the game.
example:
type t_character
  active
  x
  y
  dir
  .....
endtype
Dim Character as t_character

Object Events:
-- Holds the FUNCTIONS that are associated with the objects respectively
example:
Function Character_Move(amt_x, amt_y, dir)
  Character.x = Character.x + amt_x
  Character.y = Character.y + amt_y
  Character.dir = dir
endfunction

Function Character_Draw()
  drawimage my_character, Character.x, Character.y, on
endfunction
(( Realistically, I would stick Character_Draw() in a do loop ))


Loop:
-- Holds the Initial functions required to start the same (usually functions I have created for loading maps, initiating characters, and whatnot). Then followed by the do loop which holds functions that alter the behavior of the objects (Object Events).