Technical Updates

Until now, each level has only existed on its own, completely unlinked from any of the other levels I’ve currently created. This is mainly because the pink square that I’ve been using as my warp between rooms can only be used if the destination is in the same coordinates as the square on both sides. This is useful for entering and leaving buildings and caves, which I’ve made to line up with the main level structure -all buildings and caves are the same dimensions inside and out. However, in the transition between level one and two for example, the player jumps from an X coordinate of 2992 to an X coordinate of 688, so I’ve had to create a new item specially designed for transition between levels. The new icon uses all my artistic abilities and has formed this go faster arrow shape to differentiate itself from the standard warp square.


On contact with this object, I’ve set up variables who’s values are defined in the individual instances on the map. In the collision event I have:

room_goto(rm); //goto “rm”
obj_player.x = X; //the player object’s new X coordinate
obj_player.y = Y; //the player object’s new Y coordinate

Then, in the individual instance these figures are defined as something like:

rm = rm_2_1; //Level 2 part 1 (main)
X = 688; //new X position
Y = 178; //new Y position

This allows transition between any level regardless of score, so I’ve had to make only allow transition if a sufficient amount of flowers have been collected. Before now, I’ve used one datastructure list to hold information about the collected blossoms, but as this figure changes depending on the level the player is currently on, I thought the best course of action would be to create a unique datastructure for each level. In my GameInit script which runs at the beginning of the game, I now create four lists instead of one:


The first list controls collected sushi boxes. This was previously the same list used to hold information about collected blossoms, but as I’ve had to change everywhere in my code that uses one of the new lists it was simpler to leave this list there. The other three lists correlate to the three levels. I’ve also had to set up three different “gamescore” variables, which display the amount of flowers collected in the HUD and in the inventory. Because these are persistent global variables, each value will remain even if the figure doesn’t show. So when the player leaves and returns to level one for example, the figure will return to the previous global.gamescore1 figure.


The value of each is increased by one whenever a flower is collected, but now the room that the player is in affects which gamescore value is increased. I don’t know if this is the simplest method of achieving this, but I’ve set up the system in this lengthy but fool-proof way:


The || symbol represents the word or, so the top line of the code states that the following actions only apply if the player is in room 1_1 or room 1_2 or room 1_3 etc. The corresponding gamescore is increased by 1, the item collection sound is played and the information added to the appropriate datastructure list. The instance (the individual flower item) is then destroyed, as it has been collected and shouldn’t appear again! I haven’t had to create three different HUD objects as the player’s health remains constant throughout the entirety of the game, instead I’ve simply had to state which gamescore should be drawn depending on the current level. It’s a very similar process to before:


In order to determine whether a level transition will work depending on score, I’ve simply stated that gamescore1 must be over 9, gamescore2 must be over 14 and gamescore3 must be over 19. If not, the player won’t be able to progress to the next stage.


At the moment, the open transition is marked by my beautiful pink square sprite, so next on my to-do list is create an open door sprite to replace this with! You can now play all levels from beginning to end (as far as I’ve made, anyway.)

Devlog Video 2

This video pretty much sums up what I’ve been doing for the past few days, mainly with the background graphics and building interiors, and a few other graphical elements. From creating and playing back this video, I came up with an extensive to-do list based on bugs, flaws and things that don’t fit well or look right! My aim for this week is to fix everything that needs fixing, while away from the computer I’ve started to design the next level which now needs tracing.

Things To Do:

  • Sort out problems with the lighting (solved)
  • Sort out problems with particles (solved)
  • Delete accidental “invisible platforms” (solved)
  • Reduce the amount of lights inside small buildings (solved)
  • Sort out collision with cave walls problem (solved)
  • Animate some existing assets, like flags and the Maneki Neko
  • Make health restoration item
  • Apply more accurate collision masks to objects
  • Improve environmental tiles
  • Make new sprites for rope bridges, statues, outdoor tables & chairs and Ikebana

The biggest task here was the problem with the lighting system, which occurred when re-entering an already visited room. The code which draws the lights is called every time the room is entered, but because my rooms are persistent (changes to the room remain even if the room is left), the code was only being called when the room was entered for the first time. The result was that lights weren’t being drawn in revisited rooms, but would stay on from the previous room ie. the last place the code was called. I realised this by a long process of trial and error…

The rooms had to be persistent (or so I thought!) to stop the player from being able to collect the same flower twice. In a non-persistent room, the flowers would respawn if the player left and re-entered. There are however a couple of ways to prevent collected items from respawning, without having to create a room which is persistent. I found this post from the Game Maker Community forum to be really helpful. One of the solutions suggested on this thread is to use a datastructure, in this case a list of all items in the level with their own unique ID.


This is a script called gameInit, which is called once when the game starts. Gabriel Verdon uses a similar script for The Archer, to set global variables and position control objects etc. You can see that this script determines the keys used which correlate to the user controls, and generates the player object, HUD objects and the effects control object- all of which are persistent and remain throughout the game once called. At the top of the script, I added a generate list command, which will hold the information of flowers collected throughout the level.


This code is from the create event of the Sakura blossom object. The item is placed onto the list when it is deleted recorded by a unique ID, and this code commands a respawned item to be deleted again if it is on the list.

So now my lights stay on in the rooms they’re supposed to be on in! Most of the other fixes on the list were relatively little, some involved reducing collision masks and the rest involved clearing up some of my human errors. What I really want to see now is finished visuals.