Playmaker Forum
PlayMaker News => Work In Progress... => Topic started by: Fat Pug Studio on July 04, 2017, 02:37:39 AM
-
Hi guys, since i'm a regular poster here i thought i'd share my devlog with you too!
First of all i would like to introduce myself. I come from Belgrade, Serbia, i'm 34 and i grew up playing likes of U.N. Squadron, R-Type and Uridium on C64, then Z-Type, Project X and Xenon 2 on Amiga 500, all the way to Jets 'n' Guns and Steredenn on PC. I have been stalking the forum for a long time, but opened an account just recently, and i decided to open a DevLog thread where i could share the news on the game's development, make someone interested, and above all, help someone by sharing my experience in game development (which proved to be a very serious thing Smiley).
Gameplay and features
RHAG is, despite it's name fitting an adventure game better, a more or less classic 2D horizontal scrolling shoot 'em up i always wanted to make. It's a mixture of Jets 'n' Guns (who has the Story Mode) and Steredenn (which is basically and Endless Mode only game). The story features Rick Henderson, a disillusioned galaxy war veteran who turned to suspicious activities after the war to make ends meet, his robot follower, sarcastic Ben who makes every conversation fun, and a lot of NPC's who will be introduced during the development.
Story Mode Single Player - Interesting storyline full of dialogues with interesting characters to keep you amused between levels.
Endless mode with Multiplayer - Local and Online
Daily Challenge - Once per day Endless Mode Run with predefined equipment and perks
Online Leaderboard - Compare your scores with your friends and other players
6 factions - Pirates, Rokh Raiders, Terran Confederacy, Vakshaa, SunDyne Corporation and Paragons.
40+ types of enemies (for now)
30+ types of weapons and upgrades (for now)
Single Player is featuring a shop between levels where you can equip your ship with weapons, drones, engines, utilities, shields and armors.
Weapon types: Ballistic, Energy, Explosive, Meelee. Each type of enemy is usually resistant (partially or fully) to a certain type of damage, so watch your loadout! Ship can equip two weapons, but they can't be fired simultaneously. Weapons also generate heat, so you can't keep that button pressed all the time.
Graphics:
Game is done in pixel art which i really love and which proved itself as (usually) the best choice for shmups due to its clarity (and yes, development costs). I'm not much of an artist, so besides the things i do myself (backgrounds and small art), credits go to Lighterthief, a young lad from Netherlands who does some amazing graphics. I'm often awed how quickly he can make some good looking stuff. You can check his art on his Twitter account: @Lighterthief
Sound:
I've been a musician and sound designer in my spare time doing mostly electronic music for the last 15 years, so i've got that covered.
More Information
Website - http://www.fatpugstudio.com
Twitter - https://twitter.com/FatPugStudio
Tumblr - http://rickhenderson-game.tumblr.com
-
Log 1: Making a Flamethrower
Today i decided to finally bring an end to an agony i had with designing the flamethrower.
What are its characteristics?
- It fires a lot of small particles which increase in size over time
- The particles are emitted in cone shape
- The particles should be animated over time
I tried a bit unusual approach first time. I made a regular weapon which shoots bullets (in this case, small round sprites) by using UniBullet Hell which i use for most of my guns.
A simple setting using a tweaked random preset:
(https://s26.postimg.org/3jmz9h26h/Flamethrower_1.jpg)
The trick should be done by getting the bullets scale and collider size, saving them in a float variable, and then adjusting that variable over time. To avoid the bullets growing too big, i clamped the float value to a maximum value and put a death timer for the bullets to disappear after a certain amount of time, thus making a weapons range. Unfortunately, unexpected behavior appeared which i was unable to solve. After a while, the bullet instantiated size started growing more and more, and after a few seconds i would end up with particles which are all the same size (the float clamp size).
I scrapped the thing, and today i tried making it using Unity's particle system.
Step 1:
Making a sprite sheet of particles that would appear. It consists of 12 sprites in one row, 9 being some colorful orange and yellow blobs, and the last two diminishing blobs to mark the end of the flame spray.
Step 2:
Making the material for the particle system. It's not all easy-peasy with particles in unity. To apply spritesheet to the particles, you have to make the material out of it first. Just make sure to select the particles for shader. Some nice blending options can be chosen here too, but we'll stick to good ol' Alpha Blend.
Step 3:
Creating the particle system itself.
Shape - Needs to be set to cone since we are simulating, well, a fire cone.
Size over lifetime - Not to small at the start, since it will be practically invisible, but all the way to value of 1 at the end.
Collision - We want our fiery particles of death to collide with enemies, so we set the collision mode to world and 2D. You can also choose the layers which will be collided. Since my enemies are on their own layer, we choose that layer.
Texture Sheet Animation - This is what we made the sprite sheet for. Just enter the number of tiles for X and Y (in my case, X - 12, Y - 1, which means 12 sprites in one row). We're not touching frame over time options, which means the sprites from the sheet will be generated in order in which they are drawn.
Renderer - Here we will just put the lovely material we made from the sprite sheet we made earlier, nothing else needs to be touched.
Step 4:
All there's left to do is to tweak some of the basic settings like duration, start lifetime, speed, size, max particles, emission rate etc., which basically let's us control how long will the flame cone be, how fast will it shoot and according to that, how much damage will it make.
The thing that must not be forgotten is that the particles must have independent movement when you move the ship, so the simulation space must be set to world.
Here's the finished work
(https://s26.postimg.org/5oub79mq1/ezgif_com_video_to_gif.gif)
I just made a complete tutorial for making a 2D flamethrower in Unity, you can check it out on the frontpage of my website, www.fatpugstudio.com :)
-
Log 2: Troubles with the Flamethrower and making a font
Well, the flamethrower looks really nice, but in reality it proved quite useless. Apparently, particles, despite having their own type of colliders, don't have rigid body and collider in the sense of the regular components. They do collide and react with other colliders, but any other interaction with them must be done via OnParticleCollision behaviour, which is currently not supported the way it should be in Playmaker or Core Gamekit which i'm using, so i will probably have to do it the old fashioned way - in code.
But i have another interesting idea that i'm yet to try...i'll keep you updated :handanykey:
Edit: i forgot, i also made a custom font for the game, since i don't like any i found on the internet. I took me about 20 minutes. 3 pixels is too small, 7 is too big, 5 pixels was just about right for size and scaling. You can make your own fonts on www.fonstruct.com, a very handy website.
Here's how it looks like:
(https://s26.postimg.org/607mpnuq1/Font.png)
-
Log 2.1: Flamethrower complete!
I must admit that this was not an easy task, but i finally did it, a functional spray weapon that deals damage to the enemies.
First step was to make the animation out of the frames i provided with the sprite sheet you can see in the tutorial i posted. Animation settings in Unity are very powerful, and you can put every aspect of the thing you animate on the curve. I've put the X and Y Scale on a slight upward curve so the animation starts small, and gets bigger (like the thing i did with the Particle System in the previous try). Once i was satisfied with that i created the weapon template using Uni Bullet Hell asset. I used the Random Shot preset which has tweaks available for the Random Range Size (which is the angle in which the shots will be fired randomly, like the cone. I've set it to 15 degrees for start). Auto Release Time, or after how much time will the bullet get back to Spawning Pool (instantiation and destruction takes much resources) is set exactly to the animation length so it doesn't repeat itself. Speed of the bullet is randomized between 1.1 and 1.5 values to get a more natural, random look. The initial Random Range Size property was fed into an FSM which randomizes it between 10 and 30 range to get even more natural/random flame look (talk about natural flame in space ::)) and the Z axis of the sprite is also randomized so that every bullet slightly rotates a different way during its pitiful one second existence.
With all that finished, it was time to do the routine work, adding some usual stuff to the bullet. 2D Collider and 2D Rigid Body for hit detection, the Killable component of the Core Gamekit which is used to apply Attack Points which will be dealt to enemies upon collision (the enemies in the gif have 200 HP, so i've set it to 1, since there's a lot of small bullets. The starting weapon, a regular one bullet blaster has 100 Attack Points for example, so it takes out those little baddies in two shots), and setting the bullet to die at any collision.
Here's the result (wait a bit, it's a big gif), i may tweak the reach of the weapon a bit, or mess with the sprite sheet to give it a fuller and more colorful look, but that about does it! All there's left to do is connect it to the Heat Meter so you can't fire it indefinitely since you'll overheat, but that's the story for another log.
(https://s26.postimg.org/k9bulgymh/ezgif_com_video_to_gif.gif)
Hope you enjoyed, cheers!
-
Log 3: Introducing the Rift Miners
I've been really busy with my job, as usual on year's end, but my graphics guy has been working, so i've got a little teaser for faction #2, The Rift Miners, race of sentient mining robots. It is for the social network, so i'm not going to spam it into a new posts here, i'll just edit the existing one just to show you the process. Idea is to make people a bit interested by showing shapes fist, then identifying one ship per day. Here's all revealed
(https://s26.postimg.org/5q9us90sp/Otkrivanje_Ostalih.jpg)
Also, i started working on the Endless Mode mechanics as i decided to give people something to play before i finish the Story mode. It's not complicated, it's based on levels consisting of randomly generated waves (but in a smart way!) with the boss enemy as the last wave. Weapons and equipment will be dropable, and you get to choose perks as you gain experience.
-
Log 4: The Anatomy Of An Endless Mode
Some time before new year i realized that the volume of work required to make both story and endless mode for the game is too much for me to finish in the amount of time i have given myself. Besides work, i have a small child, and the only hours left for work are after the little one goes to bed, which can be exhausting in the long run. I made a slight reorder of priorities - finish the endless mode first, give people something to play, put it up as an early access title, then work on the story mode.
Besides having to finish all the graphics, audio, and mechanics stuff completely much before planned, the challenge of making the endless mode itself presented. Of course, for it to be interesting, it has to be semi-procedural. How is it done?
Rough Construction
First level:
3 + 0 60 seconds waves with a warp sequence between each of the waves to give player time to rest. At the end of the last wave, you fight the random variation of the first level boss, and warp into level two.
Second level:
3 + 1 60 seconds waves with a warp sequence between each of the waves to give player time to rest. At the end of the last wave, you fight the random variation of the second level boss, and warp into level two.
You get the idea how it goes further. When all the levels are completed, you start from level one but on a much tougher scale. What does that mean? Points, enemy movement, enemy shooting speed, enemy bullet damage, enemy health variables and so on, they are all multiplied. As it name says, it's endless, and the goal is to get as much points as possible.
Wave design
This one was a bit harder to implement. Around the screen, 20 spawn points are arranged (five for each side of the screen).
(https://s26.postimg.org/8q0z3tzk9/image.jpg)
Prefab pool for each type of enemy is made and squadron combinations of all enemies were made. Each is assigned a progression level, which is basically a threshold for appearing (or not appearing). The variable enables the algorithm to avoid spawning too many or too tough enemies on first levels, and too few and too weak enemies when you're already on the higher levels. Separation into prefab pools and squadron combination allows us to have a variety in spawning a combination of hand made patterns and waves of many randomly scattered enemies of one or more types.
I must admit that Unity maybe wasn't the smartest solution for this type of game. It has lot of possibilities, but every one of them must be carefully tweaked and automated for the system to work as intended. For example, i don't want to make duplicates of all the enemy squadron combinations for every movement direction, so i had to make a script that automatically flips the sprite, shooting direction and movement direction according to the position where the enemy wave spawned (if it spawned in one of the spawners on the left side of the screen, its sprite is automatically flipped on the X axis and it's movement is set to right). For enemies moving along the waypoints, this is omitted and they automatically align themselves according to the waypoint direction. Waypoints allow us to make interesting waves rather than using only linear moving enemies.
Here's one of the early waypoint making images:
(https://pbs.twimg.com/media/CqNUz2DUIAEN6UG.jpg)
So, to make things interesting, we have a combination of hand made enemy patterns, procedurally generated enemy waves of one or more enemy types, randomly (but with a distributed chance) selected spawn locations or waypoint movement patterns and different boss variations. To make things even more interesting, there's a slight chance of events (asteroid field throughout the entire level and such things). Only things predetermined are level bosses (though they are also varied by their types which are basically shooting and movement patterns), and ships carrying power-up which MUST appear every wave for the player to progress. They drop a random weapon/equipment/power-up, which can be changed by shooting it.
The progression level also determines a perk selection screen activation where (similar to crimsonland) you can choose to cooldown your weapons faster, have more damage on energy or bullet based weapons, get a score multiplier etc.
Backgrounds randomly change after each wave (warp) so that's not boring too. They are chosen from the array and removed from the array once they appear. When the array is emptied, it fills again, and background change randomly again. Same thing goes for music.
There it is in a nutshell. It needs a lot more work on testing and balancing, but i hope you will get to play an alpha of an endless mode in a month or two :)
To keep you interested, here's a pic of another faction, the Paragons, which utilize cloaking and phase shifting (basically disappearing and appearing on random coordinates of the screen).
(https://pbs.twimg.com/media/C1kEEcrXEAEP-33.jpg)
-
Log 5: Enemies
Paragons: 8 ships
Pirates: 12 ships
SunDyne: 5 ships
Terran: 4 ships
Rift Miners: 7 ships
Rokh Raiders: 0 ships
Total: 36 ship + asteroids, pickup boxes etc. The plan is to make about 10 ships for each faction, so that totals to about 60 ships, which is more than enough to keep the endless mode interesting for a long time.
The plan is to make about 10 ships for each faction, though it's a lot of work to make each ship unique in design and attack formations and weapons. So i started modyfing some of them. For example, the Pirate Marine Carrier has normal and elite variant, the other one is tougher, and spits out elite marines.
Regular Pirate Marine Carrier
(https://s26.postimg.org/6phx3lnwp/Marine_Carrier.png)
Regular Pirate Marine
(https://s26.postimg.org/flxala3wp/Marine.png)
Elite Pirate Marine Carrier
(https://s26.postimg.org/u160sp26h/Elite_Marine_Carrier.png)
Elite Pirate Marine
(https://s26.postimg.org/f6hfeisll/Elite_Marine.png)
So these days are all about designing enemies in a sense of their HP, attack power, bullet patterns etc. After the design of all enemies is complete, i'll start putting them in waves and further tweaking power and the threshold of their appearance. The good thing is that the big part of graphical assets is complete, so the expenses are coming down, so i might even finish the game in under 3k euros.
To keep things interesting, here's a little gif of player being shot by EMP weapon. Doesn't do much damage, but you're pretty much screwed if screen is already full of bullets. Probably gonna tweak it a bit.
(https://s26.postimg.org/rvbpy6yq1/Glitch.gif)
-
Log 6: Small Recap
Well, i think it's about time to (after a year of learning and developing) tip the percentage of game completed to 20% ;D
Anyway, my last devlog was 4 days ago, and i started tracking things more seriously.
Small tasks are in Wunderlist, so they can be quickly added and quickly disposed of in any time and anywhere. It's also quite convenient for jotting down a quick idea.
I use Trello for communication on ideas with the artist and keep all the stuff there for a sense of visual direction.
Since Unity implemented the cloud collab stuff, i can also write down stuff i did and see it in collab history.
There has been quite a few problems, but also a few acomplishments in the last few days, it's actually pretty great to go through the list and see all the things you have done, keeps you motivated.
So here's the list for the past 4 days:
Design of the swarm missiles weapon, though it may require an overhaul to make them more random with some sort of unnecessary crazy loops to compensate for their number.
Design of the Randomizer (work title) weapon which shoots a lot of particles but to compensate for their number they move in a random forward pattern.
Design of the shield with regeneration timer and connection to the shield integrity bar. Still needs connecting to the heat transfer mechanism (when you get hit, shield takes the damage, but your heat level increases).
Design of the Auto Cannon Drone. It tracks closest enemy, rotates towards it and fires. If on enemies are present, it stops firing.
Design of the Ripper, basically a manual shooting shotgun, that was pretty easy. It shoots as fast as you can click, but it heats a lot.
Design of the Flak Cannon. Like the real Flak, it has proximity activated "fuse". At the certain distance from the enemy it explodes and blasts into a lot of small pellets.
Design of the Proximity Mines. We got regular mines just floating in space, but i decided to put a bit more challenging ones. When you get near one, it starts slowly moving towards you until you destroy it. I also designed the EMP mines that will work the same way, but deal less damage and f*** up your screen with glitch effects. Also updated the mines with random rotation and blinking red light so they're a bit more interesting looking and easier to spot.
(http://www.fatpugstudio.com/wp-content/uploads/2016/12/Guided-Mines-768x433.png)
Artist started working on explosion for destroyed enemies, explosions for bullets, and bullets themselves. There's already a lot of ships that require a lot of time for movement and shooting patterns, so we put the design of the next round of ships on hold until the existing ones are finished.
Tons of bug fixes, as usual.
I'd post a gif as usual, but everything's done with placeholder graphics, so i'll post something juicy next time.
-
Log 7: Swarm Missiles
I don't know how smart is to waste 4 days on a small feature such as one of many weapons in the game (especially with only few months remaining), but i just can't do things half-assed.
Here's the old one, which wasn't quite satisfying. The rockets seem to go in a predefined pattern, not randomly.
(https://s26.postimg.org/5sfq069u1/Swarm_Old.gif)
Here's the new one, so much better. Sorry for the framerate, i'm still not using sprite atlas so there's a lot of draw calls. That will have to be the next thing to address.
(https://s26.postimg.org/iu603rnm1/Swarm_New.gif)
-
Log 7: Upgrade system, weapon switching, and a word on visual scripting
It's been almost two weeks and i've been very busy with my day job so i didn't manage to spare too much time for game, but i finally finished (for me) a very complicated thing - upgrade and weapon switching system.
Player starts out with one weapon. During the game he can pickup a variety of weapons from destroyed cargo ships. The first time he picks up a weapon, it is added as a second weapon, and player can switch between them according to situation (bullet, energy and missile weapons don't deal the same amount to normal, armored and shielded enemies). When another weapon appears as a pickup, two scenarios are possible: if the weapon is already equipped, it gets upgraded and the pickup despawns. If the weapon is already at maximum upgrade level, player is notified via on-screen message and the pickup stays where it is. If the weapon is not equipped, currently selected weapon is replaced (dropped as a pickup, while pickup spawns on player). While dropping the weapon is not very important in single player game and complicates the situation a lot, it is handy in 2 player game, where one player can drop a weapon for the other player to upgrade his weapon. The handy thing is that when a player drops, for example, Hyperblaster Level 4 and the other player picks it up, he'll get the Level 4 Hyperblaster too, not level 1. Since there are (for now) 23 weapons in game and the only way to upgrade them (besides universal weapon upgrade pickups) is to pickup the same weapon, that will be very cool in terms of player cooperation.
Here's a shot of an FSM
(https://s26.postimg.org/yraxsga89/screenshot_2.png)
Basically, when the weapon spawns, it checks itself if it is a weapon or a pickup (by checking if it is parented or not). If it is a weapon, that means that it is player equipped and it is added to the array and the variable is stored if it is in slot one or slot two (required for weapon switching during the game). If it is a pickup, distance check state is activated. Player can only pick it up if he is closer than a defined distance from it (by pressing space, so no accidental pickups are possible). When he picks it up, it iterates through the array to see if it will replace the existing weapon (if no weapon of same type is found) or upgrade it (if weapon of same type is found). If it replaces it, the existing weapon is dropped (which means it is despawned, removed from array, spawned on location of a pickup with its firing scripts disabled and pickup indicator enabled, while next level weapon is spawned on gunpoint with its firing scripts enabled and pickup indicator disabled).
Weapon switching is, compare to the upgrade and pickup system, a walk in the park. Stored weapons are simply activated/deactivated by pressing the switch key.
Scripting this thing alone would probably take a lot more time than it did, so using Playmaker did the job pretty quick since i can try something out in a matter of seconds, not waiting to write a couple of lines with risk of making syntax errors.
But, here comes the downside. Instead of making the script that can just be copied/pasted on all weapons (have in mind that there are 23 weapon with 3-5 levels each, so that comes to about a hundred prefabs, with more to come), i have to copy/paste an FSM to every weapon and tweak the variables in each one of them. I don't have to tell you that if any larger scale fixes in logic are necessary when all the weapons are already prepared it will be a lot of work to change everything. Not to mention the possibility of making errors when managing such a tedious task.
One more thing i did is implementing the sprite atlas which reduced draw calls a lot, and boosted frame rate from 15-30 FPS to ~150. Now everything goes very smoothly. There are some hiccups, but those are due to extensive logging which is quite necessary in this phase. I also redid swarm missile logic, now they are very cool and fly in a great semi-random manner.
(https://s26.postimg.org/b1li3rbux/Sprite_Atlas.gif)
Also, the artist guy did some weapons art for me, some will maybe change, but i thing they're pretty good looking and quite different.
(https://s26.postimg.org/htbx6m0uh/Weapons.jpg)
That's all for now, cheers!
-
Log 8: Upgrade system and weapon switching part 2
Intro
Turns out that thing aren't always simple as they seem at first glance. I spent more time than planned on overhauling the weapon pickup and replacement system i wrote about in the previous dev log. Apparently, despite the system being laid out well, there were some hurdles that appeared.
First of all, the weapon switching system that was meant to be extremely basic and function by simply activating and deactivating children objects (weapon objects with firing FSMs) on the gunpoint of the ship proved too common for the concept of weapon equipping, upgrading and dropping during the game. I upgraded the system and while it's very complicated and probably can be laid out a lot simpler, it works as intended.
The setup
Upon starting the game, Player is spawned, its child Gunpoint, and Gunpoint children, Basic Weapon Object (Level 1 out of 5 weapon) and Empty Weapon Object. You're probably wondering why would i put something like Empty Weapon when it's not even used, but we'll get to it. Every Weapon Object has two FSMs, Main FSM, used for the upgrade system, and Firing FSM, used for firing the weapon. Gunpoint object stores the Weapon Switch FSM. Bear in mind that Weapon Object can also be Weapon On Ship, or a Weapon Pickup, depending on the state in which it is and the fact that Player can have two weapons equipped, but only one active at the same time.
Weapon Upgrade System - how it works?
Main FSM controller on the Basic Weapon Object enters the first state. It searches for the Gunpoint object (place on the ship where it will be spawned. Search is done by tag, since it is quicker than searching for it by name). When it finds it, it stores it in the variable. By checking if the Weapon Object is childed to a Gunpoint or not, the Main FSM is branching in two directions, which determines if it's really a weapon equipped by Player, or a Pickup waiting to be collected.
Shorter branch is executed is if the Weapon Object is a child of the Gunpoint object. It is then stored in the Weapons On Ship array, and the Main FSM finishes it's job for now. That means that it is a weapon equipped by Player and it can be fired.
If it is not childed, it means it's a Pickup (drifting in space, waiting to be collected), its Firing FSM is disabled, a child which is an animated circle indicator for easier visibility is activated and the state machine starts its next event.
Weapon Object starts measuring distance from the Player. When the distance drops below defined value, Weapon Object can receive the key command from the Player, otherwise, it's non-responsive to key press. In game terms, when the Player hovers over the weapon, by pressing key following states can occur:
Simplest case occurs if the same weapon type of maximum upgrade level exists on the ship (checked by iterating through the Weapons On Ship array). "Weapon is at maximum upgrade level" message appears, the pickup eventually leaves the screen and it is despawned.
If the same weapon type of lower upgrade levels exist on the ship, it is upgraded. If the pickup is of the same or lower level than the weapon on the ship, the weapon on the ship is upgraded by one level. But if the pickup is one or more levels higher than the weapon on ship, the weapon on the ship is upgraded to that level. So, you get a pickup and it upgrades your weapon by one or more levels and it disappears. In game terms, it sounds simple, but actually there's a lot of mechanics behind it.
For example, Player is equiped with Level 1 Weapon, and there's a Level 1 Weapon Pickup which we collect. Level 1 Weapon Pickup iterates through the Weapons On Ship array, and it finds the Level 1 Weapon of the same type. It gets the position of the Gunpoint object, spawns Level 2 Weapon and adds it to the Weapons On Ship array. It also checks if the Level 1 Weapon in the array has its Main FSM enabled or not. If it is enabled, that means it's an active weapon (we'll also get to it when we get to the Weapon Switching mechanism), which means that the Level 2 Weapon that is spawned should also be active which is done by activating Firing FSM on Level 2 Weapon nad adding it to the Active Weapon array (needed for the Weapon Switching mechanism). Firing FSM on Level 1 Weapon is disabled, it is removed from the Active Weapon array, removed from the Weapons On Ship array, Level 1 Weapon equipped on ship itself is despawned and Level 1 Pickup is finally despawned at the end of the last state. If the Level 1 Weapon on ship is inactive (its Firing FSM is deactivated), the Level 2 Weapon also spawns with its Firing FSM deactivated, but is not added to the Active Weapon array.
What happens if the Player is equipped with one or two weapons that are different from the pickup?
Things get a bit complicated there. If Weapon On Ship array does not contain any of the levels of the Weapon Object that is the same as the Weapon Object pickup, a Replace Active/Replace Empty state is entered. Remember the Empty Weapon object from the setup? It is used as a placeholder when picking up a weapon that is different from the basic equipped weapon. By iterating the Weapon On Ship array and finding no weapons of the same type but finding an Empty Weapon object, it is simply despawned, removed from Weapons On Ship array and replaced by the picked up Weapon Object. Since it is not active, spawned weapon Firing FSM is also not active, thus not added to the Active Weapon array.
A different Active Weapon acts similar to an Empty Weapon object if all slots are taken. It is removed from the Weapons On Ship array, removed from the Active Weapon array, deparented from the Gunpoint, its children activated (circle indicator that makes it visible more better on screen), and the pickup is spawned on the Gunpoint. As i said in the beginning, whenever a Weapon Object spawns, it immediately checks if it is a parent of the Gunpoint or not, and then added to the Weapons On Ship array or not.
Switching Weapons
Finally, switching the weapons. First we need to make sure that the Player can't cycle between the equipped weapon and the Empty Weapon object. As long as the Empty Weapon is in the Weapons On Ship array, cycling is not enabled. When it is no longer contained in the array, Player can freely switch between weapons. Every switch gets the first and second index numbers of the Weapons On Ship array, stores them as Weapon 1 and Weapon 2 variables, enables and disables Firing FSM on them, adds the Weapon Object with enabled Firing FSM to the Active Weapon array, and removes the Weapon Object with disabled Firing FSM from the Active Weapon array. We need the information about the Active Weapon so it can be replaced with the pickup that is different from it. That enables the Player to upgrade the weapon of the same type as the pickup on ship whether it is active or not, or select which weapon will be replaced (if both are different from the pickup) by simply switching weapons to active or not.
Oh, by the way, you can visit www.fatpugstudio.com for version with bolded arrays, objects and things of interest, it didn't copy it nice.
(http://s26.postimg.org/rf6lbt3ux/Weapon_Upgrade_and_Replacement_System.png)
-
Log 9: The Anatomy of An Endless Mode Part 2
I've been on a month+ hiatus due to exhaustion and some personal stuff, but the things are ready to move forward now. I had some issues with the weapon switching system, mostly due to my inept dealing with arrays, but the fresh mind made things alright. As usual, it was just a minor unwanted behaviour (removing the array item which resizes the array instead of rewriting the value on the actual item position) which was hard to spot due to system complexity. Pickup and upgrade system, and together with them, HUD showing the active and inactive weapons as well as heat levels is working good now. Such a joy to see a simple system work, and the knowledge that a massive system is actually behind all of that is priceless.
Anyway, now that the most of the elemental mechanics are done, it's time to make a full time commitment to the actual gameplay.
Let's do a small recap of how things work in an endless mode.
First level:
3 + 0 60 seconds waves with a warp sequence between each of the waves to give player time to rest. At the end of the last wave, you fight the random variation of the first level boss, and warp into level two.
Second level:
3 + 1 60 seconds waves with a warp sequence between each of the waves to give player time to rest. At the end of the last wave, you fight the random variation of the second level boss, and warp into level three and so on.
I will make it quite hard to reach and beat the last boss, and even if you do so, you start all over again, but with bigger score multiplier and tougher enemies.
Now let's go a bit in-depth. As i mentioned earlier, 5 spawners are scattered on each side of the screen which makes a total of 20.
During the first wave, only the spawners on the right part of the screen are active and only one at a time can be active. That means that if a spawner spawns a wave of enemies that lasts for five seconds, no other enemies will be spawned during that time. To avoid waiting for the next one to start if you destroy them quickly, the wave also ends when you destroy all the wave enemies and the next one automatically starts.
So, in a way, the better you play, the game is going to throw stuff at you quicker. When it throws the stuff quicker, EXPERIENCE variable, which updates with every destroyed or ended wave, enables the game to do the following:
Activate additional spawners when EXP reaches a certain level
Enable more and more spawners to be active at the same time
Cut off spawning of the waves that are marked to be under EXP threshold (too easy waves)
"Unlock" spawning of the waves when certain EXP threshold is reached
Modify the Bosses' health/attack variable so they also match your skill level
But what about the waves themselves? How are they generated? Well, that's the hardest work of all. There are a couple wave types:
Squadrons separated in a few classes (Big, medium, small). Classes are determined by EXP (higher EXP unlock bigger and harder squadrons). Squadrons are a pain to make, they are a combination of a few enemies in a predetermined pattern (for example, a bomber protected by a few fighters flying in an arrow pattern). There needs to be literally a few hundred of them.
Waypoint enemies. Single enemy types following a certain movement (spline or bezier) and shooting pattern.
Single enemies. Usually very big enemies or few small enemies spawning on a random spawners in a random patterns if there are more than one.
When all of there are combined (along with random events like meteor rain and similar stuff), with randomized spawning locations and spawning based on EXP variable they should all provide an adaptive and enjoyable play experience.
-
Log 10: Endless Wave System Prototype
Finally started on prototyping the endless wave system.
(http://s26.postimg.org/5epu5assp/screenshot_38.png)
Here's a small update on the wave system, it's growing into a spaghetti monster!
(https://s9.postimg.org/5mgie84un/screenshot_41.jpg)
The start wave is the first wave that spawns enemies from a "small wave" pool of enemies, random wave, random squadron (but inside players experience points limit), the it goes to the "check experience points" state, where it check if you're inside threshold for starting the boss wave. If you are, further spawning stops until all the enemies on screen are killed or went offscreen and then the boss wave commences. If you are not, it checks how many enemies are on screen (every enemy that spawns adds a certain value into array which is being checked). So if there's already a lot of enemies on screen you're probably not doing to well and the game will send only a small wave again. If the screen is almost empty, you're bound for a big wave incoming. Also, every wave has it's duration based on type of enemies in it etc.
Anyway, when the boss wave starts. the state checks when it is dead and starts the fancy hyperspace event with animations and creates a random event! Random event can be meteor storm, laser storm, big asteroid field etc. Each one of them grants a bonus during that wave. The next wave starts and so on. Expect even more complicated state machine next time and even more insight :D
-
Log 11: Further insights on the Endless Wave System
The Endless Wave System spaghetti monster i mentioner earlier grows even larger now, but i'm encountering some stuff that needs to be addressed. Since the whole endless thing is, let's say, semi-random (predefined squadrons, random number range single enemies and enemies that move via paths, all spawned randomly based on experience points range and number of enemies on screen with their own "weight" values) the pool seems to small to give a sense of variety.
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.
(https://s26.postimg.org/lpco9um89/screenshot_45.png)
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.
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:
(https://s26.postimg.org/7uedrdrt5/screenshot_44.png)
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.
(http://38.media.tumblr.com/5944bcf4f7fe9c0c99f7a593f233731a/tumblr_mj7bx09MDo1s5nl47o2_r1_500.gif)
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, not using seeds for procedural generation means you won't ever be able to replay the level you played, maybe some other time :)
-
Log 12: The Anatomy Of A Roguelike Endless Mode, part 3
I joined all the Endless Wave System posts into one and made further additions, it's a good read!
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.
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.
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 Waypoints
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.
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.
It can be further improved by introducing a case-switch 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.
For now, that concludes the story about the Anatomy Of A (Roguelike) Endless Wave System. I will let you know if it has some further improvements, but for now system seems to be working solid.
-
Hi,
Wow, thats a pretty big and complete Devlog Very nice!!
If you are planning to add more, maybe you can 'reserve' some posts.
i can remove this post later if needed :)
-
No need, it should be an open topic for questions, ideas, opinions, whatever. That's all logs from conception to now, few months work, i'm working slowly because of the full-time job and family but slowly getting there. Next log will probably be about enemy design :)
-
Enemy design - not yet! Now something a bit different, how to avoid burnout, my experiences and advices.
7 ways to avoid burnout (http://www.fatpugstudio.com/dev-log/7-ways-avoid-burnout/)
-
Very nice blog! And this topic is really important, but hard to manage. That feeling when you take the day off to feel good again, but you feel bad all day because you are skipping the work ;D never-ending cycle.
-
That feeling when you take the day off to feel good again, but you feel bad all day because you are skipping the work ;D never-ending cycle.
Oh yeah i know that feeling, but learned to discipline myself doing a certain minimum a day and using Trello 8)
-
Thanks for reading! I know the advices are more or less typical, but i feel people in this line of work need to be reminded of them often ;D
While i'm at it, i'll be probably posting some workflow related stuff next devlog, using trello, asana, hacknplan and organizing workload :)
And yeah, that vicious circle of resting and feeling guilty about it can be quite horrible, especially when working on a loan like i am.
-
Dude. This is amazing.
Thanks for sharing and keep it up.
-
Thanks mate. I made a little break and started doing some art things, background etc, but i guess it's not that interesting to you, so i'll keep you posted when i get to playmaker related things again :)
-
Log 13: Spawning System Overhaul and overcoming the obstacle of enemy pattern making
The Grid
Wow, it's been a while, but things are moving forward slowly but surely!
I've been busy with lots of coding and programming enemies and i encountered some difficulties in proper positioning. On the image below you can find how the spawn points looked (5 spheres on each side) and how they look now (the red X signs)
(https://s26.postimg.org/gz2erxsp5/image.jpg)
Obviously, it offers much more in terms of positioning. More than a year ago, when i first started working on a spawn system i wasn't apt enough to make it the way i wanted to (grid system) so i had to be satisfied with only a few spawn points and additional repositioning upon instantiating. Needless to say, it adds much more work to simple spawning and positioning of those enemies.
By using this handy tool from the asset store (https://www.assetstore.unity3d.com/en/#!/content/20502) i created a grid made out of objects completely automatic. A fine tool indeed. After that, i simply added those to the hash table and now i can simply reference the object whose position i want the enemy to use as spawn point and voila. Besides using it to spawn enemies already in a pattern, i can use them to actually create random patterns on runtime by referencing a different object from the hash table upon predefined parameters to avoid completely random clutter. Not only that, a finer grid enables me to avoid spawning the enemies too close to each other or overlap. Since i'm using Core Game Kit for spawning, i'm waiting for the developers to implement the feature based on sphere raycasting, i.e. if there's an object of certain tag or layer (enemy) in a defined range, the system won't spawn any more to avoid the overlapping. It will work great with the system i made and described few devlogs earlies which is based on enemy pool values and enemy quantities.
Also, Easy Save 3 Beta will soon get a full release (i hope VERY SOON) which will enable IMPORTING variables from a .csv file. It will be of an immense help for tweaking the gameplay.
Enemy Pattern Making (Squadrons)
I must admit, though i am passionate about making a game, some things are quite tedious. I'm having problems with making enemy squadrons, and the way i make them is so boring and uninspiring it really halts my progress.
Before i was well into Unity engine limitations on nested prefabs (only one child per object, i.e. child cannot have it's own child as a prefab, only when instantiated on runtime due to way serialization works) i thought it was going to be a breeze, i just drag and drop enemies in a formation, put them under a parent prefab and voila! Except it doesn't work like that. All of my enemy prefabs typically have two children, Gunpoint and Thruster. Gunpoint hold the shooting logic and muzzle flash animation, while Thruster has the, well, thruster animation. It is on a separate object to avoid being colored with the rest of the enemy ship when it changes color on hit by a player weapon.
So i guess i'll keep my work and make an empty squadron prefab which will spawn and then spawn the enemies in a desired pattern coded into it. That's all nice and dandy until you actually start working that way. No more cosy drag and drop, just selecting what to spawn, input coordinates and hit play too see what you've done. If something's not positioned correctly (it usually isn't), reposition the enemy, copy the coordinates, stop, and paste them. Repeat 10 times for 10 enemy objects in a squadron, and i should have hundreds of them! Horrible! It goes something like this
(https://s26.postimg.org/w3jg96mx5/image.jpg)
So i decided to change my ways. I need to make a reverse approach. Instead of creating an enemy prefab with all the children attached, i'll attach the Gunpoint and Thruster on instantiation, which is only a two step process compared to setting the position of multiple enemies inside the squadron. This way, i have a clean enemy prefabs without children which i can joyfully drag and drop into positions i want and simply save them under a prefab which will be used for spawning.
(https://s26.postimg.org/7ob884o09/image.jpg)
Though it is a bit more work initially, it provides an immense saving of time later and makes it more visual, fun and intuitive to work with.
-
Wow, i find latest log neither insighful nor detailed as some of my previous blogs, but this one made it to gamedev.net featured blogs, woohoo!
https://www.gamedev.net/blogs/entry/2263785-spawning-system-overhaul-and-overcoming-the-obstacle-of-enemy-pattern-making/
-
Log 14: Weapon upgrade system designs and limitations
I’ve been contemplating on design of the weapon system and upgrades for a lot of time. I wanted the game to be based on skill but have a variety which would add to the replayability of the game at the same time. Here are the basic definitions i have decided on:
Game will contain about 30 weapons
Every weapon can be upgraded 4 times (levels 1-5)
Ship has two weapon slots available, you can freely switch between weapons in game
You can’t have same two weapons equipped
You eject the currently active weapon by picking up a new one that’s different
For example, you have Pulse Gun Level 1 equipped as active weapon and Biter Level 1 equipped as inactive. After blasting the enemy transport you come across Ripper and pick it up. Since you don’t have it equipped in any of slots, it will replace the active weapon and eject Pulse Gun Level 1. If you wanted to replace Biter, you could simply switch weapons to make Biter active and replace it by picking up Ripper. This will be a common occurence for adapting to the enemy types because of their vulnerability or resistance to certain type of damage (ballistic/explosive/energy/special against normal/armored/shielded types of enemies).
I could make things simpler in design and coding by simply omitting the part where the replaced weapon is ejected since there’s a small chance of picking it up by accident since it involves pressing a key while you hover over the weapon. However, two player mode requires that feature for the weapons to be interchangeable between players and that is a great way to improve cooperation, gameplay and combined firepower.
Due to some design limitations i had to make a hard choice that can affect the future gameplay on upgrading the equipped weapon and few solutions came to my mind.
1. You can only upgrade the weapon if you pick up the exact same weapon. That way, either equipped or not, the weapon in players possession is upgraded to the next level without any ejection which only happens when you are picking up a weapon you don’t have equipped on any of the slots. While challenging with high long-term impact on decision-making, you only have 6% chance of getting the same weapon from the transport which is slim to none and could severely hamper the player experience. If weapons had only one level the approach would be viable, but with total of 150 weapon levels it would only be frustrating.
2. Whenever you equip a weapon that is not equipped it is always at level 1, but when you upgrade any of the weapons on ship to level 2, the weapon you replace the level 2 weapon with will also be level 2. Basically, if we modify the first example a bit so the active weapon (Pulse Gun) is level 2 and inactive weapon (Biter) is level 1, when we pickup a Ripper instead of Pulse Gun it will automatically be upgraded to level 2. Opposite to first approach, it is less challenging and encourages experimentation, but it comes with a design problem which i’ll explain thoroughly.
When we picked up Biter it is upgraded to level 2 on the ship and Pulse Gun level 2 is ejected. This enables us to switch Biter to active weapon, pickup the level 2 Pulse Gun, eject the Biter, and then pick up the Biter again which will automatically be upgraded to level 2 now. While requiring a bit more speed to do it in a chaotic environment i would considering it cheating since you’re upgrading both weapons that way and that is certainly not something i plan to implement. As i noted in the introduction, i could simply disable the weapon previously equipped to be ejected, but that beats the idea of switching weapons between players which i find to be a great gameplay feature of a co-op mode.
Maybe i’ll disable the feature of ejecting only for single player mode for now.
3. Make weapons upgradeable only by picking up the same weapon as equipped, but increase the chance of spawning a weapon you already have
The maths on this one are simple, though a bit tedious to code. You have 25% of transport spawning active weapon, 25% of spawning inactive weapon and 50% chance of spawning a new weapon. This comes with a different kind of trade-of. Though 25% is a lot it may happen that you rarely run into a weapon you want to upgrade. On the other hand, you may always run into a weapon you already maxed out. This discourages experimentation since you will always want to hold on to your maxed out weapons, no matter how good or bad they are. There are no bad weapons per se, but holding on to weapons of the same type greatly decreases success.
4. Weapon upgrade pickups
Though not originally meant to be implemented, this could pose a good solution combined with approach 1 or 2. It is simply a kind of a joker card which levels up your active weapon without worrying if it’s the same one. If you pick it up, the active weapon gets upgraded and you just keep on blasting.
Which solution would YOU like to see implemented?
-
Just a quick update. Things are slowly starting to take shape. I'm a bit tired from coding, and lots of stuff is already done, so i'm starting to play around with graphics and lights, lookin' good so far.
(https://i.imgur.com/tum8X80.gif)
(https://s1.postimg.org/1rlu8qae1r/ezgif.com-video-to-gif.gif)
-
I saw the thread you posted on the Shmups.com forums but hadn't realised you were using playmaker, very impressive indeed.
In some ways it makes me feel a little inadequate, my own project is far more simplistic and yet I still struggle with it at times. :-[
-
Oh you can't imagine the struggles i'm having, i feel like crying every day, so keep at it!
-
I've been working hard on a scoring system, so here's a new devlog on that!
One of the most important aspects in a shoot 'em up is certainly score. Being somewhat a niche of a genre, it has a clear competitive edge among its players. It certainly lacks fulfillment in terms of engaging story, but the adrenaline rush in combination with the goal of attaining higher and higher scores or even being on the top of the leaderboard is something really hard to beat and is specific to the genre.
With that in mind, a good shmup scoring system has to be easy to understand and engaging at the same time. While it sounds simple, it can be quite hard to achieve a good "funness" factor while keeping it engaging and skill related.
For Rick Henderson and the Artifact of Gods, i dissected a ton of old and new shoot 'em ups in the search for the perfect scoring system i like. One of my all time favorites is certainly Galaga Deluxe (or Warblade for PC folks) for Amiga 500 from late Mr. Edgar M. Vigdal. Besides coins used for shop purchases (which this game won't be using until singeplayer mode is done), in Galaga you can collect gems too. Those little cuties come in different shapes and colors and each one yields a different amount of points. While not groundbreaking, it adds another layer of depth to the game besides dodging as some gems are really worth running for through a rain of bullets. Naturally, tougher enemies have higher percentage of dropping rarer gems that yield higher score addition.
(http://www.fatpugstudio.com/wp-content/uploads/2017/12/Gems.gif)
Another form of bonuses that can be picked up are medals. Far from my knowledge, medaling is prominent in shoot 'em ups. The concept is easy: you pick up differently colored medals, when you have the whole set, you get awarded a rank at the end of the level and the medal collection is resetted when you start the next level. You guessed it, ranks are just another name for total bonus multiplier at the end of the game.
(http://www.fatpugstudio.com/wp-content/uploads/2017/12/Ranks.gif)
There is a total of 9 ranks you can attain (the first being the multiplier of 1, which is your default rank):
Recruit
Private
Corporal
Sergeant
Lieutenant
Captain
Major
Colonel
Marshal
Commander
Complete randomness in spawning those can be infuriating for players with higher skill cap, but i find it refreshing to have a bit of a variety and a possibility for the medals already collected to appear again. Below you can find a weight distribution chart for the medals. When none are collected, the chance for any to spawn is equal. However, as the number of collected medals increases, the chance for already collected medals to appear diminish by 1/5 (or 20% if you like it that way). I haven't done the exact maths, but the chance for already collected medals to appear is not that large. Of course, for collecting already collected medals, you get a nice, juicy score bonus, so they are worth catching too!
(http://www.fatpugstudio.com/wp-content/uploads/2017/12/screenshot_116.png)
Multi kill bonuses! We all played Unreal Tournament 2004 back in the day. It had a nice feature of multikills which i use in my game in a bit different form. For those who haven't played it, you get multikill for killing two enemies in a row without dying. As your kill count progresses (again, without dying) you get megakill, ultra kill and so on. In Rick Henderson and the Artifact of Gods it functions based on time between two kills. When you kill an enemy, an invisible timer starts counting down. If you manage to kill another enemy until the counter hits 0, you get double kill and the timer resets. If you manage to get another one until timer counts down, you get a multi kill, all the way to monster kill. Of course, every additional kill is awared with more and more points. This is usually possible with area of effect weapons (explosive ones) and weapons like Railgun, which can go through multiple enemies, encouraging player to invest more skill in the game.
Grazing bonus is usually omnipresent in bullet hells, a hardcore subgenre of shmups. It encourages the player to "graze" bullets, ie. pass very close to them without getting hit.
Design itself was a bit harder to implement since it involves tracking multiple bullets at a time getting into the graze range and checking whether they hit the player or not.
While not neccessary for the gameplay since i don't want it to be bullet hell, it's one of those things setting apart rookies from hardcore players that want to get the most out the game.
And finally, the good old bonus multiplier which adds up with every destroyed enemy, gets lowered when you get hit, and reset at every waves end. It goes well in combination with grazing bonus, making you get closer to the bullets but not get hit. It also serves as a kind of damage control system. Since i gave up on the idea of having a 0-100 healh bar and chose a 10 life bar instead, hits from tougher enemies take more of your bonus multiplier down.
I believe the score mechanics are very easy to understand and will add up much to the investment of the player and the adrenaline pumping of the true genre players.
-
Hi guys, i've been working really hard, so i didn't have time nor will for devlogs. Here's a short gameplay video, there are lots of bugs due to pooling system which i will eventually flatten out and some debug stuff turned on, but you'll get the idea how it looks and feel in general.
-
Love the art. Really nice fx with the explosions. Dont leave this project!!
-
Thanks, i'm not :)
-
Dev Log #5 Cutting halves in half
(https://i.imgur.com/FGL6E3C.gif)
When starting out with a game in a powerful engine like Unity it seems like everything is possible and that you can make a game in a finger snap. While everything is possible and you can make something playable in a relatively short time span, making a complete game usually takes a fair share of time, especially if you are a newbie to game design, engine itself and programming.
As far as i can tell, illusions of grandeur are quite common when you begin developing a game (turns out i was not immune to it too). Enthusiasm doesn’t seem to whiff away quite easily as it is fueled by actual things getting done, but after a while you get to realize it will take too much time to make it like you want it to be, or you simply don’t know of a way that is fast and simple enough. If you want to complete the game, you will need to strip it of layers and keep it simple. It hurts and feels like taking away the originality and personality from it. Not only will you have to cut it in half, but you will probably need to cut that half in half too, reducing it to meager ¼ of the game you meant to make.
One of the things i had to cut again and again was the weapon system i was quite proud of. You can read about it here and here’s the short version:
30+ weapons in game;
5 levels of each weapon;
3 weapon types (bullet, energy, missile, each having a corresponding multiplier against normal, armored and shielded enemies);
Player can hold two weapons at the same time, but fire only one;
You can’t have two same weapons of different levels equipped;
You can’t have two weapons of same type equipped;
You have Bullet Weapon X Level 1 equipped as active weapon and Energy Weapon X Level 1 equipped as inactive. After blasting the enemy transport you come across Missile Weapon X Level 1 and pick it up. Since you don’t have it equipped in any of slots, it will replace the active weapon and eject Bullet Weapon X Level 1.
If you wanted to replace the Energy Weapon X Level 1, you could simply switch weapons to make Energy Weapon X Level 1 active and replace it. This would be a common occurence for adapting to the enemy types because of their vulnerability or resistance to certain type of damage.
I could make things simpler in design and coding by simply omitting the part where the replaced weapon is ejected since there’s a small chance of picking it up by accident since it involves pressing a key while you hover over the weapon. However, two player mode requires that feature for the weapons to be interchangeable between players and that is a great way to improve cooperation, gameplay and combined firepower.
Reality check!
Due to design limitations (limitations as in 150 weapon variants) i had to make a hard choice that can affect the future gameplay on upgrading the equipped weapon and few solutions came to my mind.
1. You can only upgrade the weapon if you pick up the exact weapon
That way, either equipped or not, the weapon in players posession is upgraded to the next level without any ejection which only happens when you are picking up a weapon you don’t have equipped. While challenging with high long-term impact on decision-making, you only have 6% chance of getting the same weapon from the transport which is slim to none. Needles to say, a bad option.
2. Equipped weapon level transfers to pickups
Whenever you equip a weapon that is not equipped it is always at level 1, but when you upgrade any of the weapons on ship to level 2, the weapon you replace the level 2 weapon will also be level 2. Basically, it would be a kind of cheating, since by dropping and re-equipping active and inactive weapons, you could get all equipped weapons to a higher level.
3. Weapons upgradeable only by picking up the same weapon
To make it more viable, one should increase the chance of spawning a weapon you already have.
The maths on this one are simple, though a bit hard to code. You have 25% of transport spawning active weapon, 25% of spawning inactive weapon and 50% chance of spawning a new weapon. This comes with a different kind of trade-of. Though 25% is a lot ot may happen that you rarely run into a weapon you want to upgrade. On the other hand, you may always run into a weapon you already maxed out. This discourages experimentation since you will always want to hold on to your maxed out weapons, no matter how good or bad they are. There are no bad weapons per se, but holding on to weapons of the same type greatly decreases success.
4. Weapon upgrade pickups
Though not originally meant to be implemented, this could pose a good solution combined with approach 1 or 2. It is simply a kind of a joker card which levels up your active weapon without worrying if it’s the same one. You pick it up, the active weapon gets upgraded and you just keep on blasting.
The basic idea was for the player to drop the currently equipped weapon when he picks up the new one, so if a mistake is made (though hardly possible, since only hovering over it won’t do – you have to press a pickup key too) player can simply pickup the ejected weapon again.
Resolution
I don’t know about you, but i got a headache just by reading this. You see how easy it is for things to get out of hand for every single layer of stuff you intend to add? Amount of work increases exponentially for every feature added. Not only did it get overly complicated, but it got to the point where it would depend on chances of picking up weapons that would be extremely hard to tweak properly. And all that doesn’t guarantee that you won’t end up in situation to have no proper weapon to amswer the challenge on the screen, which is unacceptable.
On top of that, i wanted to implement weapon overheating mechanics, but to be honest, i haven’t played any game except Jets ‘n’ Guns that has it, and that game has a completely different concept.
In the end, the whole system got stripped down to bare essentials, and an easy to understand concept:
You start with all 3 weapon types on ship (basic weapons);
No switching – you have a button for firing every weapon (with a small delay between firing a different weapon, something like auto-switching);
Automatic picking up, you don’t need to press a key while hovering over a weapon to pick it up;
When you pick up a weapon, it replaces the one with the corresponding type on the ship and the old weapon does not get ejected;
No weapon levels, which brings number of weapons to a manageable number (maybe i’ll put SOME levels in the future, but i doubt it);
No overheat mechanics, it would add another layer of tweaking which would require enormous amount of time of testing;
Much better and easier to grasp.
After a while you don’t look at the striping like something that made your game bland and simple, but as a salvation from meaningless work that would probably be too complicated for you and not turn out well. Obviously, perfection is not a thing to strive for, especially if you are a solo developer. Much bigger games suffered for trying to achieve it. So, keep it simple, and cut, then cut again.
-
Here's a small teaser.
It's getting close!
-
Looking great! Music sounds great as well!
The only suggestion I could add is to have, even if low volume, the sounds effects in the video, give it a bit more punch. But I realize it's just a small teaser, but figured I would throw some feedback out there.
-
I will, it does miss a punch with sfx! Thanks!
-
IndieGoGo pre-launch page is live!
https://www.indiegogo.com/projects/rick-henderson/coming_soon
How i made my IndieGoGo campaign
After more than two whole years of toiling, sleepless nights, stiff fingers and dry eyes, i finally reached the point where i’m ready to show something more complete to the world and prepare for the crowdfunding campaign that will help me bring the game to a final release.
While Kickstarter clearly enables a wider audience, it is not available in my country so i didn’t have much choice of a platform for crowdfunding – IndieGoGo was basically the only way to gogo (sorry for the pun).
Preparing the campaign was a really tough process and i admit it took me a while with all the other things i have to do in my life.
First of all, i had to explore the possibilities and limitations of the platform and how to fit them to my needs.
Albeit with a smaller reach, IndieGoGo has some clearly better features than Kickstarter. InDemand helps you gather the funds and build the community even when the campaign is over. Of course, you need to reach your goal before that, so you need to find a reasonable amount that will help you finish your product. Not too small, but not too large either. I had a lot of trouble in finding that sweet spot, but in the end i decided to ask for a bare minimum that will make me finish the game, no more, no less. Everything over that will be used for stretch goals. I have a lot of ideas and i can already figure out how much will they approximately cost, so i’ll see how the campaign goes and add them during the campaign.
Another interesting feature that IndieGoGo offers is flexible funding and you are probably wondering why didn’t i opt for it if i had to choose IndieGoGo. The amswer is simple, i don’t want to have obligations of given promises if i don’t reach my goal, it would not be fair towards the backers. I need funds to make my ideas to become reality and acting in any other different way than being completely honest and transparent would be irresponsible.
Luckily, i already have enough experience (that costed a lot) and have gathered data to know how much will the rest of the game cost if i want to do it my way. So herе’s a breakdown that will be visible on the campaign page when it starts:
Backgrounds – You noticed that the teaser only has three backgrounds. To make the game more visually pleasing i need 20 backgrounds in 5 thematic colors (red, green, blue, purple, yellow), each costing 45-70 USD per piece, which comes to roughly 1.500 USD since, besides the regular artist hours involved for making them, some additional hours will be probably needed for fixes and adjustments.
Additional gfx works – Additional graphics include finishing the Rokh Raiders sprites (the sixth faction that has not been finished), background elements, bullets, special effects, explosions and works on the Galaxy Database. I approximate that 1.000 USD is needed for all of that. It might seem much, but bear in mind that’s only 33 hours of more or less standard artist pay, or 4 eight hour work days, which is a really, really short amount of time when you look at it.
Translations – They cost around 0.1 USD per word for translating the basic user interface and options, but a lot more if i plan on translating the Galaxy Database. But for the basic translation into French, German, Italian, Spanish, Portuguese, Chinese and Japanese, i approximate that around 100-200 USD will be needed since the game does not have many words.
Fees and taxes – Steam Fee is 100 USD and Indiegogo takes 5%, and then there’s income taxes too, which will come around to 10-20% for this amount.
Music and SFX – Music licenses are very expensive to obtain, but i am in contact with several musicians that are willing to let me use their music for an IndieGoGo and revenue cut. Still, it will probably come to around at least 10% of the funding. I have been a music producer for more than 15 years so the sound effects will be handled by myself. I could probably do the music too, but i don’t have enough time and there are a lot of people that do it better than me anyway.
When you add all that, it comes to about 3.000,00 USD, which is an amount that i’m frankly scared of. I invested a bit more than that in the game until now, and seeing that it was enough only for the half of the graphic assets that are needed for the game of this caliber is frightening.
While the game itself is not a revolutionary product that will break the genre, i do believe it stands out a lot among lots of shmups that are out there at the moment. First of all, the graphics are reminiscing of golden age of Amiga 500 games, beautiful 16-bit pixel art with no rendered or pre-rendered 3D graphics, but with dynamic lighting. I haven’t seen it in a shmup for some time. Music in the game (at least the tracks i collected until now by Cryocon and Mlada Fronta) is damn fine and i plan to make it on par with the iconic soundtrack of Hotline Miami or old-school hits like Crusader, Unreal Tournament, Rollcage or Project X (you can listen to the tracks here - https://www.youtube.com/watch?v=mkqCOG-eo_M&list=PLsT6JqupJZVoa0xFKCyXG2h3DVk9pJ4Wp (https://www.youtube.com/watch?v=mkqCOG-eo_M&list=PLsT6JqupJZVoa0xFKCyXG2h3DVk9pJ4Wp)).
Anyway, back to the campaign. At first, i didn’t know what could i possibly offer to the backers beside the game itself. Ok, Early Access is something that i planned anyway, so i could give away that too. I plan on selling the soundtrack separately (all proceedings will go to the artists), so that’s a cool perk to add too, but what else? When i started making the game, i had illusions of grandeur, like every fresh gamedev out there. Rick Henderson as supposed to be a huge single player experience with levels and an intriguing story behind it. When reality struck me, i decided to drop the whole predefined levels concept and i had a lot of ships and weapons descriptions left behind unused. I got to an idea that they can be used for Galaxy Database, a small book of enemy ships and player weapons with their stats, description and a small backstory for each one of them. Lower tier backers will get it in PDF, while high tier backers will be getting a nice hardcover booklet.
To further engage the potential community of backers, one of the perks will be the Community Ship Designer. Backers of that tier will have the exclusive access to hidden Discord channel where they will be able to create an enemy that will appear in the game together. Sure, it will be a challenge for me since it has to be in certain design boundaries (and maybe technically, who knows what people can think of), but i think it’s a rather cool reward.
Name on a blimp is purely cosmetic. If you really like shmups and you got a lot of dough to spare, your name will appear on a space blimp with a large display on it (think Blade Runner).
Finally, with only 5 available, you can design you own enemy (not a boss though) by working with me and a graphics guy. Might not seem as much, but creating an enemy that is interesting and balanced is quite time consuming, let alone 5 of them.
Ok, i’ve got the amount i need, backer rewards and now i need to present the game in the best possible light. I hate punchlines and single sentence descriptions, but it needs to be done. Put your whole game in one sentence. It’s like an elevator pitch, but you don’t even have the time to ride to the first floor, just poke your head through the elevator door and shout one sentence. So i came up with Endless horizontal-scrolling shoot ’em up experience with infinite replayability. Well yeah, it’s infinitely replayable, but in a way that it will never get boring. I decided not to use terms like procedural or roguelike since, honestly, i believe players already have an aversion when they read those words. It is endless since it doesn’t end, you can only die. Obviously, it’s horizontal-scrolling shoot ’em up, and i like to call it an experience, since it’s an audio-visual experience made for connoisseurs of the genre and style.
I made sure to be perfectly clear how the game loop functions, how the weapons/armor relations work, even if it’s dead simple to understand and provide as much material as possible for the players to see how the game sounds and looks like. Screenshots were easy to take, but resizing images to fit in IndieGoGo’s predefined image sizes and remain pixel perfect was a pain in the ass. Preparing a small teaser took days of work and i can’t say i’m happy with the final result in terms of video quality. Unity’s inbuilt recorder compresses the video even on high setting and artifacts appear when there’s a lot of stuff going on on the screen, but i believe it’s good enough to be used as a proof of concept and let the backers know what’s it all about.
Unfortunately, i wasn’t able to provide the demo since i think it’s too early and i’m a bit of perfectionist. I regard that as the biggest flaw of my campaign and i hope it will do well even without it.
One of the things that really makes me proud and that i want to point out is the dedication to inclusion. I want everyone to be able to play the game. I’m positive that colorblind modes will probably include more tweaking than simple filters implementation, but turning off shakes and flashes will mean a lot to someone who’s suffering from problems related to photosensitivity but like shoot ’em ups. High-contrast mode is going to demand quite an overhaul, but if all goes well i’m all for it.
My fears? Shoot ’em ups are quite a niche of a genre so i’m scared how many people will be interested in a game like Rick Henderson. Deep inside i believe there’s a lot of folks that want to see something new that’s not a bullet hell or reissue of an old classic, but a modern envisionment of the classics that marked an era.
You can find the pre-launch page here (https://www.indiegogo.com/projects/rick-henderson/coming_soon) and if you had a good read and are interested in seeing this project come to life, subscribe to be notified when the campaign is launched or share it – every bit helps 🙂
-
Hey guys, Rick Henderson now has a Steam page!
https://store.steampowered.com/app/1023790/Rick_Henderson/
Wishlisting to cut through the shovelware helps ;D
-
Demo is live!
Steam - https://bit.ly/2FayeNc
Itch - https://bit.ly/2Y5Miz0
GameJolt - https://bit.ly/2XWncCr
IndieGoGo campaign starts on monday, you can subscribe here (https://www.indiegogo.com/projects/rick-henderson/coming_soon) to get notified.
-
You did an great job with a reasonable budget. I hope you get funding and its a success.
By chance, did you use a SHMUP framework or is it all custom built?
-
Hi, thank you. I didn't use shmup framework, but i did use a lot of assets that helped not to waste time on developing my own systems. Core Game Kit for pooling, Master Audio for sound management, UniBulletHell for firing patterns, Easy Save for saving settings, Energy Bar Toolkit for energy bars, Rewired for controls, ProCamera2d for managing cameras.
Without those, things would take even longer.
-
I'm going early access next week!
-
https://www.eastasiasoft.com/games/Rick-Henderson ;D
-
Hi.
Looks great!
It makes me think of a classic (R-Type)
Are you not Releasing on Steam?
-
Hi, it's already released on steam: https://store.steampowered.com/app/1023790/Rick_Henderson/
It's hard to get noticed over there over all the noise, console release will fare well i hope :)
-
Hi.
I did not look on steam yet, but on your webpage its not stated that it's on steam :)
or at least on the page you linked its not stated :)
-
Yeah i kinda neglected my homepage due to amount of work i have. As for eastasiasoft page, they're only publisher for consoles, steam edition is self published, hence the fantastic sales and visibility haha
-
Hi.
Yeah, marketing can be pretty hard.
-
Out now on xbox x|s, ps4/5, switch ;D ;D ;D