Some of the big changes here are graphical. It’s finally starting to look like a game. The models and animations were taken from opengameart.org. I just don’t have the time to do the art I need. Also, they were hurriedly inserted. One of the many things I need to do is change up some code so I take advantage of Unity’s animation event system. It shouldn’t be difficulty, but I have more important things to work on right now.

Something finished after the video was made is the saving and loading feature, and the level select map. They work completely. Saving and loading is something that won’t make it into any web player builds for obvious reasons, but the game was never intended to be made for the web player.

I’ve begun to adopt Unity’s Navmesh and Pathfinder features. The big white blocks in the test level are there to show that off. Right now, the controls of both the player and the enemies use a combination of the two. The result is an effect that makes it look like characters enemies have little control over their own momentum. Additionally, some of the AI isn’t quite as polished as it needs to be. The rangers can get briefly stuck in little loops of ActCowardly() and ActAggresively() if the player is hiding around a corner.

I’m currently getting prepared to start making greybox level designs. Two features I want to add before that are enemy spawn points and friendly NPC interaction.

One question on my mind is, of the 13 acts of the game, how many individual levels do I want? One, two, or three. I need to work on my boss mechanics…

Play the latest version

I’ve made several additions, and I’m really excited for this upcoming week. First, I’ll start with the obvious.

Main Menu and Inventory

When the game loads, your prompted with a main menu screen. The background graphics are all temporary and experimental. I really hate the way it turned out so far, but I’m working on other facets of the game right now.

I only put enough effort into the menu scene as to get its core functionality in place. That said, the two options in the main menu are to launch the test level or open the inventory. Crafting is not yet really implemented.

Finally, the GUI itself is called Necromancer. Despite the touch of class it added to the game, the issues I had setting up the GUI was not worth it. Until the next version of Unity’s GUI system comes around, I’ll be using GameObjects and an orthographic camera for any GUI more complicated than a menu.

Music and Sound

I generated my sound effects as placeholders at as3sfxr.  I got my background music from No Soap Radio. I’m collaborating with Dan Ambrosini. He’ll be providing this game with the music it deserves.

Special Abilities and Powers

The back-end code for the player and enemies to use powers that come with the player’s equipment is in place and functioning. A few changes are still in the works, but its working as expected for the most part.

Target Acquisition

The player now snaps to face enemies in front of him. Gameplay was too slippery before.

Upcoming Changes

There are still a lot of things on the verge of being added, and things I need desperately need to tweak.

The damage mitigation formula is linear. I needs to be exponential with a limit on the amount of damage that can be absorbed by the armor. As it stands, Excellent armor can render the player invincible. Really, the stats in general need an overhaul and some standardization. It will also help make the tool-tips look prettier.

Like in traditional Beat ‘em ups, the enemies will flinch or be stunned when the player hits them. I think this will aid in the feeling that the player can avoid being hit. As it stands, that’s not really possible if the player wants to progress at a decent pace. On the other hand, I may just embrace that and throw it to the winds of my endurance recovery system.

I really want the player to be able to jump onto platforms of multiple heights, but I’m having issues with the CharacterController.isGrounded variable not staying TRUE, despite the player standing still on the ground. Additionally, the controls, as they are, are too slick. It’s too easy to accidentally run off a platform.

Play the latest version

Read: Sandsea: Shadow of Umbri Gameplay Design Document

Read: Sandsea: Shadow of Umbri Story Design Document

1. Random Item Generation
2. Inventory Management
3. Crafting

The base of the itemization system was already in place. The number and functions that drove the character’s attacks and defensive statistics came from the items the character had equipped. Until now, those figured had all been defined in the inspector. A key feature of the game, however, is that the player can change the party’s equipment  between levels.

Also, considering the story of the game, it didn’t make a lot of sense for the characters to happen up a store to buy and sell items between every level. With that in mind, I designed a simple crafting system.

All the available party characters show up on the left hand side. The party inventory displays in the top right. Crafting shows up right under the inventory.

The inventory screen works! The crafting, however, is not yet implemented. It won’t be implemented until I finish the item generation system. That’s what I’m working on now.

I completely underestimated the kind of logic I would have to come up with in generating items. Attack speed, alternate fire resource costs, algorithms for implementing the stats, and character restrictions; the list of variables goes on.

In the process of developing the weapon generation, I ended up shuffling around several variables. Things that I imagined would be defined by the weapon made more sense to be defined by the character, and modified by the weapon. My understanding of the way data flows in Unity, such as from scene to scene, has has vastly expanded.

With weapon generation all but finished, I should be able to tackle armor and trinkets in a relatively swift manner.

Play the latest version now!

Serialization

It’s fundamental to the gameplay and design, and in every significant way, it’s working. I’ve created a suite of classes to represent character data, item data, and their interactions. At first I was concerned with getting XML serialization working right away, so I could populate the character data and item data objects. I quickly realized that I could put that work onto Unity’s inspector. (See Screenshot)

Items, Player Characters, and enemies all use the same core data structures. I can give the enemies the very weapons and armor they will drop for the player to pickup. Items have “magic” bonuses to the character’s stats. Weapons have unique attack data and alternate fire projectiles.

I can create a new, fairly unique character, in the inspector in just a few moments.

Character Swapping

Since the character data is totally serializable, I’m able to quickly swap out the activate character data for the character data of a benched character. I’m really excited to see this core mechanic working so well.

Right now, there are three characters in-game. They each have a set of items, but the items can’t be changed out yet. Each of their weapons has a unique alternate/ranged attack.

Enemy AI

I have stubbed methods for several types of enemies; including brutes, rangers, and minions. I’ve developed a rudimentary AI for the minions. I’ve patterned them off the behavior of Diablo’s fallen. When an ally dies in their presence, they scatter and run away. Of course, this can only happen so often, and it doesn’t happen all the time.

Weapons and Ranged Attacks

There are three kinds of items. The first kind, weapons, are the most developed so far. Each weapon has a ranged/alternate attack, selectable via the serializable weapon data. The attack radius of the weapons has also been upgraded from an awkward collision box to a programmatic arc, just as I wanted from the beginning. I had to brush up on my trigonometry, but it was well worth it. With just a few variables changed in the inspector, I can change a weapon’s reach and arc. I will definitely be able to reuse that code.

Redesigned Movement and Camera

I just recently totally rewrote the movement code. The way it was before, it wasn’t able to handle where I wanted to take it. I was trying to add code to lock onto enemies, but the old version was having none of that. Now it’s much more flexible and extensible.

One very noticeable change from the last playable version is that I totally removed that variable movement speed. I did this for at least two good reasons.

1. Technical ability for the player to control the character suffered.
2. I foresaw a game design flaw stemming from one of the main reasons I had the feature to begin with.

To top all of that off, the player, data, and camera objects aren’t so tightly coupled. That was starting to bug me.

Play the latest version now!

At 6:00pm, Friday, all the other team captains and I lead out the door where we were presented with the jam’s theme. That theme was the following image of an abandoned merry-go-round in forest and overgrown foliage.

After about an hour of deliberation, we came up with our interpretation of the image and a general game concept.

This initial concept revolved around childhood, the abandonment of the past, and disenchanting results. We continued to develop the concept as we produced concept art and build a basic environment and controls in Unity. The end result was “Estrellastray.”

Ricardo, all grown up, returns to his favorite childhood park. There he discovered his favorite ride, abandoned and in disrepair. He discovers the merry-go-round is actually an trans-dimensional ship, and his childhood imaginary friend was actually its pilot. Ricardo’s friend sees how disappointed “Ricky” is with his life and the world around him, so he takes Ricky back to his childhood. The alien friend’s child-like spirit and Ricky’s childhood imagination run rampant together, as Ricardo is transformed into a child and equipped with alien technology. With light on his side, Ricky fights the dark demons of his past.

The name Estrellastray refers to both the lonesome nature of the alien friend, and the way Ricardo’s life has deviated from his desired path.

Further development would include more imagination-warped past events, such as a pillow fort during a sleep-over gone wrong, more light-based weaponry, and the beautification of the Ricardo’s present time.

Estrellastray was developed in about 45 hours by three people. My roles were primarily designer, writer, and programmer.

Music for Estrellastray came from http://www.nosoapradio.us/

Download Estrellastray

• Windows
• Mac (Untested)

I found this piece of stained glass work. I’m not sure if it’s a physical piece of art or a digital work. I brought it into Photoshop, cleaned up the grouting, and turned it into bump, normal, and diffuse maps.

This project was also an lesson in render time, and how to not use all my computer’s RAM to render a single still image.