Week 7+8: Figuring it out

Hello everyone! Welcome to combined weeks 7 and 8 of my blog! Last week I didn’t post due to preparations for AP exams as well as attending a graduation ceremony, but now I’m back in the fray with progress to report! I finally got the sequence tracking down after a few hours of racking my brain on how to handle my combat system with GB Studio’s constraints, and I’ve managed to come to a compromise I’m happy with. So, after redesigning the map a bit and implementing visual cues, I have a small demo of my system! This was what was taking up most of the last few weeks, so now all I need to do is work out the kinks and mechanics, and hopefully we’ll see the progress as we go.

To get to this point, I’ve run into all sorts of problems – most of them logic and syntax based within the visual editor. To understand one of the errors I’ve corrected, I need to explain my game plan. This game is going to be a turn-based structure in which the player, instead of the standard context menu, has to memorize input sequences to execute certain commands. The error I kept running into was that the controlled character would not move given a command. It turns out, two of the moves I had coded in were conflicting with one another, resulting in a sort of stalemate restricting the player’s movement, because one move results from all 5 slots being identical, and the other occurs when you alternate inputs. (Ex: [AAAAA] results in a slash move, [ABABA] results in a guard move). The issue here was that the guard move was also reading the input from the slash move, because the guard move only checks that inputs alternate position-by-position, it doesn’t verify that A and B are actually different inputs. In other words, as far as the guard move is concerned, a sequence of all identical inputs reads the same as an alternating sequence. I noticed this when bringing this issue up in a brief meeting with my advisor when we combed through each actor and their associated event sequences while also keeping an eye on the built-in debugger of GB Studio. The video depicted above is what resulted after I fixed this issue, though some more obvious errors are still in the process of being corrected (i.e, the HP bar having weird values and the occasional lag spikes likely caused by the onUpdate properties of the scripts). Another issue I need to keep track of is the Actor (entity) limit in any given scene. GB Studio is surprisingly restrictive with its capabilities, only allowing around 10 actors to be rendered on screen at a time given the actual Game Boy’s hardware. If you look at the video above, you might notice some text or the enemy disappearing at times. This is because the text itself, as well as the buttons and interactables in the scene, are all actors – the same kind that the player character and enemies are. So, I need to carefully keep track of what I want on screen and dealing with keeping all associated scripts running smoothly.

Now for news on the second half of my project – its looking less like it would be an actual remake and more like a concept pitch given the time constraints (which is thankfully accounted for in the grading policy!) Games made within GB Studio lend themselves to be improved by more modern hardware, away from limits like the 20 actor restriction (10 can be rendered, but 20 can be in a scene) or the color scheme. The quadcolor scheme is also what gives the Game Boy much of its charm, which results in custom assets being published specifically for use in GB Studio. Thus, it becomes harder to find publicly available analogs to use in a remade version of the same game. This is reminiscent of real remake practices also- in a remake much of the assets are made from scratch, referencing the older and often less descriptive components of the original. While not a direct comparison I can make while using exclusively public resources, it stands to reason that large companies would try to cut costs and save time in removing or shortening content, even to the dismay of fans.

That’s pretty much all I’ve done for these two weeks, but hopefully I can report more progress next post!