Pre-planning your project

[Draco9898]

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

Because you can define it quickly like this:

Code Select Expand


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


Instead of this:

Code Select Expand


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.

[kevin]

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

PlayBASIC Code: [Select]

   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

  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.

PlayBASIC Code: [Select]

 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

 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.

PlayBASIC Code: [Select]

  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

 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

PlayBASIC Code: [Select]

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

 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. 

[medwayman]

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

[Digital Awakening]

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

[stef]

This is one of the most interesting threads here!

[Kman1011]

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.

[gvillarreal]

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!

[kevin]

       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.

[EnigmaMystery]

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?

[Alex]

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.

[Ian Price]

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.

[kevin]

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)

     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. 
       

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

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

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?

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

[Kman1011]

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



Error Missing Closing Square Bracket

[Bustaballs]

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

[LemonWizard]

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.

^^