| I wasn't sure I would be able to play on mobile but I was pleasantly surprised by the simple controls and managed to reach the third scene of chapter 1 before getting stuck, so, good job. I don't think anything needs to change with the controls, the people saying that aren't the audience and don't have the genre literacy to know what this type of control setup is doing(for those watching: Jump King, Getting Over It both have the same kind of ruthless difficulty). Regarding the technology, it's healthy to simplify the architecture - I've played a lot with the same kinds of thought processes of adding a lot of abstraction and gradually moved towards simpler answers. You already have a lot of answers that work, but my own take is that games of this type and scale need, roughly, these pieces: * A "god object" entity model(every entity is one struct containing all necessary state for all possible behaviors). Going beyond that adds memory savings that you don't need for modern machines, or modularity that will introduce more to debug. * State machine formalisms to describe what screen to draw, how to transition between them, what animations to play, and other behaviors. All control flow logic encompasses the behavior of a state machine, so you have to decide which formalism is best to use for the context and will aid debugging. That's why people sometimes gravitate towards coroutines and other high-level abstractions. Simple "scripting languages" that just describe a sequence of opcodes are something that frequently appear in old games. * A simple constraint solver for the platforming physics. The problem that all physics systems have to solve is "there are multiple possible solutions that will resolve this motion: which one is the best?" This tends to be obfuscated in platforming physics by a convention of throwing away information about potential solutions early(e.g. moving on the x axis and resolving collision there, then doing the same on the y axis). Instead I recommend breaking down the motion into multiple permutations of "x then y" vs "y then x", then sorting and ranking the outcomes relative to a heuristic of unimpeded free movement. It's a more expensive check that also gives a better-feeling result. * A pipeline to load the graphics, collision and scene assets. Although you can hard-code a lot of these things in a simple game, it can be convenient to export them from a spreadsheet and make it data-driven. Things like describing what "chapter 1" is are basically asset problems. I noticed that you have dialogue boxes described with a tileset and code to draw the tiles. This is how I would have done things once, since it is "how they used to do it" - today I would be likely to turn everything at runtime into an image, and to build the text itself, compile pre-baked images of text in the build process using tools like imagemagick. That makes the runtime simpler and reduces the kinds of assets it tracks, while allowing total freedom with the content of dialogues. Sometimes with these projects, the engine development is being used to avoid content work. I suggest a physical graph paper notebook to create a location for that content to be designed, and to engage in some blind contour sketching to warm up to doing anything visually-oriented. When you have a whole storyboard for the game it becomes easier to conceptualize what code is necessary to get the effect, and do exactly that instead of generalizing it. Two commercial "back in the day" games I would also look at for more inspiration: Xargon, Little Big Adventure 1. Both written in C, original source code is available. Studying those will give you a sense of where you are relative to finished work. |
Yes, that’s exactly the kind of thing I was going for! Though I will say: I feel like my controls, although difficult at first, are easier to get used to than either of those two, or at least they were to me. After a while playing with the game, you “get the hang of it” so to say, and it starts feeling more natural.
Also, thank you for your advice! I have some thoughts/questions about some of it:
> Things like describing what "chapter 1" is are basically asset problems.
Well, my current solution is to encode the different “assets” (chapters, characters, images) as source code, and link them with the rest of the game at compile time. The biggest benefit is that I end up with a single executable that is easy to run, and don’t need to bother loading assets at runtime. To me, it doesn’t seem to matter ultimately whether I store information about how a chapter should play out as plain data or as code, and making it code seems simpler insofar.
Though a lot of the assets the game uses (e.g. the dialogue boxes you mentioned) are generated during intialisation, and then just displayed as a set of images during gameplay. Effectively, it shifts some “during build” work to “when the game starts”. The benefits include a simpler build system and fewer required build dependencies, besides being more straight‐forward to work with.
> A simple constraint solver for the platforming physics.
I don’t think I fully understand what you mean by this. Are you saying you feel like it would be better to avoid performing collision checks in order of axis? I.e. that it would make more sense to perform the checks in conjunction somehow?