texmakesgames

[texmakesgames]

Bird-Gular Post-Mortem

(The final version of the one page design document for Bird-Gular)

This project was an excellent opportunity to experience other peoples approaches to design and problem solving. I never would have designed this game on my own, so much of it is built on interesting concepts and ways of thinking that were provided by my team-mates Jayden and Oliver. 

It was also an excellent chance to practice iterative design with a large project. The problems raised in playtesting were really interesting to try and solve, and the solutions have significantly impacted the shape of the game. 

I personally was focussed on fixing the recurring issue of players being confused as to their goal. Several ideas were thrown around, including an arrow which always points towards the elevator (the players ultimate target on each floor), however, research I have seen shows that when you give a player such a clear and obvious arrow, they never explore. To encourage exploration you need the player to be intrinsically motivated (self motivated), and so I implemented the softer option of a simple mini-map that only shows: your location, where you’ve been, and an ‘X’ over the elevators room. Whilst only a small difference, the map being in the corner rather than on the player, and the fact that it isn’t constantly updating, encourages the player to ignore it until it is needed, whilst not leaving them to be completely confused. Numerous other fixes and additions were made by the team and I.

(The minimap in top-right corner of the screen, green is the players room, white is previously visited rooms, x is the elevator)

If we were developing this prototype again, one thing I’d change is that I would have put less effort into art early on. This is a point brought up in Tracy Fullerton’s “Game Design Workshop”, that there is a risk in creating art for early playtests that it will need to be scrapped. Earlier on I could definitely have spent less time working on the games graphics, and more on the actual gameplay and design. Ultimately this meant that when it got to a time when art was needed I would have had a better idea of scale and feel, and the art may have ended up being more cohesive and clean.

(The upgrades menu elevator between levels)

One thing I would change about the prototype is the debugging tools. The random generation is excellent in game, but it makes level design a bit of a pain to test, and so it would have been wise for us to implement a simple piece of code that goes something like: if global variable “testingLevel” != 0, then set generation to Level “testingLevel”. It is such a quick fix but we never got around to it cause the inconvenience was only small each time, but it added up, and it would definitely add up if we were to start adding dozens of levels.

In conclusion, I am really happy with this project, and really enjoyed working with this team.

[texmakesgames]

Bird-Gular Playtesting

first off, there have been several development changes since the last devlog, but the most notable one that I had a part in is adding lights to the game:

By shrouding the level in darkness, and having light emanate from the protagonist, it creates a feeling of mystery and danger, and significantly increased the difficulty and player experience of the game.

This leads onto playtesting, with the first big thing found being that players really did enjoy the mystery and exploration aspects of the game. This was tied with the feelings of fear and exhilaration when players were chased by a guard, which was the response we were hoping for.

There were many issues with the playtest however, all of which have been compiled into a large detailed findings table:

To save time I shall focus on the major playtesting issues, and possible solutions.

“Why am I collecting gold?” - This was a common issue, but also is easily fixed by a planned addition. We just need to fully implement an Upgrades shop in between floors/games. 

“The characters movement feels slow”, also, “The guards movement feels too fast” - Guard patrols can be slowed, upgrades can be included to increase speed, and a sprint button could be added to give the impression of speed.

“The objective is confusing“ - This was the single biggest issue, everyone repeated this sentiment multiple times. To help with this we can add a minimap, and add lights to the elevator so the player sees it when they enter the room.

“The guard saw me through a wall” - The flashlight has been one of the largest issues in this games design. Unfortunately Gdevelop doesn’t have an easy way to do obstacle clipping, so I have tried many techniques to simply get the flashlight to not go through the wall (Using light objects, raycasts, drawing the flashlight using the in-engine draw tool, constructing the flashlight as several segments, etc.). The current version of the flashlight has multiple animations, with each frame being shorter, and connected to a collision object. This still has issues, but we can roughly fix it by increasing the size of the collision object, and adding more in-between frames.

There are many other bugs, level design mistakes or just little tweaks that need to be made, but those are the largest and most game breaking issues.

[texmakesgames]

Bird-Gular Devlog

Me, along with Jayden Manton and Oliver Rutland, are developing a stealth based rouge-like about a bird trying to reach the top floor of a building. I am responsible for art, as well as a bit of design, QA and bug-fixing. 

(the one-page I made for bird-gular, presenting the art style as well as an example of the potential threats and challenges)

I have been following chapter 8 of Tracy Fullerton’s “Game Design Workshop” to improve my methodology for digital prototyping, especially for this team based prototype. 

Page 244 is on prototyping Aesthetics. What this section focusses on is the balance between providing enough Aesthetics to communicate an idea or feel to playtesters, without wasting time on art might end up being scrapped. This influenced my approach to art, pushing me away from adding polish and scene fillers, and towards working on concept art, user interface, and the basic art required to communicate the “feel” of the game to players. In order to get a bit of scene filling without wasting time I have modified free assets from the “Kenney” organisation to produce the plants and gold, giving me more time to focus on the art that does need to be personalised.

(The main menu, designed to provide a quick tutorial to playtesters, get the feel of the game, provide credits, and simple controls for sound)

Page 260 contains a section on “Selecting Viewpoints”, which was helpful when dealing with an issue the team had early on. Partially as a result of reading this section, we have elected for a minimalist UI and a directly top down perspective. The top-down perspective was chosen as it works best with the gameplay, and allows the player to be aware of the guards and gold in each level. 

The reason we chose straight top down rather than the  more commonly used orthographic was to provide ease of level design. GDevelop doesn’t have an easy to use inbuilt Tile Map tool, so an art style that would require multiple sprites for each object just wouldn’t work. It also sped up art production, as each object only needed one sprite rather than 4 (or 8), which is excellent for fast turnaround. 

The UI is extremely minimal to not distract the player from the threats onscreen, as well as to provide ease of play and a feel of immersion.

[texmakesgames]

Jog-Simulator Post Mortem

Jog-Simulator was developed with a heavy focus on game feel, what chapter 8 of “Game Designers workshop” refers to as Kinesthetics. However, I should perhaps have paid more attention to chapters 3 and 7, and spent more time actually thinking about what the objective of the game is, and potentially making some physical or video demonstrations of the idea.

If I could go through the design process again I definitely would have focussed down on a single mechanic, the crowding behaviour, and developed that to its fullest extent. I should have designed a quick (potentially physical or simplified) prototype and begun testing out of the gate. This would have allowed me the data to figure out how to design the mechanics, and would have provided data for setting up variables such as the size of the swarm, size of the characters and the flexibility of their connections. 

Relatedly, if I could have changed the prototype I would make it simpler, but easier to tweak. Essentially, I should have focussed less on AI and attacking, and instead made the actual player character (swarm) a robust and simple to edit object with numerous variables for each aspect (Elasticity, wall bounce, accelaration, max speed, swarm size, character size, distance between objects, etc.). This would have made a much more useful prototype for gameplay balancing purposes.

[texmakesgames]

Jog-Simulator Playtesting

I seriously over-scoped Jog-Simulator, and as such with playtesting, the aim was especially to find out which aspects were of the most interest to players. Here are the comments provided by playtesters, as well as any comments or solutions I have in response:

“Satisfying when you hit the wall” - This was a relatively common thought, and highlights that similar to games like “Human Fall Flat” there is a lot of potential for visceral collisions in the swarm mechanics. To heighten this I’d have to rework the movement a little, and potentially make each person larger (or the crowd larger)

“The camera is too slow to keep up” - This is true, as the runners speed up the camera pans too slowly to hold everyone on screen. This is an easy fix, with a variable for camera speed that is related to player velocity.

“Being able to go anywhere is nice” - This was just a little comment about how the fact that you weren’t tied to any particular direction was nice. It does highlight a larger concern that I had though, which is that this game might work better were it not a racing game.

“If the bowling mechanic worked it’d be fun” - People generally liked the idea of the bowling mechanic, which is reasonable, it was part of the intended gameplay loop, and the game feels a bit lacking without it.

“Needs enemies/consequences” - This is true, this prototype is barely even a game as there is no real competition or what Tracy Fullerton’s “Game Designers Workshop” refers to as Dramatic Elements. 

“Collecting people is fun” - This was my intention, and I am glad that it was peoples response.

[texmakesgames]

Jog-Simulator Devlog

I have over scoped this project. 

The art used is mostly from a free Kenney assets pack, as I felt the mechanics were enough work without adding custom art.

In the past week of development I have gone through numerous iterations of a “swarm” mechanic. The problem’s I have experienced evolved from the basic issue that the “move as a group” mechanic is a mixture of gameplay, kinematic and aesthetic design. I have used chapters 8 and 11 of Tracy Fullerton’s “Game Design Workshop” to aid with the various tweaks and versions of the game mechanics. 

Unfortunately, I still have been unable to get the core mechanic working as smoothly as I would like, and the need to use Gdevelop’s Physics system has made the movement too glitchy to be even aesthetically pleasing. I have some ideas of how I could change it and focus more on one aspect (such as physics or aesthetics), but I will have to wait until playtesting to receive a clearer view over what people enjoy of the game. 

[texmakesgames]

Jog-Simulator Elevator Pitch

Teamwork makes the dream work in this brutal dystopian nightmare. Groups of Joggers are set against each other, each trying to achieve the fastest lap time in order to be freed from this eternal cycle and return to their families. In order to increase speed a group needs to increase its size, with the moral support boosting the maximum velocity of a herd. To gain new runners, unlucky joggers are  rolled at their opponents, hoping to knock them down take them into their own crew. 

A racing game, based around the mechanic of building a large herd of runners. The larger your group of runners the faster you can run. Every herd has an ability to roll one of their runners forward (like a bowling ball), in the hopes that they will scatter a group ahead of you and allowing you to gather up all the scattered people.  

Unique selling points:

- Weird controls

- A trade off between offence and defence, for every attack you make reduces the size of your herd

- Strange dramatic elements

This sort of game is targeted at the puzzley arcade game audience, the sort of people who would play “what the golf”, or “qwop”

[texmakesgames]

Smashteroids Post Mortem

The final version includes some minor art improvements, as well as a piece of introductory text and a oscillating wave of difficulty. The difficulty was implimented by setting a variable for the time between each asteroid spawning, starting with a long pause between each for the player to get used to it. this is slowly reduced, until it is down to one second, at which point the number of spawned asteroids starts being counted. Once this reaches a critical point (a variable I called “Swamp” because the player is being swamped) the timing resets and the player gets a pause to breath. But, the “Swamp” variable is increased each time, meaning that the periods of high density get longer and longer, increasing the difficulty as you play.

The entire process of this game’s design was very iterative, and I used a lot of the prototyping advice from chapter 8 of Tracy Fullerton’s “Games Design Workshop”, with multiple iterations going from concepts and storyboards, through gameplay, aesthetic and kinematic tests until reaching the final prototype. 

There were many flaws with the development process for this prototype, but I feel the most notable was that I didn’t playtest early enough in development. It would have been helpful to perform many stages of playtesting throughout the grey boxing prototyping period, so I could have got the gameplay and kinematics down smoother before working on the art and overall Aesthetics of the game.

The thing I wish I could have added to this prototype was different types of asteroids, and especially the ability for asteroids to break apart into smaller asteroids. I was too busy getting the basic gameplay to implement this, which was ultimately worth it, but I still regret not being able to add this extra bit of design. 

Ultimately, I am happy with how this game worked out. I could imagine making a full version of this, most likely in a different engine with vector graphics and more complicated asteroid collisions, but as a prototype I believe it works well enough (even if it is perhaps a bit difficult). 

[texmakesgames]

Smashteroids Playtesting

I was unfortunately ill for the playtesting period, but did manage to get a few very nice folks to play the game online, and was able to get a small amount of playtesting feedback. Here are: Their comments or questions, what I think is the underlying issue, any ideas I have for solving it:

"At the beginning, the game wasn't too intuitive, and I didn't know what I was doing", "The objective of the game wasn't clear until a little bit of experimenting" - This was one of the more common complaints, and was extremely understandable. I didn't think about it, but if you were expecting asteroids, a game where you avoid getting hit in order to destroy things, it is not intuitive to play a game where you must charge through things and defend somebody else. - To solve this would most likely require: adding a piece of tutorial text to explain the aim, and maybe adding a difficulty curve where the asteroids become more common.

"The gravity messing with my control becomes quite frustrating", "the ship changing direction once it got pulled into the planet... it screwed up my maneuver mid-control" - This one is also understandable. When designing the prototype I had to make the drill automatically flip when it collided with the planet tail first, but the flip is jarring and was an unhappy compromise. - I don't exactly know how to solve this. I will have to try different means of flipping the ship, or potentially have the ship rotate as it nears the planet, making it less jarring.

"the number of asteroids made it difficult to learn to master the controls early on" - This is very self explanatory and completely reasonable true, I had only gotten used to it because I had been testing it for several hours. - The simple solution to this would be to start with few asteroids and slowly increase the number generated, maybe using a scene variable to control the timer duration.

[texmakesgames]

Smashteroids Devlog1

I started development with as many simple prototypes, using advice gleaned from chapters 7 and 8 of Tracy Fullerton’s book “Game Design Workshop”. as such I first attempted rough on paper ideas, essentially storyboards of how the drilling and gravity mechanic would look, before moving to GDevelop for digital prototyping. The first prototypes were to test game mechanics, and went through several tries to get working. Initially I tried using physics objects, like I did last time, but this made the digging to floaty. Eventually, I figured a reasonable way of doing gravity without physics, simply using object variables and adding forces to the character.

I spent some time prototyping the Kinesthetics for the character and movement, messing with forces and speeds, and adding an air dash to provide a feeling of floaty maneuverabilty in space to contrast the tight control while drilling. I made some simple art, aiming to get an Aesthetic feel for the prototype version, rather than have a fully detailed game.

According to chapter 3 Tracy Fullerton’s book “Game Design Workshop”, there are ten major types of objectives in games. Asteroids, the original, falls under the objective “Capture”, as the aim is to destroy targets whilst not getting destroyed yourself. For the game I am designing I hope to change the objective slightly, so instead the main objective will be “Chase”, as your character is trying to chase down the targets before they reach the planet, which you are defending. 

Through prototyping I realised that the game also could fall under the objective of “Alignment”, as with some slight tweaking a player could line up several asteroids and drill through them. This was done for the latest prototype by refreshing your boost upon destroying an asteroid. I added some more art, a health bar, small tutorial and score card, leaving the game looking like this: 

[texmakesgames]

Smashteroids Elevator Pitch

The intergalactic mining conglomerate hopes to harvest the rare minerals from an uninhabited planetoid. The only problem is that an asteroid storm seems set to destroy the small world. Armed only with a drill you must defend the planet from the approaching projectiles. The only problem is you have limited space mobility, and will have to build up speed by digging through the planet before launching into space.

Control Diagram: The game focusses around a central planet, with the playable character being able to dig through it, building in speed as they do so. When they leave the planet the character no longer accelerates, and instead is pulled by a gravity style force toward the planet, until they are eventually pulled back in. Asteroids of different sizes will fly at the planet, and the aim is to drill through them to break them apart. If they collide with the planet too many times you lose.

Unique selling points: 

- a back and forth between building speed and floating through space

- interesting gravity mechanics

- an aim to defend a large stationary object, leaving your character safe and powerful

[texmakesgames]

Ultra - Neon - Playtesting - Devlog

There were many comments and questions from play testers: here is a list of most of the questions that needed fixing, and the solutions I implemented:

“why are you small when you jump?” - I added to the double jump tutorial.

“what is a wall jump” - I didn’t even think that some people don’t know what a wall jump is, but I added the term to the tutorial when a play tester asked me this

“wait, are orange objects physics objects?” - added a sentence to the tutorial text introducing the orange objects, making it clear they act like the purple ones as well.

“what’s the missile?” - added a sign indicating the missile, shown below:

“how am I safe from the missile” - made the instructions clear that the missile freezes when you are on black objects

“the climbing section at the end of level six is impossible” - moved that section further away, adding a longer buffer before the missiles can get to you

“white objects feel like they are slowing me down” - they were, I fixed this by making the player frictionless when touching them

“the arrows in level 6 can be deceiving” - this was true, I removed them

*immediately goes on top of the white platform in level 6* - I don’t know how I missed this, but for some reason I assumed they’d go underneath. I added platforms and a missile to the  top to make both sides dangerous

“the start of level 6 feels like you can’t strategize, it’s sort of random” - this was sort of true. I added a block to the right of the missile, allowing the player to avoid it if they stick to the right walls. This is a bit of a quick fix and I would rework this if I had the time.

Here are some things that I didn’t change:

*Immediately presses R when they see a sign saying “press R to restart”* - this I didn’t fix, as I couldn’t decide whether it was bad, or educational, as it made them remember it

“the white object tutorial is hard to read” - I also didn’t change this, as having the player move back and forth teaches them how the white objects work

“what you need is a timer” - there is a timer, but it is not very well implemented and obviously wasn’t that clear. However, I get the feeling that that sort of systems code would be time consuming in GDevelop, so I focussed on the core gameplay instead

Thus Concludes this Devlog - the last for this project. The next post will be a post mortem.

[texmakesgames]

Ultra-Neon-Inter-Spatial-Post-Mortem

To begin, I believe I may have gone a little overboard on this prototype. I don’t know that I will do so with the next one, but it taught me a lot about Gdevelop and playcentric design in general, and I am ultimately glad that I put in the time. The origin of the idea for this game was “all objects are affected by physics when colliding with the player”, which was so strict a limitation that it was almost immediately abandoned. Borrowing a lot of idea’s from Chapters 1,7 and 8 of Tracy Fullerton’s book “Game Design Workshop”, I early on tried to put myself in the mind of the player, and this lead to many decisions that improved the actual playability and fun of the game. A major early example was to add platforms that remained stationary when touched. This small addition gave the player a bit of respite and grounding and kept the levels from getting out of control, but it also made it, too some extent, less “interesting” from a design perspective. As the development progressed I definitely started to lose perspective with the player. The difficulty and the snaking levels mean that whilst I was already adept and able to find myself around, I had tunnel vision that let me see the correct paths. I introduced playtesting early (though still later than I could have) and I received so much useful feedback, which all went into improving the accessibility and understandability of the game. The major thing this improved was the tutorials and direction, as I was unable to predict what people wouldn’t understand.

If I had to redevelop the prototype the major development change I would make would be to make most of the systems of events global. This seems like a small change, but it would have allowed me to design the mechanics more iteratively. This would allow me to easier add some mechanics, make a few levels, playtest, tweak and repeat, whereas containing all the mechanics in each scene caused any change or addition to require me to go through and rework every scene, and as a result discouraged me from level designing and playtesting until near the end of the development. 

If I could change the design of the prototype in any way it would be to focus on the speed running element a little more, specifically by improving the timer to keep a continuous record of the players time throughout the whole game. If I had made it global I could have done this, however I was too focused on other things to look into global variables, and I didn’t know if people would want it. Playtesting, however, proved that players would have liked this feature, and my last lecture taught me how global variables could work for the feature.

Still, I am happy with this prototype, I feel I got an opportunity to explore the idea more than I have in previous game jams. The focus on playtesting and itterative design has made it more fun than it would have otherwise have been, and I would consider adding to the game in the future. The game can be found on itch.io here: https://neighbourhood-snake.itch.io/ultra-neon-inter-spatial-soul-drifter

[texmakesgames]

Ultra - Ghost - Coast - 2 - Coast Devlog 3

The last week of development has mainly been split between 4 main tasks: Small Additions, UI, Level Design and playtesting (which is split into its own devlog):

Part 1. Small Additions - 

Before I even got to bug fixing, level design and playtesting/QA, I had some small things I wanted to add: 

- I added in some synth music (I had some lying around from a pack of assets I got in a Humble Bundle in a while), as well as a sound for the missile, which gets louder as it approaches (This took longer than was reasonable as I kept trying to use maths for a gradient approach, but I ended up just adding in 3 specific stages of volume) and an explosion sound, which also cuts the music for a second. 

- I added numerous simple text tutorials into the world, allowing the player to simply move past them if they want to, but ensuring a new player will see them simply by playing the game. 

(a tutorial in level 0)

- I also added many arrows to direct the player, especially when their target is offscreen due to the limited view of the camera. Often, however, not following the arrows will allow for a faster but more difficult route. This is to encourage speed runners thinking outside the box. 

(an arrow directs the player where they should jump)

- As can be seen in the above pictures, each level has a different background and lighting colour, shifting from bright white in level 0, through sunset orange, to dark purple in level 6.

(the levels get darker as the difficulty increases)

- I also added a new object. The white object does not get dynamic when collided with, but instead has 3 unique properties: 1. It is frictionless, and makes the player frictionless when collided with. 2. When colliding with it the left and right buttons no longer have any effect, meaning the players speed and direction remains the same. 3. If the player holds the jump button while underneath a white object they can stick to its surface, allowing the player to flip back and forth from the ceiling and floor.

(the player flipping back and forth from the ceiling and floor)

Part 2. User Interface (UI) - 

Three types of menu’s have been added to make the game more accessible:

- The first added was a simple pause menu, allowing the player to stop the game and return when they need too, simply using GDevlelop’s ‘pause and change scene’ Event’. 

The pause menu set the precedent for much of how the subsequent menu’s were made, using text objects, and then using events to detect if the mouse hovers over them and clicks, changing the size of the objects to signify that they are being selected. 

I also added a moving player object to the pause menu that loops back and forth across the screen to make the menu more interesting and tie it into the game. 

(the pause menu)

- The main menu was made next, with the major difference being a looping title. this was done by simply moving the title object and changing it’s x position back to zero when it gets too far, with some overlap text to make it seem more reasonable. this set the precedent for how all the menu title’s would work. I liked it enough to go back and change the pause menu title, adding some jokes to the scrolling text. The main menu also included a volume button, which just changes the games global volume.

(the main menu - the colour of the title changes every second)

- The third type of menu was a intermission at the end of each level, allowing players the option to replay a level rather than forcing them straight to the next level. I had some fun with the scrolling title’s for these. My major regret is that I didn’t manage to connect the level timers to the end screen, as that would have encouraged speed running.

(the end of level 0 - every end screen has a different looping title, level 0′s says “No More Tutorial!”)

Part 3. Level Designing - 

I have made 6 levels (and a tutorial level) which aim to introduce the player to new ideas one at a time, allowing them to improve slowly. Level design took a lot longer than expected, as the precise nature of the game causes a delicate balance between too-easy and too-hard. One of the most significant design decisions is the length of each level. These levels are very short, to prevent frustration from having to replay long portions of easy section only to continuously die at the end. The aim is to make the game feel fluid and non-repetitive. One of the major design ideas I followed is the Mario gameplay loop of: Introduce an idea > test the player on it > move on. This ensures that every new mechanic is taught fully to the player one at a time.

- Level 0 is more of a tutorial, teaching the player how to move, jump, double jump and wall jump. It is important to me that games are accessible even to those who haven’t played other games before.

(Level 0 in full - Level 0 is the only level fully surrounded by solid walls, meaning that it is impossible to lose. It also means that intrepid speed runners could go around the left and finish the level quicker, which was intended)

- Level 1 is very easy, and aims to introduce the player to the physics when touched mechanic in a safe environment. The only really dangerous point is a seesaw bridge which is very easy.

(Level 1 in full - the block at the beginning serves only to demonstrate the mechanics.)

- Level 2 serves both to test the player with the purple objects and then introduce the orange objects mechanic of allowing the player to slide up them.

(Level 2 in full - the verticality of the level is allow for demonstration of the climbing mechanic with the orange objects)

(the bridge in level 2 looks dangerous but is actually quite easy, aiming to make the player feel skilled and provide a small thrill)

- Level 3 introduces the games primary antagonist: the missile. The missile was introduced in the last Devlog, so I’ll just briefly recap it: the missile constantly follows the player, its speed can be set differently for each level, and it freezes if the player touches a black platform. As such the layout of black platforms significantly impacts how difficult the level is. Level 3 has many black platforms close together, giving the player time to breathe.

(Level 3 in full - if it weren’t for the missile level 3 would actually be easier than level 2. This was partially because I believed that the stress of the antagonist would make people play worse, which ended up being true in playtesting.)

- Level 4 is the first level to not introduce any new mechanics, and is a test of the accumulated skills the player should have picked up by now.

(Level 4 in full - large spaces between the black platforms reduce the chances for the player to take a breath. the looping nature of the level allows the possibility for the player to skip most of the level if they are clever. This is another part intended for speed runners, as it is quite difficult)

- Level 5 introduces white platforms, and is almost exclusively focused on them, trying to teach them to the player before the last level. The real danger in this level is that you can’t accelerate on white objects, so the missile will catch up with you unless you outmanoeuvre it.

(Level 5 in full - the layout is extremely long to make use of the sliding mechanic)

(the introduction of the white objects)

- Level 6 is the final level. It is intended to be a difficult obstacle course of all the previous mechanics. It had the most changes from playtesting, as I struggled to get a good balance of difficulty but not impossibility.

(Level 6 in full - the largest level in the game, includes long vertical and horizontal elements)

(level 6 also contains 2 missiles. This was not that difficult to implement, but I had to apply a new variable to the missiles, lights, and trails to get the second missile to have a trail)

[texmakesgames]

Ultra-Neopets-Inter-Galactic-Snake-Skater Devlog 2

Since the previous devlog the game has been fleshed out to the point that all that's left for a full prototype is a collection of playable levels and a UI. Here are the most notable challenges, changes and additions since the last devlog:

-  most of the objects in the game use GDevelop 5’s physics object behaviour, which works well, but inherently has the effect of making larger objects harder to move due to inertia. This can impact the flow of the game, but reducing all objects density (or increasing the players) results in the smaller objects not feeling like they have any weight at alll, which is also bad. to solve this I added a variable called density to all the objects, allowing them to be set on an individual basis.

(a large cube, set to a density of 0.1, thus allowing it to be pushed)

- I made some simple animations for the player character. 

(idle)

(run)

(jumping/flipping)

The animations had a problem however: In terms of physics the player character is still a square, and so would tumble through the air and land on whichever side collides with an object. The animation, on the other hand, is a person, meaning they have feet that should be on the ground (or at least on the wall if they are wall running). This took a while to fix, but in the end I created four objects called testUp/Down/Left/Right respectively. these where placed on the corresponding sides and hidden. then I could just check if any of them collided with an object and rotate the character in the corresponding direction.

(The running animation flips to the side facing an object, allowing wall running)

In the end I actually realised that the more minimalist design of everything being squares worked better for what I was trying to do anyway, and the animations were ultimately scrapped, but it was useful practice in pixel art and debugging.

- I added a timer to the top of the screen to keep track of how long you have taken, adding a small incentive for speedrunning. The timer was actuallly quite a pain to implement due to how GDevelop handles variables, but in the end I used a string variable for the current time, as well as a integer variable which counts up every time a timer on the actual timer text object counts to one. 

- lighting was added to the player to make the game more visually interesting without sacrificing the minimalistic design. 

(all the objects have the light obstacle behaviour, resulting in them casting nice shadows)

- The game was fluid and floaty, but there was minimal pressure for the player to move swiftly. I tweaked an idea from ‘N++’ and a few other games and added a missile that follows the player through the level. unlike many other games however, this missile doesn’t explode after a time, or if it collides with a wall, in fact it can push walls out of its way. The only thing that stops the missile is standing on the safe platforms scattered throughout the level, which freezes the missile in place. I am considering making these checkpoints, but I am unsure about GDevelops capability to do that.

(the missile chases the player character, pushing blocks out of its way)

The missiles max speed is determined by a scene variable, meaning as the levels progress the missile could get faster and faster, and also that a potential difficulty selector could change the missiles max speed (an easy mode could also potentially remove the missile)

I spent some time getting a suitably stylised explosion using the particle  generator, as well as nice particles for the missiles tail and the players shadow.

(the player explodes)

- to increase the overall destruction in the game I added the feature that objects colliding with other objects also makes them dynamic, meaning there can be be knock on effects.

(without objects being able to push other objects)

(With objects being able to push other objects)

- I had given the player character a double jump, but I found it difficult to tell when it had been used in practice. I borrowed an idea from ‘Celeste’ (in which the character’s hair changes colour when you have used your air dash) and tried to figure out a nice looking sprite to represent a depleted jump. In the end I decided to just reduce the characters size (by using a smaller sprite, not by actually scaling the character), also reducing their trail’s size to match.

- Finally, as may be noticeable from the previous images, I have been constantly changing the background and lighting colour, trying to get a style that looks nice. potentially I may have each level be a different colour, which would only require a variable to set the lighting colour to suite. 

Hopefully by the next devlog I will have added menu’s and a UI, made multiple levels, and potentially found or made sounds and music that suits the game.

[texmakesgames]

Ultra-Neon-etc-etc Devlog 1

Initially I ran into problems trying to get the mechanic to work in GDevelop with standard platformer mechanics. However, I soon realised that the solution was to convert the player and objects to physics objects, thus allowing the engine to do most of the work of managing forces and such. From there some time was spent fine tuning masses, forces and gravity on all of the objects and player, with the end result being that the player character is very dense so as to add impact, but the objects don’t experience gravity. 

In order to implement wall jumping I initially just allowed the player to jump whenever they were colliding with a surface. This, however, resulted in the player being able to slide up walls at high speed. I fixed this by setting the event to trigger once, but I liked the idea so much I added in a new object (the red wall) which lets you do this as a mechanic, allowing wall sliding in sections. 

The next step is to add more interesting graphics, design some levels and introduce a few new objects. If I have time I may add sound but that will have to be seen.

[texmakesgames]

Ultra - Neon - Interspatial - Soul - Drifter

Platformer Elevator Pitch: Time has frozen, the universe has fallen apart, but in the liminal space between worlds a string of consciousness races to reform reality. A fluid but floaty platformer (similar in flow to games like n or super meat boy) where obstacles are static unless colliding with the player, in which case they are affected by physics, causing the world to collapse as you parkour through it, leaving you feeling like an action hero.  

Control Diagram: The player character is mechanically simple, left, right, a jump, wall grabbing and a double jump which regenerates every time you touch an obstacle. The obstacles remain static, unless the player character is touching them in which case they should be affected by forces such as gravity and the force of the player character. Importantly they become stationary again as soon as the player leaves, meaning the general gameplay loop should involve the player parkouring through the level, leaving it looking like an explosion has been frozen in time. 

Unique selling points:

1. The world falls apart as you touch it

2. The player moves fast and fluid like the ideal of a ninja

3. The obstacles act as fast paced puzzle elements, as you can knock down walls to make bridges, etc.

Student Contact Information: texbarnes88@gmail.com || N10008217 || Texas-Pete Barnes