Walker

waveSystem 2.0 is now finally working!

I can't believe how much time I spent on this system. I don't even get paid for this.

While I was working on the system, I added some visual and audio assets to actually make it feel more like a game.

I've also went to go find some people to try and playtest the game since I don't think I'm going to develop the game further any time soon.

The feedback received from the playtesters were very useful. Some players found the waves of enemies in the new waveSystem 2.0 to be too difficult (I'm just that good ig). Others noted how the enemies weren't behaving very dynamically and were predictable (fair, the AI hasn't really been modified to do much other than act in a swarm and fire at the player within a certain angle of them looking at the player). Feedback like this allows developers to be able to make meaningful changes, especially for issues that the devs wouldn't be able to find by themselves. External feedback is extremely important guys.

See the video for a small example. The project is starting to look more like a game now.

Postmortem reflection:

One aspect I would definitely change about the prototype’s development process is how late I implemented difficulty balancing and feedback testing. Had I set up some baseline balancing early on, a lot of the later stress and debugging (especially around budget scaling and batch spawning) could’ve been avoided. I was too deep into writing custom spawn logic before properly playtesting wave-to-wave pacing, and it came back to bite me.

If I were to revisit the design side, I’d rework enemy variety and wave pacing based on player location on the star map. Right now, waves scale in difficulty, but they aren’t responsive to what sector you’re in. I think tying spawn batches and AI aggression to the environmental context of each arm of the galaxy would’ve created more interesting moment-to-moment decisions for the player. This is something touched on during class: how systems and aesthetics can reinforce setting and narrative. I didn’t really follow through on that part.

External feedback was probably the most valuable part of this whole dev cycle. Developers might never notice what feels unfair or flat until someone else tries your game comments on these things.

Unfortunately, I believe I’m the only one actually doing any work on the game. So, I guess this is now my game. I’m now the proud sole developer of Storm the Core, although I’d probably change the name of the game to be honest.

I've sorta taken some ideas from Ch.5 in Tracy Fullerton's Game Design Workshop textbook. In it mentioned a whole lot on games as systems and working with system dynamics. The game system would have elements such as objects, properties, and behaviours. This part is highly relevant to my dynamic enemy wave system. Also, a lot of other topics were relevant to components like the XP system and credits that drop from enemies. An importance on how these systems work and interact within the game and the other elements of the game should be noted and taken into account while building such systems in games. The whole interaction between the player and these systems should not be overlooked either. Questions we could be asking ourselves are:

How much information do players have about the state of the system?

What aspects of the system do players control?

How is that control structured?

What type of feedback does the system give the players?

How does this affect the gameplay?

The chapter also touched on game balancing as well. This is important for what I'm trying to do right now. Put simply, I’m currently trying to implement a new design, essentially a whole rewrite, for a new wave spawning system. I’m dubbing it waveSystem 2.0.

Currently super proud of the progress on this system so I'm going to talk about the engineering design of this mechanic now so feel free to skip if you don't give af. The concept is that this system now uses a battery system where each wave has a specified budget to use for enemies and their types. This battery system accounts for the difficulty multiplier variable for the entire game and calculates a budget for an arena containing enemy waves.

A calculator goes through the four types of enemies, each with their own cost and weighting that determines how the random calculator returns the wave budget and the enemy presets for the wave. Each enemy type has a specified chance of spawning and when it’s selected, it will subtract from the total budget of the wave.

Another dynamic calculator computes how much budget gets allocated to each wave, simulating an increase in difficulty as the waves get larger. We have an equation of n ^ i, where n represents the wave number and i is the factor. When i = 0.7, the waves will have a weighting of 1, ~1.62, ~2.157, ~2.639, etc. We then consider the maximum waves that should spawn in the present arena (the calculation for this is also dynamic) and portion each wave with the intended budget. Essentially, when we have a wave budget of 400, waves 1 to 4 get budgets of 54, 88, 116, and 142. Might have to adjust the curve but this is how it works.

I haven’t even mentioned the logic to spawn batches within the waves. Each wave spawns batches of the generated enemy preset, so you can have something like 20 tiny enemies, 5 small ones, and maybe like 2 medium sized ones in the preset, and have them spawn in batches. The preset generation also is affected by the difficulty multiplier and how far the player has gone through the game. Did i mention that the amount of batches spawned in each wave is also random too?

Yes, I realise what I’ve done and I don’t want to talk about it. I don’t even know why I’m putting so much effort into a stupid prototype.

Regardless, each part has variables that are tweakable, especially when customizing the system to behave how we want it to. Future iterations of the game will tweak this system to either balance or modify behaviour of the system depending on player feedback.

Disregarding the different kinds of enemies in the spiral arms, I’m aiming for a prototype with one kind of enemy of four types. Each type are of different sizes: tiny, small, medium, and large. Currently we only have the tiny one in the game because I haven’t had time to add in the others.

So I've implemented a prototype wave system that spawns in enemies in batches. Currently it just works as a simple batch spawner where each wave consists of a certain amount of enemies, and spawns them in groups with each group having the same amount of enemies. I might try to design a better system later on but for now, this is a decent enough test of the wave system.

I've made a map. I have no idea why it took so long but, yes. This is a mockup of what the star map could look like. Each galaxy arm would represent one of four types of enemies that the player has to counter when deciding what to level up and buy at the shop. Each of these enemy types should represent certain behaviours and have different strengths and weaknesses.

Notice the nodes on the galaxy arms. There are multiple paths that the player can take to progress towards the centre. That is where you would find the boss. Hopefully the player has upgraded their ships and improved their skillsets enough to defeat the almighty Zorg!

To realise the game idea, I've developed a small draft of the game.

To start off, I focused on the player ship and the movement. I specifically wanted the space feel via having the player movement represent the inertia of the spacecraft as it floats around the area. I didn't want an asteroids like behaviour however so I've added linear dampening to the Physics2 behaviour of the player object.

I've randomly spawned an example enemy type onto the field. Notice in the video how each enemy displays a shield when they are hit, indicating a hit mark. I want to point out how each enemy object has their own unique shield that spawns with them. See, this doesn't seem like much but GDevelop is so ass to work with. Trying to figure out how to have each object type spawn their own object while also having both objects linked together was a huge hassle and wasted so much of my time. I'd rather be using Godot; at least that actually uses programming code to make the game.

Also note the addition of the two turrets on the player's space ship. Kinda proud of that, actually. The way it works is that the weapons are generated via a loop. I've built in on the player's spaceship four hardpoints to mount weapons or other devices. This allows for other weapons and items to be mounted onto the player's spacecraft.

In Storm The Core, players assume the role of a lone spacecraft pilot navigating a procedurally generated galaxy in a single-player, PvE universe. The journey begins at one of four spiral arms on a strategic star map, where sectors can transform dynamically into battlefields, bustling markets, or specialized challenge and reward zones. This variability ensures that every sector offers unique gameplay experiences and strategic opportunities.

Storm The Core is envisioned to be a take on the space arena shoot-em-up genre. When the pilot is ambushed, waves of dynamically spawned enemies test reflexes and tactical acumen. Each encounter rewards the player with XP and credits, driving both immediate and long-term progression. Designated checkpoints—serving as secure quiet sectors—offer moments for recovery and moments of strategic depth, enabling the pilot to repair, upgrade, and customize their spacecraft with improved weaponry and abilities before moving on.

As the pilot progresses toward the galactic core, the stakes rise: enemy forces grow more diverse and challenging, and environmental hazards become increasingly unpredictable. This steady escalation of difficulty is balanced by a robust upgrade system, where every new milestone reached translates into tangible boosts in performance. The evolving threat environment reinforces the importance of careful resource management and adaptive combat strategies.

The narrative reaches its climax when the pilot finally confronts Zorg—a formidable overlord whose long-standing domination has plunged the galaxy into chaos. In a final, high-stakes confrontation, the pilot’s carefully honed skills and upgraded arsenal are put to the ultimate test. Success against Zorg not only restores balance to the galaxy but also validates the player’s journey of constant evolution and strategic resilience.

Procedural Roads

So I’ve started prototyping how the track generation works. Instead of fixed tracks, I want the city to feel endless but also tight like urban Japan or Hong Kong (because these are the birthplaces of the Cyberpunk genre, obviously). Having elements like one-way speed traps or shortcuts could add some diversity in the gameplay. I built a basic road tile spawner that generates chunks on the fly, but it’s very scuffed right now. Generation sometimes doesn't work because making loops in GDevelop is so ass.

Night-Time Cyberpunk Theme

Also experimenting with the visual identity with effects like light trails, streetlight glow, and rain effects (this one I haven't figured out et). I only have really basic effects in since GDevelop doesn't have a lot in their library but the idea is there. Pretty happy with how the color grading is going so far: deep purples and neon blues, highlight reds, and teal highlights. Trying to aim for that night-time driving experience in those cyberpunk games and movies.

Driving Physics Implementation

Started building out the driving mechanics for Neon Drift, specifically making the drift actually feel like a drift. Top-down racers can feel kinda floaty sometimes, so the goal is to get this balance between slick and responsive.

Implemented basic car physics with simulated momentum and “friction zones” (basically it tries to simulate grip loss and regain depending on how sharp you turn and how much throttle you’re applying). Still messing with friction coefficients and damping values. Might also add a burnout mechanic or something if I'm bored, idk.

Right now I’ve only got one car in a placeholder city road map with glowy roads and animated billboards that I grabbed from free asset stores. Trying to get the whole feel and vibe down early. Next goal is probably making the boost system work and maybe adding an overheat mechanic so people don’t just spam speed boosts.

Random Generation of Food

My intention was to have the food be placed randomly around the scene. This requires a loop logic that spawns the food object a number of times in the area (preferably not infinitely obviously).

Implementing Food

I've added food to the game scene. Currently it animates and gets absorbed into the player and adds 1 to the player's life points.

I haven't decided how to represent the player "growing" but that's an art designer's job lol.

Theme design & Ideation

I've tried messing around with behaviours by adding publicly avaliable modules from the internal GDev library.

Currently I've attached a health behaviour to the player object. It does make managing the health mechanic slightly easier since I don't have to set a health variable for each entity. Other features are also attached to the health module such as health regen and defence mechanics (damage reduction or armour).

Since the game theme is about these aquatic biological creatures I thought having elements and features of real creatures and turning those into mechanics would be a creative idea. So I've made a small list of ideas to consider when working on this game.

Creature survival instincts or evolutionary traits:

Adaptation to threats (acting in self defence, strength in numbers, fleeing, etc.)

Preferred method for finding sustanance (how they gather food)

Social behaviour (whether they interact with others of their kind or are solitary in nature)

and these can be turned into game mechanics:

All creatures have a will to survive and prosper but there is a limit on how fast nutrients grows in the area (basically nature's max capacity/population) Creatures will be fighting it out and depending on their evolutionary path it determines whether they stick with naturally grown resources or hunt smaller creatures for their nutritional and energy needs.

Growth and healing of the creatures can be tied to their rate of nutitional consumption minus their energy spenditure. Creatures (probably just the player and not the naturally spawning creatures in the game) normally spend energy to live and must look for food as their fuel source. The ability to grow can be tied to this where any extra energy/nutrition could be used for evolving and adapting to their environment for the purpose of survival.

I'm not going to add creatures procreating; that's just TMI geez.

I was thinking the player can heal but can't regen health to max. We can have the mechanic of regaining health tied to the act of consuming edible material. Biological creatures can only heal to a certain extent since without nutrients the creature wouldn't be able to heal efficiently or grow.

In King of the Sea (or KotS), players begin as a small oceanic organism in a top-down, procedurally generated sea environment, where every playthrough presents a unique configuration of generated obstacles and opponents offering fresh moment to moment gameplay that changes on every playthrough.

The gameplay centers on natural selection: players grow larger and stronger by strategically engulfing weaker competitors, a process that not only increases their size and strength but also unlocks new abilities and upgrades through defined milestones.

Each milestone represents a level of progression; as players accumulate points, they gain enhancements that are offset by rising difficulty. Overtime, enemies would evolve by acquiring abilities similar to the player’s, ensuring that survival is a dynamic, ever-escalating challenge.

Playtesting and current issues.

Recently I've given some people to try out some of the mechanics of the game so far. The feedback that I've been getting from the testers was very valuable indeed.

One thing that keeps coming up is about the rotation mechanic. Some people may find the rolling a bit disorientating and could make them dizzy or a little sick. This is definitely something to take in to account and should be looked into further.

As development goes on, a solution should be found to help reduce or hopefully eliminating the occurance of the player feeling any kind of sickness.

Otherwise, people seem happy with the simpleness of the game and it's easy entry to the gameplay. There was also appreciation for the small puzzles and challenges as well so I'll look into designing even more engaging and difficult puzzles.

This rotation mechanic is really something interesting to work with and I've been enjoying the process of learning how to build it.

Postmortem Reflection

Looking back, I think the design process for RollWorld was both interesting and chaotic in equal parts. The rotation mechanic ended up being a cool idea that led to some neat puzzle designs, but I didn’t anticipate just how disorientating it could feel for some players.

This wasn’t something I picked up on until people actually tried it, which shows just how important external playtesting is. If I were to go again, I'd go test the visual and motion feedback much earlier in the dev cycle.

Something else I’d change about how I approached development would be to prototype smaller interactions first instead of focusing so much on how world rotation works technically. I tend to focus on getting specific mechanics to work well but GDevelop stops me from being efficient, and that slowed down progress on level design and actual gameplay feedback.

Probably would’ve helped to spend more time iterating on puzzles early on instead of just tweaking values and trigonometry functions for half a week. Easy solution is to just switch development platforms. I'd rather use Visual Studio Code and build a game with C++.

From a design standpoint, I think one takeaway was that the novelty of the mechanic needs to be supported by the right pacing and level structure.

I got some positive feedback about the puzzle elements and the clean mechanics, so if I were to keep building on RollWorld, I’d focus more on expanding level variation and smoothing the user experience to reduce discomfort.

Objectives + Puzzle items (Key + Door)

Camera mechanics (Zoom in + out)

Working on the game mechanics

To create something interesting and different to the puzzle platformer genre I've decided to make a game centered around a physics-based game engine. This mechanic will hopefully be very focused on gravity and could create some very interesting puzzles and situations for the player.

So, I've started working on the mechanics of the game, specifically the world rotation part and how gravity will work.

World rotation + gravity vector

Camera mechanic (zoom in/out)

Level design with puzzles + objectives (key & door)

Gravity Vector + World Rotation Implementation

In order for the player to move the ball along the map, the player needs to control the world so that the ball can "roll down" a slope. As mentioned in the previous post this game focuses heavily on physics and momentum.

There were two ways of implementing this; either I have the entire world and it's objects rotate, or I rotate the camera. The latter seemed like a better and easier approach.

Implementing the world rotation was quite easy: Player press LEFT/RIGHT = World rotates clockwise/counter-clockwise.

However, trying to implement a changing and dynamic gravity vector was not as simple.

I had to figure out how GDevelop's Physics 2.0 Engine parsed in values for the gravity vector. Initially I thought using sin() and cos() methods required x in sin(x) and cos(x) to be an integer. Normally you'd expect sin(90) = 1 and sin(30) = 0.5, except it seems like GDevelop requires a unique type specifier of radians in order to make sin(90) = 1.

For example:

Let x = 45.

sin(x) = 0.8509

sin(ToDeg(x)) = 0.806

sin(ToRad(x)) = 0.7071

Seems like sin(x) in GDevelop assumes x is radians then calculates sin(45 rad).

ToDeg() converts radians to degrees with x*180/pi then calculates sin(45°).

ToRad() converst degrees to radians with x*pi/180  correctly returns 0.7071 as expected.

This confused the hell outta me but I get it now. I've also been working on a simple level to try the simple world rotation mechanic. Seems pretty good so far and the ball is behaving as expected.