next »

[anapestdigital]

DevLog 1: https://anapest.digital/introducing-restless-ground/

For the last six months or so, I’ve been working off-and-on on a new game. More on than off at the moment. For now, let’s call it Restless Ground.

Restless Ground is a puzzle-RPG hybrid, where you must match tiles in the ground below you to create mighty skeletons (and other nasty things) to protect you from an angry horde of villagers. Perhaps you’d like to imagine Diablo 2 made a baby with Candy Crush. (Then again, perhaps you wouldn’t.)

You’re the bad guy, I guess. You’ll also get awesome spells, find cool treasure and make potentially lucrative deals with various devils.Combat takes place on a thrilling one-dimensional plane. As the guardians of your persecutors appear, you must strike them down to make it to your goal. As you defeat wave after wave, you’ll eventually be worn down, and die (again). In this state, you can develop your abilities and forge new demonic items, ready to rise again more powerful than ever.

PLANNED FEATURES:
(Numbers are subject to change and expansion)

4+ playable characters with unique skills and ability curves.
~9 summonable skeletons
~4 game levels with endless stages
~50 skills in ~10 schools
~50 unique enemies to vanquish, including 13 mighty bosses, all with unique spells and effects
Thousands of procedurally generated weapons
A thrilling story. Probably.
1 exciting dimension of battle

ART

I’ll be the first to admit my limits as an artist, so I’ve gone with a simplistic pixel style. By restricting myself to a slightly-expanded Pico8 palette and using repeated, simple elements, I feel like I’m able to deliver a game that is… if not beautiful… at least consistent and not-ugly.

This IS my first real game — and I plan to finish it. I have already learned a LOT from the process.

TOOLS

• Unity (C#) as the game engine
• Aseprite to make sprites and animations
• WMHelp XMLPad to edit XML
• Excel/Google Sheets for balancing/prototyping mathy stuff
• TBD for music/sound

PLOT

TBD. Probably something occult and revengey.

CURRENT STATE

Most of the game’s systems are in place and working (more or less). Now I am focusing on tweaking systems, finishing UI, writing a storyline and creating content.

[anapestdigital]

DevLog 2: https://anapest.digital/heck-make-match-3-game/
Why The Heck Would I Make a Match 3 Game?

Yes, I know. Match-3 games have been done to death and they stink of freemium. But...

I WANTED CREATE AN ACTIONY-RPG BUT TO LIMIT THE NUMBER OF INPUTS.

I love the idea of a stats-heavy RPG, but I feel like a lot of modern RPGs fall short by not limiting players enough. On the other hand, I didn’t want to create something with a single input (like Mario Dash). In this game, you always know what you can do — move some tiles, move your character or use a skill. That may not be a lot of interaction.. but it is tried and true interaction.

I WANTED TO START WITH SOMETHING THAT PEOPLE ALREADY FOUND FUN (AND PEOPLE APPARENTLY FIND MATCH-3 GAMES FUN)

I have big ideas about games that I’d like to make. Grand narratives. Monstrous experiments. This isn’t one of them. I know that people like match-3 games. I know that people like RPGs. I’m not creating an art game. I’m learning how to MAKE a game.

I WANTED TO TAKE A COMMON GAME ELEMENT AND TAKE IT IN A “NEW” DIRECTION.

If I can combine the elements  in a slightly novel way, I feel like I can create something that 1) isn’t totally alien to new players and 2) provides a framework for me to finish a game, finally.

SO THIS ISN’T MY DREAM GAME?

No. This is a game that I think that I could finish, by myself, in a year or so. I think it’s a reasonably FUN game, and I’m really enjoying the process of making it. But no, it isn’t my dream game. I might take on a more ambitious project after this, but I don’t feel comfortable leading a collaboration until I have had a chance to create something myself.

In essence, I made this because I thought it might be kind of easy.

EASY?

Okay, it’s definitely not easy. But it’s been manageable. I have gone from knowing only a little bit about Unity (from trying to make a very unfun — but programmatically interesting — AI-based Sims-type game)… to being pretty proficient while making a much simpler game. I’ve learned about asset management and refactoring. It’s not been easy, but every challenge has been a great chance to learn something new. I’ll cover those in future devlogs.

[anapestdigital]

Refactoring my Unit and Protagonist Classes! Full devlog: https://anapest.digital/refactoring-protagonist-unit-classes/

Let's talk about refactoring! Early in development, I conceived of two types of “fighters” for Restless Ground: the protagonist and everyone else (“units”). This made a lot of sense... until it didn't.

My original thinking: a lot of the code for units concerned their behaviour loop, and I’d probably want a different set of stats for the protagonist and units. I wasn’t even sure I wanted the protagonist to be able to move. However, they both had to be hittable; so I quickly implemented an interface called “IDamageable”...

CONVERGING CLASSES AND BADLY IMPLEMENTED INTERFACES

If you’re not familiar with C# interfaces, here’s the very basic practical use for them in this situation: you can have a class implement an interface (public class Protagonist: Monobehaviour, IDamageable). It now must have whatever public methods indicated in IDamageable — void TakeDamage(int number), int GetHP(). Now, my Attack() method doesn’t have to worry if it’s hitting a Unit or the Protagonist; it knows that anything that implements IDamageable can be… damaged. This is literally a textbook example.

So I tossed that in there and said "good enough." A few months later, my Protagonist class and my Unit class began to look very similar. Both eventually implemented spells. Both needed to trigger animations. And both held similar state data, and interact with the world in similar ways.

IDamageable made sense for damage- and HP-related functions, but I had to implement an ICaster interface to handle spells. And what about something to get unit transforms? And then I started thinking about introducing player movement...

WELL, THAT GOT OUT OF HAND FAST

As it turns out, I want the protagonist and the units to share a LOT of functionality. After some design-thought, I decided that there are two fundamental differences between units and the protagonist. One is that when the protagonist dies, the game is over. Two, and more importantly, is that one is controlled by the player, and the other is controlled by AI. The fix?

Go from this:

IDamageable, ICaster, IWhateverable, Monobehaviour > Unit
IDamageable, ICaster, IWhateverable, Monobehaviour >  Protagonist

To this:

Everything is a unit. Every unit has an AIController or PlayerController component. These take care of AI behaviour or player input commands.

After I refactored my code, I managed to implement controlled player movement in less than an hour. That was easy! But it also makes future improvements easier. My protagonist now has access to a huge suite of Unit commands that I had written for movement and similar functionality.



A FEW NOTES ON PLAYER MOVEMENT AND REFACTORING

• When I was first designing the game, I hadn’t thought too much about player movement. My test character class was a ranged caster type, but I intend to create more melee-oriented classes, too, but I wasn’t testing on one. This delayed the functionality.
• It makes the game FEEL so much better if you can move your character around responsively.
• The code reads so much better with the behaviour loops taken out of the unit class.
• I was daunted by the refactor at first. After all, I have maybe 100 classes that interact with IDamageable in some way. It took a bit of brute force, that's for sure, and the better part of an afternoon. But after the refactor, everything seemed to work JUST FINE.

[anapestdigital]

REFACTORING PROTAGONIST AND UNIT CLASSES


Full devlog here: https://anapest.digital/refactoring-protagonist-unit-classes/

Let’s talk about refactoring! Early in development, I conceived of two types of “fighters” for Restless Ground: the protagonist and everyone else (“units”). This made a lot of sense… until it didn’t.

My original thinking: a lot of the code for units concerned their behaviour loop, and I’d probably want a different set of stats for the protagonist and units. I wasn’t even sure I wanted the protagonist to be able to move. However, they both had to be hittable; so I quickly implemented an interface called “IDamageable”…

CONVERGING CLASSES AND BADLY IMPLEMENTED INTERFACES

If you’re not familiar with C# interfaces, here’s the very basic practical use for them in this situation: you can have a class implement an interface (public class Protagonist: Monobehaviour, IDamageable). It now must have whatever public methods indicated in IDamageable — void TakeDamage(int number), int GetHP(). Now, my Attack() method doesn’t have to worry if it’s hitting a Unit or the Protagonist; it knows that anything that implements IDamageable can be… damaged. This is literally a textbook example.

So I tossed that in there and said “good enough.” A few months later, my Protagonist class and my Unit class began to look very similar. Both eventually implemented spells. Both needed to trigger animations. And both held similar state data, and interact with the world in similar ways.

IDamageable made sense for damage- and HP-related functions, but I had to implement an ICaster interface to handle spells. And what about something to get unit transforms? And then I started thinking about introducing player movement…

WELL, THAT GOT OUT OF HAND FAST

As it turns out, I want the protagonist and the units to share a LOT of functionality. After some design-thought, I decided that there are two fundamental differences between units and the protagonist. One is that when the protagonist dies, the game is over. Two, and more importantly, is that one is controlled by the player, and the other is controlled by AI. The fix?

Go from this:

IDamageable, ICaster, IWhateverable, Monobehaviour > Unit
IDamageable, ICaster, IWhateverable, Monobehaviour >  Protagonist

To this:

Everything is a unit. Every unit has an AIController or PlayerController component. These take care of AI behaviour or player input commands.

After I refactored my code, I managed to implement controlled player movement in less than an hour. That was easy! But it also makes future improvements easier. My protagonist now has access to a huge suite of Unit commands that I had written for movement and similar functionality.

And voila! He moves, he whips. What can't he do?



A FEW NOTES ON PLAYER MOVEMENT AND REFACTORING

When I was first designing the game, I hadn’t thought too much about player movement. My test character class was a ranged caster type, but I intend to create more melee-oriented classes, too, but I wasn’t testing on one. This delayed the functionality.

It makes the game FEEL so much better if you can move your character around responsively.
The code reads so much better with the behaviour loops taken out of the unit class.
I was daunted by the refactor at first. After all, I have maybe 100 classes that interact with IDamageable in some way. It took a bit of brute force, that’s for sure, and the better part of an afternoon. But after the refactor, everything seemed to work JUST FINE.

[Logan Hart]

Hey! I love the look and idea of this! I don't think you'd be overdoing the match-3 mechanic--if anything, you'd be breathing new life into it, in a sense.

I also think that giving the player some movement is a good idea--too many restrictions might lead to frustration, and a little bit of control like that will give it some feedback to the player. And I'm not too keen on coding, but the new system seems much cleaner.

Looking forward to more!  

[anapestdigital]

Thanks Logan! Appreciate the feedback. 

[anapestdigital]

Calculating Projectile Trajectory (Almost Certainly the Wrong Way)

Full post (with code): https://anapest.digital/certainly-wrong-way-to-calculate-projectile-trajectory-in-unity/

Figuring out projectile trajectory should be pretty easy right? Well, I’m not really a math guy. This is not a statement of character, just of condition. I’m good at math — I’ve always been able to grasp concepts when I put my mind to them. But, for years, I’ve told myself that I’m not a math guy.

I recently completed Math 12 (as a 29 year old) in order to get back into university, and I did well (really well). But I still don’t know very much.

I’ll do a bigger post on maths in game development soon — the basics seem to be hella useful and I am going to get deeper into it when I get back in school — but I’m just going to touch in on my struggles with projectiles here.



Projectiles are not very important in my game. Though many spells and attacks USE projectiles, they aren’t physics objects with hit boxes. There’s no collision (per-se). I’m also not using any physics from the Unity engine. All the projectiles do is follow a path and check if they have reached the “x” point of an target in order to “resolve.”
Making projectiles go straight is easy. However, I wanted to have the option to arc them nicely.

USING ACTUAL BALLISTICS CALCULATIONS

Might as well do it right the first time… right?

I started with this Wikipedia article (https://en.wikipedia.org/wiki/Trajectory_of_a_projectile) on calculating trajectories of projectiles.

Inputting this created projectiles that flew everywhere, very fast. I realized that I am definitely not using the pre-approved Unity world-units (since I thought I could make this game with no physics), and would have to tweak gravity and my scene structure to get any sort of sensible result. I tried this for a while. Then I gave up.

Next I had a look at this one: https://blog.forrestthewoods.com/solving-ballistic-trajectories-b0165523348c

…but it seemed to be much more robust (accurate, complicated, and possibly processor-intensive) than I would need.

If I were starting this project over, I could do a little bit more early work to make sure that the physics would make sense. But I’m not going to do that.

FAKING PROJECTILE TRAJECTORIES

In reality, I didn’t need projectiles to do much more than look reasonable and give me some sort of sense of attack timing. So I decided to fake it.

My current WIP ballistics code fudges it using this answer on Stack Exchange https://gamedev.stackexchange.com/a/40546.

Here’s what I have.
First, my co-routine checks if the projectile is at its target. If not, it moves it along based on the calculated velocity:

Code:

private IEnumerator RunPath() {
 while (!at_target) {
  if (PositionWithinPointOhFiveOfTarget(target)) {
   at_target = true;
   AtTarget();
  } else {
   MoveToward(target);
  }
  yield return new WaitForSeconds(.025f);
  yield return null;
 }
 yield break;
}

private void MoveToward(Vector3 t) {
 Vector3 velocity = GetVelocity(origin, target, 0.55f);
 transform.localPosition = new Vector3(transform.localPosition.x + velocity.x, transform.localPosition.y + velocity.y);
}

private Vector3 GetVelocity(Vector3 from, Vector3 to, float power) {
 float distance = to.x - from.x;
 //Ultimately, we want the y-velocity to start higher and become more negative. 
 //I have cheated that by having it multiply the y-offset by a percentage of completion.
 float distance_now = to.x - transform.position.x;
 float percent_done = distance_now / distance;
 float y_offset = percent_done/2 - 0.29f; 
 //This makes it end up a bit further down (on the Y axis) than it starts. Use - 0.25f for a level shot.
 float angle_to_point = Mathf.Atan2(to.y, to.x - from.x);
 float distance_factor = 1f / 5f;
 float angle_correction = (3.14159f * 0.18f) * (distance * distance_factor);
 float velocity_x = Mathf.Cos(angle_to_point + angle_correction) * power;
 float velocity_y = Mathf.Sin(angle_to_point + angle_correction) * power * y_offset;
 return new Vector3(velocity_x, velocity_y);
}

When it hits the target, I can trigger whatever I like in my “AtTarget()” method.

Does this look absurd and bad? Probably. Unscaleable? Maybe. But I hope it’s more light-weight in terms of performance (compared to doing a lot of square roots). If you have any feedback, I’d love to hear it below!


PEOPLE ARE PROJECTILES TOO

So I needed a visual jumping mechanic for a skill and thought… well… maybe I could just use that projectile script:


People are projectiles too!

Obviously I’ll need a better animation for the hero, but this looks hilarious.

DISCLAIMER

This is almost certainly a BAD solution if you care about physics. If you are creating an Angry Birds style ballistics puzzler, don’t use it. I also don’t totally understand the code snippet I included from Stack Overflow. But I needed something that was quick to implement and looked okay, and it seems to work mostly. Since this isn’t a major part of my game, I feel like a hacky approach (at least for now) is fine.

TL;DR:

I should learn math better, but it doesn’t matter much for this feature. If I have to refactor and improve my code, I’ll probably revisit this topic. However, this works okay for now! Use at your own risk.

[foofter]

Lol I like the projectile jump, and general style and idea! No sure how the game is 1D tho...?

[anapestdigital]

I'm calling it 1-D because all of the action takes place along a single axis. The graphics are, of course, 2D.

I suppose this is not entirely true now that I've given characters jumpy abilities  though!

[anapestdigital]

Hooks Ahoy!

Full post at https://anapest.digital/hooks-ahoy-event-triggered-effects/

I wanted to have a system that handled interesting, event-based effects (like on-hit or on-block procs). One COULD hardcode things like critical hits and ripostes, but I wanted to try a much more flexible and generalized solution.

After some thought, I modelled these after a piece of software that I know pretty well: WordPress. In WordPress, “hooks” are called at key moments during core, theme and plugin functionality. Developers are able to hook functions — any functions — to these, and they’ll be called. This allows us to stick code into the middle of things without having to break plugins. It’s also one of the reasons that WordPress is a dream to extend.

I’m not sure if this is typical — or good practice — for game developers. The usual disclaimer applies: I do not know what I’m doing. Never follow along.

…WHEN HARD CODING DOESN’T MAKE YOU HARD ANYMORE.

Sorry. Anyways:

Pseudo-code for a simple but unflexible system might look something like this:

Code:

AttackMethod(Unit target, int damage) {
 
 if (Critical()) {
  damage = damage * 2;
 }

 if(SomeOtherEffect()){
  //do something
 }
… etc.

 target.Attacked(this, damage);
}

Attacked(Unit attacker, int damage) {
 if(Block()){
  damage = damage * 0.5f;
 }

 if(Thorns()){
  attacker.TakeDamage(2);
 }

 TakeDamage(damage);
 
 etc...

}

This doesn’t seem to arduous with only two or three possible on-hit effects. Actually, it’s probably perfect for a small game. Which is... I guess... what I'm making. But I'm ambitious (and lazy). What if we want to make twenty or thirty effects?  Or three hundred? And what if we don’t want every single unit to constantly be checking if they can do every possible thing? And what if I don’t want to be cracking into my unit code whenever I want to do this?

INTRODUCING HOOKS FOR EVENT-TRIGGERED ACTIONS!

My solution was to create a master list of functions that can be assigned at specific points, with dynamic chances to be called. This involves getting our hands messy with delegates, which are a lot of fun (I think).  Actually, I had to figure out how to implement C# delegates for this task, so I hope I’m not way off base.

The first thing to create was a series of hooks. I set these up as an enum with values like HIT, BLOCK, DAMAGED etc. These would be used to identify the points at which an effect would have a chance to trigger.

Next, I created a data structure for the effects themselves. These would be “EffectChances,” and they would take in a name(“Critical Hit”), an action (CriticalHit()), a chance (out of 1) to trigger (0.05), a power level, an optional hook for beneficiaries (“all enemies”, “all friends”), and a hook (Hit, Take Damage, Block etc.)

 

Code:

public EffectChance(string _name, int _chance, Action<IEffectHookable, Unit, int> _action, int _power, EffectBeneficiary _beneficiary, EffectHook _hook) {
 effect_name = _name;
 chance = _chance;
 action = _action;
 power = _power;
 beneficiary = _beneficiary;
 hook = _hook;
}

Now that we had something to hook and an enum of hooks to use, we needed something to hook it to. I wrote an interface called “IHookable” which is currently only implemented in Units. This contains the meat of the hook script: AddEffect(), ApplyEffects() and RemoveEffect(). These manage a Dictionary<EffectHook, EffectChance[]> (that is to say, each dictionary key is a hook (HIT, DAMAGED etc.), and the value is an array of effect chances (10% chance to crit, 5% chance to poison etc.).
Here’s how they look in the Unit.cs script:

Code:

public EffectChance AddEffect(EffectHook _hook, EffectChance _effect) {
 if (!hooked_effects.ContainsKey(_hook)) {
   hooked_effects[_hook] = new List();
 }

 hooked_effects[_hook].Add(_effect);
 return _effect;
}

public void ApplyEffects(EffectHook _hook, IEffectHookable _subject, Unit _target = null) {

 if (hooked_effects.ContainsKey(_hook)) {
  foreach (EffectChance effect in hooked_effects[_hook]) {
   int roll = Random.Range(0, 100);
   if (roll <= effect.chance) {
    effect.action.Invoke(this, _target, effect.power);
   }
  }
 }

}

public void RemoveEffect(EffectHook _hook, EffectChance _effect) {
 hooked_effects[_hook].Remove(_effect);
}

Finally, the actual effect actions themselves are contained in a script called effects list, which keeps a Dictionary<string, Action> of actions. The actions are delegates that take in an IEffectHookable (unit), a target unit, and an integer for power. Here are a few examples:

This effect drains mana from a target and gives it to the protagonist.

Code:

public Action<IEffectHookable, Unit, int> DrainMana = (IEffectHookable subj, Unit target, int power) => {
  subj.GetUnit().CalculateDamage(power);
  FindObjectOfType().GetProtagonist().ChangeMPAmount(power);
};

This action triggers when a unit is hit and gives them a small speed buff.

Code:

public Action<IEffectHookable, Unit, int> Fury = (IEffectHookable subj, Unit target, int power) => {
  subj.GetUnit().AddCondition(new CndSpurOn(power, 5));
};

It can get more complicated, too. Intercept is a temporary condition bestowed on allied units that allows your hero to take damage for them.

Code:

public Action<IEffectHookable, Unit, int> Intercept = (IEffectHookable subj, Unit target, int power) => {
 int total = subj.GetUnit().damage_to_be_resolved;
 //Find INTERCEPT condition on unit
 Unit u = subj.GetUnit();
 CndIntercept cnd = u.FindCondition("Intercept") as CndIntercept;

 //Find INTERCEPT caster from condition
 Unit caster = cnd.GetCaster();

 //Split damage
 float percent = power / 100f;
 int damage_to_caster = Mathf.FloorToInt(total * percent);
 int damage_to_unit = total - damage_to_caster;

 //Damage units:
 u.damage_to_be_resolved = damage_to_unit;
 caster.CalculateDamage(damage_to_caster, "Pure");
};

Fun fact: Since the last one was hooked to the damage hook, it crashed Unity (since it kept trying to intercept its own damage) until I made it check for “Pure” damage to escape from the effect hook! It also made me create a “damage_to_be_resolved” value for units, and a way to track back a condition’s caster (in order to apply the intercepted damage to her!).

Now, in my Unit.cs’s attack method, I can include:

unit_target.ApplyEffects(EffectHook.HIT, this, unit_target);
…and every single effect “hooked” to the “HIT” hook will have a chance to be called.

It took a while to figure this all out, but it seems to work quite well … as long as I remember to use the feature.

(That’s another reason I’m devlogging… so I don’t forget how to use my own code).

WAS IT WORTH IT?

Yes! I definitely think of this system as a bit of up front work for a lot of down-the-road time savings. It’s also one of the more complicated systems that I’ve authored without much help, so I hope that it’s not embarrassingly useless (or utterly obvious) for other people.

This hook system means that, in order to make a unit prefab that has unique special effects, I can just specify a hook, an effect, a chance and a power, rather than have to muck around with specific scripts for units. It’s a powerful way to create a lot of strategic diversity among different units. And I love power.

[anapestdigital]

DESIGNING CLASSES FOR RESTLESS GROUND

Full post here: https://anapest.digital/designing-character-classes/

In Restless Ground, I wanted to give players a lot of flexibility to grow their character to fit their play style. To that end, I am creating multiple character classes.
At the moment, choice of class does a few things:

It changes how much it costs to unlock new skill schools, and gives certain skill schools for free. For instance, a new Warlock character has access to the fire-based “Hellfire” school on creation.
They can then spend just 3 skill points to unlock “Demonology,” but if they want to branch out into more physical skills, they can unlock the “Devotion” school for 7 skill points.
It affects the amount of stats gained per level. A tanky character like the Deathknight might get 3 points of defence when she levels up, compared to the Warlock’s 2. Such differences wouldn’t be obvious in the early game, but will compound over time.
Each class has access to their own school special abilities, meant to compliment some possible strategies.
Some items — notably weapons — are class specific.
It’s also a cosmetic or roleplaying choice. Play who you identify with most.
My goal was to make the character classes unique, but flexible enough to allow for some emergent play. A few things that all classes can do: access all non-class specific skills, match 3 to create skeletons, wear most equipment.

THE CHARACTER CLASSES:



WARLOCK:

The Warlock begins the game with the Hellfire skill tree unlocked. This includes powerful damage spells as well as a spell that grants massive temporary fire resistance to friendly creatures (particularly useful since these spells do a LOT of collateral damage). The Warlock may also unlock the Demonology school for cheap. Demonology is still being designed, but will likely focus on summoning creatures and life sacrifice. The Warlock’s special abilities currently include: “Spur On,” in which the Warlock cracks his whip to damage creatures but buff allies; “Constrict,” which stops an enemy in their tracks and causes damage over time; and “Gate,” which summons a wave of ravenous demons.

This character was built to be a high-damage character focused on powerful direct damage abilities, but weak to direct physical confrontation. Fire-focused Warlocks might also have some trouble dealing with fire-resistant enemies. They should pick up some alternate skills for these occasions.



DEATHKNIGHT

The Deathknight is the game’s basic tank character, focused on defence and positioning. Through their Devotion tree, she can take damage in the place of skeletons from their army, leap into the fray and deal extra damage based on lower health. She may also access the Tactics school, which allows her some flexibility to bolster her army.
The Deathknight is intended to get in the middle of things and take some hits. She has skills that allow her to heal herself, deal up close damage, and deal extra damage based on lower hit points.

GENERAL (CONCEPT)

The General is a melee character focused on pushing his forces to victory, no matter the cost. He comes with the Tactics school unlocked, granting him an unmatched ability to manipulate the battlefield and buff his army, and can unlock Demonology for cheap to fill out his forces. His skills and stats growth will focus on improving his army and dealing sustained damage.

ENCHANTRESS (CONCEPT)

The Enchantress is a magic-focused character with skills that focus on debilitating and turning enemies against each other. She will also have access to an ice-based school of magic that can be used to freeze and slow enemies.

ICE BEING (CONCEPT)

The Ice Being is an unstoppable force of ice and mayhem. It mixes ice magic with powerful melee skills to freeze and shatter enemies. Though its army-boosting stats suffer, it boasts strong physical and magical abilities to make up for this.

CURRENT THOUGHTS:

These character classes are obviously not quite done and subject to change. I’ve animated and built many of the skills for the Warlock and Deathknight, but have a lot of work to do for the rest.
I worry that I’ve made things a bit more complicated than they need to be, and may minimize my skill sets so that I can focus on honing them to perfection.

[LyricalReverie]

I love those sprites. So cute. 

[anapestdigital]

Thanks Lyrical  I'm doing a bit of a refresh at a higher resolution at the moment, but I'll try my darndest to preserve the cuteness.

[anapestdigital]

PARTICLE SYSTEM MADNESS: THERE WILL BE PIXELATED BLOOD. AND FIRE. AND POISON. AND ICE.


Full post here: https://anapest.digital/particle-system-madness-pixel-blood-fire/

I’ve been working on particle emitters to provide some spell effects, damage reactions, and condition indicators for Restless Ground. My first impression: Unity’s particle system component gives a lot of flexibility, but it offers an overwhelming palette of choices.

Unfortunately, there isn’t a lot of good information on creating pixel particles. Unity’s docs are okay, but are mostly focused on creating more realistic effects. Once I’m more confident with how particle systems work with pixels — and figure out how to get them to be pixel perfect — I may cobble together a tutorial for interested devs.

Anyways, here’s how it works: I created these particle emitters and saved them as prefabs. When the game calls them, they are pulled from an appropriate “PoolParent” (a generic class I whipped up to efficiently manage prefabs) and childed to a unit’s transform. These particle system-based animations are rudimentary, but I am pleased with how they look. Unfortunately, I haven’t figured out how to keep these animations pixel perfect yet.

A DAMAGE PARTICLE SYSTEM


I’ve replaced the sea of floating damage numbers with a system that spawns blood (or other appropriate unit chunks) on hit. After a recent playthrough of Diablo 3, I am designing away from “numbery” games. Also, I think that this is just a funner way of showing damage.

Bigger hits spawn more chunks. At the moment, chunk density (eww) is a function of the amount of damage done AND the percent of the unit’s health the damage represents. I may tinker with this later, since later bosses might be doing huge amounts of damage.

Then again, I might not. A puny skeleton bursting into a shower of bone meal sounds like a fun visual.

Since these particles don’t have any particular shape, I am just using a simple white material to represent them. I can then recolour the particles appropriately in script. When the particle is summoned from its pool, my damage script activates it with the correct colour and spawns an appropriate blast of gooey bits. These have an upward force at a variable angle, and fall according to gravity.

One important thing: I set “Simulation Space” to “World,” or else falling damage particles will follow their parent’s transform around.

A BURNING PARTICLE SYSTEM


At first, I wasn’t sure how to implement fire, since I was avoiding transparencies and gradients. But I’m already breaking a lot of my original rules (pixel perfect, PICO8 palette only) for the sake of coolness and expediency, so here goes!

For fire, I created a particle system negatively affected by gravity. I’m also using two different colour ramps between PICO8 orange, PICO8 magenta and PICO8 gray at different frequencies. This provides a bit of variance as the particles float up and grow into smoke.

It’s not perfect fire, and it could definitely use some tweaking, but I think it’s at least close to working with my simplistic aesthetic.

A POISONOUS PARTICLE SYSTEM



For a poison effect, I took inspiration from Final Fantasy’s green soap bubble effect for Bio spells.

Since Unity’s particle systems can take a multi-row sprite sheet and randomly render out different rows, I created a green bubble sprite with 5 variations. Then I added it with the Texture Sheet Animation’s “Random Row” option. Whenever the particle system generates a particle, it will appear as one of my random variants.

Like the burning effect above, gravity negatively effects these. They appear, animate, and float away until they pop.

A FREEZING PARTICLE SYSTEM


I created a single-row sprite animation for my frozen effect. These particles would appear over the unit like shining ice. This looked very bad until I tried draining all of the red colour from frozen enemies. Brrrrr. So much for sticking to PICO8 colours!

This has been my first real dive into Unity particle systems, and it was a lot of fun. They are very powerful and quick to iterate over, though you definitely lose a lot of per-pixel control. Mostly, I’m happy that I’m able to easily influence particle systems through code and promote some minor randomization.

I think I’ll be creating some more condition indicators soon, and I will likely be using particle systems more to quickly create spell effects without having to create hundreds of sprite animations. Stay tuned!

[anapestdigital]

THE GREAT RESIZING: DOUBLING PIXEL ART RESOLUTION



Full post: https://anapest.digital/resizing-doubling-pixel-art-resolution/

So I’m probably doubling Restless Ground’s pixel art resolution. I’m not sure how it got into my head, but it did, and it stuck there. It probably started when I got Unity Remote running on my iPhone again, and things felt… big and blocky. Too big and blocky.

It scared me at first. I’d already produced rough animations, icons and backgrounds for about a third of the game. But, one night this week I sat down and started working on some higher-resolution pixel art backgrounds and icons, and I like the results. A lot.

Here’s a what the change between 16×16 and 32×32 pixel tiles looks like:




It’s a big difference. And the resolution change will take time — maybe a lot of time. But it’s better that I do it now than later, when I have more assets complete at a 16×16 tile size.

Here are some considerations I made:

DOUBLING MY PIXEL ART RESOLUTION MEANS I CAN MAKE UNITS A BIT SMALLER…

This is a major concern for me. Currently, with units as big as they are, the battlefield seems very small. Right now, a battlefield might look like this:



This looks fine, but I think the game would have a better feel if I could make the units about 2/3 of that size. Upsizing will be a bit awkward.

However, if I decide to run with units at 1/2 size, I won’t have to redo my animations! I can just change the pixels-per-unit for the assets in Unity. I’m not sure how I feel about this, since they look VERY small on a phone screen. But on a PC screen they give off a Risk of Rain vibe, which I like a lot.

…BUT I’LL HAVE TO KEEP MY PIXEL ART SKILLS SHARP.

Pixel art at a very low resolution is a special skill, to be sure. But you don’t have to worry about detail too much (because you CAN’T). You can get away with a lot of blocky abstraction. At a higher resolution, I have to become better at accounting for shadows and textures. I’ll have to add details that I got to ignore in the past. I’ll still have to account for every stray pixel, but now there’ll be 768 more to wrangle. And for that reason…

I SHOULD PROBABLY REVISIT MY PALETTE BEFORE I GO FURTHER.

Currently, I’m using a PICO-8 palette with a few added blues. This might be useable for my new higher resolution pixel art, but, if I later decide that I’m going to need a a few extra colours (maybe another orange or red?) I’d be behooved to add those colours BEFORE I dive into animating ~30 characters and ~50 spell effects.

I MIGHT JUST BE SICK OF SEEING MY LOW RESOLUTION SPRITES.

Redoing the art for my game now isn’t too daunting. As I said before, I’ve only created a fraction of the total assets. But I wonder if I’m just sick of looking at it and want to change up?

[freank]

candy crash + a platform game? :D
I joke! Nice work!