Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / A guide to Structured Programming

Author
Message
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 18th Oct 2011 15:26 Edited at: 18th Oct 2011 17:56
Intro

Have you ever attempted to program that project of your dreams, and ended up with 10'000 lines of spagetti madness? Have you ever had a program that became more and more complex the more you added to it? With this guide I hope to introduce you to a very structured style of programming which guarantees success with larger projects.

We begin with the 5 HUGE RULES. These rules can not, under any circumstance, be violated.


5 HUGE RULES

1) You must only have one main loop in your program. If you notice you have a loop for your menu, a loop for your game, a loop for your highscores etc. then you're doing it the wrong way.

2) Your main loop must only contain functions, and be command-free (except cls, sync, set cursor, and a few other very basic commands).

3) For every entity (be it a unit, effect, console, etc.) you must have a seperate source file containing functions. The structure of these functions are explained later in this guide.

4) I DO NOT want to see any numbers for things you load. Use constants. This will be explained later on in this guide.

Wrong : load object "tank.x",1
Right : load object "tank.x",TankOBJ

5) ALWAYS use User Defined Types (UDTs). This will be explained later on in this guide.

Code Template

Whenever you start a new project, and you want to use this method of programming, I advise you to just copy/paste the following template:



Constants, UDTs, Variables and Arrays

This section will wrap up rule #4 and rule #5 : Use constants where possible, and always use UDTs. First a few norms that you should use:

When making a constant or UDT, try to add some kind of "ID" to the name you give it. For example, all maximum values have a "Max" at the end, all IDs have an "ID" at the end, all images have an "IMG" at the end:



When making UDTs, you should have either a "VT", or an "AT" at the end of the name. "VT" stands for "variable type", and "AT" stands for "array type". Doing it this way tells us two things : We know that it's a UDT, and we know what it will be used for an array or a varaible. Examples:



It is essential you follow those norms.

Let's say we want to add a player in form of a 3D Tank (because tank games are awesome). To do so, we need to define the following things:

-Maximum number of tanks
-Unique ID
-Control value
-UDT for tank
-array for the tank

Maximum values and the ID go at the top with the constants:



The control value goes in with the UDT ctrlVT:



Then we create a UDT for the tank. We need the position, angle, input buttons and the active value (explained later on in the section "Adding entities"). So:



And last but not least, the array for the tank:



The whole code will look like this in the end:



When loading media, you have to define it at the top among the constants:



This makes it a lot easier to 1) keep track of what you've loaded and 2) remember the index value without having to look for the part where you loaded the image, remember the number, and jump back to where you were to write it into your code.


Adding entities

So let's start with adding things to your code. I'll do this with an example. Let's say we want to add a player in form of a 3D tank (because tank games are awesome).

Rule #3 requires that we make a seperate source file containing functions. The structure of these functions are as follows:

Create
Destroy
Control


Those are the fundamentals of creating an entity using this structure: You create an entity with a function, you destroy an entity with a function, and you control an entity with a function. You can of course add more than just that later on, but for now we stick to the 3 basic functions. How does this look using our example?

CreateTankPlayer(x#,y#,z#,angle#,btn_up,btn_down,btn_left,btn_right)
DestroyTankPlayer(index)
ControlTankPlayer()


What I thought behind those functions is : Creating a player requires at least the position, the angle, and four buttons to move around. The buttons will just be scancode numbers. Destroying a player requires an index so the function knows what to destroy. Controlling the player must be called once every loop. So let's go ahead and examine the first function. Here the entire code:





This section will count through the array Player(n) until it finds one that has an active value smaller than 2. If it doesn't find a free slot, it will exit the function immediately and return a value of -1 (meaning it failed). Let's talk a bit about active values, and what they mean:

0-never used
1-inactive
2-active state 1
3-active state 2
4-active state 3
5-active state 4
...

If an entity has never been used before, it's active state will of course be 0. So the next thing to do is load it:



After that we set some object properties, and save the values passed through the function into the array:



Note that here we set the active value to a value of 2, which means this entity is now active. This last section of code returns the index value of the entity:



An example on how to use this now would be something like this:

Player1 = CreateTankPlayer(0,0,0,0,201,203,205,208)

The index of the entity is stored in the variable Player1. We can access the player later on in the game by using that value.

Next up is the Destroy function:



If the passed index value of the player isn't active, the function exits and returns a value of -1 indicating that it failed. If the player is active, it hides the object(s) affected, and sets the active value to 1, which means "inactive". You're probably asking why I don't just delete the object, and not have this complicated system where 0 means never used, 1 means used, and 2 means active. The reason is : speed. It could be that your tank is some really high-poly model that takes 5 seconds to load. Hiding and showing it is much easier than deleting and then reloading it again. An example on how to use this function would be something like this:

success = DestroyTankPlayer(Player1)

The last, and probably easiest part, is the control section. This function is called once every loop, and controls how our tank behaves in the game. Here's the entire code:



Here we can control all entities that are active. Notice how I use the active value as a holder for what state the entity currently is in. This is known as state-event based programming. If you don't know what this is, I urge you to google it, as it is vital to know. Here is a small example demonstrating what it is:



This is a powerful way of controlling things in your game if it has multiple states. You end up writing a little more than you'd normally write, but you eliminate the problem of the player getting confused and trying to jump and idle at the same time, because it can only have 1 state at any given time, and this structure makes it really simple to add and remove features.

It is essential you understand the concept of state-event based programming, and it is essential you understand how to correctly add entities using this method before we carry on.


The Main Loop

According to rule #1, we are only allowed one loop in our program. Behold, the main loop:



This is the heart of any program, because it runs in a loop and stops the program from ever ending (or until the user presses the escapekey, but lets ignore that). So lets go ahead with our tank example and add it to the main loop:



I've added the line

if ctrl.TankPlayer=true then ControlTankPlayer()

This gives me the power to disable all control code to all tanks by just changing one variable. Just to show how easy this is, I'll make an example. Let's say you've been working on your tank game, and have something like this in your Control_Game_Elements() function:



You can easily change game modes by writing functions such as:




Outro

I hope this was helpful for you and I hope this small guide can improve your coding structure so you don't end up with that huge bowl of spagetti in the end

If you have any suggestions for improvement, feedback, things I should add/mention for this guide, please post

TheComet

Red Eye
15
Years of Service
User Offline
Joined: 15th Oct 2008
Location:
Posted: 18th Oct 2011 16:30 Edited at: 18th Oct 2011 16:32
Nice guide, but:

1. One loop in program is only if you arent parrallel programming.
2. A Menu Loop isn't bad AT ALL this way you totally seperate the program and make it more clear whether you are in the menu mode or game mode. And it would be an easy switch and less checks.

Keep it up!

PS:
Quote: "You must only have one loop in your program."


A loop can be loads of things:
- for loop
- while loop
- for each loop
- etc.

But I think i got what you mean. Just pointing out that you will always need to for example update all object before syncing this would require a for loop to go through all objects and thus using a loop within a loop (which is your main loop).

Loopception!
CumQuaT
AGK Master
13
Years of Service
User Offline
Joined: 28th Apr 2010
Location: Tasmania, Australia
Posted: 18th Oct 2011 17:18
Have to say I disagree with quite a bit of this, but still a good read for the newcomers!

Malevolence: The Sword of Ahkranox
www.msoa-game.com
www.facebook.com/malevolencegame
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 18th Oct 2011 17:55
@ Red Eye - I agree with your 1st point, but not quite with your second. If the buttons of the menu are controlled in the same loop, you can have the game continue in the background while you configure things in your menu. If you had both loops separate, this would not be possible. You'll probably answer with a "well the game needs to be paused when you're in the menu anyway", and this is the case with most single player games. But when you move on to online games, it's best to do it this way. Besides, using this technique allows you to have both options.

Thanks for the feedback! And yeah, I'll edit the "having one loop" to "having one main loop"

@ CumQuaT - This is my first attempt to write a tutorial, so please do elaborate on what you don't agree with, and how you'd see it better Don't worry, I can take a bashing.

TheComet

Jimpo
18
Years of Service
User Offline
Joined: 9th Apr 2005
Location:
Posted: 18th Oct 2011 18:05
It's hard to write a guide for something like this, as a lot of it is personal preference. There isn't just one way to write structured code. What one person may see as an unbreakable rule, someone else might see as a messy way to code.

Red Eye
15
Years of Service
User Offline
Joined: 15th Oct 2008
Location:
Posted: 18th Oct 2011 18:50 Edited at: 18th Oct 2011 18:52
@TheComet: You are right, the point I made was that it totally depends on what you want to create (you said it yourself, 2 types of menus). As Jimpo said it totally depends on your personal style. Structured code can be written in many different styles. But good first tutorial nevertheless. I think you have choosen a hard topic which many people have tried to create an formula for, thats all.

Keep it up,

Leo

PS: A good topic around yours would be discussing on how effectivaly use many for loops and why in some cases you can combine them and combine while loops, there is more facts to give on that, yet that also depends on what you want to create ofcourse, but giving some good hard examples would clear stuff up and help newcomers to the world of programming.
BatVink
Moderator
20
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 18th Oct 2011 19:13
This is one way, made up of a number of points that are not set in stone:


Quote: "1) You must only have one main loop in your program. If you notice you have a loop for your menu, a loop for your game, a loop for your highscores etc. then you're doing it the wrong way."


I disagree strongly with this. My personal preference is for a top-down style; it allows for easy expansion of functionality.


Quote: "3) For every entity (be it a unit, effect, console, etc.) you must have a seperate source file containing functions. The structure of these functions are explained later in this guide."


Definitely disagree. If I need a separate set of functions for a unit, then the program is far too granular.

It's good advice you're giving, but go easy on the "MUST DO" language.

Daniel wright 2311
User Banned
Posted: 18th Oct 2011 20:16 Edited at: 18th Oct 2011 20:25
Quote: "Have you ever attempted to program that project of your dreams, and ended up with 10'000 lines of spagetti madness?"


YES!!!!!!

Quote: "Your main loop must only contain functions, and be command-free (except cls, sync, set cursor, and a few other very basic commands)."


I also dont belive this should be in all games depending on the game type.If I must write code to controll my player and my enemies I like to have this code in the loop as it helps me write better, But this is just me as I am dyslexic.

my signature keeps being erased by a mod So this is my new signature.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 18th Oct 2011 21:09
Quote: "Don't worry, I can take a bashing."

I'll take you at your word

1. No - it makes sense to separate your menus from your game from your highscore display etc. Why should your possibly highly complex game loop be further complicated by your main menus and highscores. Why maintain several variables of state when you can simply branch off and do something completely different more easily.

2. Maybe, but there's no 'must' about it. I generally code what's needed, until it gets complex, at which point I'll move logical sections into a function instead.

3. No - I may have separate files for major units of logic, but not for the game opponents, although again, I may do so if the code for each opponent gets very complex.

4. Yes, I tend to agree, but again, there's no 'must' about it.

5. Huh? Do you mean instead of separate arrays for related data like they have to do in DBC? If so, then yes - group logical units of variables together.

Naming:
- AT/VT - no, but I sometimes use a '_t' suffix for types. If I needed VT or AT because it's not clear when reading the names, then I've used the wrong names.
- ID - maybe, if it makes sense, and where it makes sense (which will usually be as a suffix).
- Max - maybe, if it makes sense, and where it makes sense (which will usually be as a prefix, eg. MaxEnemyId)

Let me summarise by saying that I don't do much of what you suggest, although I consider my DBPro code as 'structured' and 'modular'. My primary aim after correctness is readability, which includes one-purpose-per-function, naming variables and functions clearly according to their purpose (not their content), simplicity of code, logical grouping of functions/variables etc.

And just to underscore something that BatVink wrote - more experienced programmers are generally used to 'standard' speak (used by standards organisations such as ISO, ANSI and BSI), so are fairly sensitive to the words 'must', 'shall', 'will' etc. Those words have very specific meanings, which may have a use in coding standards documents within teams or company settings, but not in a non-team environment. I suggest that you replace all occurrences of 'must' with 'suggest', 'prefer' or 'may'.

(Link to my preferred code organisation, which people may find useful )

CumQuaT
AGK Master
13
Years of Service
User Offline
Joined: 28th Apr 2010
Location: Tasmania, Australia
Posted: 19th Oct 2011 04:07
IanM and BatVink pretty much summed up my counterpoints hahaha

Many institutions fight voraciously to enforce coding standards and I can see their value, but for individuals, it just comes down to common sense.

I, for example, use GOTO a fair bit, but I don't have spaghetti code. I properly map out my programs to avoid memory leaks and infinite loops. If you know what you're doing, you will develop your own coding style. 14 years of programming on a daily basis has helped me get to this point, but too many new programmers don't properly plan out their game before making it. They just start coding. That's what leads to spaghetti code. No design document, no von neumann diagrams, no planning.

Malevolence: The Sword of Ahkranox
www.msoa-game.com
www.facebook.com/malevolencegame
Grog Grueslayer
Valued Member
18
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 19th Oct 2011 05:48
1) I agree with this but of course there have to be other loops within the functions... especially any Menu or high score function.

2) Ideally if it's done right this is what you should end up with but it shouldn't be set in stone.

3) I prefer to keep all my code in one file. Does it really matter though if we use 100+ source files when their all combined to compile anyway?

4) I don't like to use constants at all. On small projects I use numbers but for large projects it's all taken care of in arrays... which is much better to use than constants.

5) For this one it really depends on the type of project. I think I've mentioned this before but for most things I use UDTs except for Text Adventures. The easiest way to deal with movement in a Text Adventure is with a normal array rather than a UDT. For example if I want to check the exits in a normal array I only need to use a FOR/NEXT loop and check all the exists. If that same data was in a UDT I have to have a name for each direction and cannot do it in only 3 lines but rather 12 lines to check for N, S, E, W, NE, NW, SE, SW, UP, DOWN, IN, OUT. UDTs are amazing but not the end-all-be-all data structure for everything.

I'm with IanM on the ID and Max ideas. I'd rather have Max at the beginning rather than at the end because it just sounds better... MaxRecord, MaxEnemy, MaxOverdrive.

On UDTs if you notice on most of my examples you'll see only one naming contention for my UDTs... they all have SomethingData. UDTs are just that a variable or array of Data so I always define UDTs with "Data" at the end.

The bottom line though is your code is great TheComet so don't let all our different opinions sway your personal preferences.

misifield
16
Years of Service
User Offline
Joined: 23rd Nov 2007
Location: ohio
Posted: 19th Oct 2011 06:07
I think its a nice tutorial, wish i found it two weeks ago. I have been programming for awhile but after a few hundred lines of code it falls apart. I use several of the ideas that you had in the tutorial already. I am still working with 2D code, the 3d seems to advanced still for the things that I would like to make. I am working on a 2D networked rpg with just dots and stuff for graphics. With the help of the Db community I have made it to several thousand lines now and im still going. My next project I will remember the switches that you created seems like a great idea.

mfield
CSL
15
Years of Service
User Offline
Joined: 22nd Mar 2009
Location: USA
Posted: 20th Oct 2011 18:30 Edited at: 20th Oct 2011 18:30
In general, this looks like, correction: it is a very well written piece on coding standards. With that said, most of it shows description of better practices rather than guidance on actual structured programming, which the title suggests.

Coding standards differ for each developer. There are always a good set generally agreed upon standards, but in the end, it is up to the particular developer's or team's preference. Coding standards have an impact on the development cycle rather than on the user experience. Structured programming does affect the end-user because a badly coded program usually suffers performance issues and instability which in turn affects the overall user experience.

Overall, a good article, but there's a lot more to structured programming than this.

CSL
EdzUp
21
Years of Service
User Offline
Joined: 8th Sep 2002
Location: UK
Posted: 20th Oct 2011 19:44
Loops should be for things the user has to have interaction with, gameloops, menus and frontends.

There is no wrong way to do this BUT do not whack everything in one loop this is the wrong way to go about everything, for one having a main menu loop will mean that you can have a lighting fast main menu and a main loop for lightning fast games.

If you must share the game level (for main menu backgrounds etc) then have a renderer function that you can call from either the main menu loop or main game loop.

Never put EVERYTHING in the one loop as it will confuse matters and make a neat code program look completely messy and unprofessional.

-EdzUp
Graveyard Dogs
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 20th Oct 2011 23:00 Edited at: 21st Oct 2011 00:11
@ Red Eye - Thanks a lot for your feedback

@ BatVink - Thanks You're right, I should go more easy on the MUST language

@ Daniel wright 2311 - Well what works for you works best for you

@ IanM - Thanks, great feedback you have there I'll go ahead and change all of the musts. I'm interested in those coding standards, could you possibly link me to one of them you found helpful?

@ CumQuaT - I've only recently started to make design documents, and I find them very helpful, but they require a lot of your time to make...

@ Grog Grueslayer - It doesn't matter so much to the compiler if you make one file 10'000+, but that's not exactly the point. The point is that you as a user are able to quickly and efficiently navigate through your source code, and I find this easy to achieve with a lot of separate source files.

I'm used to writing the Max at the end of a variable/constant, but again, that really is just my personal preference.

Thanks a lot for your excellent feedback

@ misifield - Thanks, may the force of the dark side (DBP) be with you in the future

@ CSL - Thanks for your feedback I think we can all agree that Notch is a great example on how not to code xD

@ all

A lot (actually almost everyone) have suggested that throwing everything into one main loop is a very bad idea. While having multiple loops can be regarded as "more structured", and does work, my personal preference is stuffing it all in one loop and using those controller flags, because no jumping is done whatsoever, and you only really need one loop, because each function works entirely by itself independent of the other functions. So in this situation, making more than 1 main loop will introduce chaos.

Quote: "for one having a main menu loop will mean that you can have a lighting fast main menu and a main loop for lightning fast games."


Not really, because you entirely disable the menu by setting ctrl.Menu = 0, and I don't think one simple check like that is going to slow down your entire game, or vice versa slow down your menu.


Thanks for all the great feedback everyone, I really do appreciate it!

TheComet

IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 20th Oct 2011 23:44
I suggest that you find something more interesting to do than read through standards documents, however if you really feel you need to, start with a very short explanatory document and follow it up with a highly publicised recent example language standard (read the first, scan the second at the very most).

Quote: "Not really, because you entirely disable the menu by setting ctrl.Menu = 0"

You haven't answered my objection to '1 loop' regarding complexity. Why make your game loop more complex than it needs to be be adding menu and highscore handling for example.

TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 21st Oct 2011 00:19
Quote: "You haven't answered my objection to '1 loop' regarding complexity. Why make your game loop more complex than it needs to be be adding menu and highscore handling for example."


I disagree with saying that it's "more complex". For me (and this is a personal opinion), having multiple loops and jumping between them when switching modes is a lot more chaotic than having just one loop with flags controlling what is active and what not. The key point of my style of programming is that each and every function works for itself. You can literally copy/paste the functions for an entity into another project, dump them into the main loop there, and they'll work by themselves, completely isolated from the rest of the program. That is why I throw them all into a single loop: There's no reason to make multiple loops, they are already isolated.

I see your point though of it being less complex to have more loops, and I agree that this is the case if you don't follow the method described here. But for this method, 1 loop is much less complex.

TheComet

CumQuaT
AGK Master
13
Years of Service
User Offline
Joined: 28th Apr 2010
Location: Tasmania, Australia
Posted: 21st Oct 2011 03:17 Edited at: 21st Oct 2011 07:08
There's also the fact that was raised that a FOR/NEXT nest is also a loop. FOR/NEXT is absolutely essential in any sort of advanced program, and should be used liberally. Not just once.

However, with the main loop, which I assume is a DO/LOOP or REPEAT/UNTIL, having a menu structure inside that is fine for simple programs, but what about menu structures like my game, Malevolence, which have a distinct main menu before the rest of the game loads, or multi-tiered menus such as Main Menu->Options->Video Settings, etc? It just makes more sense to have separate loops for them. Even if it is for no other reason than the fact that your main loop should only have a few function references in it and nothing else. So inside the functions there will be other loops while waiting for mouseclick events, etc on the menus.

To use my game as an example again, I have about 28,000 lines of code all up, but my main game loop only has 6 lines of code in it. Everything is blocked out nice and simple.

And while I agree with your comment that design documents take a long time to develop, they are absolutely an essential part of any large project and should be considered part of the development process. Especially when working with a team!

Malevolence: The Sword of Ahkranox
www.msoa-game.com
www.facebook.com/malevolencegame
Daniel wright 2311
User Banned
Posted: 21st Oct 2011 04:06
Quote: "having multiple loops and jumping between them when switching modes is a lot more chaotic than having just one loop with flags controlling what is active and what not."


I think this all depends on the size of your game and or code all together.

I think if your game is a larger game a sepreat loop for your menu and sub menu is best. Here is why for me, if I have 30 levals of a game, and each leval has to load in as if leval1=1 then load leval 1, this would only happen from the main menu.

If I load in leval 2 from the menu then it will load in leval 2 before the main loop. But,if I wanted to load leval 2 from the main loop and have never played leval 2 then this would take just more code I dont want to write.

my signature keeps being erased by a mod So this is my new signature.
Stab in the Dark software
Valued Member
21
Years of Service
User Offline
Joined: 12th Dec 2002
Playing: Badges, I don't need no stinkin badges
Posted: 21st Oct 2011 06:06
TheComet

I have a question about your example above.

1.Why do you use Repeat/Until as your main loop?
2.Wouldn’t using Do/Loop be the accepted standard in DBPro?
3.Why do you put “End” after until, isn’t it unnecessary?

This post has been a very interesting read. It has given us a better idea of how the DBPro community writes and organizes their code.

[img][/img]


WindowsXP SP3,Vista,Windows 7 SP1, DBpro v7.7RC7
Stab In The Dark Editor
The coffee is lovely dark and deep,and I have code to write before I sleep.
Grog Grueslayer
Valued Member
18
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 21st Oct 2011 09:27
Quote: "3.Why do you put “End” after until, isn’t it unnecessary?"


It's good practice to always put an END before the first function. Even if it's a loop that never has an EXIT it's always good to have END just in case the unthinkable happens.

Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 21st Oct 2011 14:34 Edited at: 21st Oct 2011 14:37
I do see some benefits of using one loop; you can control what is and is not active in one place instead of having to look around; but this gets ugly when you have to manage menus, physics and the whole shabang in one room, so to speak.

By having a b]specific[/b] loop for the current sub-program, there is no need to coding over code and running boolean conditions for parts of the program that have nothing to do with the current sub-program.

I'm working on a VB GDK project with roughly 11,000 lines of code so far.

I always say to my self:

First Rule: Put all code in functions with a specific purpose.

Second Rule: Keep your functions as small as possible.

Third Rule: Functions must specificly perform what it says it does, and should, where possible, work only with its local variables (and in OOP its class members).

So I could not use a single loop, because it would get to large and vague in purpose; its a bit like having all of your document and program links crammed into the Windows Desktop.

Sasuke
18
Years of Service
User Offline
Joined: 2nd Dec 2005
Location: Milton Keynes UK
Posted: 21st Oct 2011 23:20 Edited at: 23rd Oct 2011 12:27
Heres what I use with one loop:

Program Structure (Top Down)
- Core Constant for are program
- Core UDT's
- Core Delcare (globals)
- Class Declares
< SYNC ON >
- Core Setup
- Class Setups
- Director Setup
< Initialize Loop >
- Director Update
< SYNC > (depending on what the director is doing, like multiple sync)
< End Loop >
- Clear all data
- End

Class Structure (Top Down)
- Constants
- UDT's (User Defined Types)
- Declares
- Setup or Initials (After SYNC)
- Function Set For Are Class¬
- > Creator/Operator Functions (ex. Create Object)
- > Update Functions (ex. Update Object)
- > Arguments Functions (ex. If Object Exist)
- Misc (Data Statements or Other Gosubs)

Note: The classes would be modular, so in there seperate source files depending on project size.

Now let me explain this, my engine doesn't work like... well I don't think theres and engine out there like mine. So I'll explain:

Directors are what control the engine, a director is a parent control with children hanging off it. Each class, sub class, custom class has a director and there's the core one call the rootDirector. Now here's where my engine gets cool. Anything that's attached to a director gets updated, the advantage being I never need to check if something needs to be updated. But what is really cool is I can complete drop classes from being updated on the fly. I don't have to waste any time checking if every classes needs updating.

Lets look at this visually.

Take a standard engine with one loop (can't be bothered to put in correct order):

<Loop>
- Update Core
- Update Input
- Update Camera
- Update Audio
- Update Objects
etc...
<End Loop>

Note: just imagine all the checks within those updates.

Now what if the only thing thats going on is theres some audio thats playing, you'd waste time checking all other classes that don't need updating.

So this is what my rootDirector would look like:

updateDirectorChildern >
- Audio
<

That's it. Because thats all thats attached to the director that mean thats all that will be updated. But I can do far more cool and advanced stuff with this engine design, but I won't take over this thread with talk about my engine, unless you ask me.

All I wanted to point out is code is only as complex as you make it, so I don't see any argument here.
Chris Tate
DBPro Master
15
Years of Service
User Offline
Joined: 29th Aug 2008
Location: London, England
Posted: 25th Oct 2011 17:38 Edited at: 25th Oct 2011 17:49
Sasuke

Quote: "Directors are what control the engine, a director is a parent control with children hanging off it. Each class, sub class, custom class has a director and there's the core one call the rootDirector. Now here's where my engine gets cool. Anything that's attached to a director gets updated, the advantage being I never need to check if something needs to be updated. But what is really cool is I can complete drop classes from being updated on the fly. I don't have to waste any time checking if every classes needs updating."


I and many others also update objects through parent objects; this part of the whole point of object orientation. You call them directors but the concept is similar, and it makes sense because as you say, nobody wants to..
Quote: "waste any time checking if every classes needs updating."


My loops however, are context based; they exist per sub-game, per screen type, per menu; think Super Mario overview and side view sub-games or the different perspectives in the Final Fantasy games. Each of these parts use objects, sprites, buttons, physics, bonus-levels, AI, cut-scenes, intros, game objects and in my case user login, registration, character editing, vehicle configuration etc etc, different uses of object classes for different purposes, based on the current context.

But still, the root objects (base classes, and structures in classes, in VB terms), handle the updates through one function call. I'm one function call man; when I can be.

Login to post a reply

Server time is: 2024-03-28 11:32:32
Your offset time is: 2024-03-28 11:32:32