Blogs - bdsowers

Preamble

Alien Star Menace is available now for iPhone & iPad on the Apple App Store and on Android in the Google Play Store.

Background

Alien Star Menace started with a simple goal (if you’re a dumb person) - make 7 small games in 7 days. There was some downtime at my day job, and I was itching to put another game out there; I hadn’t released my own indie game since Cuddle Bears three years ago. So I browsed the net for some art assets I could use and jotted down some designs.

The more I looked over the list, the more “strategy game in space” stuck out at me. I knew it wasn’t a 1 day task. But it was interesting me more than all the other ideas I had. So I decided to throw out the original motivation and instead undergo a more ambitious project.

I grabbed the art from Oryx Design Lab, prototyped some early gameplay in Unity, and Pixel Space Horror was born. Obviously, that name changed later in development. But we don’t need to go into that.

What Went Right
TIGSource Forums & Early Web Builds
The initial design of the game had some fundamental flaws. The Action Point system - which was modeled after Hero Academy’s - didn’t work for this kind of strategy game. It encouraged standing still and letting enemies come to you. Units couldn’t move or shoot through allies. Hallways were too narrow. All things which seemed OK as I was developing but which very much weren’t.

I was using Unity, so even though the game was targeting mobile devices, it wasn’t terribly hard to push out a web build for public feedback. The folks at TIG immediately rallied against the game’s obvious flaws. I fixed those issues, and through a steady stream of feedback polished up other pain points in the game.

Flexible Milestones
My mindset on milestones has always been to try to respect them vehemently. No new major features after alpha, certainly none after beta, Time leading up to an RC candidate should be all about bug fixing.

I don’t think I’ve ever worked on a game where these rules actually held, and Alien Star Menace was no exception.

Case in point #1: I didn’t have a finished title screen until a week before submission. I had some very pixel-art looking text. I wasn’t even sure there *was* a title screen being worked on until the artist surprised me with it. What’s there now is much, much better than what used to be there.

Case in point #2: Two days before RC, I decided I absolutely hated the banner ads. They made the entire game look hideous, and they were almost certain to make no money. So I switched to Unity Ads - interstitials. Which were, by the way, scary easy to implement and have been giving pretty good return rates for the number of players I’m seeing.

What Went Wrong

Content Heavy Design
I’ve come to accept that level design is not a strong suit of mine, and it saps away energy like nothing else in game development. I gradually learned which things in my levels worked better than others, but it was hard learning and not terribly rewarding personally.

I’m not unhappy with how the levels turned out, I actually think a lot of them work really well, but I think a talented level designer could’ve done better and had more fun doing it.

Writing was also stressful. It was something I enjoyed initially - I like telling jokes and crafting stories. My enthusiasm came and went for this; I think I would’ve benefitted from having another person punch up the text some.

Art Direction
Sometimes I trick myself into thinking I have an artistic eye, and then I try to use it and quickly realize I was horribly, horribly wrong.

I had a huge struggle trying to get the later levels to look good. Once you touch down on the alien planet (spoiler), the background changes - a starfield didn’t make sense anymore. And I had no idea what to do.

I hacked for days trying to get something that looked good. And I was never satisfied. I’m still not satisfied. I came up with a neat, creepy visual effect, but the backgrounds still feel flat overall

.

What’s Undecided

Task Tracking
I signed up for a bug tracking system over at Axosoft. I used it for about two days before I nixed it. Instead, I either fixed bugs as I went or jotted them down in a notepad. It might’ve helped if the project had more people, but for a one man game it didn’t do much for me.

Marketing
I put together a pretty comprehensive Press Kit. I wrote over 160 e-mails/messages to various reviewers & YouTubers. I kept running dev logs on Tumblr, TIGSource, IndieDB and GameDev (that last two not as frequently). I posted almost daily on Twitter and less frequently on Facebook. I talked to everyone I met about my game, including a few dates who couldn’t have been less interested ;). I attempted community involvement wherever I could fit myself in.

It’s hard to gauge the impact this has all had. The initial launch has been slower than I’d like, but there’s time for it to build.

Conclusion

It’s still a little early to determine if Alien Star Menace was a success or failure. I’m writing this while everything’s fresh in my mind, and the game hasn’t been out long enough to get a good impression of its performance.

I’m pleased with how the game came out. It’s my largest independent work, and in some regards my best. I think it brings a type of strategy game to mobile that was previously missing or underserved.

I’d like to thank owmywrist for her constant support, testing, and for listening to my endless gamedev babbling, multitude-ofcasualities for her naming help and press kit advice, pythosart for her fantastic title screen art which I used in a ton of different unintended ways, ua86 for some really solid gameplay advice / feedback, and missmesmer for basically being my #1 Tumblr fan.

I hope you enjoy the game, and I’d love to hear your feedback!

I divided my development plan into various 'Phases' based on where I wanted to be in development at a given point. There are 11 phases total, which puts me past the halfway mark for finishing this game.

Here were my goals for this phase:

• Sound & music
• Multiplatform considerations
• Actual iPhone build
• AI tweaks
• Font selection & integration
• Unit Unlocks
• First 15 levels

And all of that is finished! Plus I created a new title with the help of a friend:

All my music is sourced from good ol' Incompetech and my sounds from Freesound.org. It's not the most cohesive sound design, but it's working out OK.

I changed the camera from my last update. I tried supporting multilevel zoom, but it just looks & behaves clunkily. Instead, on large devices, the camera will encapsulate the whole scene. On small devices, the camera will focus up close and track whatever unit is selected/active. There will be a full-scene view, but the player won't be able to play via this view. I might add this camera mode to the large device builds for cohesion and to get some better testing on it.

The next phase is the "Alpha Demo" phase, where I incorporate a lot of the feedback I've received and get the game feature complete (minus some business/social features that I'm holding off). I'm going to go wider with that demo. After that I'll probably start pushing more regular demos.

During this phase of development for Pixel Space Horror, I'm focusing on content. Specifically, I'm trying to get the first 15 levels roughed in - not final, definitely not polished, but playable.

I'll keep this update short on words and instead just show you:

How am I going to rationalize a graveyard on a spaceship? I'm not.

Update 5: Units & Enemies
I spent most of the weekend adding the vast majority of units & enemies that will be seen in the game. The majority of the implementation details were already there: the game already supported most of the attack types & buffs that units would provide.

I created a simple test level to make sure everything was behaving - that units were attacking and moving correctly and nothing exploded.

So here it is, the full cast of Pixel Space Horror:

The units aren't done-done. Visually, most of the attacks use stubs. I want to add flashy VFX (particle systems, camera fun, full-screen effects) to make the game fun to watch. Not quite Atlus-level. I don't have those resources, and also I don't want to slow the game down the way Atlus does in their games. The stats need heavy tweaking - heavy, heavy tweaking after a lot of playtesting - and the writing for them isn't final.

I wanted to put together a small web build, mostly for friends to evaluate. If you want to try, here's the link. I'm not putting it up in Playtesting yet - it's a little early to get a huge number of eyes on it. Feel free to leave any comments/feedback. Pointing out bugs isn't as useful at this stage, as it has plenty.

My goal with this demo was to just make a small slice of representative gameplay. To that end, there are:

• 5 levels
• 5 available units
• A handful of different enemies
• Stub UI - this definitely isn't anywhere near complete

None of the numbers/unit stats are final, and the levels definitely still need tweaking. The "story" will get edited, but the jokes in there are pretty close to what the game's humor will be like. The UI flow will be similar, but I've scheduled in a lot of time for heavy polish.

Features not even remotely represented:

• Unit unlocking - you don't actually start with 5 units
• Level ratings - you'll get stars based on how well you do
• Multiple win conditions - not every mission requires you just kill everything

So far I've only put it in front of one other person. She tells me there are some crash bugs (I have yet to see them myself). She also tells me it's pretty easy. It is only the first 5 levels though, so being pretty easy is kinda the point. Oh, and please forgive the font. I'll be changing that ASAP.

Anyway, lots of forward progress! I'll probably have an alpha build before the month's end which I'll push out to more people.

Most of the last few days has been spent putting together some necessary UI elements. I'm trying to keep the game pretty UI-lite, but there's no avoiding some things.

First, the level selection screen or "lobby." Right now we're assuming all the levels are unlocked, which is definitely not the start state. There are some graphical flares that don't get represented in a screenshot: stars randomly twinkle and the moons rotate around their parent planets.

Then there's the squad selection screen, where the player selects which units will go into combat. Will probably need a bit of text to tell the player what to do. But it's fully functional - you can drag units into the squad and they will be represented in battle!

And finally, the basic cinematic text dialog. Most of the story is going to be represented by one or two sentences at the beginning/end of each mission. This isn't an RPG - it's a tactics game, and the story is not a driving focus.

It all needs a little love. More flares, tweaked layout, definitely a better font. But it's functional, which right now is the most important part!

Pixel Space Horror Tumblr

Background
Pixel Space Horror (PSH) is a very streamlined strategy game: units can only move and attack. For movement, they have a fixed range they can move. Attacks are more varied – every unit has some special qualities when it attacks, such as whether attacks do explosion damage or whether they require line of sight.

Being turn-based, the AI doesn’t have the complications of many other games: we have plenty of time to calculate pathfinding and decisions without the player noticing any lag. We don’t have to rely on as much estimation and can take a more complete view of the scene. Further, we don’t have to respond in real-time to a changing game – the player can’t move out of the way mid-action.

However, being a strategy game, the AI comes under extra scrutiny: it has to make solid tactical decisions to wipe out an enemy team. Everything it does can be seen at all times, and if it does something stupid, players will immediately notice.

Goals
The goals for the AI system were the following:

• Don’t be stupid – enemies don’t need to think 10 moves ahead, but they can’t stupidly move back and forth every turn.
• Don’t be predictable – the game should play differently each time, and the enemies should respond differently to the exact same situations.
• Don’t be boring – if there’s one over-powered enemy, that enemy should not move every time even though it may make tactical sense.

Pathfinding
The pathfinding is crazy-simple, but no AI article would be complete without mentioning it. PSH doesn’t have the real-time, large-scale needs of many games: we have plenty of time to consider movement possibilities, and the slow speed of the units makes the decision space pretty small.

PSH uses a simple breadth-first search to evaluate all the different spaces a unit can walk. It starts at the unit and evaluates every neighboring space for walkability. Once all the neighboring spaces have been evaluated, it then repeats the process starting at those neighboring spaces, and then repeats that process again until it has reached the unit’s maximum distance and/or exhausted all walkable spaces.

This produces paths which are good enough – they may not be quite the most natural paths, but for our purposes the player won’t notice.

Decision Making
PSH uses a brute-force mechanism to determine the next action. It evaluates every possible action for every unit and uses some priority-based decision making rules to determine which action to take next.

There are three varieties of actions for the AI system to consider:

1. Move
2. Attack
3. Move + Attack

Strictly speaking, Move + Attack is two actions, but we group them because it often looks more natural for a unit to move and then attack immediately after (it looks like the unit moved with the intention of attacking).

We evaluate an action based on the following parameters:

• Does this action kill anyone? These actions take the highest priority. If an obvious kill is left dangling, players will notice.
• How long has it been since the unit last moved? We want to spread out actions over all the units so the system doesn’t get boring.
• Does this action involve an attack? Actions that hurt the opponent take priority over actions that are simple movements.
• If this action involves an attack, how much total damage does it do? Attacks which do a lot of damage to multiple units take priority over attacks which only hit one unit for a little.
• If the action involves an attack, what kind of units are we attacking? We may want to hurt healers more than other units.
• How close will this bring the unit to the enemies?

Each of these criteria is weighted so that some are more important than others. If the unit just moved, it might move a second time in a row if that move can do a lot of damage. If it has moved three times in a row, the odds are unlikely it’ll move again even if it could do a lot of damage.

We add up all those weights to calculate a priority and then pick an action based on that priority. We don’t necessarily pick the action with the highest priority – instead, we randomly pick an action, but the actions with the higher priorities are more likely to be selected. Obviously non-ideal actions can still happen, but it’s more likely the system will pick something better. This gives us our unpredictability.

Results and Future Work
The system isn’t yet perfect. There are edge cases that aren’t being handled gracefully. For instance, if there is only a single unit left to attack, sometimes the system thinks it’s more valuable to just move away than it does to attack. This leaves it possible for the player to gain victory over an obvious defeat. Some of this can be fixed by tweaking the weights on all our criteria, but some special handling will be required to be safe.

We also don’t yet account for special units – units which heal or which apply stat bonuses. These will introduce new edge cases and new weighting considerations.

Still, the AI is producing reasonable results. It’s moving and attacking and killing left and right. It’s taking reasonable actions. I can beat it every time (some of this is the product of immature level design), but it usually takes down several of my units on the way. I’m happy thus far with the results.

Hello IndieDB, I'm Brian!

I'm an NC-based professional game developer and part-time community college teacher. Been making games for about 15 years in some fashion or another.

My primary Tumblr is here. It's still pretty new; adding content gradually.

My current side project is a turn-based strategy game: Pixel Space Horror. I'm also working on a board game about running a town in a JRPG, but it's not *quite* ready to show off.

Trying to get more involved in the indie community. I don't know to what extent I'll be using this blog versus Tumblr versus other venues, but I thought I should at least say hi!