Over the course of the past year, my son has been having difficulty regulating his big emotions. Part of this, I realize, is being a three year old. It’s kind of unavoidable that a meltdown will happen. His brain is still developing. I realized that I wanted to do as much as I could to meet him halfway, help give him an environment where he can be free to express his strong emotions.

It started out with simply acknowledging them, and making sure he felt heard. It evolved into trying to draw them, or express them physically by punching pillows and stuffed animals. Eventually, Lo bought a series of posters we have hung in the kitchen area where he can easily point and identify with what he’s feeling. There are red, green, blue and yellow areas representing anger, happiness, sadness and anxiety/silliness respectfully.

I wanted to take that a step further, by building a small app that allows him to identify his emotions in a visually pleasing and tactile way. I set out to make a digital form of the posters we were using to great effect in the kitchen.

Aris (and Ander, as it turns out!) can slide the slider left or right to choose an emotion, select it, and engage in a small activity that can help redirect and soothe stronger emotions.

What I focused on chiefly for this app is to not overload the user experience with bloat. The app is designed for small children who are in the midst of the most overwhelming moments of their life. It needed to have a super-abbreviated, super-simple user experience that gets to the point and immediately helps soothe big emotions. My goal is to develop dead-simple “mini-games” or “activities” associate with each mental state to help regulate and bring their minds back to a place where they can make better decisions.

I’ll keep updating as the app continues to develop. In the meantime, feel free to try it out at the development endpoint, here: EmotionApp

Iterating on the firefighting logic, I added some logic to decide when to give chase, when to give up, and when to fire at the player. I can play with these values until something feels good, but I think for demonstration’s sake, I’ve got something that works. The enemy turns red when they’re alerted, and back to gray when they’ve de-aggro’d.

Looks like fun.

Next I’ll add some more enemies to the scene, then start designing some of the background processes, such as resource gathering and experience. It might require a break from code while I hash all of those details out.

I set out to figure out a fun movement pattern for enemies. Initially I just added some random bursts of movement, which was pretty easy. Just figure out a random angle, and burst in that direction.

It was pretty fun, and I think it could work for some dumb enemy types, provided we give it some bounds. It could also be used as like, “roaming” or something. But I wanted something a bit more sinister.

So I added some logic to track the player’s ship and burst in that direction. Added a timeout and potency for the acceleration. It turns out it’s a lot of fun.

Pretty cool. I’ll add some detection logic based on proximity, and we’ll have some smart enemies. After that I’ll try to figure out some cool flocking behavior for multiple enemies.

My son played the prototype I’ve been working on, and immediately asked me if he could “bully the sun”. I think he meant he wanted to shoot lasers at it like you could at enemies and asteroids.

My first attempt at doing this caused the body and ALL of its revolving children to just, poof, destroy themselves. So I had to change how we make the bodies revolve around each other. I had the asteroids and planets be children of the Sun, so I moved them out of the hierarchy and re-wrote how a body revolves around another body. Using GameObject.RevolveAround wasn’t working. In the update function:

angle += orbitSpeed * Time.deltaTime;

// Calculate the new position based on the center object's position, radius, and angle
Vector2 newPosition = parent.position + new Vector3(Mathf.Cos(angle), Mathf.Sin(angle)) * radius;

// Update the position of the object
transform.position = newPosition;

I then wrote a DestroyListener script that defines an event for listening on when a GameObject is destroyed. Then defined a callback in the Revolve script of rotating body that fires off when the parent is destroyed. When a rotating body’s parent is destroyed, I have it fling out into a random direction. The result is a brief moment of fun chaos when you “bully the sun” by blowing it up. All of its children, planets, asteroids etc just scatter slightly.

Thanks for the tip, Aris!

I added the ability for an enemy, the cube here, to target and fire at the player. It took me an embarrassingly long amount of time to figure out the logic for aiming and firing, but…eh that’s how you learn.

Then I added a reusable set of scripts for taking damage, managing health, and exploding. It gives entities hitpoints, and manages when they explode or when they take damage. I added them to the asteroids and the enemy.

It feels alright, but it plays a little clunky. I think I’m going to free up the aiming of the canon away from the steering of the ship. It’s a little hard to aim and steer at the same time. That should make it feel a lot better.

I’ve added the ability to fire lasers, hit planets and make them explode. I also changed the control configuration from WSDA to mouse control. Before, I had the ship snapping to one of eight directions when hitting left, right, up or down. It was super complicated, and I figured it’d be a cause for frustration if we were creating an aim-and-shoot game.

So mouse movement for steering the direction simplifies things. Still having trouble figuring out how to make realistic acceleration and deceleration working in this new configuration, but we’ll get there.

I learned about particles here too. The particles look really derpy at the moment, but we can improve upon them too. The real difficult piece in all of this was learning collisions. I had the lasers affixed with a Rigidbody, but that just caused them to flop around like fish shot out of a canon. It turns out you can just have one item have a static collider, and then its target can have a kinematic Rigidbody (the asteroids, in this case).

I want to create the concept of hitpoints and power on the projectiles, so some targets can take a few projectiles before they explode.

My next big step will be introducing smart enemies that fire at you. That’ll be a doozy.

Back in 2022, I wrote a game that got way out of hand called Planets. It was fun, but the scope just blew up and I was not disciplined with it. I decided to take the same concept and port it to Unity in “3D”. That is, the game is still played on a two-dimensional plane, but with 3D assets and effects.

I wrote a design document during my week off from work, which you can find here. I also managed to get the thing up and running with some basic logic for entering and leaving a star system. You can watch the repo here.

Stay tuned for more Planets 3D developments.

I’ve been working on a Gameboy inspired bullet-hell game to celebrate my wife’s pregnancy. The idea for this game came from a conversation my friends and I were having while developing another game for a game jam in Louisville, KY some years back.

At the time we cackled at the idea of a bullet-hell game centered around the journey of a sperm to an egg, as the similarities were, to our very limited understanding of anatomy, stark.

Now though I was able to code the prototype in the scraps of free time I’m afforded when my son goes

You play as a little guy competing against other little guys, dodging obstacles and making sure you are the only little guy to make it to the coveted egg at the end.

You charge in all directions, and while charging, are able to take out rivals. Taking out rivals without taking damage adds to your combo, and keeping a high enough combo let’s you form shockwaves when charging into enemies, which causes more enemies to be destroyed.

I’m going to be refining it, adding a level select screen, more levels, enemies, and maybe some powerups– but for now I’m satisfied with the simple gameplay loop I’ve created.

The end of the level has you meeting with the egg. I was thinking of doing a sort of horde-mode mechanic where you defend the egg from rivals, but decided to keep the scope simple and turn it into a pseudo-boss battle.

Feel free to drop a comment and let me know what you think.

For the past couple of weeks, I was busy tooling around with a couple of side-projects. One of the projects is an interface for a friend who is trying to make an analytics platform. Another is a NodeJS app that runs a chron-job to scrape some apartment websites and records the data in Firebase for me to visualize later.

After I got a little bit of that out of my system, I came back to my game. I left it in a state nearly a week and a half ago where I sort of had targeting multiple enemies working, but not quite.

I had to revisit how I was handling targeting enemies and allies. Instead of passing a single target to an event object, I changed the interface to always pass arrays of enemies. That way if we have a spell that targets multiple enemies, it will iterate through each enemy and apply the spell effect.

In addition to that refactoring, I also added battle cursors! So now you don’t traverse a list of bad guys’ names, you actually traverse the bad guys (or good guys, if you’re casting a beneficial spell…).

In addition to that, I also added a new spell, Flame All. Flame All does precisely what you think it does –attacks all enemies with fire! Flame All is a perfect showcase for multi-targeting, visible cursor, and the last thing I added, called primaryAnimationEffect. This effect plays before the actual spell effect on the targeted enemy. In this case, I made a cool (reusable!) explosion effect. Take a look at all the features in action!

Characters can now cast spells in battle!

In order to get spell casting to work, I had to lay the groundwork with a few lower level systems:

• Characters had to be able to ‘learn’ spells at certain levels. I created an array of ClassSpell objects on each class, each containing a required level to cast in addition to a reference to a Spell object.
• Spell objects hold all the data associated with a spell (MP required, potency, casting type, targeting type, etc) in addition to a reference to an animationEffect. An animationEffect is essentially an object with a play method, which handles playing an animation I created using Phaser’s tweening and animation API.
• I tie it all together in a SpellController which handles getting a spell from the database, its related effect, and mapping that data to an actual usable object.

It all essentially looks like this:

And in practice, it looks like this!

Since the effects are stored decoupled from the spells, I’ve also got AnimationEffects associated with items, so using different kinds of items will also trigger similar animations and sounds.

I’m really looking forward to making some cool spells and effects. On the docket for the foreseeable future, I’m going to be working on:

• Targeting improvement
• Spells that target multiple enemies or allies
• Spells that add status effects or attribute enhancing effects