MicroCosmic: Water Bear Warfare

Community Showcases
1

Hello! Check out the video below for a quick overview of what MicroCosmic: Water Bear Warfare (previously known as Shooting Star: Tactics) is all about, or read on for more details.

You can try out an early version of the game on itch.io at the link:

MicroCosmic: Water Bear Warfare
We’re making a turn-based strategy/tactics game that flows a bit like Worms (Worms Armageddon). On your turn, you can choose which ship you want to use, move it, shoot with it, switch control to a different ship, etc. You have a limited amount of action points (AP) to spend on moving and using weapons/tools that is shared between all of your ships.

The game is designed to be played locally with 2-4 players (although online play is a possibility for the future) using a keyboard and mouse on PC. We’d like the game to be playable on mobile devices in the future as well.

Compared to my last game, MicroCosmic is quite complex, and I’m still trying to figure out the best way to explain it concisely. The best way to understand is probably just to watch a little bit of one of my gameplay videos, or just try it out yourself.

The Team
Rob (me): Game design & programming
Matt: Graphics & game design
Darren: Sound effects

-------------------------------------------------------------------
DevLog #1

Hi all.

It’s been a little over three years since I finished and released my first game, CATACLYSM. What a tremendous learning experience that was, not to mention a perfect distraction from my studies.

Since I finished with that game, I have dabbled in a few other projects, but nothing has really stuck. I have a good feeling about this new one though. I’ve gotta say, it’s very nice to be this excited about game development again, as I didn’t know if my passion for it would ever come back.

The Idea

The idea for MicroCosmic came to me when I was just mindlessly watching completely unrelated stuff on YouTube. My initial idea was to have a single-screen, turn-based, multiplayer game, like a cross between Worms and Asteroids. Initially, I thought there would be a heavy emphasis on doing bank-shots to bounce bullets off of obstacles on the map to hit your opponent without giving them a free hit on you. On each player’s turn, they would have a limited amount of fuel to move either before or after they shoot. As I recall (I haven’t played much of it and it was many years ago), Valkyria Chronicles has a similar system.

I called my friend, Matt to tell him about it, and with his input, the concept evolved into something much deeper.

The Game So Far

I started the Unity project file on June 6th, 2021. This is what we have built so far (that I can think of off the top of my head):

  • Two animated ships
  • Two projectile types
  • Action Point (AP) bar drains when flying
  • AP bar shows “preview” that indicates how much AP the selected weapon will use
  • Players can use “Cycle Mode” to freeze the action and switch control to a new ship
  • After AP reaches 0 (or the player manually skips), the turn changes over to the next player (up to four… only tested with two)
  • Players are damaged when hit by projectiles (friendly fire is on!), and may be pushed away (eventually ships will take damage if they crash into stuff)
  • The camera follows the active ship

It sounds so unimpressive when I list it out, but I’m feeling good about the rate of progress being made as this is all being done after work and during my 30-minute lunch break.

What’s Next

At this point, the game is “playable” in the most generous sense. You can take turns shooting at each other until one person runs out of ships and the game throws a StackOverflowException (“You Win!?”). There are, frankly, an overwhelming number of things that I could work on next. A few priorities that come to mind are:

  • Defining the world bounds and what happens when you try to leave them
  • Building one or two more projectile/weapon types to give the two ships a little more distinction
  • Build the ammo system to give a better idea of how the game will play, as it is on paper
2

DevLog #2

With me doing the programming, Matt doing the art, and both of us working on gameplay design, there’s still one massive element that neither of us currently have the skills to create: The sound effects. Fortunately, Matt’s friend, Darren, has experience in this area, and is interested in contributing to the project. He has already created some “early prototypes”, some of which I have built in.

Anyway, here’s a list of features added since last time. Both Matt and Darren have done some work that isn’t in the game yet, but I’ll do that soon.

Border teleportation
After looking into it, I decided that a seamlessly-wrapping world was not in the cards for this project, but I still wanted a similar effect. The tricky thing with teleportation is making sure you don’t accidentally have an object teleport into another one, which is an especially high risk when you have many teleport-able objects. While this is still possible with my setup, it’s much less likely: Touching the inner edges of the border will trigger a teleport, but the object will exit inside of the opposite border. The border regions will push objects back into the arena. This way, you’ll never have objects sitting idly on a teleport exit.

Collision damage
This is both a tactics and skill-based game, so you will be punished (or rewarded) for reckless driving. Ships take damage partially-based on the mass of the other object. At this point, I think both the Scout and the Fighter have the same mass, although that ought to change.

Ammo
In addition to AP, you’ll need ammo for each of your weapons and your “utility”. When your turn starts, every ship in your fleet will get +1 ammo for Weapon 1. For Weapon 2 and your utility, you will need to rely on pick-ups that randomly spawn between turns, drop from destroyed ships, and are deployed by the supply ship.

Mini HUD
There will be a larger HUD with more detailed information about the ship that is currently selected. I thought it would be important to also have some basic information about ammo and health (of course) of all ships easily visible to enable you to make better-informed strategic decisions.

Camera zoom
This was my personal biggest achievement since last time. It wasn’t just a matter of changing the camera’s orthographic size because there are two other camera modes to consider (snap to next ship, and follow current ship). Also, I wanted the camera to stay within the world bounds when you zoom out, so that was tricky too. Finally, I wanted the mini HUD to be visible when you zoom out. I thought that if they scaled, they would cover the ship that they’re attached to, but that doesn’t seem to be a problem. Obviously, they will get cluttered and overlap if there are many ships together, but I don’t have a big problem with that, especially since you’ll be able to toggle the mini HUD elements on and off.

Fighter
The Fighter ship is now equipped with a missile. The explosion animation will not be made until we’re confident that the size of the blast is appropriate. It also has a machine gun that fires five large bullets with fairly high accuracy.

Scout
The Scout has the energy ball as its primary fire. Later, this ball will be able to bounce off of targets and obstacles. The Scout’s machine gun fires a spray of twenty small bullets. You can barely hear it in the video, but Darren’s sound effect is perfect for this.

Sprites
Nearly every sprite has been modified slightly as Matt wanted to make the jet flames more prominent. The colour-tinting kind of ruins it, but this is only temporary until I have different coloured versions for each team.

1 Like
3

Hello there!

Have a great developing journey, both of you!

I like the idea, Worms and Asteroids are some of my favorite games (i’ve never played Valkyria Chronicles). The possibilities are there for you to discover.

One of my first ideas for a game was a 2d top-down game in space visually like this and i worked on it for some days. I am a visual guy, so the first thing i did was to create a deep parallax background. I remember having 4 or 5 parallax images with stars, planets, nefeloma and others. Plus, i was having space rocks and others moving objects between those images. All those gives a lot of perspective into the scene and make it look alive instead of having just a static background. But you have to do it correctly, so the background not confuse players. I totally recommend you guys give a try.

Of course, for you now, it maybe be too soon for that, but the best advice i have learned from indie devs, is that first of all, you have to make your visuals to look good. I also get many ideas for the gameplay when i start from the visuals.

Keep going!

1 Like
4

I’ve always been a huge Worms fan too. My experience with Valkyria Chronicles is very limited, but I mention it because I think those games use a similar “Action Point” bar which you deplete by moving and shooting with your various units. My first version of SS:T had a separate bar (or fuel gauge) for each unit, and they got to act once per turn. It was during that first phone call with Matt that this changed quite drastically, but I think it’s better this way.

It’s funny that you mention paralax backgrounds as Matt and I were just talking about this yesterday. He definitely wants to do that to give the game some extra visual depth. We’re using a placeholder image for now (Edit: it’s a public domain image) just to have something to fill in that space. I think backgrounds will be something that don’t show up until later in development, as they don’t really affect gameplay.

I love that you have a completely different approach though. You have the visual artistic skill, solid gameplay design abilities, and you can code, so you can do your games in whichever order suits you best. I appreciate good-looking art (such as yours), but when I’m making games, it’s a low priority until the gameplay systems are figured out. Fortunately, I have Matt to work on that stuff, and make cool-looking ships and explosions, etc. while we plan gameplay systems and I build them.

Thank you for your feedback. :slight_smile:

1 Like
5

DevLog #3

I’ve been quite busy working on the game (and getting married), but it’s time for another update.

This stage of development is interesting because there’s still room for pretty significant gameplay changes. I have been playing games against myself to figure out what kinds of strategies are effective, and how useful the ships’ weapons and abilities are. One thing that I found is that there was little to no reason to ever use a ship’s primary fire if it has its (better) secondary fire available. Our answer to this is a very simple “weakness” system where each ship is weak to one particular type of projectile. In the final game, information such as what a ship is weak to and how projectiles are classified will be clearly available to players.

Force Fields
This is an extremely important element, so it’s nice to have it in the game. Every ship has a region around it (which is invisible until you get close enough) where if you cross it, your ship is pushed away and a small amount of damage is dealt. This is to discourage players from flying up and shooting at point-blank range. You can still do this, of course, but it will cost you some HP as well as AP, as you’ll have to burn more of it to fly back to the target after it has pushed you back. This defence effect will only trigger once per turn, and the currently-selected ship will not have an active force field. You can use these areas to score additional points of damage by shooting enemies towards your own ships, knocking them into their force fields.

Weaknesses & Weapon Classes
As explained above, we decided to make ships weak to certain weapon types. This meant that we had to determine how we’ll classify weapons and how we’ll communicate this clearly to players. Each weapon class will have two primary variants. For example, “Ballistics” will include “bullets” and “shells”. Ammo pickups will have icons that alternate between the “bullet” and “shell” icon, indicating that the pickup will restock either ammo type. Ship weaknesses will not get as granular as being specific to variants, as I think it would be needlessly complicated. Instead, they’ll be weak to any weapon within that class. The weapon types are (currently) as follows:

Ballistic: Bullets & Shells
Plasma: Condensed & Raw
Explosive: Missiles & Mines
Electrical: Chargeable & Disposable

Scout
The Scout is meant to be a fast, light ship whose primary function is to “get in, do damage, and get out”. Its primary fire is a long-ranged (but low damage) “condensed plasma” shot. “Condensed Plasma” just means that it’s a round, bouncy bullet that maintains its velocity after hitting something (we’re just making up terms, of course). Its secondary fire is a machine gun that sprays bullets with fairly low accuracy. Finally, its ability is a dash attack which allows the Scout to quickly approach/escape while burning a small amount of AP. The dash also disables enemy ships’ force fields, damages ships that are hit with the dash, and pulls hit ships towards the Scout, allowing the Scout to do a potentially-devastating point-blank shot with its machine gun. The Scout is weak to missiles, so leaving it within range of a Fighter is unwise.

Fighter
The Fighter is sort of a general purpose ship. It has average mobility, and powerful weapons. The primary fire is a heavy machine gun which fires only five rounds with a narrow spread, meaning there’s a good change you’ll hit your target with a few of your shots, even from a distance. Its secondary fire is a small missile which files in a straight line for high accuracy. The Fighter’s ability is a shield that protects from a certain amount of damage before being destroyed. Its best used when the Fighter is in danger of being attacked by multiple Scouts. The Fighter is weak to ballistics, and the shield is weak to electrical attacks.

Explosion Animation
Matt has drawn the first of many explosions. I still need to write the script that makes it fade out, but you get the idea.

More SFX
I have implemented a few more of Darren’s SFX. I’m still having a bit of trouble with getting them to play at an appropriate volume, particularly the teleport sound. I’ll get it smoothed out eventually.

Map Size
We’re fairly confident that the map that we currently have is what we’ll use as a “small” map. I expect that there will be two or three map sizes. Instead of allowing players to zoom all the way out to see the entire map, you can now only zoom out a fixed distance to see the space around whichever ship you have selected.

Reticle
It’s a small detail, but the reticle makes it clear where you’re aiming, even if you’re zoomed out too far to clearly see your ship.

I’m getting closer to the point where I can start focusing on building the other ship types, which I’m really excited about. There’s still work to do before I can really prioritize that, but maybe the next update will have something cool like that to share.

6

DevLog #4

I think the most exciting kind of update (for me, anyways) will always be when a new ship type has been implemented. This is one of those times. Introducing: The Stealth Ship (name not final-- we’re considering calling it the “Cuttlefish”).

It is the first ship to have a passive ability. That is, at the end of your turn, your stealth ships will turn invisible. No surprise there. A stealth ship will be revealed if either a ship or a projectile enters its force field area. You could fly around trying to bump into it, but the stealth ship’s force field does more damage than others, so that’s generally not going to be the preferable way to go.

Primary Fire: Taser
The taser is the first electrical weapon implemented. As with all weapon types, there are two sub-types. The taser is a chargeable battery sub-type. Whereas other primary weapons restock one ammo at the start of your turn, chargeable batteries will charge one level (up to two levels, normally). When you fire, the battery is completely drained, so it’s a one shot per turn deal. Collecting ammo of the type matching your primary weapon when your ammo (or in this case, charge level) is full will normally give you one bonus ammo. The chargeable battery’s equivalent is an overcharge level.

For the taser, its effects are as follows (all “disable” effects last one turn):
Level 1: 6 damage, disable target’s secondary fire, reduce target’s max speed, disable target’s force field
Level 2: 12 damage, disable target’s primary fire, plus above effects
Level 3 (overcharge): 22 damage, “shut down” effect (target is unable to move), plus above effects

Secondary Fire: Raw Plasma Spread
The Scout’s primary fire is of the condensed plasma sub-type, which is a bouncy projectile with a long lifespan. Raw plasma isn’t necessarily limited to short-range, but each projectile adds to a DOT multiplier on the target, so hitting them with all three can be quite effective. The DOT effect is pretty straight-forward: Each DOT does 3 damage at the start of your turn, and then the multiplier is decreased by one. So, if a ship is hit by all three projectiles, it’ll take 9 damage at the start of that player’s turn, 6 on their next turn, and then 3 after that. The projectiles also do 3 damage each on impact. All of these values are likely to be changed as we playtest, but that’s the idea anyway.

Ability: Smoke Screen
I admit that this ability had me stalled out for a little while. I wasn’t exactly sure how to do it, whether or not it would be useful (especially for the Stealth Ship), and what an alternative ability could be. Matt and I came up with several other ideas that will likely be used with other ships, including one that I was excited about. Matt liked the idea, but still felt that the smoke screen would be best for this ship, and after explaining how he pictured it working in more detail, I was convinced, and got it working the same day. I’m sure I’ll adjust the emitter here and there, but I’m actually pretty happy with how good it looks given the small amount of time it took. Since the video, I already decided to decrease the lifespan from 3 turns to just 2. Also, I’d love to get a vision cone on the Stealth Ship so that it can see through the smoke when you hold right click (used for “precision aim mode”).

I’ve also made other little changes/additions. The Fighter’s shield works a little differently now. Instead of protecting you from a certain amount of HP before disappearing, it protects from all damage* for one turn, and then it is disabled. It can also still be disabled by being hit by an electrical-type attack. Matt drew a really nifty-looking shield animation which is implemented, but I was so focused on the Stealth Ship that I forgot to show it off. That’ll have to be for next time.

In my last log, I mentioned that there was still room for significant gameplay changes. Well, I came up with some stuff that I think will completely change how the game works. Getting it implemented is a high priority, so hopefully I’ll have something to show next time.

7

DevLog #5

This first video just shows a couple of the sprites that Matt has made to replace my “programmer art”. The taser looks awesome, and that’s just the “charge level 1” sprite. There will be bigger effects for the level 2 and 3, of course.

I spent the last few weeks primarily working on implementing the new “Mother Ship Mode”, which I see as the main game mode. The details are explained in the video, but just in case you can’t sit through my half-asleep drawling, I’ll give a summary:

Each player will start the game with a Mother Ship and a Drone, plus their fleet of ships. You can win the game by either defeating their fleet or by defeating their Mother Ship. In order to damage the Mother Ship, you first need to disable its shield by destroying the Drone (which has very little HP), and the Drone respawns at the start of your turn.

And now, just because I like writing this stuff out, I’ll detail the two new ships:

Mother Ship
In order to ensure that a “Mother Ship Victory” (destroying one) is always a viable strategy, the Mother Ship’s HP is based on the sum of your fleet’s HP. Currently, it’s 50% of the fleet’s HP, but this will likely be adjusted as we playtest.

The Mother Ship’s force field is a little different from others. It’s bigger, does more damage, pushes ships away further, and it also heals any ally ships within its range at the start of your turn.

Primary Fire: Restock All Pick-Up
The Mother Ship can create (via projectile) a unique pick-up. When collected, a ship will gain one ammo to their primary and secondary fire, and also restock their ability. The Mother Ship and the Drone cannot collect these pick-ups.

Secondary Fire: Condensed Plasma Barrage
Like the Scout’s primary fire, the Mother Ship’s primary fire shoots condensed plasma, which just means a round projectile that bounces when it hits stuff and doesn’t lose its momentum. Unlike the Scout, the Mother Ship’s attack shoots three large projectiles (per use), each doing 25 damage. Because it’s a secondary fire, it will not replenish automatically, and the Mother Ship is too slow to get pickups manually. This is where the Drone comes in handy, as it can fetch pick-ups and bring them to the Mother Ship.

Ability: Restock Fleet
Rather than creating a pick-up that only one ship can collect, this ability gives one ammo to the primary and secondary fire of the entire fleet (excluding itself and the Drone).

Drone
The Drone’s main job (aside from not getting killed) is to collect pick-ups and deliver them to other ships, primarily, the Mother Ship which is all but incapable of doing this on its own. When the Drone is killed, a beam of light will shoot towards the Mother Ship, revealing its location.

Primary Fire: Restock Secondary Pick-Up
Most ammo pick-ups will be specifically useful for ships that use that ammo type (plasma, explosives, electrical, ballistics). There are also generic ammo pick-ups that will either restock a ship’s primary or secondary fire. This is where the Drone’s primary fire comes in. It can collect any ammo pick-up (excluding the Mother Ship’s “all” pick-up), and convert it into a generic secondary fire pick-up. So, for example, if your Fighter is out of missiles, but there are only ammo pick-ups of the other types around, the Drone can collect them (one at a time) and fire a generic secondary fire pick-up towards your Fighter. This is also the most viable way to restock the Mother Ship’s secondary fire. Unlike other ships, the Drone does not get a restock of its primary fire at the beginning of each turn, and after respawning, it will not have any ammo.

Secondary Fire: Restock Ability Pick-Up
Similar to its primary fire, this can be used to replenish the ability of any ship that you hit with it. If you miss, it will turn into a pick-up that does the same thing. When the Drone collects an ability pick-up, this will be restocked, rather than the Drone’s own ability.

Ability: Ship Transport
The Drone’s ability has a unique icon to differentiate it from other ships’ abilities. When used, the Drone self-destructs, and the Mother Ship is teleported to its location. This will, of course, disable the Mother Ship’s shield, so I envision it only being used in situations where your Mother Ship is overwhelmed with enemy ships.

UPDATE: This ability has been tweaked in a pretty significant way. Now, the Drone can “tag” another ally ship by (gently) bumping into them. When the Drone’s ability is used, the tagged ship will be transported, rather than the Mother Ship. If the tagged ship dies before it can be transported, the Mother Ship will automatically be set as the tagged ship. When the “3” key is pressed (for selecting a ship’s ability), the message box will indicate which ship is tagged.

That’s it for now. I don’t really have any big things on my to-do list at this point aside from implementing more ships, which is always a lot of fun. I do need to get that dashboard HUD going and I’ve been waiting on Matt to provide the graphics, but perhaps I should get the framework in for that sooner than later. The next update will probably have something resembling the complete HUD and possibly a new ship. Stay tuned!

8

DevLog #6

It’s been awhile! This process has been similar to the development of CATACLYSM in that I went through fairly long stretches of not working on it for one reason or another.

Some of these “new” features have been in the game for some time, but I wasn’t ready to share them. I guess it was starting to feel ridiculous that I was just using the “Fighter” sprite as a placeholder for every new ship. It could be a long time before Matt is able to make something nice-looking, so I decided to throw together some placeholders of my own. They aren’t pretty, but they do make each ship distinct, and that’s the main thing. Also, making the Mother Ship a significantly larger target is important for (probably obvious) gameplay reasons.

Anyways, here’s what’s new:

Orb-Weaver
This is the “Mine Ship”, which was one of the early ideas that Matt and I came up with. We are both interested in ships that are built around doing something aside from direct attacks and this ship fits that category nicely. This ship is a bit unusual in that it fires from its rear end. Nope-- nothin’ funny there.

Primary Fire: Mini Mines
This is probably a “no brainer” for a “mine ship”. The Orb-Weaver spits out a whole mess of tiny mines. They only do a small amount of damage each, but they pack a fairy strong knockback effect, meaning that ship that hit one are 1) at risk of getting bumped into other mines and 2) will have to either slow down to navigate mine fields slowly or burn extra AP to go around. The slowing down aspect will play a more significant role once a turn time limit is implemented. Come to think of it, that should happen soon…

Secondary Fire: Magnet Mine
This functions pretty much as you’d expect from the name. On release, the magnet mine is temporarily harmless-- I didn’t want it to be treated like a simple missile. After a delay, the indicator light switches colour from yellow to green and the spikes pop out indicating that the bomb is now armed and will explode on contact with any ship it touches. Matt and I were in agreement that their range (in which they’ll be triggered and drawn towards a ship) should be invisible, however I found that in practice, this results in too many accidental self-hits. So when it’s your turn, you’ll see a ring around your own magnet mines to make them much easier to avoid. Of course, opponents can still use your own mines against you if they shoot you into their range. One thing that I found sort of accidentally amusing about their behaviour is that they only move towards moving ships, so if you’re being chased, you can “escape” by stopping. This doesn’t eliminate the threat though as you’ll still be in their range, and they have low “drag” meaning they’ll still drift a bit after they’ve stopped targeting you. Skilled players could use this trick to bring them towards opponents, then take a single shot at the enemy to make the mine move towards them instead. This will require extra time, AP, and skill, so there’s no “free” way to escape one of these.

Ability: Gravity Well
This is one of the plainest examples of what Matt and I mean when we talk about “synergy” between a ship’s weapon and ability. The gravity well releases as an almost invisible black circle (placeholder graphic-- we’re planning on making it look more like a star that collapses into the “singularity” you now see. After a delay, a donut-shaped field opens up that pulls ships and most projectiles into its centre, trapping them. Until recently, the effect lasted just one round, disappearing at the start of the turn on which it was deployed. I recently increased that to two rounds. We’ll see if that ends up being too powerful. Most ships can’t escape the gravity well on their own. The V-Raptor (“scout”) can get out by using a momentum trick that’s difficult to describe (I may upload a video later showing this in more depth), but if the area is full of mini mines, this is much more difficult to execute. The V-Raptor’s dash ability is the easiest way to escape. The Scorpion (I’ll post about this ship in detail soon) has a sort of grappling beam that can be used to pull itself out. Other ships will need the help of the Drone and its transport ability as it is also capable of using the V-Raptor’s momentum trick. This fact is incredibly important as it makes it so that the gravity well can never be abused to create an unwinnable situation in an unfair way-- at least, as far as I have come up with.

Dashboard HUD
This was nagging at me on the to-do list for a long time. It got to to the point that its absence was getting on my nerves as I played test games. This should go without saying, but I’ll say it anyways: Everything ugly in this HUD is only temporary. Matt made the slick-looking AP bar, and I drew up the weapon icons which I think are mostly acceptable. I’m not sure how many of those icons will be replaced, but everything else is built in to be purely functional.

Pressing the help key will display the game controls as well as detailed information about the currently-selected weapon. I think that Matt will be contributing to these descriptions with some flavour text, and he’s very good at that sort of thing, so consider my descriptions to be functional placeholder as well.

Square Aspect Ratio!?
I feel like this would be controversial if anybody else cared about the game (it’s ok :stuck_out_tongue: ). As (tiredly) explained in the video, this turned out to be an essential move. Using your AP wisely is a huge part of the game, so in widescreen, you would pretty much always want to retreat either up or down as it requires the other player to move further before they can see you. I think this would have been a terrible design blunder had I not dealt with it in this way. It would have been nice to be able to use the vertical bars to house the HUD, but with the many possible device aspect ratios that people could play the game with, I couldn’t see any way to layout the HUD in a way that wouldn’t break in some cases. Given that you can hide the HUD with the right-click, I’m not as concerned with the relatively small amount of screen clutter that the dashboard causes, at least, as long as the extra “help” info is hidden.

Randomized Space Junk
Like the dashboard, this was planned long ago, but put off. I assumed that it would be more difficult than it ended up being. Currently, the system only supports simple circular or rectangular (non-compound) colliders, but I have a couple of ideas of how to expand it to work with any kind of collider.

The idea is that we’ll have a few environments defined by their backgrounds and the types of space junk (and possibly obstacles) that may appear. Players will be able to choose an environment, and then the amount of obstacles they want to spawn. I’ll probably break it down by obstacle size, and then vague terms describing how many to spawn (“A few”, “Moderate”, “Lots”, “Crowded”). This is for two reasons: 1) The numbers behind these descriptions will vary depending on the arena size (we’re planning to have three variations), and 2) The exact number of spawned objects can’t be guaranteed. The system takes a list of objects that it will try to spawn, randomly selects one (currently, with no regard for its size classification), then tries to spawn it. If it fails too many times to find a clear spot, it gives up. I was also thinking of giving a few options for how the objects spawn. Generally, an even distribution around the map is probably ideal, but if players wanted things to spawn more around the edges of the map or perhaps in a line or cross through the map, that might be interesting as well.

Negating the first-player advantage is tricky in a turn-based game. The randomized maps are part of my effort to accomplish that. If the map never looks the same, the first player won’t know which part of the map they’re on, and they certainly won’t know where the opponent is. They’ll have to branch out and/or explore to find them. Because of the way the camera moves between turns, the second player will always have a pretty good idea of where the first player is (if they’re paying attention). I feel like this is a good balance. On top of this, all players start with half AP, so in a three or four-player game, it’s impossible (I think) for anyone to get annihilated before having a chance to act.

Pick-Up Spawns
This is another thing that I plan to allow players to customize in settings: They should be allowed to decide the odds of each type spawning, how many, and how frequently (every turn, every other turn, etc.). For now, it spawns a random generic 1, generic 2, or ability pick-up.

I don’t expect that anyone is reading this navel-gaze-y junk, but if you’ve checked out the video, I’d like to hear your thoughts.

9

DevLog #7

I don’t remember what came first, the Orb-Weaver (mine ship) or the Scorpion. I kind of made them at the same time. I talked about the Orb-Weaver in the last post, so this one is all Scorpion, baby.

Scorpion

This ship’s namesake is already not at all subtle, but I still want to see how Matt feels about calling it the “Scorpion-MKII”. The ship was nothing more than a “shotgun” ship in my notes for quite awhile until somebody (possibly me-- possibly not) suggested that the tractor beam ability (which was planned for a different ship) would be a great combo with close-ranged weapons. I don’t remember what came next after that: The idea to give it a flame-thrower or the idea to base it on Scorpion (Mortal Kombat). Either way, it was one of those things that just felt right

Primary Fire: Shotgun
Aside from the obvious use, the shotgun is great for revealing enemy stealth ships: Any projectile or ship that crosses a cloaked ship’s force field will disrupt the cloaking effect and reveal that ship. So, if you know approximately where a ship is hiding, a blast in that general direction is very handy. As another incidental counter to the stealth ship, the shotgun can be effective at sweeping away smoke bombs.

Secondary Fire: Flare Cannon
I’m sure the particle system I have set up will be revised many times, but it does the trick for now. As for functionality, I thought I’d be doing some crazy per-particle collision where each particle collision would an x% change of doing y damage. I think I was having problems making this work as I wanted, but once I realized how difficult it would be to control the burn damage (D.O.T.), I decided it wasn’t the right way to go anyway. Much more simply, the flare cannon actually shoots out (currently) six invisible bullets that roughly match where you see the fire. Each one does a small amount of damage, but the strength of it is the burn damage. Toasty!

Ability: Tractor Beam
It’s not really a traditional “tractor beam” at all. I was going to call it a grappling beam, but I remembered that that’s already Samus’ thing. This one will certainly get a visual overhaul as well as some mechanical polish, I’m sure. The main idea is just to pull enemy ships close to you so that you can get them with a powerful close-ranged weapon without wasting lots of AP driving up to them. Ships that are pulled in will have their force field’s disabled to make this whole procedure work.

The tractor beam can also be used to pull your own ships towards you should it ever be necessary, as well as pick-ups. Finally, if the beam hits an obstacle in the environment, the Scorpion will be yanked towards it with enough force to get right up close. This can allow you to cross large distances with very little AP drain, but it’s also a blind fire if you’re shooting beyond what the zoomed-out screen shows you. I have experimented with giving the Scorpion a scope (which I built for a future ship) to make this a more useful maneuver, but something about it didn’t feel right. It might not feel so weird once there’s a proper sniper ship in the game that also has a scope.

The Scorpion’s combination of abilities (disabling force fields and applying heavy burn damage) make it exceptional at taking down Mother Ships (because healing burn damage on them is more difficult). On the flip side, the Scorpion is weak to plasmic weapons, so the Mother Ship will make quick work of it if it runs out of AP within an angry Mother Ship’s range.

The following features were added after this video, but they’re in the current build…

Turn Timer
I’ve gotten away with pushing this off for a long time, but the urgency of a ticking clock is part of what makes the Orb-Weaver’s mini mines useful. Still, I intend to allow players to decide what feels right for them as a turn time limit, or if they want to disable it altogether, that will eventually also be possible. I’ve described this game as having some Worms DNA, but what I really want to take from that series is the robust game customization. I haven’t built in any of those menus yet, but there’s a growing list of things that I want players to have control over.

Health Pick-Ups
Weird that it took so long to do these, right? Not only will they restore some HP, the health pick-ups will also completely wipe your burn damage multiplier. It also just not occurred to me that they should also probably fix any EMP effect on your ship. There’s another item for the to-do list.

That’s all for now. I’m not really sure what I’ll tackle next. Muzzle-flash? A new ship? Maybe I’ll get started on a game setup menu. Hmmm…

10

DevLog #8

The latest ship is one that Matt and I had planned (at least, the general functionality) from very early on. Of course there has to be some kind of repair ship.

Leech
It was either Matt or Darren that threw out the idea of a “radio ship” that could provide some kind of map. I wasn’t sure if I could build an entirely new ship out of that idea, but one of them (sorry-- I forgot who) suggested that the repair ship could have this ability. It would allow the ship to more easily find allied ships that may be in need of help. Makes sense, right? So here we are.

Primary Fire: Repair Shot
The most basic and obvious functionality forced me to come up with a way to handle the relationships between weapon types, the “mini HUD” icons that represent them, and which pick-ups are compatible. I wanted the repair shot’s icon to match the health pick-up appearance, but then that implies that health pick-ups will restock this. What are the consequences of that?

First of all, it means that health pick-ups should not heal the Leech. How does it heal then? Well, any ship can gets a small amount of HP back if they are within range of the Mother Ship at the start of your turn. That may not be good enough. And what inspired playing a mode that doesn’t use Mother Ships? Well, the secondary fire answers the question, and I’m quite pleased with how it has worked in playtests…

Secondary Fire: Power Siphon
Finally, another electric-type attack (and the first of the “disposable battery” subtype). Electric attacks are defined by the EMP effects they apply. The power siphon is a single-shot projectile that does a level 1 EMP effect (I think I explained the EMP levels in my Stealth Ship post). As a secondary fire, it also deals a significant amount of damage. After doing damage, it then returns to the Leech, healing it by however much damage was done. The fact that it doesn’t heal by a fixed amount means that if you use it on a ship with very little HP remaining, you’ll only heal by a small amount. If you want a better healing effect, you can use your primary fire to heal the enemy ship only so that you can take it away. It’s a neat combo that I hadn’t even really planned-- the situation just came up in a playtest where I realized that it would be useful.

Ability: Radar
The radar assists the Leech with finding injured allies, enemies, and pick-ups. Each player’s ships appear as different shapes. I intend to use symbols to make the ships themselves distinct so that it’s not exclusively communicated by colour (for accessibility). Once activated, the radar is visible to all allied ships and lasts for (currently) two rounds.

11

DevLog #9

I skipped on posting about my most-recently-Tweeted video because I’m an idiot and forgot that I had already introduced the “dashboard HUD” that I talk about in that video. There were a couple of new things that I had not covered, so I’ll touch on them here first.

Next/previous Ship Indicators
This is one example of why playtesting is so important. I had recognized early on that it would be nice to see which ship you’d be switching to before hitting the “next” or “previous” button, but I also knew that the way I coded things would make it a headache. Well, I finally had enough of blindly cycling through my fleet just to get to the ship that was just one key press in the opposite direction, and went ahead and gave myself a headache. It was exactly as annoying as I expected, but it seems to work now, and I’m grateful for it.

Magnification Outlines
This game has an inherent visibility problem in that you will usually want the camera zoomed all the way out to see as far ahead as possible, but then the objects (most importantly, ships) shrink down to nothing. I was playing with the idea of having a duplicate sprite on each ship that scaled as the mini HUDs do, but I worried that this would interfere too much with the ability to hide in a smoke cloud. More importantly, I didn’t know how to handle the fact that the collision shape would not scale, so aiming at far away ships would become a mess as you’d appear to have a lock on them, but projectiles would sail through if they weren’t dead-centre. I’m please with the compromise I came up with here: Every ship has a faint outline that scales down to being just one pixel bigger than the ship (for contrast against the black background), and scales up to make it easy to spot ships without causing any confusion about their collision bounds. These can be toggled on and off with the “M” key.

Team Insignias
I thought I was being so clever with my use of colour in CATACLYSM. As it turns out, using just one visual language like that makes the game way harder for people with colour-blindness. Who knew? While Shooting Star: Tactics doesn’t look it yet, I intend to make it much more visually accessible with a range of player settings (font & mini HUD sizes, team colours, etc.). Most of that stuff won’t come until much later, but these little “insignias” are one more small step towards that goal. Each team has a different one which, by default, is shown behind the HP on the mini HUD. You can press ‘i’ to hide them, hide the HP numbers, or hide the entire mini HUD (it cycles through these options). The insignia graphics that I drew are intended to be temporary, but their shapes were chosen to match the shapes shown on the radar.

Ship Info Display
I keep thinking about putting a playable demo out on Reddit or something, but there are certain boxes that need checking before I want to do that. One such box is to ensure that everything that isn’t blindingly obvious has some kind of in-game explanation. The weapons and abilities all have descriptions (which will be updated), so that much is covered. But some of the ships have behaviours that aren’t immediately intuitive, such as the Drone / Mother Ship relationship. It’s suuuuuuuper ugly, but the information is there if you want to read it. I’m looking forward to getting Matt’s input on this stuff, as his writing is much more fun than mine.

Burn Indicator
Matt gave the idea to make some weapons apply a “DOT” (damage over time). This materialized as a “burn” status effect inflicted by “raw plasma” type weapons. Once I had this worked into the game, I stopped short of creating much of an indicator to show that a ship was burning. They’d flash red, but that was about it. I’d still like to get some small smoke effects and/or flames on burning ships, but that’ll be for later. The new addition is a new (and possibly final) element on the mini HUD. In the video, the number shows the DOT multiplier-- one per hit, each represents three damage that will be dealt on the start of your turn. As I got the video ready to upload, I realized how silly this was and changed it so that the number shown is the exact amount of damage you’ll take at the start of your turn. No mental math or knowledge of the “burn value” required!

Scorpion Scope
I’ve had the scope working (at a basic level) for quite some time, but it was planned for a couple of the long-ranged ships that Matt and I had discussed. Why would I give it to a ship with a shotgun and a short-ranged flamethrower? Well, it’s all about the Scorpion’s tractor beam ability. I was finding the ability to be far too limited in its usefulness when you could only pull ships towards you if they were already close enough to be on screen unless you got lucky with a blind fire. So, while it’s weird to give it to a ship that was never planned to have it, I believe it’s necessary for its ability to live up to its potential.

I think the next thing I’ll be working on is a little feature that Matt suggested quite awhile ago. We’ll see how that goes.

12

DevLog #10

There are always hiccups along the way, but somehow this project has continued to move incredibly smoothly for me. Granted, I took a few months off when work (school district) started up again, but once I got back into it, it was like I never left.

I just recently started to (try to) take note of significant changes since the last post as I don’t always remember. Here’s what I wrote down for this time:

Damage Numbers
This was an idea/request from Matt from quite awhile back: Make numbers fly off of you when you take damage as in many RPGs. At the time, I didn’t feel too strongly about their inclusion one way or another, but I told him that I’d make a note of it. Unlike CATACLYSM, I figured out how to do object pooling for this project. It wasn’t as hard as I thought it would be, and the pooling system that I wrote made it pretty easy to get this working. The real challenge was figuring out a font style and size that was readable without being obstructive. You wouldn’t want the numbers to be so big that they give away your position in a smoke cloud or something, right? So, the size of the font will scale with the amount of damage taken (to a maximum, of course). When you heal, you’ll see green numbers float up from above you. It all looks quite nice and I’m glad Matt gave me the idea as it’s one of those things I never would have thought to do on my own.

Mini Mines (updated)
I had been struggling a bit with the mini mines dropped by the Orb-Weaver ship. It seems like such an obvious (and good!) idea: The ship sprays out a bunch of tiny mines to force enemies to go the long way around or risk blowing themselves up, or spray them directly at somebody to sort of trap them.

In practice, they were rarely all that useful (aside from the very effective combo with the gravity well). I bumped up the number of mines per shot from 30 to 50 which helped, but I still wasn’t satisfied. Then, I had the idea to make them “twinkle”: When it’s your turn, they look just as they always have. When it’s an opponent’s turn, they become invisible. If they remained that way, it would be too annoying, I think. So they play a brief animation with a fairly long interval. This way, it is possible for enemies to navigate through them, but the absolutely must slow down and be careful. I’ve only had a few games with this new feature, but I feel like it’s exactly what they needed.

I also made it so that both mini mines and magnet mines will be pushed away if they are within range when a ship’s force field is triggered. For example: If you dumped a bunch of mini mines into an enemy Mother Ship’s force field, they would all be blasted away if you then bumped into (triggered) her force field. I’m not sure what the strategic benefits of this are (if there are any), but it looks neat!

Force Fields (updated)
Every ship has a force field and its triggered if an enemy ship gets too close (they have to be moving). Once triggered, the force field doesn’t reactivate until the start of your turn. This has almost always been how they work.

I was concerned that it would be a cheap tactic to be able to bump into enemy ships to make them move, thereby triggering your force field. To counter this, I made it so that force fields are deactivated when you select (are controlling) a ship. After giving it some thought, I decided to change this. Now, you can drive around with your force field active. It’s not as simple to use as I thought though: In order to get close enough to an enemy ship to bump it, you have to cross into their own force field range. You can do this if its already been triggered that round, or if you disable it with an EMP effect. Either way, I don’t think it’s anywhere near as easy to abuse as I worried.

One issue that force fields did have is that there was no way to know which ships had theirs currently active without driving up close (including your own ships). This isn’t the worst thing in the world, but there are times when you may have a trick shot planned that hinges on the bump of a force field. Matt didn’t like how it looked when they were just visible at all times (as opposed to just when you get close), but the mini HUD doesn’t really have space for an icon to show this. So, I added the pulsating rings as a compromise. Eventually, I’ll ask Matt to draw something that looks better, but I think the idea works.

Click to Select
This was a huge no-brainer, but I was worried that the code controlling which ship is selected would make this so difficult that I may never want to attempt it. The little labels that I added (see previous dev log) that show the “next” and “previous” ship forced me to take another look at that code. As it turns out, it makes more sense than I expected. Once I refreshed my memory on how to get a game object to respond to a mouse click (I created an interface that all clickable objects will have), it kinda just worked. Are there nasty bugs hiding somewhere? Maybe. But for now, it seems stable, and the game will be so much easier to play because of it.

There are a bunch of small and/or uninteresting items on my “to-do” list aside from adding more ships. I think I’m getting close to the point where I need to start thinking about my game setup menu screen. It’s a scary thought because I’ve been operating on the assumption that I’ll be able to carry things over from one scene to another without too much trouble. I know it’s possible, but I’ve never done it before. I’m also just not fluent in dealing with UI components. That’s all on the horizon though, so I will try to mentally transition from working on fun stuff to the boring stuff. It’ll be exciting (for me) once it’s all working. That’s one of the last things I need before I can put a playable demo out there, which I’d really like to do.

Until next time!

13

DevLog #11

The concept of this game started as something quite different from what it became after the first conversation with Matt, and it changed again when I got the idea for the Mother Ships. Well, I’ve got another fairly significant addition:

Victory Points
I’ve thought about how I can incentivize players to move their ships around beyond the path between their own Mother Ship and their enemy’s before. The idea I kept coming to was some kind of object that can be collected to build towards another win condition, but I felt like this might be seen as too similar to Killer Queen. Given how different that game is from Shooting Star: Tactics in every other way, I figured that wasn’t a good enough reason to keep a feature out of the game that could make it more enjoyable, so I went ahead and did it anyways.

We haven’t decided what the “victory points” ("VP"s) will be exactly (some kind of valuable material, I assume), but for now, they’re little yellow diamond things. Starting after the first player’s first turn, four of them will spawn in to random locations on the map. I will probably update this so one spawns in each quadrant. I will also likely set a limit to how many may spawn into the map based on the total “victory points-to-win” for all players.

Any ship can collect a VP and ships that do so will have an icon on their mini HUD appear. If a ship takes damage while carrying one, they’ll drop it. VPs can be fired as projectiles (similar to other pick-up shots) to pass the shot to other ships. The Mother Ship does not have access to this shot, but that’s because delivering VPs to the Mother Ship is the goal: Once the Mother Ship has a certain number of them, that team wins. The number of VP required to win must scale with the Mother Ship’s HP similar to how the Mother Ship’s HP scales with the fleet’s total HP. Currently, it’s 1VP per 10HP (rounded). I’ll be adjusting this as I playtest to feel out what makes the most sense. The goal is to make the three win conditions as close to equally-attainable as possible. This will be a very tricky thing to work out as the combination of ships in play will likely influence which win condition player’s will be aiming for.

I thought that the Mother Ship should not drop VPs when they take damage (I stated this in the video), but after only a couple of playtests, it became obvious that this is probably wrong. With Mother Ship’s dropping one VP per instance of damage taken, there are interesting implications for which weapons are more appealing to use against the Mother Ship: Machine guns can quickly make a Mother Ship drop its entire load, but because other ships can only carry one each, players won’t usually be able to actually steal them all in a single turn. This also should lead to situations where a player is close to collecting their required number of VPs, so the other player will greatly prioritize hunting down their Drone and attacking their Mother Ship.

Like the Mother Ships, my intent is to make VPs an optional game element in the final game, and possibly expanded into other game modes. I haven’t given the other modes too much thought at this point though-- I want to make one great mode first. :slight_smile:

So, that was the big update. But there’s one more fairly substantial change:

V-Raptor Dash (upgraded!)
To avoid situations where the V-Raptor’s dash lands it inside of an obstacle’s collider, I had it so the ship would stop a pre-defined distance from any solid object (except for ships). The problem is that it made the ability unreliable as an escape option as there could (and often would) be obstacles just off-screen. Now, instead of stopping at obstacles (except for shields), the dash will smash through, breaking them into smaller pieces. It was always in the plans to make obstacles break (particularly the asteroids), so the need for this ability upgrade made it necessary to start doing it now.

Destructible Obstacles
The asteroids break into smaller asteroids, which break into smaller ones, etc. until they get to a certain size. In the future, I might make these objects drop pick-ups on some random chance. Without any effects, this looks a little silly right now, but it works as intended.

The non-asteroid obstacles are more complicated, and I’m still figuring out what the best way to do it is. Currently, the rectangular obstacles will simply disappear once they’ve taken enough damage, but the cross-shaped obstacle behaves more like how I’d like them all to eventually: They’ll shatter into odd-shaped pieces made from cutting up the original sprite. I’ll probably make a help thread for suggestions on this.

New SFX!
Darren has prepared another batch of sound effects, which is always exciting. This includes:

  • Force field break/disable
  • Force field triggered
  • Missile fire
  • Mother Ship shield down (currently also being used by the Mantis)
  • Shield Up
  • Taser (level 1)

Burn Recovery (adjusted)
The burn effect can be extremely deadly, and the more burned you are, the worse each successive burn will be. Because of this, I thought it would be appropriate for health pick-ups (and other healing sources) to completely remove the burn effect. This resulted in burn attacks being highly useful in certain situations (when you can disable/trap a ship on the same turn that you burn them, or when you’re attacking a Mother Ship when the opponent does not have a Leech), and highly ineffective in most other situations as burned ships can be brought to the Mother Ship to be healed at the start of their next turn. The “fix” that I’m working with now is for healing sources to remove three points of burn damage. This is much easier to represent now that the mini HUD displays your next incoming burn damage.

Vision Cone is back
My attempt at fixing something resulted in losing the ability to leave the S-Cuttlefish’s “vision cone” on while switching to other ships. Instead of trying to make it work the way it used to (which was a little clunky), I’ve made it so that the vision cone turns on when you right-click regardless of whether the S-Cuttlefish is selected. As long as it’s your turn, it’ll go on.

And that’s it for now! I’d like to get the obstacle destruction worked out in a more practical way. Aside from that, I think I’ll mostly be playtesting with the victory points to see how they impact the game, how many should it take to win, how many should spawn-in per turn, and what the max should be (if any).

14

DevLog #12

Somehow, I managed to pull together the energy to get some work done while being very sick. I’m assuming it’s covid, but I don’t qualify for a test, so who knows. It’s miserable, and I can’t wait to get over it.

So, it’s just a quick update this time.

Compass
Maybe “compass” is a misnomer-- we’re in space, so the concept of “north” doesn’t really apply. Maybe “navigation system” is more appropriate. Anyways, the idea is to help players maintain their sense of direction by using arrows that point to your other ships. The Mother Ship and Drone have distinct pointers so you always know where you are in relation to those two ships.

Impact Effects
This was a long-overdue feature. I’m pretty happy with how the bullet effect looks. I was getting really tired of the unsatisfying feeling of hitting somebody with the S-Cuttlefish’s plasma splash at close range. Those particles make a world of difference.

Victory Points: Spawn All
The few playtests that I’ve done since adding the victory point system have lead me to believe that it might be better if all of the victory points spawned at the start of the game, rather than the four per turn that I started with. I’ve kept it so that it’s easy to switch between the two settings in case I decide to make it player choice in the game settings. I’ll have to play around with it to make sure that it won’t be possible for the first player to win on their first turn by collecting all their needed VPs. Balancing that kind of thing is quite tricky.

I’m not sure what I’ll work on next. Maybe I should just rest. :slight_smile:

15

DevLog #13

I wasn’t really planning on doing an update-- I wanted to just get a good gameplay video recorded-- but some of the changes I’ve made are too significant to not address.

Victory Points: “Process” to score
I’m continuing to figure out the best way to work the collectable “victory points” (VP) into the game as I like the added dimension they bring. The idea from the start was that these objects (which will eventually be fleshed-out as some kind of valuable material) can be collected and brought to your Mother Ship to score points. Once you’ve scored x points, you win the game. This is just one of the paths to victory.

If a Mother Ship is attacked while it is holding VP, it will drop them, allowing the enemy to steal them away. However, a player now has the option to “process” a VP using the Mother Ship’s fourth firing option which prevents it from being dropped when the Mother Ship takes damage. This is also how you actually score the point-- simply holding the number of VP required to win isn’t good enough.

Victory Points: Entering the field
In my previous post, I suggested that it might be best if all the victory points that could spawn in a game were just there at the start. This had some appeal, briefly, but I realized that it was defeating the purpose of the VP element: Players should have some reason to branch out away from the path to and from their opponent(s) as it leads to a more interesting spread of ships.

Instead, this is how it works: Four VP will spawn at the start of the game. The only way another one will spawn is if a VP is processed by a Mother Ship (effectively, removing it from the game). This allows for more opportunities for players to fight over a limited supply of VP.

Victory Points: Crunchy outer layer
Another problem with my first implementations of the VP was that it was too easy for a Drone to zoom around, finding and collecting VP to return to the Mother Ship. With the whole “process to score” system, I don’t know if this was necessarily broken, but it wasn’t very fun when it was always an option and often the best option. So, as one more measure to mitigate this, I gave the VPs a “shell” of sorts. They appear as tiny asteroids that, when damaged, break to reveal the VP inside which can be collected. The shell only has 1HP, so they can be cracked open with any damage-dealing weapon, or by simply crashing into them. Doing this will do one damage to the crashing ship. Because the Drone only has 5HP (max) it can only break a maximum of four VP unless it gets healed.

Drone: The “Scarab”
I’m not sure if I’ll officially change its name, but the Drone now comes equipped with an extendable pair of pincers that are controlled with the right mouse button. They don’t grab things to do damage or anything. Instead, they give the Drone a shape that’s more conducive to pushing things (particularly pickups) around. The main reason for this addition was to make it a more viable option to bring health pickups to critically-damaged Mother Ships, though it obviously will have other uses. For example, it will also allow the Drone to bring two VP to the Mother Ship in a single trip-- one that it stores as “ammo”, and one that it pushes. It’s not necessarily easy to steer while pushing something, but it can be done. The animation also just looks really cool.

Magnet Mine: Triple Threat
The purpose of the magnet mine is to create zones that are difficult for the opponent(s) to pass through safely-- they are (currently) one of the few ways to build active defenses. In my play tests, I was finding that they weren’t very effective at achieving this. I played around with making their AP cost low enough that you could fire off a few to create a defensive area, but then it was just more appealing to shoot all of them bunched together near an enemy ship. Now, each use of this attack will release three mines with a wide and even spread. This looks more like an effective defensive ability. While you can still “abuse” them in some situations, particularly with the gravity well, they will hopefully now be able to fulfill their intended purpose.

Mother Ship: Ability buff, weapon nerf
The Mother Ship’s ability allows it to instantly give every ship in your fleet (aside from the Drone and the Mother Ship itself) one ammo to their primary and secondary weapons. Now, it will also restock their abilities.

As for its weapon, the Mother Ship’s “plasma barrage” has been downgraded to a single (large) plasma ball attack. It took me far too long to see why the previous set-up was broken, but I think it has an appropriate level of punch now.

I’ve made some very small movements towards getting a “Game Set-Up” scene together. That’s probably where I should be focusing my energy (aside from the usual play-testing). Maybe I’ll do that. Maybe I’ll make a new ship. The latter is much more appealing, but the sooner I have that Set-Up screen, the sooner I can get a playable demo out there. It would be really useful to get some player feedback as I’m sure there are exploits and bugs that are eluding me. We’ll see.

16

DevLog #14

That was a very long hiatus.

Over the past few months I was working on a game project with the kids at daycare (ages 5 -10… mostly 7 - 9). I don’t think it would be appropriate for me to share it here as it’s mostly their work (drawing, sounds, ideas), but I’ll tell you, it was super cool to help them put it together. They drew their characters on paper, I scanned them, cut out the backgrounds, and dropped them into Unity. We even did some “traditional” animation using an iPad as a lightbox (brightness max, notepad open to a blank page, guided access on). Those kids are brilliant, and I can’t wait to see what they come up with next year if they choose to keep adding to our game.

But the school year is over, and that means re-calibrating my brain for my personal project. I intend to work hard on Shooting Star: Tactics through the summer. I have no idea how much I’ll be able to do over the next two months, but my to-do list is enormous. One thing at a time though.

When I left off, I was beginning to work on one of the game setup screens. I was fumbling my way through the UI stuff, but what I came up with kind of made sense. Trying to figure out my set-up was a good lesson in bad/incomplete documentation. There’s so much work to do, but I think I’m starting to get a decent idea of how everything fits together.

17

DevLog #15

This came together pretty quickly by my standards. On this screen, you can choose which ships you want in your fleet. The video shows how it works. I think it’s pretty intuitive, right? I’m definitely open to suggestions though.

A few things I have planned for this screen:

  • Show more basic ship info (HP, maybe speed)
  • Show more weapon info (damage, AP cost)
  • Message box that tells you that you can’t remove your Mother Ship or Drone from the fleet, should you try to.
  • Prevent players from starting a game without choosing any ships, with a message to alert the player of this.
  • Sorting buttons for the ship selection list: Sort by deployment cost, weakness, primary weapon type, secondary weapon type, HP

A screen preceding this one will let you choose a fleet selection method: Deployment Points (players will be able to choose how many each player starts with individually), number of ships (also will be able to set this per player), free choice (up to a cap, of course), and randomized. If I feel particularly ambitious and if there seems to be any use in it, I may try to include a randomization option that attempts to build balanced teams according to the DP costs. We’ll see about that.

I’m not 100% sure what to do about the order in which players choose their ships. It absolutely matters as you can easily build a fleet specifically to counter another one, but enforcing this through code could be complicated given the various selection modes. I’ll probably leave it to players to decide how they want to do it. The obvious way to go is to take turns, but if we’re dealing with DP or otherwise uneven teams, somebody is going to get to choose multiple ships in a row anyways.

Side note: I’ve also been playing with the Victory Point (VP) goal calculation. That is, how many VP should a player have to collect to win given their particular fleet. I significantly lowered it while also implementing a minimum (4) so that it isn’t possible to win on the first turn, even with a one-ship “fleet”. The idea behind scaling the VP goal is that ships with more HP tend to have more firepower and be slower. A fleet like this is better suited to a victory by combat-- either taking out the opponent’s fleet or their Mother Ship.

EDIT: I forgot to mention: With this screen (mostly) working, I’m almost at a point where I can put out a playable demo. This thread hasn’t exactly set the forum on fire, but maybe a demo will help. I’m very tempted to start working on a new ship because that’s the most fun thing to do, but I’ll try to focus on getting things in demo shape first.

18

DevLog #16

Am I crazy, or is it often the most boring stuff that ends up being the most difficult/time-consuming?

I had a hell of a time with a bug that I assumed was related to something I did wrong or misunderstood about Lists and Scene changes. After a good night’s sleep, I took a closer look and discovered that the problem code was a snippet that I got from a help thread/Q&A page. Immediately after re-writing the code in a way that made sense to me, it worked. Sometimes I don’t know whether to be elated by the success or extra frustrated that the solution was so simple. Anyways, new features:

Pause Screen / Status Bars
I actually built this prior to my hiatus, but I forgot to mention it. It includes little status bars to show the overall health of each team’s fleet (excluding the Mother Ship and Drone), a separate one for the Mother Ship, and a third one to show progress towards the “Victory Point” goal. This, I find, goes a long way towards helping you to decide what you should be focusing on.

Camera: Variable Speed Limit
It’s always been possible to switch back and forth between your ships across the map to get a peek at what’s in between them. This always felt a little “cheat-y” to me. There were two ways to go to solve it: Hide the screen/objects while the camera is moving or 2) Slow the camera way down to make it clearly intentional that you can see stuff. I went with the second option. Usually, you’ll probably want to switch quickly between ships, so you can hold the key down to speed up the camera.

Game Setup Screen
From early conversations with Matt, we had all kinds of ideas that we agreed would be best as optional. In my mind (as the thread title tells you), my game is meant to be a Worms-like of sorts. Those games have always given players tonnes of options to make your match exactly how you want it, so that’s what I’m keeping in mind as I come up with new ideas for the game.

Small Arena
I finally got my wife to play a bit. She’s been insistent that unlike my previous game, CATACLYSM, this game is too hard/complicated. I see that mostly as a failure on my part to make the game mechanics visually welcoming and clear which I will be continuing to improve. One thing that she mentioned when I asked her what she found difficult was flying around, looking for people. I get where she’s coming from. I didn’t plan it this way, but a big part of Shooting Star: Tactics is spatial awareness-- being able to remember where ships are in relation to one another. I already built in a very useful tool for that (the nav “compass” arrows). With this in mind, I made an arena that’s half the size. She still found it difficult to fly the ships comfortably (I got her to play Asteroids after and she also struggled there), but navigation was much less of an issue. I’ve only playtested skirmish mode on it myself, but I actually liked it quite a bit. It changes the feel of the game significantly, but it feels good as an option.

Skirmish Mode
Once I started cooking up the idea for Mother Ships mode, I kind of left the original idea on the back-burner. The idea is as simple as can be: You and your opponent get some ships. Destroy all of their ships to win. While the Mother Ships mode gives your ships a place to start (somewhere in a circle around the Mother Ship), Skirmish mode has your ships spawn in at random positions. I hadn’t even tried playing in Skirmish mode because I knew there were a few sections of code that wouldn’t work as they relied in there being a Mother Ship present to start a game. Once I put in those mode-checking conditions, I was shocked to find that I already did the random spawn-in coding at some earlier point in development-- I completely forgot. I did end up having to re-do some of it, but most of the work was done for me. Nice.

Fleet Selection Limits
I have found that the game is best played with a smaller number of ships than I expected-- four or five in Mother Ship mode, and probably six or seven in Skirmish mode, however, I’ve made it so that you can have up to 20 if you feel like having a game that takes way too long. Hah. The Game Setup screen lets you define the limit to how many ships each team has. If you’re playing with a randomized fleet, this is how many ships will be spawned for you. The nice thing is that you can use this option to give less experienced players an extra ship (or more) to hopefully make the game more fun for everybody.

Healthcare Guaranteed
It’s been nagging at me for awhile. The power of setting ships on fire is difficult to balance, especially when your Mother Ship racks up an alarming burn-status which can very quickly put a time (or turn) limit on the match. My solution: Every turn, there is guaranteed to be a health pickup spawn. This means that if you’re desperate to cool down your Mother Ship (or anything else), you won’t ever be searching in vain for relief. Will you have to spend AP to get it? Of course. Will you find it in time? Not necessarily. But it’ll be out there, and that fact makes me feel much better about the whole situation (in theory-- haven’t playtested yet). I’m planning on making this adjustable in the settings eventually: How many health pickups are guaranteed to be present at the start of each turn? Zero? Fine-- you must like burning (or watching others burn).

End of Turn Pop-up
When time or AP runs out, the turn abruptly switches to the next player. This was occasionally confusing, even for me, so I added a little notification in the top-left message box. But I knew that wasn’t good enough for other players, and after seeing Matt play the game a bit the other day, I felt compelled to bump this way up the priority list. So, when your turn ends (unless your end it manually), the action will pause, a little pop-up will appear for 2.5 seconds, and then the camera will move to the next player. Much better.

Victory Point (VP) Goal Adjustments
I think I’m getting closer to be comfortable with the number of VP required to win given a number of ships (or rather, the sum of their HP). The last time I adjusted the calculation, I made the requirement way less. Well, I made it way less again. I want them to be something that you can shift your focus to mid-game if your other plan(s) aren’t going well, but not something you can easily scoop up early on to end the game before it even starts. It’s a tricky balance. Maybe I finally got it right.

Future
I said in my last post that I was getting close to being at a demo-ready state. That’s mostly true. I still need to make a controls screen and several screens to explain how to play the base game and the various modes. That stuff could take awhile.

Matt reminded me that there’s supposed to be a “Sudden Death” mode with several options for what happens when it starts. It would work as it does in Worms: Define how much time you want the game to last, and some kind of “Sudden Death” event happens when that time runs out. That’ll be fairly high on the priority list.

But there’s something else, too. I need to stop doing this, but I’ve thought of another gameplay mechanic that I think will fit very nicely in the game. It’ll be optional, of course, but I think it’ll improve the game overall. I won’t say anything else for now. Hopefully I can get it working without tearing my hair out.

That’s all for now. I might post again later with a full match playthrough. We’ll see what I have time for tonight!

19

DevLog #17

I just have a small update for now:

The process of switching control from one ship to another is something that I’ve given a lot of thought to, so it’s frankly a little embarrassing that it’s taken me this long to figure this out. Basically, instead of being restricted to cycling linearly through your ships, or clicking on ones in sight, you now have buttons on-screen that you can click on to switch to a particular ship at any distance. The buttons appear in the exact same spots as the nav arrows, so you can see where each ship is in relation to you.

When Matt was playing the other day, there was a moment where he forgot that you can’t freely move the camera, so he wasn’t sure how he was supposed to switch ships. I’m pretty sure that this stuck with me subconsciously. Haha… It just goes to show how important it is to get a fresh perspective.

One other (very small) note: I increased the scope view pretty significantly for the Scorpion (and any future ships that use one). This way, it won’t be so difficult to find a target from far away.

Apologies for the awkward commentary, but I’ve been wanting to get a gameplay video out. Here’s a Skirmish playtest of me vs me. Who’s gonna win?

20

DevLog #18

This is the biggest update since the Victory Points mechanic was added. I’ve got quite a bit to share, so I’ll just get to it, starting with the biggest stuff…

Stardust / Supernova
Scattered around the map, you’ll now see tiny, twinkling stars. This is “stardust”, and you can collect it fill your stardust metre. Once filled, you’ll transform your normal primary weapon into a powerful “Supernova” attack. Using this will, of course, drain your stardust back to zero and also deplete your primary weapon ammo. Also, taking any damage will reduce your stardust metre, so there is some incentive to use it while you have it. On the other hand, if your stardust metre is full, you’ll gain 1HP for each additional stardust collected.

Each ship has a unique Supernova attack (not all are strictly “attacks”). They have not been extensively play tested, so I expect that they’ll be adjusted for balance, as needed. Currently, they are as follows:

V-Raptor
Plasma Meteor: A massive ball of plasma that bounces off of things and causes burn damage.

Mantis UV-XII
Heavy Machine Gun MKIII: A heavy machine gun with three-times the payload of the standard weapon with higher accuracy and a higher rate of fire.

S-Cuttlefish
Plasmic Lightning: A violent electric shock that causes a level 2 EMP effect and mild burn damage.

Scorpion MKII
Quake Shotgun: A wide spray of high-caliber shot that deals devastating damage to ships weak to ballistics.

Orb-Weaver
Magnetic Stardust Mine: Like the standard Stardust Mine, only each mine does slightly more damage, and the mines are drawn towards ships that come too close (friend or foe).

Leech
Triple Repair Shot: Fires three Repair Shots, each of which will turn into collectible health pickups if they fail to reach another ship in time.

Mother Ship
Plasma S-Wave MKI: Fires a stream of small plasma balls in a tight wave formation.

Drone
Stardust Fill: Fires a special projectile that instantly fills the target ship’s Stardust Metre. It also heals a small amount and reduces burn by one point. The Drone requires less stardust than other ships to fill its metre.

I’m hoping that this addition will add a meaningful strategic layer to play. I was finding that skirmish games that came down to just two ships weren’t particularly exciting as their options were fairly limited and the best choice was often obvious. We’ll see how much this actually helps with that.

How To Play
This is a huge addition. Not that it’s impressive or particularly difficult (especially in the bare bones way that I currently have it), but giving players a reference for the controls (which will be customizable in the future), and how everything in the game works was really the last thing I needed before I was comfortable with putting up a demo. More on that later…

The other changes are pretty minor, but they include nerfing the Scorpion’s primary weapon (shotgun), bumping up the Leech’s Power Siphon attack to a level 2 EMP, and (finally) giving the Scorpion’s Tractor Beam a proper EMP 1 effect instead of just knocking out the force field.

I’m very eager to get a demo out, but before I do, I want to spend a day play testing to make sure I didn’t miss anything silly. I’m sure I’ll miss something anyways, but it’s worth taking some time to check. That’ll be a tomorrow project. Stay tuned…