Demo of GDevelop prototype for Mortem
Misplaced Lens Cap
tumblr dot com
Xuebing Du
Sweet Seals For You, Always
Jules of Nature

⁂
DEAR READER
almost home

if i look back, i am lost

izzy's playlists!

JBB: An Artblog!
Stranger Things
Three Goblin Art
cherry valley forever
Show & Tell

Origami Around

Kiana Khansmith
Monterey Bay Aquarium
AnasAbdin

No title available

seen from United States
seen from United States
seen from Türkiye
seen from China
seen from United States
seen from United Kingdom

seen from Türkiye

seen from Germany

seen from Brazil

seen from United States

seen from Netherlands
seen from Ireland

seen from United States

seen from Türkiye

seen from France

seen from Netherlands

seen from United States
seen from Indonesia

seen from Brunei

seen from Germany
@n10061207
Demo of GDevelop prototype for Mortem
Game Project Postmortem
We have now finalised our prototype for Mortem and are in the process of finalising our report for submission. I am happy with what we have achieved for our game. We have all the elements working correctly and it now has a more polished/visually appealing look to it.
My role ended up being a little more focussed on programming (albeit the programming with GDevelop is not true programming as it’s done through an interface). The process to incorporate the final sprites and their animations was more involved than I first expected. While controlling the animations was straight-forward (similar to what was done in workshops), the more complex game features required for more advanced controls for the animation (e.g. using variables to control player falling on moving platforms). I was also able to develop further from what our game developers had done in terms of player death, as I was now adding more depth to include additional sprites (e.g. amending the rules for player death when in contact with the new world borders). The last few tasks that I completed for the game were making sure that it was running smoothly, consolidating/finalising global variables to ensure all scenes were consistent, and cleaning up our project folder (mainly for images as editing through GDevelop creates multiple iterations for an object’s image).
There is always room for improvement, so this game would not be considered final, but it is a good next version for the game. The improvements that were planned from the play testing results were integrated.
Our team worked well together. We had different strengths that suited the roles we were allocated. We reviewed our progress around once a week to ensure that everyone was on track with their tasks or to discuss issues/make decisions regarding general gameplay.
Demo of game to follow.
Mortem Game Progress Update
Quick update for our group’s game project, Mortem, specifically what changes have been made since we play tested.
As we already had the core design of the game done for the first version (mainly to show the open world), the main differences are graphic/animation. As my roles as artist/animation programmer, I am in progress of finalising the look of game and ensuring that the final version is a more aesthetically pleasing experience for players.
Aside from graphics, we have also made/are in progress of making the below changes to the game mechanics, in addition to minor changes and fixing bugs that players noted in play testing.
- NPCs now explain why they need a coin/clearer explanation is given for the purpose of the NPC.
- A different world border is to be created so that is doesn’t appear the same as the portals used to transfer between worlds.
- Menu page has been added so that players are sent straight into gameplay. The graphic side of this is still to be completed.
- Different screens for the different endings are to be completed to give players a visual representation of their outcome.
Book Chapter Postmortem
My postmortem of book reading for chapters 13-16.
Project Planning:
I found it interesting reading about the project planning for game development. As I’m studying computer science (programming), my projects quite often use agile sprints to track project progress. While this isn’t something that was utilised in depth for this project (whether or not this was done correctly; the team only used a general timeline for the project), it was interesting to see how it can be applied to a different style of project.
Communicating Designs:
One aspect of this that we did utilise for our project was using a flowchart to map our game. As we have an open world plat former with (although limited) multiple levels, we created a flow chart to track how these levels connected to each other (copy of chart included below). The other aspects of this chapter were similar to what was done for Assignment 2, by providing visualisation and description of the game. The description part in particular I thought was relevant to me as it explains to list game’s details with specifics that I didn’t realise was necessary for an early stage game idea (something that affected my result for Assignment 2 - I hadn’t realised the level of detail that was required - not just that players move left or right but what button/s were used to do so, or what number of health they start with/is taken when they are hurt).
Game Industry (Genre):
The main thing that stood out to me for this chapter was that when I was applying these genres to our game project, it wasn’t clear where it fit. The best suited may be Role-playing as we’ve given players a character in a situation and they have to make choices, but this is combined with more action (less story) than what is usual for a role-playing game. Our game could also fit into Experimental, as it has a unique enough concept/design (with it being an open world plat former with different, almost puzzled levels). One play tester had even mentioned that it was somewhat similar to Super Meat Boy, which is one of the games listed under Experimental.
Selling Yourself:
I found this chapter was of less relevance to me personally, as this unit for me isn’t a stepping stone to learning more about game development or becoming a game developer. In saying that, the general concepts (aside from specifics of pitching game ideas) can be applied to most careers if there is a need to showcase completed work.
Game Mechanics - Choices
Just a quick post to touch on my thoughts around game mechanics (choices in particular), as one of the topics for our blogs was ‘Another Interesting Mechanic’. A few of weeks ago in one of our lectures they were discussing RPG mechanics and how to design for choices/making choices work and be enjoyable for players.
This topic is relevant for our game project, Mortem, as we are creating a platformer that allows the character to make choices and have different endings based on the choices they make. One of the main choices the players face is whether to save a follow soul by giving them one of the player’s coins. In the initial play testing, players noted that (aside from it not being explained clearly) that they weren’t sure why they would want to give up their coins for other souls. We are now working on crafting the endings so that players have a positive ending (sent on to Heaven) if they save multiple souls. We are also adding in prompting to steer players towards this choice by making it a morale choice. The other souls will ask a player to spare them a coin, which will then turn it onto the player whether to deny them (pushing them closer towards a negative ending; getting sent on to Hell), or to be kind and help them.
By doing this we are aiming to evoke an emotional decision from the player. While the players will be informed of the choice they are making, they also won’t be aware of the effect of their choice (option for players to know how to achieve different outcomes, but not what those outcomes will be). We are also balancing this with it being a weighted decision, as giving away coins to help others may have a different consequence (player needs a coin of their own to pass on).
Prototype Play Testing Notes
This week we conducted play testing for the first playable version of our prototype for Mortem. This included getting 5 naive (to the game) players to do an initial testing of the game for feedback. This feedback will be used to make changes to the final (next playable) version of the game.
I play tested one person, Chris Sykes, who is a relatively experienced game player who, while wouldn’t choose a platformer as his favourite, does enjoy a good platformer.
His play testing results are included in my post today, along with a summary of the overall play testing done by the group.
Notes Summary:
Full Notes (player was recorded during testing and notes were fully developed after testing was complete):
Overall Survey Results for Group:
I believe the play testing was a success. We got some good feedback from our players and are starting to put together our findings, with notes on how we plan to improve the game for the next version. I am particularly excited to focus more on the graphic/animation side of the game now, as that was something we had mostly left out for the first playable version.
First version of our game, Mortem, to be play tested. Developed with GDevelop
Assignment 3 - Development Progress
The team has finalised the first version of the game to be play tested next week.
Development: So far, only the very basic elements have been included. The levels were developed the most, in order to give players a structural idea of the game. Art and animation were left to a minimum for the first version, as these elements are in progress, to be developed fully for the final version. Some game features were also left partially developed. All major errors were fixed so that a working version can be used for the play testing. The small bugs have not yet been fixed.
Progression: development began by creating the structure of the scenes; creating the platforms and sprites. The scenes were first sketched out by our level designers, then created in GDevelop by our programmer. The scenes were then developed further with the creation of scene events and object behaviours and a small selection of draft art was added.
We then finalised the first version of the game and discussed/started producing the play testing documentation. This included putting together a questionnaire, a survey and some prompting questions to ask the players during testing. As the upcoming testing had been anticipated, the team had already organised players.
Assignment 3 - Planning
Planning phase of project was completed this week.
- Group was formed during the workshop (4 members). Programmer, Game/Level Designers, Artist/Animation Programmer.
- The Game: Team discussed ideas for the game and voted on a pitch from a few options. The game pitch was then fleshed out and roles were assigned. A project plan was formed for the development phase.
- My Role: Majority art and animation, contributing to play testing and documentation, assisting with game development if needed. This was interesting for me, being a programmer, with less involvement with programming and more focussed on graphics/appearance. I do have attention to detail for design, which is why I was chosen for this role.
- Game Name: Mortem
- Genre: Platformer
- The Pitch: You are a lost soul who just recently died, as you wake up, you find yourself in a hellish environment with Death telling you to go and collect gold coins if you want to pass on to the next life. As you wander around, you find other lost souls who are unable to pass on as they did not collect their coins in time and are beginning to fade into nothingness. The players can then choose to either let them fade away and collect the coins they drop or give them more coins so they may pass into the afterlife. Player’s choices will affect the ending the player will get in the end.
- Unique Selling Points: Multiple Endings, Free Roam Map, Morality Choices
- Controls: A/D for Left/Right, Spacebar for Jump, E for Interact
Racing Game - Postmortem
GDevlop Experience: I found it slightly harder to configure the racing game with GDevlop. It took a little more time than expected to control/center the camera, as the positioning wasn’t as expected and a fair bit of adjusting was required. As with the asteroid game, development was more focussed on movement and collision than animation, especially force to get the appearance of passing other objects.
Elevator Pitch: While I didn’t implement the specific features of my racing game pitch, I do believe it would be possible to implement it for this style of game, without needing make adjustments to the pitch.
Feedback: The main notes I got for this game was that it was less of a racing game and more to do with object dodging and reaction time. The implemented suggestion was that an end game screen is shown when the car crashes, as it’s odd when the car disappears and everything else keeps moving.
Improvement: The additional features that I would add to this game would be increasing the difficulty (increasing the speed/force of the objects) as the game continues, shift the challenge style to be how long the player can last and what score they can get before they crash. I do think that to do this, I would have to also increase the screen size to allow for a better chance of reaction.
Choices/Decisions: There is little option for decision for this style of game. Players can choose which lane/approach they want to take to avoid collision, but the main choice is only avoid or crash.
Emotion: This game would evoke a fear/stress type of reaction if the player is trying not to crash. This especially would be the case if the game was improved to have increasing difficulty.
Challenges: The main challenge is physical co-ordination focussed. The game challenges the player’s speed, reaction time, accuracy and timing to ensure that they move the car correctly and not too early or too late to avoid collision.
Difficulty: There is currently a small amount of difficulty, as it’s not a complex game. However, with no lives, it is unforgiving for mistakes in that one crash means games over.
Demo of racing game prototype developed with GDevelop
Racing Game - Elevator Pitch
Title: Dragon Derby Daydream
Pitch: Imagination is everything to a child. Timmy loves playing on his trike, but for Timmy, it’s more than just riding his bike in the backyard. Timmy is riding a dragon through the skies and racing in the Dragon Cup. Only the best dragon rider can win, before play time is over.
How to Play: Players play as Timmy and are immersed into his imaginary dragon race where they must race to win the Dragon Cup.
Unique Points: A racing game that is not the stereotypical car racing theme. Played from a child’s point-of-view. Themes of daydreaming/imagination, where the main setting is not reality.
Images:
Asteroid Game - Postmortem
GDevelop Experience: Once again I found GDevelop easy to use to create a basic game prototype. I found that creating an asteroid game required more of a focus on movement and less on animation. Where the platformer required multiple animations with multiple frames to show movement, the asteroid game needed the object to actually move (force, angle, speed) correctly, rather than appearing to move through animation.
Elevator Pitch: I am quite happy with my pitch for the asteroid game. I feel that it suits the style of the game, as it allows for more complexity (if levels were added or difficulty increased), but isn’t too complex for the style of game. It may, however, result in a low number of levels as there only so much a player can do and how difficult it can get when blasting baby turtles into the ocean.
Feedback: I didn’t receive too much feedback for this game, as there was limited play testing done. The players liked the concept of the game, especially the aspect of saving baby turtles by blasting them. I got the advice to make it a little more graphic; one suggestion was to add effects (splash) when the baby turtles are blasted into the ocean. Another suggestion, which was added into the prototype, was to have the baby turtles move towards the ocean in a straight line (x point remains the same), rather than having them all move towards the ocean’s center point.
Improvement: There is definitely a lot of room for improvement. I would have liked to add a timer to the game, as it is currently continuous, so that players can build their score within a certain time limit. I would also like to work on collision, either to make it so that the blasts can only affect one turtle or so that turtles can push each other. It could also be much more challenging; either have the turtles appear faster or have them move quicker. There could also be improvement on the spawn areas/starting angles, as some turtles were able to spawn at the edge of the screen and move straight off it, which causes the player to lose points without given the proper (fair) chance of earning the point instead.
Choices/Decisions: There isn’t much room for player options/choices with this style of game, as there is only one objective. Also, they only have obvious decisions to make (choose to save the turtle).
Emotion: I believe the concept of the game may evoke emotion, through the narrative/characters and game play. As the focus is on saving baby turtles, players may feel happiness when saving them, sadness when they don’t, or fear if they are worried that they won’t save them. It may also evoke a sense of achievement when they save more baby turtles.
Demo of asteroid game prototype, Turnaround Turtles, developed with GDevelop
Asteroid Game - Elevator Pitch
Title: Turnaround Turtles
Pitch: Baby turtles have hatched on the beach but they’re going the wrong way! They need help getting to the ocean. Use the water blaster to get them into the water as quick as possible, before they get too far and are snatched by predators.
How to Play: The player controls the water blaster and must blast the baby turtles into the water. Points are given when a baby turtle is saved and lost if a baby turtle gets too far.
Unique Points: Player is blasting objects to help them, not destroy them. Objects do not move in a direct line (turtles move around the beach randomly until falling off screen). It strays from the stereotypical setting for an asteroid game, as it is set on a beach rather than in space.
Images:
Platformer Postmortem
GDevelop Experience: After the two weeks of developing with GDevlop, I found it very easy to use for the basics that we covered. It allowed for a lot of action with objects, without having a complicated process to set them up. The only downside is that it doesn’t seem to allow for background layers or images, which would be a good feature.
Elevator Pitch: The only changes I would make to my original idea would be to involve the environment less. The idea was to have the environment evolve over the levels to not only look different but to have different textures/shapes. I have realised now that this would possibly have been difficult to do with GDevelop.
Feedback: The feedback was positive, main notes for improvement were just adding more features and for the environment. Also got the suggestion to include the death animation for the knight, which was added.
Demo of Platformer prototype, The Dark Wizard, developed with GDevelop