Request for general architecture guidance/advice

Hey,

I'm new to Lua (despite naming my dog Lua eight years ago…) and game development — full-time iOS developer in the day time. But I'm super excited for my Playdate and really wanting to build a small game for it!

I'm just out here asking for some general tips on how to structure my game. It's going to be a fairly straight forward main menu into a game view that loads a level of some sort, upon completion the level be loaded, and then a game over screen.

But I feel stuck, not knowing at all where to even begin! :sweat_smile:

Any tips greatly appreciated. Until then I guess I'll just flail around with the SDK and see what comes out haha.

So check out SDK/Examples!

But your scenario could be as simple is an if statement in your update loop to manage the different states.

That's what I did in

Begin with the example in the docs https://sdk.play.date/inside-playdate/#basic-playdate-game

Thanks! I have had a lot of looks inside the Examples directory, but hadn't seen the example in the docs. I'll check it out.

Something we set up for our last prototype was a basic event system using the Signal library here: A list of helpful libraries and code - #3 by dustin

Then our start screen could broadcast an event that our main process could listen for to change between start screen, game screen, pause screen, etc.

Not sure if it's a good idea yet, but it seemed to reduce the coupling between our classes quite a bit!

1 Like

Thank you! Very interesting to read more "advanced" Lua if nothing else. :smiley:

not in lua but in c, but this might still be helpful to give you an idea of ways you can go about architecting your games: GitHub - pondodev/playdate-invaders: just me fiddling around with the playdate yaknow how it is

this is my first project for the playdate so it's definitely rough around the edges in a lot of ways, but i've found some useful ways of managing things that might be helpful to you. i'll try to give as quick a rundown as i can below:

  1. try treating sprites like entities. i had a quick look at the lua api and it doesn't seem to allow you to store arbitrary data in the sprite like the c api does (though i could be wrong!) but you can also do what i did before finding that out and define a table which contains all the entity's information--including a reference to the sprite itself. doing this allowed me to much more cleanly manage the entities in my game
  2. have a look into some game architecture design patterns like ecs and component pattern. for larger games this can help you reduce code reuse, increase maintainability, and in the case of something like ecs help improve performance if implemented correctly.
  3. create classes/entities with larger "responsibilities". what i mean by this is have a class that handles music, one that handles sound effects, one that handles game state, etc. doing this just makes your code a bit easier to organise really.
  4. maths! don't be scared of it, cause maths is often REALLY helpful in game dev. at a minimum learn how to write your own functions that handle 2d vector math operations since that's often super helpful when doing things that involve moving sprites around a screen. also, learning how to use easing functions in your games is super helpful for all sorts of things (for an example i use them to control the difficulty curve in my game)
  5. create a scene manager. this sort of links back into point 3, but i think this is really important. having a scene manager helps you manage the resources required for a given scene effectively and easily, and if done right will allow you to switch between main menu/gameplay real easily.

good luck with it all, and most of all have fun!

.1. is possible in lua mysprite.customproperty = 123

2,5. these are advanced methods more suitable for PC, be wary using them on the limited Playdate hardware

3,4. agreed!

1 Like