Final thoughts

So I’m finished, more or less. I still have a bit more work to do on my GDD to submit tomorrow, but as far as implementation goes: I’m done. Overall I’m happy with what I’ve created. I set out to make a small-scale 2D platformer with a twist on one of my favourite game-mechanics (Fez’s rotation), and thats what I’ve produced. As far as beign a fully-fledged indie game goes, it’s nowhere near. The art and aesthetic is rudimentary, with a lot of room for improvement, and I feel that the level-designs I’ve produced don’t make the most interesting use of the core meachanics. However, in the time-restricted scenario of coursework, I feel that I’ve produced a solid product.

I feel that my overall design approach was solid. I had a good idea of what I was aiming to produce from the get go, as laid out in my initial pitch presentation. My consistent blogging has documented every part of this project in detail, and clearly illustrates the problem-solving and continuous iteration that the development process consisted of. Every bug, development and new idea/decision is recorded in this blog, resulting in a comprehensive account of the development of my game. This has been one of my favouite modules this term. I feel like assessment of our “Design Process” could have taken a million different, much drier, forms, including essays/reports and small design tasks, but the use of a small-scale game-dev task (combined with developement documentation) provided an engaging and interesting assignment, and I’ve learned a lot while working on it.

While complete with regards to the assignment, as I talked about above: AntiGravity is by no means a finished game. I fully intend to continue working on it in my free time, as I still have lots of ideas to try and areas of the completed product that I want to improve upon.

IMPLEMENTATION/DESIGN/CONCEPT? So we were required to have some sort of playthrough video as part of the submission of our GDD. With pretty poor screen-cap software, and no video-editting suite to speak of, the video isn’t much of a playthrough. More of a teaser video. Anyway. Here it is. 1minute of off-the-wall, crazy hectic gameplay. Just wild.

DESIGN/IMPLEMENTATION:

I added the starting captions to the levels that I felt required them. They pop up, provide a bit of exposition/context to the level and a control tip (if a new mechanic is being introduced in that level). I feel pretty satisfied with the game as it is now - I’ve done as much as I can in the time left and I feel like what I’ve created is fairly close to what I had in mind when imagining it. The core mechanics work exactly as I had imagined, with the only real issue I can see being in the isual polish and the overall aesthetic. My art-abilities are hardly exceptional, but given another week or 2 I think I could have created a much more detailed tilese, and some much better level-backdrops. Anyway, onto the documentation.

A Release

So I have distributed my game to gamejolt - a free online host for indie games. It is playable at: http://gamejolt.com/games/platformer/antigravity/62096/

The issue is - this doesn’t allow the work around for the rendering bug. In order to achieve the animated world-rotation, I had to alter the world bounds and the levels location. This, however, means that at a normal browser-zoom (100%), the bottom half of the levels are rendered off-screen (depending on monitor-size). In order to avoid this, the browser must be zoomed out very far before the game-page is loaded. Once loaded, you can zoom back in again to 100% wihtout causing the rendering bug. Or this is normally the case. With a distribution on gamejolt, you have to specifiy the canvas size for your game. However, if you specify a size larger than your game requires, the game is scaled to fit the larger canvas. This negates any posibility of having a larger canvas to accomodate the zooming in/out required to solve the rendering bug, ultimately meaning that in the gamejolt distribution, half of some levels are not rendered. It’s a pain, but it is what it is. At least I have a non-repo release.

DESIGN/ IMPLEMENTATION:

I drew up some backdrops for all the levels in my game now. They’re by no means exceptional or particularly artistic, but they’re certainly a lot better than the empty black background that they all had before. Plus some of them add a bit more context to the level design. For example, the 2nd level is just a vertical “tube” with the player spawning at the bottom, and the door at the top. The player must utilize the gravity mechanic to reach the exit. By having the backdrop as a broken ladder, it provides a contextual reason for the player needing the ascend a tall vertical space, and also reasoning as to why they cannot just climb to the top - the ladder is broken. I’ve also solved a couple of bugs/come up with a couple of work arounds. One issue was that when the player was holding the crate above their head, and then alternated gravity, the crate didnt reposition to remain above the players head - instead it remained at its absolute position which was subsequently below the player when upside down. To solve this, i just have the player drop the crate when reversing gravity. Perhaps a bit cheap, but it solves the problem and honestly it isn’t too outrageous to believe that the player wouold be unable to hold onto the crate during the gravity-inversion.

I also have the pause menu included on all levels. The final thing to do is to add starting-captions to levels that require some exposition/context. Then I need to update my GDD in preparation for tomorrow’s playtest, which requires me to record a short playthrough video.

IMPLEMENTATION / DESIGN / CONCEPT:

I’m 95% done now. I completely redid the tileset, i still want to add some more detail to it but it looks a lot nicer than it did originally. I’ve also created and included more levels. I’m at 9 now, with what I feel are 4-5 decently challenging ones. 2 contain the glowstick mechanic with no lighting aside from it. I’ve got 2 bugs to iron out: when a crate is picked up and gravity then reversed, it needs to remain above the players head (at the moment he ends up standing on it when revesed gravity is in effect), and i also need to remove the massive jump that occurs when the player picks it up. I also need to add some text-overlays to a few levels to provide some exposition/context regarding the controls and other things. I’d also like to add an opening animation to provide the main exposition to the game, though this is something i’ll only do if I have the time. I’m aiming to get the text overlays and bugs sorted tonight so I can work on a good animation for the opening tomorrow.

IMPLEMENTATION: So i found the the cause of an extremely annoying bug - when you progress between leves, occasionally a door will spawn twice, so that when the door’s plae is used to open itm another door remains behind. I had NO idea what was causing this, but I’ve figured it out. It’s happens when the door is open at the change between levels. I.e. if the player opens a door and then triggers the next levle loading before the door closes, it will spawn again (i’m assuming because the doorXOpened variable i store for the opening/closing cycle remains false). All I need to do is reset all the values upon progressing between levels and it should be solved. On a different note, I’ve decided not to implement the timer as I haven’t enough time to write a work around for the fact that it doesn’t stop/reset when it should. I’ll add a counter for rotations in a bit so there is still some level of score-keeping, but the time-constraint wont be used.

IMPLEMENTATION: So I’m working on adding the timer before I add some aesthetic polish to the tilesets/animations. As you can see, the timer works and is counting down, and when it reaches zero it ends the game and displays the pause menu (at the moment - Im drawing up a game-over menu also). However, it’s a bit buggy.

The timer works on the game.time.now value, by subtracting the elapsed time from the time I want to allow players to complete the game in (probably half an hour?). However, this.game.time.now still increases while the game is paused, meaning that when you unpause, the timer carries on as if the game was not paused at all - if the game is paused for 5 seconds, the timer will have elapsed by 5 seconds upon unpausing. This shouldn’t be too hard to solve as I read somethign in the phaser docs a while ago about the time object containing parameters/functions regarding the last-pause, so I’m sure there’s somethign there I can use to account for pause-time. The other issue is that restarting the level, or exitng to the main menu, then restarting, doesn’t reset the game.time and so doesn’t reset my timer. I’ve utilized the game.time.reset() method in the create function of the game state (which is started/restarted from the main menu/pause->restart button) but this still doesn’t work. So if you restart the level with 30seconds left on the timer, it will begin with 30 seconds left on the timer, and not reset. I’m really not sure what to do about this if im honest. The time.reset call SHOULD work as i want it to - the phaser docs explain that it sets the time._started value to the current game time. But it’s not working. I may have to just remove the timer. I’m not sure I have the time to play about with it and add the level of visual-improvement that I want to with the time i now have left (today).

IMPLEMENTATION/DESIGN:

Added door opening animations as well as a sound effect for it. Obviously the sound effect isn’t aduible in the above gif,, but it’s basically just an electrical humming/buzzing sound to punctuate the animation. The door is like an energy-shield (or something like that), and so opening the door disipates the shield, which the animation is supposed to reflect. I’m no artist but I still think it looks a lot better than just having the door disappear. This is officially the beginning of the end: I have my 5 levels (i just need to add the tutorial ones, which are already made up), so now im making it more presentable. I have a few more animations to add (to the player, for example), and then I need to improve the tileset. All of that will be done tomorrow, as I am sorting the final bug with gravity tonight.

IMPLEMENTATION: Got the pause menu working now. Just had to do what I said yesterday, where I had to map areas of the screen to a function (like restarting the game-state, or going to the main menu state, or unpausing) when the game was paused, and then determine which “area” a mouse-click event took place in and call the relevant function. The game can now be paused, resumsed, level restarted, and quit to the main menu. Time to come up with a final level.

IMPLEMENTATION: Behold: glowsticks.This provides good context to the work around I did for the lighting whereby the player can activate it on their location, but the light does not follow them. Now the player drops a glowstick at their location which illuminates the area. They can drop another at any location, but the first one is removed. It was easy enough to achieve. I just added a new object using a quick sprite mockup I did, and then change the source of the light to be the glowsticks location. Im thinking of making them a pickup now, whereby the player must collect their delpoyed glowstick before they can place it at a new location.

IMPLEMENTATION / DESIGN / CONCEPT:

I’ve got a pause menu working now. It’s not exactly pretty, but it’s just a placeholder I was working with while I got it working. I utilize the game.pause attribute which literally pauses everything in-game. This caused an issue though, as it also pauses the registering of key-inputs. With the pause function bound to the P-key, once paused, the game would no longer register the P-key presses to unpause. As a result I had to add a further mouse-input event handler, which only fires when the game is in a paused state (so that clicking during gameplay doesn’t do anything). At the moment the buttons on the menu dont work - you can just pause the game with P, and unpause by clicking outside of the menu. The way I’ve achieved the menu is by just adding a menu-image as a sprite to the world when the game is paused. Because you can determine the coords of the mouse-click event, I unpause the game should the coordinates of the event be outside of the pause menus location on-screen. I’ll achieve functioning menu-buttons in the same way - just determine the coordinates of the click, and perform the relevant action if the click occurs within the coordinate-bounds of one of the buttons.

Once I’ve got the menu buttons working I’m gonna finish off the lighting with glowsticks. I’m thinking of having them as a pickup. The level will start in darkness, with the glowstick in a certain position, eminating light, and when the player walks over it they’re able to pick it up. From that point on they’ll be able to drop a glowstick at will to illuminate a location. I’m nearing the end now - I need another level, the glow-stick sprite/mechanic (which im doing next), and then I’ll apply some polish to everything - work on the visuals and improve the overal aesthetic of the game, add a timer, add sound effects, and possibly some text-overlays to provide context to the levels (though this may prove to be too ambitous with the time I have left).

IMPLEMENTATION: Okay. So I’ve gone with a quick fix to solve the performance issues that the lighting effect was having.

The fps was pretty choppy at times because the black-filter that appeared over the world AND the light-circle had to be updated each frame. I’ve basically just altered the lighting to be an additional mechanic. In the context of the game-world, the player has “glow sticks” that they can drop at any given time, but doing so will remove the previous glow stick dropped. Basically, they can activate the circle of light on their current position at a given time (though there is a time delay between activations). Reactivating it calls the update-lighting function, snapping the light-cricle to the players new current location. This sovles the fps issue as the update-lighting function will only be called when the lighting button is pressed, which cannot occur more than once every given time-period (e.g. 5 seconds). This means that it is not being called every frame, and prevents the performance deficit it caused before. I also think it actually makes for a more interesting mechanic than simply reducing the players field of view. By having the opacity o the filter such that the level is just visible without the light, the player is stil lable to see where they’re gong to an extent, as well as seeing roughly where doors are. However, the dark colour of the pressure plates causes them to be invisible at this opacity. As such, the player must explore and utilize the glow sticks mechanic to locate plates.

IMPLEMENTATION:

So I had a play with the lighting effect I’d discussed before. I found examples of similar effects on Game Mechanic Explorer, and they were simple enough to adjust for my purposes.

Basically, you establish a texture the same size as the world, and set its colour (in my case black (rgb(0,0,0)), effectively blacking out the entire world. Then you establish an opaque (1 - alpha channel ) circle of “light” (white) around a given point - in this case the player.

The issue is this seems to be quite an expensive task to complete, as the light-circle has to be reestablished every frame. This is cause some noticeable fps dips - if i cant improve the efficiency of this operation, I may have to opt not to include it. Hopefully I can though.

DESIGN/IMPLEMENTATION:

So last week I took another break from this to focus on a different assignment; I spent all week making an online auction-house site. Anyway, that’s done now so I’m coming back to this. Working on level design. I’m almost certain that level design just isn’t my thing now - I’ve been racking my head to come up with ideas and I’m struggling somewhat. Anyway, here is a new level with a somewhat increased skill-requirement of the player. The initial sketch depicted in image 1 was somewhat basic but it’s realised and improved upon in image 2. I’m still aiming for 5 decent levels plus a couple of tutorial-esque levels. I still want to add that other level where the lighting is flashing/failing. I mean that feels a bit like artificial difficulty - substituting complex level design for a superficial mechanic that makes a simple level a lot harder, but I think the lighting thing would be neat to play around with and it’d only be in one level. There are 2 options for this lighting:

- flickering vision of the entire level, including the character and all objects and terrain. OR

- no lighting in the level, so nothing is visible, except around the player who emintates an aura of light. It extends to a certain radius, outwards from the player, creating a circle of visibility around them. I’ll play with both options and decide which i think is the best. I also have another idea for a level where the player is trapped in a room adjacenet to the level-endpoint, with a single door separating them. The player is unable to have any direct effect on the level, as they are contained within this room. The player must therefore utilize the rotation and gravity mechanics on crates alone in order to open the door that allows the player to reach the exit. With these 2 ideas, and the 2 levels I already have, I’d be nearing my target. I’m shooting for finishing 1 level a day at the moment,  so I’ll have all the levels done by friday and I can spend the weekend polishing it off: adding sound, menus and the timer.

IMPLEMENTATION: Had to take a break for the past 2 weeks to focus on other work. The end of term is here and i’ve had deadlines all week for other modules. Anyway, they’re done now so back to this. I sorted out the crate pickup issue where it would rotate around the players body - just had to add a lock constratin in addition to the distance constraint.

Originally, this meant I would have had to have a flag to represent whether the crate was on the left or right of the player, and adjust the constraints accordingly - before, the crate was always being picked up on the players right-side, so if it was on his left side it would shoot to his right side instead. But instead I just decided to have the crate picked up above the players head - regardless of the side the crate is on, it will always be picked up above his head. Hooray for cutting corners!

I need to get my head back into this. 2weeks off and Ive forgotten a lot of the logic I was thinking about the last time I was working on it. Some mechanics need a bit of polish - crate-pickup sprites need to be added, the players gravity still screws up on 1 or  2 orientations when he’s upside down for some reason. Then i need to add some general game-polish - an updated tileset, some sounds, a nice shiny menu system.  Oh and I also still want to add the lighting effect on a level somewhen.

All of the above should take me like, 2 days max I reckon. The key focus is on level-design. I need to have, say, 3 good levels that are puzzling and fun. That’s the part that will take a bit longer.

IMPLEMENTATION/DESIGN/CONCEPT:

Added crate pick-ups. Instead of just nudging crates to move them, the player can now hold onto them and drag them around. This allows for much more accurate crate movement and allow the player to use crates much more effectively so solve problems.

It’s not a perfect implementation yet, I need to add some frames to the player when they’re holding a crate (sticking arms out in the direction of the crate so it looks like he’s holding onto it) and so on. Also need to prevent the crate looping round the player when infree fall like in the gif above.

I have been working on level design some. The level shown above provides more of a challenge than previous posts, having multipe crates that the player must use to reach the end, as well as concealing the crates behind doors themselves, creating more obstacles for the player to overcome.

The level also utilizes the conveyers. 2 conveyers are palced either side of a pressure plate the player must use, overlapping it slightly. The challenge this is supposed to pose to the player is 2 fold:

1. Simply put, the plate is harder to spot due to being concealed by the conveyers. The player may not initially notice it  and puzzle over how to open one of the doors for a while before finding the plate

2. The conveyers being so close together will prevent the crate from sitting on the plate and holding the door permanently open. As soon as the crate touches the plate, the door will open, but it will also be moved off the plate by the conveyer. The door will then run out its timer and close. The player must therefore time placing the crate on the plate to allow them enough time to get to the door it opens and pass through.

I’m honestly struggling with my level design somewhat. I feel like it isn’t my forte. I definitely have enough core mechanics in place (that complement each other) to create some decent puzzles in-game, I just struggle to piece all the separate mechanics together into a cohesive whole level. But i’ll continue to work on it. The assessed, final playtest is the first week after the holidays, so I’ll have a good amount of time over easter to work on it and pump some good levels out.