Jump to content
  • Advertisement
  • entries
    17
  • comments
    4
  • views
    948

Dev Log #4

Sign in to follow this  
FatPugStudio

325 views

The Anatomy Of A Roguelike Endless Mode

Endless Mode, for now, will be the backbone of the game. I don’t much like the term, but let’s call it Roguelike. For those not unacquainted with the term, it’s pretty simple. The basics of roguelike games are permadeath (which means you start all over when you die) and procedurally generated levels. Procedural is basically a fancy catch-phrase for controlled random. It means that the levels are made by parametrized procedures that keep the random factor under control by defining the aforementioned procedures, certain value ranges and all sorts of parameters you want randomized. Anyone ever trying to make a completely random piece of any sort of art, be it visual or sound, knows that it usually turns out horrible. With the assistance of parameters like harmonies and scales in music, or color palettes, fractals and similar stuff you can get bettes results, but without the human input it’s usually a meaningless chaos with only glimps of something human-like.

Then what is it good for you ask? Well, with proper parametrization, you can get a gameplay experience that is different every time you play the game, yet it has the same essence and feeling. How does that work in my game, more precisely, in the endless mode? The most obvious thing that can be parametrized is the appearance of enemies on screen, so how do we do that?

Triggered Spawners

For spawning enemies, we need spawners, predefined locations on the screen where the enemy ships appear. Since we want the illusion of ships flying IN the visible part of the screen, spawners are set OUTSIDE the visible part of the screen, just a little bit beyond camera frustum. There are a total of 20 spawners, 5 for each side of the screen, and each of them spawns enemies by the command sent to them. That command, in the form of a triggered custom event (hence the name Triggered Spawners), is chosen randomly by a set of rules.

Rules are not made to be broken

In opposite of the old saying, rules in roguelike game must be well designed and not broken, unless you want your whole game to be broken. A tight set of rules need to be implemented to the enemy spawning system for it to be challenging enough, but not too hard and various enough, but not too random. So besides the variety, by making the rules for a procedurally generated Endless Mode i came up with something i call the Adaptive Difficulty System. Here’s how the whole thing works:

You start the game with 0 Experience Points (the first variable), empty Enemy Value Pool (the second variable) and empty Enemy Array (the third variable, let’s call it Enemy Counter from now on).

Experience points are the core to the system and a lot of stuff depends on them:

  • You earn them by destroying enemies.
  • Enemy Value Pool is the value of all enemies present on screen. When they appear, their value (based on their characteristics, HP, weapons, etc.) is added to the pool. When they are destroyed or they leave screen, their value is subtracted to the pool. The Enemy Array is simply a counter of the enemies present on the screen, when the enemy appears, it’s added to the array, when it disappears by means of leaving screen or death in flames, it is removed from the array. The thing is, Enemy Value Pool has a limit that is based on your experience level and it is raised higher as you earn more experience by destroying enemies.
  • Trigger for unlocking more complex and harder waves, new types of enemies and upgrading already unlocked enemies.
  • Trigger for bosses appearing, and transports with pickups appearing (that means no level is of the same length).

Enemy Value Pool works in conjunction with both experience points and the Enemy Counter and it is crucial for the difficulty level adaptation. The game will never spawn more enemies than the pool can hold, so it ensures a gradual progression in difficulty based on your skill. If you’re not such a good shot, experience will rise slowly, and with it the pool size. If you are a hotshot and hit ’em dead on the spot, you will progress much faster, get upgrades much faster and get to the bosses faster.

So what’s the Enemy Counter for? Тhe Enemy Pool Value has a certain limitations without it. You can have a pool half empty, but a lots of small enemies on screen that already pose a challenge by sheer numbers. Based by Enemy Pool Value only, the system will start an event of filling it up by spawning more enemies. The Enemy Counter serves as a fail-safe system against this. Instead of spawning more enemies, it will either delay further spawning if the number of enemies it too large, or perhaps launch one big enemy to add some variety to the situation.

Simplified Schematic of Adaptive Difficulty SystemSimplified Schematic of Adaptive Difficulty System

Enemy Waves

As stated before, enemy waves are spawned in a controlled random manner, featuring procedural and hand-crafted elements. Procedural elements would be random number of single enemies moving on their predefined agenda or via paths with their numbers and type defined by experience points, while hand-crafter ones are squadrons.

Squadrons

They have the largest number of variety, but they can be painstaking to make if a large number of ships is involved. For example, this is a basic one, Marine Carrier in the escort of five Provokers, six ships total.

A typical representation of hand-crafted squadronA typical representation of hand-crafted squadron

Due to Unitys limitation of nested prefabs, i can’t just pop them into scene view and save the whole squadron as a prefab (which would be really awesome and speed things up), instead i have a prefab which instantiates ships on defined coordinates in local space. That needs a lot of tweaking, entering values manually then pressing play to see where they are actually positioned. In the whole process, waiting for Unity to start the game to see where the ships are spawned takes the most time. Obviously, the time spent is the largest con, but the pro is that i can simply replace prefabs in the squadron in a blink of an eye. That means i can change those Provokers escorting the Marine Carrier with another ships in only a few seconds, or even set each position to spawn a random ship, thus making the ships following the carrier different each time and even spawn different ones according to the players experience level.

When you take into account around 40-50 ships made until now, you get the idea how tiresome can sometimes be to make all these squadrons, but it keeps the game away from being a procedural generated crap, it keeps the randomness factor but in a structured way.

Random Number Range Single Enemies

Now this is the actual procedural generated crap that is to be avoided, but when used properly it functions great. What does that title actually mean? There are several enemy spawn points scattered all around the screen, by utilizing this approach, depending on certain variables, they will spawn single enemies that follow their own behavior, be it the regular “move forward and shoot” or something else. There are some cool thing regarding this. For example, i can spawn 1, 2 or 10 ships in a random pattern based on the players experience level or number of ships already on screen. They act like fillers, we already have one or two squadrons on screen, so let’s drop a few more small baddies that do their own thing. It also keeps the players on toes since they don’t know what to expect. A horrible drawback is that things can get too random if not controlled by various parameters that need to be finely tuned, like mutual distance that avoids overlapping the sprites.

Enemies That Move Via Paths

I’m sure you’ll agree that the game would be very boring if all the enemies would just move forward towards players side of the screen, no matter how many types of them there is. Using paths to move the enemies further deepens the variety and the semi-randomness factor of the game.

Obviously, paths can be used for both Single Enemies and Squadrons. They work great for single enemies since we can set a wave to spawn, let’s say, 5-7 small ships and then use a path that’s branching, like this:

Enemy WaypointsAn example of a branching waypoint

In this example, when the ships get to the first waypoint (purple square in the upper part of screen) they will do a check which will apply random branch choice, some will keep moving forward towards the left part of the screen, and some will circle around and go back right, or maybe sometimes we’ll set them all to follow the same path, so for a path like this, we actually have three outcomes: all follow path 1, all follow path 2, all branch random, which is flexible and great.

Using paths in Squadrons take a bit more time to work on, but they add further variety to squadrons. The Provokers following the Marine Carrier in the first picture may spread or fall back after a while.

Another important option that using paths gives is the easing of movement. Ship may start moving slow, than speed up while moving down the path. Or other way around. That can be randomized to, per ship, squadron, or a whole wave. It gives a lot more natural feeling to movement since ships moving at the same speed constantly may feel mechanical and boring.

Easing types that allow for more natural movementEasing types that allow for more natural movement

 

In Out Expo Ease type in actionIn Out Expo Ease type in action

Utilizing all this stuff drives the game away from the classical “memorize the pattern while moving on rails” type of play. It takes a lot more time to work on but definitely keeps every game session exciting and fresh and rises replayability to a whole new level. Unfortunately for some, and in contrast to a usual Roguelike practices, not using seeds for procedural generation means you won’t ever be able to replay the game you just played, but i see it as a great thing.

Further randomizations

While not essential for gameplay itself, backgrounds are randomly changed with each level. But what IS essential for gameplay are the Random Events that come with some of the background. They are created in a brief moment of whiteout when ship enters the hyperspace after defeating the level boss and further improves the challenge and replayability. Some of those include meteor rains, ion storms or asteroid fields, adding up to the difficulty, variety and that juicy bonus multiplier.

Weapon upgrade system overhaul

Last, but not least important is the overhaul of a weapon upgrade system i spoke about in the last devlog. After a few weeks work it turned out that the weapon pickup and upgrade system is not functioning really well when handling the pickup after the first weapon switch. I refactored some array related stuff regarding the active/inactive weapon status and now it works like a charm.

Weapon Upgrade System RehaulWeapon Upgrade System Rehaul

It can be further improved by introducing a case-switch instead of all the yellow colored states which i will do in the next iteration. It will further simplify the machine, but i don’t think it can go simpler than that, at least using the state machine.

The post Dev Log #4 appeared first on Fat Pug Studio.


View the full article

Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Jamesgz
      Hey my dudes,
      Me and 4 friends are third year compsci students. Three of us are pretty good at drawing. We are hoping to make a 2d roguelite game with unity during the next few months. We are still brainstorming. At the moment, my idea is to create a card roguelite game:
      First, you would need to choose 2 heroes to enter the dungeon with the goal of finding a treasure. The treasure found gives you extra bonus in later runs. You can choose between mage, gunner, rogue, paladin, warrior and fighter. Each hero has their own unique cards. And there are common cards that every heroes can get(like hearthstone).
      The progression system would be like slay the spire’s. You can choose your own path, but every paths leads to the boss. It would use procedural generation. After defeating an enemy, you get to choose a new card out of the three options. There would be shops, random events, elite enemies, etc
      The combat system is where i need some suggestions on. There would be two piles of deck. One for each hero. I can think of two good combat systems:
      1. Before every enemy encounters, you can choose what cards to use from your deck. Cards not used would not get discarded. Cards are drawn from the deck only if they break or due to special card’s effect. Every card have a durability number. Ones the durability reach zero, the card would break and can no longer be used. Events/enemies can modify the durability of the cards.
      2. Card not used this turn would get discarded. Once the deck is empty, the discard pile gets shuffled and copied to the deck. Card/item effects can increase the number of cards you draw.
      How can I make the game more interesting? Any suggestions would be appreciated.
    • By therax1986
      Hi everyone. For the last few months I’ve been working on a simple HTML5 2D side scrolling action game called Theraxius. It's nothing new and revolutionary, it's more like an evolution of different technology (combination of HTML5, PHP, MySQL). The game also includes a level editor so you can create your own levels. The game and the level editor is written almost completely in JavaScript, no download is required. Just load and play. Here are a few screenshots and the link to the page.
      In the next weeks I’ll try to post some videos, try to add registration (for newsletter and later for public test).
      Release date: when it's done
      theraxius.com



    • By horror_man
      Hello, I'm currently searching for a talented and passionate programmer to create a small but great horror game that would take around 3 months to be done.
       
      About the game: The game would be a sci-fi/post-apocalyptic survival horror 3D game with FPS (First person shooter) mechanics and an original setting and story based in a book (which I'm writing) scene, where a group of prisoners are left behind in an abandoned underground facility. It would play similar to Dead Space combined with Penumbra and SCP: Secret Laboratory, with the option of playing solo or multiplayer.
       
      Engine that'd be used to create the game: Unity
       
      About me: I'm a music composer with 4 years of experience and I'm fairly new in this game development world, and I'm currently leading the team that'd be creating this beautiful and horrifying game. I decided that making the book which I'm writing into a game would be really cool, and I got more motivated about doing so some time ago when I got a bunch of expensive Unity assets for a very low price. However, I researched about how to do things right in game development so I reduced the scope of it as much as I could so that's why this game is really based in a scene of the book and not the entire thing (and also that's why it would take 3 months). Also I'm currently learning how to use Unity and how to model things with Blender.
       
      Our team right now consists of: Me (Game Designer, Creator, Music Composer, Writer), 3 3D Modelers, 1 Sound Effect Designer, 1 Concept Artist and 1 Programmer.
       
      Who am I looking for:
      - A programmer that's experienced in C# and with Unity.
       
      Right now the game is very early in its development (GDD is completed and all 3D Items, Music and Sound Effects are completed).
       
      If you are interested in joining, contributing or have questions about the project then let's talk. You can message me in Discord: world_creator#9524
    • By kcirkl
      Hello, 
      So, I'm aware this may be a broad question with a vast variety in the anwser. However, I am a game design student that works professionally for a large engineering company conducting software configuration. Naturally, I'm curious about the path ahead and I'm desperately gathering information on the overall process of developement with Unity. Are there professional resources available that can outline the processes and functions of the engine, and what can be used to interact with it? I'm looking for options other than the official documentation. I have already jumped into that. Thanks!
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!