FMP Production

The creation of the game

The first think I had to do was create the project itself, so I set the size of the viewport to the standard size, as I felt like it would work well in my game, though I can change the size later whenever I wish to make adjustments.

I then made a simple level layout, and added a player sprite as a size comparison, this is pretty much exactly what my level design plan looks from my planning page. I may change the level slightly depending on possible future gameplay issues or any issues arising with enemy movement/ detection.

I then added some simple code to the player sprite, which allows the player to move. The 8 direction code allows the player to simulate the directional movement, which will need some graphical tweaking once I move to the graphics, as the player doesn’t face the direction they move the whole time. One small issue I encountered was the sprint code, which didn’t work as intended.

This allows the regular enemies to walk up and down throughout the various corridors within the map, all the code does is toggle a boolean instance variable that moves the enemy back and forth appropriately. This ends up working perfectly, as the enemies now patrol as intended with no downsides.

This is the code featured in my game that allows the circular patrolling enemies to patrol in a circle. This was done through the use of boolean instance variables on the enemy, which are the up, down, left and right pieces of code. The enemy’s collision with the yellow markers then enables the next boolean, and disables the previous, allowing the enemy to move in the correct way, simulating a circular motion.

This was the old version of the aforementioned code, which obviously didn’t work for one reason or another. It was after a short amount of brainstorming that I realised I should have used boolean variables in the first place, leading to the next set of code working.

I initially intended for two enemies to be patrolling parallel to each other in a circle, but the code didn’t seem to be working for some reason, so I scrapped that code too. This was intended to provide players with a bit of an extra challenge, as they would have to better time their movements across the map.

Reflection – In the past week, I managed to create the level layout and then place several moving enemies across the entire map, with only a small amount of problems. The biggest issue I encountered was with the enemies that patrol in a circle, as this kept failing to work. I then had to settle with only using one enemy walking in a circle, which left me a little disappointed but still satisfied with the existence of one. I will most likely be revisiting this to see what went wrong and to see if I missed anything.

This is the sprite I designed for the detection radius, it has a simple design and works to show the player where the enemies can see, and thus where to avoid. The design in game is changed slightly, as I have made it so all detection indicators have an opacity of 60%, which means it is see-through but still visible.

Here is the code that pins all of the detection elements to their respective enemies. While there isn’t anything that stands out about this code, the reasoning behind the inefficient use of sprites is. When I implemented the detection mechanic in the first place.

The above gifs show the two phases of character movement I designed. The top one is slightly too fast due to the selected framerate, but is also less detailed than the latter. The second one is a much more detailed drawing than the original, which I ended up using for my game. The sprite is a lot more detailed due to the size increase of the actual sprite itself, which is scaled up by about 20 pixels. These animations showcase the simple movement that is initially in the game, which will be followed by other forms of player movement, such as movement while aiming with a gun and possibly sprint movement.

This is the walking animation for the standard enemies featured in my game, this follows the same rough template as the walking animation for my player, but the design itself is changed a fair bit, this design is quite simple and is open to further modification (such as the addition of a rifle held in marching formation), though will most likely stay the same for simplicity’s sake. The design itself is based off the real uniform for a British soldier in 1899, as seen in my planning page.

The idle animation for the game consists of a single still frame, I found this to be the simplest option, as I couldn’t find a particularly good way of portraying small movements a person might make, from a top down perspective.

This is an animation made for the keys that the player picks up near the start of the game. For these keys I decided to draw a large ring of keys, as I found it to be quite comical. The keys themselves have a shine animation for them, which indicates to the player that it is a pickup item.

This may look a bit confusing from a top down perspective, but this is supposed to be a victorian wrought iron gate, which will be used to cut off the area leading up to the final door to escape the level. This gate will be unlocked by the aforementioned keys and will be guarded by one or two guards.

This is the art I made for the tile that will be placed on the floor across the level, as I plan to use it in a tilemap and plaster it across. I designed this small piece to infinitely loop once placed next to another of the same design, so that the tilemap doesn’t have any issues with it.

Reflection – The main thing done after my last reflection, was the movement animations, which took less time than I expected, they do, however, have some small issues regarding their conflicting priorities with other animations. I also designed the sprite for the keys, enemy walking and idle animations, as well as the key gate and floor tiles. I did, however, decide to change the floor tile idea, as the tilemap had several issues, and didn’t feel right when I placed it in the game, so I switched to a simple dark background with some light detailing and decided that it looked miles better than my original idea. As for my schedule, I am more behind than I would have liked, but completion of my work is more than possible with the remaining time I have.

This is a screenshot of the code I made to allow the player to aim and shoot. The top section shows the aiming, which is a simple “Right button down” event, which sets the player to the aiming animation, while in this animation the player is set to follow the mouse location (MouseX, MouseY). Once the player is in the aiming state, they have the ability to shoot, this is done by left clicking in the direction you would like to shoot. While the code itself is good, I have come across some issues in regards to the actual animations themselves. The main issue I am encountering is the player’s movement when aiming, as the player can still activate the movement animation, but it jitters the character about, preventing them from moving anywhere, while repeatedly playing the first frame of the walking animation. This is only done when the player tries to move and shoot, which shouldn’t happen too often.

I received some feedback that mentioned how dark the level was, and was provided with a suggestion of adding some light to the game, so I brainstormed some ideas, and thought about several options. One option was to provide the player with a torch of some sort, and providing the enemies with one too, so that the important elements of the game are still visible. The other idea I had, was to implement dim lights across the entire level, which I decided would be a much better idea than the former.

The layer itself, is completely black and has an opacity of 60%, this provides the level with a sense of darkness across the whole level. This initial darkness makes it hardly visible across, requiring the use of lights dotted around the level, to provide vision for the player.

To make these lights, I added sprites around the level that I had painted on with the brush tool, in black. I then resized them and placed them around the level, and made sure I had changed the blend mode to “destination out”, which basically inverts the sprite and cuts it out of the level, specifically the darkness section. After this had been done, it provided the level with “lights” across the entire thing, I had also done this in a different style for the lighting in the key room, which is more of a square light.

This is the animation I designed for the aiming feature. This animation will play when right click is held down, making the player aim their gun. This will then make the player face wherever the mouse is currently pointed, so that they can shoot where the mouse is.

Reflection – Since the last reflection I implemented a lighting system in the level, which provides the player with a bit more vision, as per some of the feedback I have received. These lights cover the entire map and provide it with a dim source of light, so that the player can actually see. The other big thing I implemented was an aiming and shooting system, which admittedly took me way longer than it should have done. It still has some issues I’m trying to work out, but other than that it seems to be working decently well. The biggest issue with the aiming system, is that it is affected by the walking animation, as attempting to walk while aiming makes the player move incredibly slowly, because the game is trying to make you do them both at once. Despite the annoyance, this issue will almost certainly be fixed by the next reflection.

After thinking about various different ideas for detection, I decided to go with the most simple one, using a global variable to control the detection number. The variable, and following code, made it so that the number goes down as the player is in the detection cone. The number variable initially started off as 100, but I eventually changed it to 50, as having a detection of 100 felt way too strong, as it allowed the player to be more reckless and not need to plan out movement, as they could just walk through the detection and not have to deal with the consequences. I also added a feature on the main menu, which allows the player to press a button and change the “difficulty” of the game, which essentially changes the global variable number to 1, meaning players immediately lose if they so much as touch the vision cones.

This is the animation I designed for the assassination the player can perform, this can be done by walking behind an enemy and pressing E. This will only work when the player is in the detection box for the attack, as I wanted the player to have to sneak behind an enemy to be able to attack them.

I had meant to record this section and put it up way earlier in the production, but I must have forgotten to do so.

While going through my level’s code, I encountered several issues with the initial code that needed revision. As it turned out, the animation issues I had involving the walk cycle, which was conflicting with other issues, could have easily been solved earlier with various conditions.

Reflection – In the past week, I designed the animation that goes with the melee code, which took me far longer than I would have liked it to. The animation itself started being worked on by me last week, and has only now been finished, granted I have been working on a lot else at the same time. I also went back and changed a lot of the code I initially implemented into the game, such as adding conditions to the movement that allow animations to flow more smoothly.

The first question asked on the final feedback sheet was in regards to presentation and game graphics. Unfortunately most of the responses focused on the presentation, which at the time of the feedback was unfinished. However, there were still a couple of answers that provided some insight into how people felt about the graphics of the game itself.

The next question asked people what they thought of the gameplay, which were mostly positive, and made me feel quite confident in my ability to create a fun game.

For the question placed on my itch.io page, I asked “does the game make you feel stealthy?”, and the following are the responses to that question.

These answers told me that I had succeeded in my initial design focus, which was to make the player feel stealthy. I had these answers across the board from my feedback and felt successful in my main design focus.