Sorry your browser is not supported!

I'm working on some more complicated games now and I am wondering how people around here structure their code. So far I have been using a simple state machine (sometimes even a sub-state machine) but I feel like this can sometimes be counter productive. What do people around here use? Also is there a good level editor around? I feel like making a new level editor for each app is wasting my time.

My coding style is what we used to call RAD (Rapid Application Development). Rather than building a house from the ground up, it's more like building a sandcastle where you keep shaping and moulding it until it is finished.

I start by creating empty functions...

Init()
GameInit()

PlayGame()

GameDeInit()
DeInit()

I've written them in the order you would use them, although there is of course much more to the final game.

For global resources like menu buttons, fonts etc, I load them in Init(). Each time I add to Init(), I also write the code to unload it in DeInit()

GameInit() and GameDeInit() are used in the same way, but for resources used only in the game.

I will keep adding to these functions as I progress through my development. There are many more functions such as menu display and so forth. The initialisation functions also include things like creating arrays, Tweens and other building blocks of the game. The PlayGame() function will call many other smaller functions to perform repetitive tasks.

Finally...I build PlayGame() as a State Machine. This is a SELECT statement with CASEs for the different game play states (e,g START, END, PLAY, PAUSE, LEVELSTART, LEVELEND.) These can also include smaller state machines within each case. For example, PLAY can include WALK, RUN, DIE, SPAWN, FIGHT.

It depends on how complex the project is for me. I don't even split the code up unless it's over 1000 lines, and really there's a lot you can do with 1000 lines in AGK.

I typically create the project and make an initiate function after the main loop, and build the project organically from that - adding globals, constants, and arrays and typed arrays at the start of the init function, and functions piled onto the end of the code any-which-way.
If I know the project is gonna be bigger than 1000 lines, or a substantial portion is reusable, then I will split the code up. This is a no brainer really, but I think that the areas that need a lot of fiddling are better off as separate source files - like if your setting up precise physics, getting things balanced well and making your own functions to put a leash on physics sprites, control limits etc, then you probably don't want to have to do that twice - better to have your own physics source file for sprites, that adapts things to the way you want to work and your own perceived scales.
I always indent and add a brief comment for each function, but I don't comment much unless I really have to - I prefer to get a function working, get it folded so I don't have to look at it's ugly face anymore
I don't do a great deal of planning documents, I go trough a lot of graph paper and note paper as I work, but that tends to be for lists and simple diagrams to help visualise what I'm working on. I can go without design documents, but I need a graph paper pad beside me whenever I work... try and find an A5 graph pad and make it your bible.

I'm not sure what this method is called, it's organic and adapts to the project - lets call it the 'blindfolded guide dog who smells waffles' method.

As for level editors.... really you have the best option in your hands already.... make one that will suffice for several projects, or is easily adaptable to the project at hand. People all work different ways and AppGameKit is no exception... even if there was code available for making platform games for example, you'd still need to adapt it for your own project - it will always do something that is outwith the norm, and editors need to adapt to the project they are part of. A while ago myself and Cliff M started a retro 3D dungeon crawler, each enemy, item, wall texture is 32x32 icon sized images, so I made my own sprite editor for that - but I spent the time making it decent, and now it's a vital tool that I use in several projects.... even proper retro like the Atari ST - when you have all the code you can add support for anything you like.
Moreover, I always consider making the level editor part of the actual game - if I was making a platform game for example, I'd consider polishing the level editor and having it as part of the game, let users design levels like Mario Maker. It's the ideal situation to be able to design a level and test it as you go, it's like developer steroids... let's face it, level design can be tedious and time consuming, I think it's always worth spending an hour or two tidying and improving editors, that time is typically saved later on. Things like undo features are difficult to implement, but damn are they handy - if all you need it to do is save the level with each change, and reload it when you mess up, then do it - the time it will save, the confidence it will give, the mistakes it will mitigate, it's worth it.

My method of choice is about as far removed from VanB's as you can get and probably as close to OO as you can get from within a procedural language.

I put everything in a file of its own and when I create the file I create a 'constructor()' and 'destructor()' which would work in much the same way as BatVinks init() and DeInit(). Any globals, constants and UDT's associated with it get put at the top of the file.

So for example: My games score would be in a file called score.agc and any code associated with the score system would be in that file. To increase the score I wouldn't increase the global variable called score but would call a function called incScore() and that would be in the file 'score.agc' keeping everything together. Doing it this way makes it very easy to change the way I increase the score in future. I may initially just choose to simply increase the global called score and show the new change but later I might choose to animate the score from the old one to the new one. This way I know I just have one incScore() function to change and I don't have to look for all the places in the code that I change the score.
Additionally the score is probably made of text so the constructor for the score system would call the constructor for the text system to create a new text object which happens in text.agc. That keeps all my text systems together too. So I can easily change the way I use text and I know that everything is in the same place and I don't have to trawl through multiple lines of code looking for anywhere that text is referenced.

Ah yes, like Scraggle, there is the file segregation too. 95% of these are started as a self-contained subsystem that can be dropped into any project....

I do that too
I can almost create a complete game just by dropping previously created files into my new project.

Ah okay... So everyone seems to be using some sort of state machine type thing. On my current arcade game I am using that. I have a root game.agc file which has a BeginApp, a EndApp, and a UpdateApp function. These functions are then called by the main.agc file at the start of the game, update of the game, and end of the game. Then depending on what state the game is in I call the begin, update, or end function for each state (every state has its own file). I also have a GoToState function which will call the end state function for the current state and the begin state function for the new state. Is this a good system to use? My current game does not need a level editor because it is endless but new games I make might.

I tend to plan ahead according to function and dataflow. So I draw up diagrams like this:



Each non-grey 'box' in there is a separate .agc file that I create. When all that is done, I plan out my data-structures and start getting some functionality up and running. I try and keep to the single responsibility principle - not intertwining the logic and decisions end of the app with the front end GUI and presentation of the app. Or mixing the bread and butter with the bells and whistles. As a result of one function one job, the functions themselves tend to be pretty short and sweet. Most functions are in the 10-20 lines of code area. Only the larger control structures get up to perhaps 2-300 lines. It makes for pretty clean and easily maintainable code.