Quick Fixes

Today I’ve been fixing up little bits here and there, rather than concentrating on something bigger…my intention is to clean up some of the game’s little blips before moving onto anything excitingly new. This is following on from my previous to-do list, which as the days go on gets increasingly longer…

  • Apply more accurate collision masks to objects
  • This I have done today, although most of the problems with collisions were solved by reducing the collision mask around the player object.
    Previous mask:

    Based on head dimensions

    New mask:

    Based on lower body dimensions (much thinner!)

    This stopped the player from gradually sliding down corners and standing on thin air! This also means that collisions with obstacles are more accurate, as it is often the body that contacts that obstacle sprite rather than the head. I’ve increased the masks for the mushroom and swinging enemies to accommodate for this reduction, but only slightly.

  • Improve environmental tiles
  • I haven’t done much to improve the tileset, but I’ve cleaned up some of the edges by adding corner details and rotating some of my existing tiles to fit in more instances.

  • Make new sprites
  • There were just a couple of things from the end of the level that I’ve omitted to draw so far, so I figured it was probably time to put these in. Among the sprites still to create was the “end object”- the door to the next level. This stays closed until all the flowers are collected (although I haven’t coded for it opening yet as there is nowhere to go!) The idea for the new sprite came from this lonely little place, that sparked my imagination.



    The orange doormat represents the colours of the next level…

    As well as these items from my previous list, I started to work on some more minor details that I wanted to be ready in time to demonstrate to others. I’ve spent a lot of time working out a parallax scrolling system which affects the rate that the background imagery moves at, although this isn’t quite finished yet as it produced quite a jittery result. I’ve also added in a code to randomly generate the cloud sprites I previously drew. This works by producing a small amount of cloud sprites just outside of the player’s view, scrolling each cloud along at a set pace and deleting them once they are off the screen at the other side. The code then regenerates each sprite at the same coordinates back on the first side of the screen, resulting in an endless amount of clouds.


    This seems to work fine, until you enter a cave or building and exit back into the main level. Instead of randomly generating cloud sprites at this point, they seems to align along the Y axis and scroll across together. This is probably a fault with my coding, however I haven’t figured out how to solve the issue yet…


    So I’m kinda just creating more problems for myself right now! As a de-stress technique, I’ve been sketching details into my new level design, which looks a little like this right now:


    Personally, I think this level looks a lot more like its original kanji than the previous design, but it’s still pretty tenuous!

    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.

    Draw, Animate, Code & Play etc…

    Drawing
    Over the past couple of days I’ve tried to prioritise sorting out my environmental tiles, but still haven’t really come to a conclusion. I tried to test out my new idea for rocky tiles with real parts of the level design, but so far can’t seem to make them work well as they do on paper! To stop myself from ending up in a rut, I’ve discarded ALL rocky texture tiles for now and replaced them with a plain purple colour, which can easily be swapped for a textured tile when I decide what it will look like!


    I made a little progress with the rock pattern around cave entrances however. I considered using straight edges around rock outcrops so that straight edges around other level features wouldn’t stand out so much, but didn’t feel this worked as well as the more natural, uneven design which is closer to my previous trace design.


    I tried this design here with my previous rock texture, but decided that the rocks looked better against a more plain background. Even if I bring a heavily textured tileset back for platforms, I may stick with a plainer tile for cave walls.

    Whilst trying to ignore all the complications of seamless tiles etc, I’ve diverted my attention to creating more Japanese-looking objects for the level. I’ve started by taking objects I’ve already made and adapting them to suit various instances, which is great for level continuity.


    Amongst these smaller features I’ve been working on some large objects inspired by specific Japanese things, like this shrine gate:


    and this bridge:


    Although, the reason for the bridge’s funny shape is because it follows the shapes of my platform mask tiles. I may round this off later to make it look nicer and have the character follow the tiles rather than the shape of the bridge.

    And I finally got round it pixelising the small food stand that I designed about a week ago. You probably can’t tell even if you’re Japanese, but I attempted to write ramen “らめん” in hiragana on the sign!

    Without the ground texture tiles, the game definitely doesn’t look as “nice” as it did before, but the more empty spaces of the level are starting to fill up. (I haven’t built the lights in this screenshot either, which is why it looks so dark!)

    Animating
    In time for a proper working level prototype, I wanted to get many more character animations in. Before now, I’ve simply had one continuous running animation! I’ve only created the basics so far: running, stopping, jumping and climbing ladders.

    To make the character stop you could use a single frame of the character just stood still, but I like to keep the character moving to ensure the player that the game is still running! Before now, I’ve used a breathing motion by making the character move slightly up and down, but where Hana is made of so few pixels, any rearrangement of pixels results in something far from “subtle”. I think a breathing animation is out of the question, unless I find a clever way to do this. For now, I’ve created a couple of frames that make her look fidgety when stood still, and a blink frame that flashes up irregularly.




    For the jumping animation I’m currently only using one frame, although I would later like to add another to differentiate the character jumping up and coming back down.

    My climbing animation is currently universal, used for climbing up and down ladders. This particular animation works best for climbing down ladders, so I may later add another one which looks more like climbing up a ladder.

    Coding
    The main bulk of the coding I’ve done over the past couple of days has been in the character step function, which controls the way the character moves. With all the new sprite sequences, I’ve had to customise things like image-scrolling speeds for each individual animation and can no longer rely on one over-ruling command.

    I’ve split character movement into two separate “modes”-one fore running, jumping etc. and one for climbing. If the player is not on a ladder or in mid-air, the player is on_ground (this is a ready-made variable that comes with the Grandma Engine.) If the player is on_ground, the rules of horizontal movement apply, including sprite sequences and player input. If the player crosses a ladder but does not climb, ie. does not press up or down, then the rules of on_ground still apply.

    if on_ground && place_meeting(x,y,obj_ladder) && !keyboard_check( key_up ) && !keyboard_check( key_down ) {
    can_c = false; }

    But, if the player crosses a ladder and does press up or down, can_c (short for can climb) becomes true, and the rules of ladder climbing apply. This code is pretty similar to the code I wrote before for vertical movement, but I’ve added sprite sequences and image-scrolling speeds. As you can see, I’ve applied the climbing animation twice, once for each vertical direction, so if I wanted to I could use two animations that would represent each direction.

    else if (place_meeting(x,y,obj_ladder)) {

    vspd = 0;
    can_c = true; {

    if (keyboard_check( key_up ))
    vspd = -S_MAX_V /4;
    sprite_index=spr_hana_climb;
    image_speed=.1;

    if (keyboard_check( key_down ))
    vspd = S_MAX_V /4;
    sprite_index=spr_hana_climb;
    image_speed=.1;
    }

    I haven’t written much other than this, but I’ve added a few lines of code for more warp objects throughout the level. This has helped me create some clarity where caves are involved, as I have created two new rooms for caves that are joined to the main level by these warp points. Now you can see a definite distinction between the outside and inside of the cave parts!

    Outside:

    Inside:

    Playing

    Adding a lot of visual features doesn’t occur easily whilst play-testing, due to the fact that in Game Maker the platforms are made of these red-block objects that cover the background imagery. They need to do this so that I can see where I’ve put platforms! But at the same time, I can’t see if I’ve made a mistake with the imagery below. So when I’m editing tiles and want to see how they look in-game, I have to add these red blocks temporarily and delete them again afterwards. One major criticism of Game Maker is that it doesn’t allow bulk actions to be applied to all instances, so each block must be added and deleted individually, which is a looooong and tedious process. My main focus is still on visuals, but I’ll build the complete level for a play-test from volunteers next week.

    This concludes my lengthy summary or the past two days!

    I’m still having problems capturing videos of gameplay, so until I work out how to sort this out/find an alternative to Hypercam, I’ve strung together some screenshot highlights of my game so far.

    This week’s aim was to create a level which was playable from start to finish and included some of the functions that would be seen in the final game. The result is a playable place-holder graphic level with a basic placeholder HUD (“Heads Up Display”) containing level progression info. Below is a list of all the current features…

    Incorporation of the EasyLighting system

    So far I mainly have lights inside the first building, some of the lights can be seen in the image above. When the player moves into a light source, the light affects the brightness of the sprite’s colours. A comparison can be seen below, when the character moves into an unlit area.

    Ladders

    When the character comes into contact with a column of red lines such as this one, the custom variable “canc” is enabled which I’ve set up to allow for vertical movement. I’ve used some of the Grandma Engine’s custom variables such as “vspd” (vertical speed) and “S_JUMP_SPEED” (jump speed). The current climbing speed is half the value of the jump speed, which I’ve currently set to -5.25. This has actually resulted in climbing speed which is faster than the walking pace, but I’m keeping in for now for faster level testing!

    if (place_meeting(x,y,obj_ladder)) {

    vspd = 0;
    canc = true;

    if (keyboard_check( key_up ))
    vspd = S_JUMP_SPEED /2;
    if (keyboard_check( key_down ))
    vspd = (-S_JUMP_SPEED) /2;
    }

    Press up to warp function

    Previously, warping from room to room occurred on contact with the “warp” object (invisible in this screenshot!) In this instance, the warp object is placed in front of the door, so that when the character came into contact with the door, the character would be automatically transported outside the building. The X and Y coordinates for the door are the same in both rooms, so the character arrives in the new room in the same location.

    Since incorporating this feature, I’ve adjusted the mechanism to only warp when the “up” key is pressed. This was quite simply achieved by adding the line:

    if keyboard_check ( vk_up )

    to the code!

    Item Collection/Level Progression

    I’ve dotted some of my sakura objects around the level for player collection. On collision with the character, the blossoms disappear as they did before to avoid the player picking up the same flower twice.

    I’ve created a very basic HUD which tells the player how many flowers they’ve collected. Each time a blossom is collided with, the figure (starting at 0) goes up by one. This affects the global variable “gamescore”, controlled by a HUD object which always appears in the player’s view rather than on a fixed point in the level. The object contains draw commands which tell Game Maker to draw the figure “0” followed by a string of text saying “/30”. This is currently just a random figure as there aren’t even 30 collectable items in this level…

    Player Hit Points

    Underneath the level progression information is a figure representing player health. This needs the most work so far! I’ve currently set this figure to start at 5, and decrease by one every time a black blossom is collided with. These blossoms also disappear on contact, so you can only be hit by something once. The “enemy” objects probably won’t disappear in the final game, for now I have simply set it so that health cannot reach 0. I don’t currently know what will happen when this figure reaches 0! But it will probably re-locate the player to a designated re-spawn point.

    As for the rest of the level, I’ haven’t really made any changes but I’m hoping to work on some new tiles soon. Tracing the level design by hand has given me some really good ideas for environmental tiles and objects. Hopefully I’ll get a video up and running very soon!

    EDIT: My Devlog Video 1 is now online! And nearly works.