Uncanny Works

There’s not really much new stuff to visually show at this point, so no screenshots today.

I did get the turret shot count and cooldown timers setup as mentioned in my last post.  I broke the turret firing out from the gesture tracker since it’s internal cooldown was interfering with the user’s ability to fire.  Things now fire a bit smoother, and have a decent pace to them with the shot counts and timers in place.

I also received all the final ships and the mountable turrets from my artist, so I broke all those out and gave both the pivot and static turrets each separate firing abilities.  Shots now have kind of a rudimentary muzzle flare.

My plan from here is to look into ways to do lighting tricks against sprites.  My buddy Chris had mentioned using the sprite’s grayscale as a heightmap and then applying the lighting from the source angle up to a certain grayscale threshold.  This is a little high level for me, so I’m going to spend some time seeing how I can get it working with a shader.

Sadly I was not as productive as I had hoped today.  I was only able to knock out the firing mechanism for the cannons.

The current idea is that you can fire the cannons 5 times each, with a 1 second cool down per shot.  Once you use up all 5 shots the cannon then goes on a full 5 second cool down until it reloads and you can use it again.  The idea here is to give the game some kind of controlled pacing, and doesn’t wear the user out from flicking upwards so much.

Goals for tomorrow are to get cool down timers (numbers and/or graphics) on the cannons.  I’ll give the ship patterns and direction facing another look, but I think I need to nail the actual game play flow in general before I spend too much time on smaller details.

Today I have met the goals I set out yesterday by about 95%.

• Finish queue system.
• Tweak the spawn system so it spits out sets of ships.  Ties into the queue.
• Change the ship code so the ships play “follow the leader” in their chain, and adjust when a link in the chain is broken.  I ended up not doing this.  It was extra code for nothing, I can just make the ships follow the same pattern over time.
• Make it so when a ship blows up, it blows up the nearest N ships near it.  Ties into the queue. I didn’t need the queue here, ended up doing collider detection.
• Give ship chains different move patterns.  This mostly applies to fighters and bombers.  Frigates, capital ships, and the carrier will more than likely just move straight in with some possible variation.  The code here is in place, but still needs more patterns and refined a bit.

Here’s a shot of the ship chains, and chain reaction explosions.

Before I headed for bed last night a buddy of mine gave me some feedback on Eros.  I ended up tweaking (deleting actually) some stuff in relation to his suggestions, and assuming there’s nothing else needs changed I’ll upload some updates this week.

As far as Space Slash goes I added the last of the new ships I received from the artist, and did some low level coding today.  I decided that I need to write the object queue system sooner than later, so am currently in the process of tackling that.

Things on my immediate todo list:

• Finish queue system.
• Tweak the spawn system so it spits out sets of ships.  Ties into the queue.
• Change the ship code so the ships play “follow the leader” in their chain, and adjust when a link in the chain is broken.
• Make it so when a ship blows up, it blows up the nearest N ships near it.  Ties into the queue.
• Give ship chains different move patterns.  This mostly applies to fighters and bombers.  Frigates, capital ships, and the carrier will more than likely just move straight in with some possible variation.

Longer term todo list:

• Finish the beam laser graphic.
• Add engine trails for the ships.
• Add lighting effects to the ships so that when explosions occur or projectiles fly past they light up.

Things I’m still pondering gameplay wise:

• How to determine score multipliers.
• How to unlock what I am calling the “shape drawing abilities”.  Abilities become usable via timers?  Kill combos?  Kill counts?  Kill type kill counts?  Kill speeds?

The part I’m struggling with is, will it really be fun just flicking shots at ships and drawing special ability shapes to kill handfuls of incoming ships before they blow your base up?  Does it need more?  Maybe not strictly just a static base on the bottom of the screen, but according to your score over time the enemies push closer to your base?

My goal for the end of the day tomorrow is to at least get the queue system up, and enemies spawning and moving around in chains using various preset patterns.

This isn’t really day #1.  On the other hand it’s the first day I’ve diven deep into the new game project and am now on the path to release, so I suppose in that regard it’s true.

Today was spent working on trying to nail down a laser effect.  It’s taken me longer than I expected, but things are coming along nicely.

I ended up stumbling across this line drawing library for Unity3d today, and was immediately impressed.  I figured even if it doesn’t do what I want it’s worth keeping in the toolkit.

Here’s the result:

This isn’t by any means the final product.  It definitely looks a lot cooler while the sine waves are animating.  I’m hoping to get some glow/freeze/cloud effects, the core beam effect, and some light particles done tomorrow.

My trigonometry is years out of date, so it took a bit to get the relatively simple animation going.  It utilizes the library’s Spline line method, and simply animates the array of points the spline is built from.

Here’s an unrelated shot of the explosion stuff I did yesterday.

Now that Eros is up on both stores, I have to shift focus to my next title.  I was given a year, enough cash to survive, and a small budget in order to release two games.  I’ve blown most of my time on Eros, so I have no choice but to hunker down and knock the next game out before the end of summer.

In order to achieve that goal I’m going to try to make daily posts to this blog so I can focus and keep track of my development work flow.  I’ve decidedly aimed at making a much simpler game this time around, and focus on the gameplay first and foremost.

Here’s some shots of the ships my artist is making for me.

These are the enemy ships, there will be 4 more in the set for a total of 10 (I may variate them with sizes and shaders to increase that count).  The game itself is shaping up to be a new age take on the ancient classic Asteroids, and will hopefully have some fun and addicting gameplay.  Also:  EXPLOSIONS

I’ve built a touch tracking class to allow for arbitrary touch based shape drawing, so that will also factor into the gameplay mechanics.

Today’s goal is to experiment will various visual effects, such as lasers, lighting, ship engines, etc.

After half a year of development I’ve finally released Eros to Google Play, but to be honest my feelings are only somewhat bittersweet.  Visually I think Eros turned out alright, the artists who helped me out really made everything look nice.  The audio made by my buddy Ian Womack is also quite good, and lends itself to making the overall experience decent.  However, in the end what makes or breaks a game is the gameplay, and that’s where I feel I’ve failed.

I started with the idea of a space “tower defense” game, yet in the end Eros turned out to be more of a “space drama where you watch pretty things shoot.”  I’m not sure where I lost sight of the goal, or at what point the game morphed into what it is now.  Are there too many enemies?  Are they poorly timed?  Is the game as it stands right now more about collecting enough energy to jump, and not defending against all the enemies?

I’ve already received some feedback about a few things.  The tower upgrade “shield” button which toggles between primary and secondary fire for combat towers isn’t explained anywhere, so it’s function is completely arbitrary from the player’s point of view.  It had been commented on in the past and again by someone today, but the research tree is also another area where it’s not clear how things flow.

There’s no one to blame but myself for releasing such a low quality game.

That being said, there are some things that I’ve learned along the way.

• There’s many comments from experienced game developers saying “don’t try to run before you can walk”, usually in regards to wannabe devs talking about how they are going to make a next gen MMO.  They tell everyone to start small, and for very good reason.  Making games is hard.  I thought Eros was actually pretty small in scale, but in hindsight it was probably a little bigger than I could chew.
• Unless you are working on something really small in scope, developing a game solo in an almost vacuum like environment is a horrible idea.  Lack of immediate feedback, no idea bouncing, and no discussing what works and what doesn’t is ultimately what it takes to make a good idea great.  Sadly Eros had little to none of that.
• Never release a game with zero tester feedback.  If your testers don’t give any comments whatsoever, then increase the amount of testers and try to find people who will.  Most of them will probably see it as a “game preview” and not contact you, but you may find a couple people who genuinely want to help you succeed.  I’ve already got a few “I don’t get it”, or “Why doesn’t this work like I expect?” reports from people, which is a huge buzzkill.
• Having an artist directly on your team is better than contracting out people.  Unfortunately this doesn’t work for small indie devs, and especially if you barely have enough side cash to pay for your art work.  However, working directly with an artist can influence many of your design decisions.  Eros also suffered here, even though the visual style ended up being alright in the end.

Eros really needs to make sales to justify the time and money that went into it.  It wasn’t cheap to build, and so far I’m considering it a poor investment unless sales soar.  This could very well be release day apprehension, but I’m skeptical.

On the other hand Eros has prepared me for everything it takes to make a complete game from A to Z.  Hopefully the next game I release will be that much better for it.

Another unexpected thing I ran across which killed the performance on a smartphone was audio.  It dawned on me at one point that between all the shooting effects and explosions I was making around 120 audio calls per second, and was more than likely one of the reasons my frame rate was dying.

To smooth out performance I built an Audio Manager class.

This gets attached to an object in the scene (special or camera).  There is also an AudioChannel prefab which simply has a Transform and AudioSource attached to it.  I then have an AudioPlayOnce script which then takes the assigned AudioClip(s) and hands it off to the manager (among other things, like random clip play, random pitch, etc).  If a channel is free it will play the clip, otherwise it gets tossed out.

Audio that absolutely needs to be played bypasses the AudioManager and just uses it’s own AudioSource.

I was somewhat excited about finally getting around to building a development blog because now I can post the few little things I’ve discovered about using Unity3d along the way.  One of the more interesting things I had fun building was my object recycler.  

It turns out calling Instantiate() on a prefab creates a massive amount of overhead on a smartphone.  This wasn’t even remotely a concern of mine when I started working on Eros because I was strictly using the PC development environment from the beginning, with the idea that I’d start testing on a device once I had something worth looking at.  After I acquired my iPhone and Android development licenses the first thing I noticed after throwing a build on my phone’s was that everything slowed down to a crawl.  A bit of googling here and there about optimizing Unity for smartphones and I came across this well written blog which gave me some decent hints about what I needed to implement.

Queue System

When a new object is instantiated via the queue it either pops a recycled object off the queue, or instantiates a new one in the case that the queue is empty.  It has the ability to prime the queue with a pre-specified amount of Instantiate()’ed objects so that all of that happens during level load time and not while the game is running.  There’s also an object spawn limit parameter, with the idea that there might be a situation where a few objects still look as good as all of them being spawned (in my case explosions).

The main pieces of the system can be viewed here.  The first is the linked list for tracking and storing the objects.  Next is the core script which is attached to queue-able game objects.  The final bit is the queue system itself, which gets attached to an object in the scene (a special prefab, or the camera would do fine).  When a CoreBehaviour object is built it also contains a reference to the queue so it can spawn other objects, or despawn itself to the queue on destruction.

I’m somewhat torn about using strings as indexes due to the fact that they apparently have poor performance, but by the time I discovered this I had built way too many objects to bother going back and changing things.  I’m not sure how much performance I would gain anyways, but my somewhat uneducated guess would say not much at all.

A configured queue system object looks somewhat like this.

Unfortunately I don’t have the performance numbers in front of me right now, but needless to say this was an immense help in reducing overhead and making my game lag free on smartphones.  Having access to a Unity Pro license was also a large help in regards to debugging this and many other problems I encountered.  I’m not sure how people could release a smartphone action game without running it through the profiler.

The next system I’ll post about is my AudioManager, which addresses another unforeseen performance bottleneck I didn’t consider until later down the road.

Project Eros

Eros is a space drama tower defense-ish survival game being developed in Unity3d for both the iPhone and Android platforms.  The game is about 90% done, but requires a few bits of logic and interface tweaks to bring it to completion.  Release is scheduled for sometime in March.

The following are some screenshots of my progress.

There’s still a lot of things to finish.

• Tie rest of research logic into game.
• Calculate actual scores and credits earned.
• Build tutorial stage, and 20 game stages.
• Build survival modes.
• Polish stage select screen.
• Small little bits of game logic improvements, more sound effects, and more visual effects.
• Optimize texture atlases so they can run at full resolution on lower end devices without being memory killed.

Hobby Project

This is a little project I recently started on the side.  Basically it’s a learning process to mimic the popular Minecraft game, and hopefully create an end product worth using for a completely unrelated idea I have.

I started writing my own game engine in C, had cubes rendering, movement going and the like, but the sheer amount of work it would take to get things where I want is obscene.  Unity3d is truly a great engine to work with, so rather than waste my time on bare metal logic I’ve jumped to writing the system logic for my game world.  Even at this level there’s still a lot of things I haven’t considered, and each little bit increases my knowledge that much more.

I’ll post more about this project as things come up.  My main focus is getting Eros completed right now, but I’m the kind of person that has to juggle two things at once to move forward.

Here’s a screenshot of the progress.  It’s not much, just a few dynamically generated mesh chunks displaying the blocks they represent.