Welcome
Since last week, I’ve worked mostly on Story.GS, and the relevant Level and associated functions. My interpretation of Story has changed a little bit, and Level 0 now has a filled out story function. However the bigger change is that I have now added a skeleton of the Room object, and have been working on getting that filled out. I have filled out many functions of room and related to room, but I don’t have quite enough to show anything big yet. I will soon though.
In the mean time, I have a few other things to talk about. Firstly, let’s update the overall game engine diagram because I’ve made a few changes:
As you can see, I’ve realized that I had included a few too many things in room, that were actually a part of Level. Basically, I was forgetting that although torches, objects, and monsters each have in-room sets, doors are actually not owned by rooms, but are in fact simply functions of the entire level, and genSprites, cycles, and sparks are all collective sets that don’t care what room they are in. As such, they are not inside room, but rather a part of the Level. They are still within the object layer however, as they are only applicable to the objects in the game, not the engine as a whole (cycle is a little iffy, but as far as I’m concerned right now, cycle is the object limb of the sprite, and as such it is one layer of abstraction away from sprite and datasprite). The other notable change is that bullet as a struct is now in monster instead of room. This is because the projectile handling code is room based, but the actual projectile creation/deletion is the job of the creature that owns the projectile, which is the monster or player.
Okay, one other thing to mention from recent findings. Story gets very confusing, very easily. This was probably already an assumption, but I’m going to make it a little bit more confusing but also more clear. Here’s a new diagram:
For most of the Story data types, it’s one level of redundancy. You have Story records which are ROM, and then per room you create RAM versions that exist and get cleared as needed. But with torches, it gets a little weirder. The Story record of torches actually gets turned into an array of all torches within the level, where each entry has a reference to the room and the flame pattern, as well as the x,y. Then, when the room is drawn, you create a new set of torches, this time only ones that are for the particular room. So you may ask, why not just do what objects and monsters do and simply be two arrays? Because this way, you can have action permanence in a small capacity. This may not seem like much these days, but having something the player did in a room remain that way the next time they reload the room, in terms of small scale things, is impressive. Basically, the game keeps track of which torches you have lit (and what flame patterns are being used generally as well), so that if you light a torch and then leave the room, it will still be lit when you return, as you would physically expect. On small things like torches, I think it’s a very nice touch that they did this. Especially since rooms can be ‘lit’ or ‘unlit’. However it does make the code more messy in the source and on our end as well.
So to sum up, I’ve added a number of new things, like the room object skeleton, the torch skeleton, and more story related data. More to come soon for sure. It’s been a bit of a slow week in terms of interesting developments unfortunately, but I imagine next week I will have a lot more to talk about.
Until next time, thanks for reading!