Onyxeagle

Week 13 was a busy time for both the game and myself personally (due to unexpected sickness) - luckily things have now mostly wrapped up, after a scramble to finish playtests. Much of the week was a rush to implement feedback from about two participants each - a group ranging from friends to siblings who had never heard of the game before. Going into playtests we'd completed levels 2 and 3, both of which explored different concepts and themes - 2 was very puzzle focused, with the twist of needing to dodge a large enemy rat. 3 on the other hand, was almost entirely exposition and narrative focused, which felt like a good way to end out Bean's journey.

The results of playtesting were both surprising and expected. Playtesters quickly found issues and gave feedback that the team had never considered - things such as how it wasn't always obvious that objects could be used as platforms or clicked and otherwise interacted with. This hammered home the value of playtests being able to point out simple features and QOL improvements (such as automatic highlighting on interactables) that were simply skipped over because it was 'obvious' to us how things worked.

Overall the experience creating The Way Home was illuminating. I got to work in a group with other people sharing similar passions and collaboratively worked on a shared vision for a game. Being much less directed then previous endeavors in the class, I found it very enjoyable to go for a more unconventional spin on things learned in class - namely, the game's focus on the story of Beans finding his way home. While it didn't quite cover the depth of story I might have hoped for, I learned much about everything from Gdevelop, teamwork, playtests and just game development in general. Moving forward, I feel that I could do a much better job the next time around - always, in my opinion - an important feeling to be able to take away from any project.

Week 11 came with the first developing prototype of our group project "The Way Home" - to start we had a title screen and level select.

Designing this was a unique test, as I hadn't previously done any prior work with menus. While not complex to delve into, I ran into an unexpected issue with the font - we had been wanting to use the Sue Ellen Francisco font for it's homey style, but the typical text of Gdevelop couldn't properly display it. The font was too tall for Gdevelop's display boxes, leading to the use of a free converter to turn the font into variously colored BitMaps for use in the game. Once this was settled, the main meat of the 1st level was created. We had decided on Beans - the new name of our feline protagonist - needing to explore the side of the building to find a way inside.

To do this, we used a couple of gently guided puzzles (a movable bin and a climbable drain pipe) to introduce the player to the game and it's fairly standard platformer movement.

Leading into week 10, we got to form groups of three with our peers as we prepared to get into assignment 3 - creating our very own game based off one of our OneSheets. During this, I paired up with the awesome Natalie and Brandon, where we decided to further develop Nat's design, called "The Way Home".

Going from here, we amended and worked over the onesheet to adapt it for the assignment. From the start, the group was eager to keep the unique charm of the proposal - we kept the platformer and story based aspect, focusing more on narrative and puzzles rather then hack-n-slash, infinite progression or the like. We decided to make 2-3 levels with the story and proceed from there.

In week 6 we received the opportunity to develop our elevator pitches for asteroids game. I'd been keen for this part in particular, as while I wasn't particularly inspired for my elevator pitch, I was excited to develop a game that was so different in construction compared to week 3-5's platformer.

Differences were everywhere, but the key ones revolved around the top down aspect, as well as the inclusion of obstacles to avoid - naturally this should involve a health system, and maybe even a scoring system for the player.

To avoid the cookie-cutter sameness of many asteroids games, I decided to do away with the very linear progression of typical asteroids, with asteroids planned to come from any direction, not just the top of the screen. To aid the player in this more free form approach, they are given the ability to aim their weapon independently of the ship itself - a mechanic existing to give the game a unique twist, something outlined as important by Fullerton on page 21, under "Designing for Innovation".

When I started creating the game in Gdevelop, I decided to use free-use assets from Craftpixel than the provided ones, as they had worked very well last week in making the game more vibrant. Finding an excellent ship sprite for the player;

Spliced together, four images from Craftpixel's free 'Asteroids' pack combine to form a nebulous background;

The final asset necessary for any good asteroid game is - unsurprisingly - the asteroids themselves. In this case, there was a conveniently included set of sprites included with the Craftpixel assets, already in a sprite sheet ready for splicing.

With my assets collected I got to work. The player sprite was given animations for moving, and set up with 3 key components of Asteroid games - lives, movement, and true to the name, a blaster. The unfamiliar part of this experience came when I had to actually set up an implementation of the Lives and Scoreboard system - it required global variables and linking those to text objects on the screen, along with triggers linked to asteroids being destroyed and hitting the player - a particular inclusion I was pleased with was the "force field" surrounding the player's ship, which changed colour based on lives. Looping the screen, I manually placed asteroids going at different directions so that they would naturally drift over time and prove a challenge for the player to evade.

circa Astro Blaster

When it comes to the design process, I wish I'd clearly outlined all necessary requirements I'd like to see in the game from the get go - I had somehow completely forgot how important a continuous and varying gameplay loop could be, and by the time I realized what was missing, it was too late.

Leading into week 4 our focus was on the classical Asteroids style games, typically represented by simple top-down gameplay consisting of destroying and avoiding obstacles.

Our goal is to - eventually - recreate said type of game for ourselves using Gdevelop. With this focus on Gdevelop development this week, we learned one of the most important aspects of development - the limitations of the system we want to use. For Gdevelop, it's greatest strength is also it's biggest weakness - simplicity. Gdevelop has quick and simple prototyping alongside an intuitive system. This comes at a cost of complexity and true control over the game system - while Gdevelop is perfect for simple indie games, it is insufficient for truly large and open ended games, alongside games like high-fidelity multiplayer shooters.

This week in class we discussed the latest tutorial activity - an Asteroid game, typically a style of top-down action game that has served as an arcade classic for decades. While I've never personally played anything more then a simple and barebones web-version, my elevator pitch is called "Astro-Blaster".

A typical representation of the game style, Astro-Blaster is an action game targeted at audiences of 8 and above. See the following synopsis; Lost in space! In Astro-Blaster the player will captain a small ship lost in an asteroid field, and must safely navigate their way out of a hectic place fraught with danger by using their ship's thrusters and laser cannons to avoid disaster.

Reference:

With the end of week 4, development of our prototype platformers came to a close, serving as a fantastic first dip into game design. This post will go over the influences on Starman and any insights on impartments for the next time I dabble in platforming.

Development of the game itself, while quick, was heavily influenced by the platformer Dead Cells - namely that it was primarily combat oriented, with a focus on the main character and his abilities, as opposed to exploration or worldbuilding.

In regards to the design of the game, Tracy Fullerton's textbook "The Game Design Workshop" (namely chapter 2) informed me of the importance of adding challenges to the game so as to keep the player hooked and wanting more.

Last week I began to learn how to develop a rudimentary platformer in class. This week I learned much about the process of Playtesting and receiving feedback. Unfortunately my platformer was in a very rudimentary form at the time, and so I got rudimentary feedback that nonetheless proved extremely helpful. Namely, that for the playtester, having snappy collision boxes and responsive controls was a must. Taking this into account, I dove into working. Given my elevator pitch - Starman - was also a platformer, I decided my prototype would try to hit the key parts of the elevator pitch - Space and Superheroes. To start off, I used a fantastic image created by X user @norma_2d in this post for my background:

Following that I downloaded a series of free pixel asset packs from CraftPixel to fit my theme - of which consisted of a punk sprite and a spacecraft pack. Teaching myself how to use SpriteSheets, I spliced them in Gdevelop and got to work, leading to the following;

The changes and additions I made consisted of: Setting the controls to WASD; Adding explosive death animations; Adding the ability to shoot a (deadly) bolt of light; Adding a glow effect; Adding punching, running and jumping animations.

My initial elevator pitch for a game is Starman - a roguelike platformer that attempts to evoke Dead Cells meeting superheroes. The theme itself would probably revolve around stars and space, as the game itself will consist of fighting your way through waves of enemies as you progress in levels. The difference of the game will be the tools you have to reach your goal - instead of typical swords and dodging, you will play as Starman, fighting with his fists and managing a bar of energy that fuels special skills like flight and various energy powers. This energy can be recovered faster by successfully timing your block with enemy attacks. This recovery will be proportional to the potential damage taken, hopefully promoting a high-risk high-reward playstyle.