It is not unreasonalble, I agree! I just haven’t gotten around it. You can get past it by chosing either chapter (by clicking on the left and right sides of the screen to move in the UI), then choosing it (by pressing on both sides of the screen at the same time).
That sounds awesome! This is the most advanced game I have ever made, so I don’t feel like I have as much experience as you. I’m glad you seem to have liked what I came up with in some way or another!
I feel like designated initialisers can be circumvented by simply assigning the fields individually. It’s a bit more verbose, but I feel like it works almost as well, the biggest downside being that the compiler won’t warn you if you miss some.
Regarding loops and variables, I opted for just declaring all variables at the top of each function definiton (only using an initialiser for ‘static’ variables), which I find almost reminds me of how Python handles variables, except with a chunk of declarations at the start of each function.
Of course, this is all subjective, but I find this style looks neat, and I don’t think it gets in my way at all, personally.
> Jump King, Getting Over It both have the same kind of ruthless difficulty
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?
If a platform is one tile tall, it will act as a semi‐solid that you can jump up through. If that’s not what you mean, then any kind of evidence (like a video or a screenshot) or some description about what you were doing that caused it would be very helpful!