January Postmortem

Going to keep this short and sweet, can’t stop and reflect too much.

What went right:

  • Web editor –  having a web editor where I can make changes and just re-launch a level for testing was incredibly useful
  • Music – the non repeating drumtrack for in game music works really well wit the musical queues
  • Title screen fire – Damnit particles just make me happy.
  • Pathfinding and combat –  while it’s not the most dynamic combat (see what went wrong) it’s fairly well balanced.
  • Flexibilty of code – adding new UI elements and restructuring how combat works 4 days from launch and not a glitch.
  • Game website – Im really happy with the new http://www.drakkheim.com website.

What went wrong:

  • World rendering – having to re-write the world map rendering took a whole weekend of progress and as such required that things like traps, and ranged combat got cut. no Elves or Kobold archers.
  • Fun – the last minute changes to combat really improved the moment to moment gameplay elements, but really it’s not something you’ll be playing over and over.
  • lack of animation – lack of variety – essentially more time to create art assets would have been really nice.   I have a feeling this will be a recurring theme.
  • Broken analytics –  I totally messed up and forgot to install analytics on the website until 4 days after launch.. so I have no idea if anyone has even played it.

That’s it for now.

 

Stalls, Inertia and Progress

I’ve followed a ridiculous amount of indie and small developer projects over the last couple years and watched them just peter out and vanish into the ether.  Hell, I’ve started quite a few that have gone the same way.. unfinished paintings, games, websites, etc.  So why does this keep happening?  What can we do about it?

Well.. It seems to be all about preventing Stalls and building Inertia to make manageable Progress.

Stalls

By ‘Stalls’ I mean it literally like a plane..  Sometimes projects get caught up on a glitch, bug or feature that is unexpectedly problematic or simply a massive chore to complete.  Then the motivation to work on it stops being fun and an awful lot like work.  That’s not a problem if it’s your day job, you can button down and just work through it, but for the indie developer who is doing this in their spare time, once development stalls everything else starts looking more and more interesting and exciting. The longer the project remains stalled the stronger the chance is that the project is going to crash and burn.

So here’s a couple thoughts on recovering from when your project seems to be stalling and the enthusiasm is waning that seem to be working for me.

  • in my task list, I keep several parallel development tracks.  So if UI development gets bogged down, I can simply just get it to a basically compiling state and hop over and work on something else in the project, like art assets , AI or path-finding.
  • but sometimes you just get sick of the whole project.   If you’re like me, you keep running across things/tech you want to try and work with, so keep a folder/binder/google doc around where you can jot down ideas for short exploratory exercises however it’s essential that they pertain to some shared functionality with your ongoing project.  So give yourself a day or two to work on it (like making a demo with a new api or skinning a UI library or something) Then force yourself the next day to IMPLEMENT it in your current project.
  • but some times you simply have to force yourself to sit down and bite the bullet.  Schedule some time, get away from distractions and simply sit down then work through it… yeah sounds stupid, but the ‘Schedule some time’ part is what makes this the hardest approach.  Which brings me to the next problem

Inertia

The fact that this isn’t a dayjob for many indies it means that life can sometimes turn the smallest molehil into a mountain, because Everything is a competition for your time, and the rolling rock of your project can’t go uphill very far on its own.  So we need to build up momentum in our project, make it feel like it has got a life of its own or decrease the amount of work it takes to get it rolling again once it comes to a complete stop.  Because, your time is precious and limited (even more so when you start having to work around a family life and maintaining a home) I tend to lean heavily toward the second approach, decrease the amount of effort needed for the next milestone.  I can imagine that the first approach would work well if you have a small team where everyone is all rushing forward together, so when one person stumbles the ball keeps rolling along and lets them catch up after their personal disaster has passed.  However I’m just me by myself so my tips lean toward:

  • Get your project compiling as early as possible.
  • Add basic core gameplay as soon as possible.
  • Build you milestones on that and make them each a standalone ‘functional’ improvement.

Because, sooner or later, something is going to come up and you’ll have to step away from your daily progress for a week or two, like children, broken computers, holidays, family vacations, household chores etc etc.  And when you come back to having time to work on your project you gotta hop back on the ball and be able to easily see where and what to do so you can get to that next ‘hey I’ve made something cool!’ moment and prevent yourself from stalling out.

Progress

Progress is king.  Progress also doesn’t like being kept in the corner. Getting your project to a point where you can shout out about your progress, via tweets to #screenshotsaturday, self serving blog posts like this, friends and family on Facebook, myspace, g+ or whatever is essential. Take pride in your progress. Get used to practicing saying in public that you’re working on something, have made progress and show it off.  Make it real to you and it will be that much harder to drop when the new toy sheen tarnishes and you have to spend a week debugging the text editor.  It seems almost impossible at times and the odds of actually finishing something really are stacked against you but it can be done.  And with great success.  MinMax did it over a period of two years,  CokeAndCode is doing it, RampantCoyote has done it,  all of them with keeping a dayjob, family and real-life’s responsibilities.

I hope to do it too.

[deleted a bunch of excuses for my lack of progress.. lets just chalk it down to life’s little mountains]

 

Three Days

Three days.  That’s not a whole lot of time left.

The list of cut features is growing on a daily basis, and new incidental bonus things are beginning to crop up.

New Stuff:

  • Music!  makes a world of difference
  • New website area and working Facebook integration
  • 4 final levels (6 more in development)
  • new backend tools for tweaking text wrapping issues
  • new bolt particles and images and tweaked effects
  • improved dialog for failure 🙁
The Must Get Done List:
  • more levels
  • three tutorial dialogs (timing, prisms, advanced prisms)
  • signed jar
  • button noise issue
  • success dialog and information dialog images
The Would be Really Nice To Have List:
  • the final enchant tick fix
  • collision enchantment graphics
  • better /more sounds
  • Mac applet support (pc only for now )
  • emitter hover path highlighting and count to impact for making adjusting timing much much easier.
The Not Gonna Happen List:
  • Loading Objective images from site instead of in jar
  • Standalone App
  • Further FB sharing & Integration for wall posts.
  • Many more levels
  • More placeable types (triggers etc)
  • better level editor that lets me edit saved levels.

Screenshot Tuesday

Ok, so last Screenshot Saturday slipped by in a haze of yardwork, cleaning and taking the baby shopping at Ikea and other general domestic goodness.

But better late than never, eh?   So here it is:

Enchanting Cadence Screenshot - week 2

Yeah.. Looks a lot like the last one, right?

Well, so it’s all still placeholder 20 second photoshop art, but here’s the rundown of the basic stuff that now works.

  • Magical Emitters exist.
  • Everything has a facing direction and is aware of it.
  • Emitters can shoot MagicBolts.
  • Magic bolts can bounce around off of mirrors.
  • Things are a bit more objectified and things like placeable and object manager entities are starting to do the stuff they need to do.
  • The game is either in editing mode, or enchanting mode (ie when  you get to watch things either work or not)
Next up:
There’s a couple consulting tasks to wrap up in the next week or so hopefully so that’s going to take a bit of the dev time But here’s what I’d like to have working for next screenshot saturday.
  • Be able to rotate mirrors in edit mode. (right now it’s hardcoded)
  • Have functioning Splitters
  • Get a basic enchantable object that can start to track its requirements for success
  • Get Energy changers put in place
  • Have bolts die if they leave the board.
Overall I’m happy with the progress  however I can easily see how all my plans are going to mean the 2 month deadline for the Slick contest is going to be tight.

Mutant Sheep Balanced on a Razor’s Edge

Well as promised, here’s a recap of the weekend’s playtesting. It’s gona be a long one.

The good:

It was amazingly fun.  A bit unlike other games, the going strategy seems to be hording your cards in your hand until you can twist the game in your favor, which seems a bit of a hard concept for Parker to grasp.   Really, even the two player game was a lot of fun and not totally skewed which was one of my big concerns.  It was fun for all of us and the base mechanics and strategy work exactly as I imagined they would.

There was a slight issue with the print of my cards, but the super responsive guys (JT) at TheGameCrafter.com explained the issue and how they were going to have the issue rectified well before I finish up for launch.   So no worries on that front.

The colors looked great and the quality of the cardstock is very nice and they shuffle well.

beta1-gameplay

The ok:

Lots of typos and little phrases that need to be tweaked and made into english.  I got some great feedback on the rules on the little bits and pieces that I assumed the player would know.  During the games we played over the weekend I got a dozen or so cards whos’ verbiage either needs to change or simply be clarified as the ability didn’t make as much sense as I hoped.

The instructions need to mention a couple things about adding Event location points to the size of the current area, but that’s minor.

The eh:

This is probably the biggest list of issues that came up, and the good thing is that they are all fairly easily correctible.

The timing of when you can use side effects and sheep special abilities is not clear and some cards contradict each other.  The usage of Blue (sheep is stunned/busy/incapacitated) tokens was not consistent.  These are essentially just going through and making all the cards agree and putting it in the rules.

Keeping track of mutation abilites  and side effects can become a bit of a slog.  Cleaning up the timing and usage of abilites will make it easier.  Additionally I’ve decided to add a card case which will leave me with a board with some spare space where I can print out some tokens for things like keeping track of the Hairless sheep (yes, its a serious issue when the blizzard shows up)

The massive number of tokens for large events (we easily had some places in the mid forties ) makes it hard to see exactly how much landmass is remaining in the location to be eaten (which is how you get victory points).  This makes planning things 2 or 3 turns ahead extremely difficult.   This will be remedied by cardboard tokens with numbers on em.

There need to be more side effects with a variable range so you can tweak the total amount eaten by your (and other player’s) sheep a bit more easily.

The Uggh:

Late game balance is a bit out of whack.  Not in the sense that it’s once sided or anything, just that once each player gets 5 or 6 sheep out and a couple mutations on them there’s not much you can do to stop them from devouring a whole location per turn.  So the amount of luck to winning goes up as the game goes up.   The good part is that this is easily fixable by a combination of minor tweaks to the game.  We’ve got three major tweaks that we’re going to be testing indiviually and in combination.  1. Make Side-Effects permanent.  This would let you permanently alter yours and other player’s sheeps appetites.  2. Increase the size of the smaller locations so they last longer.  This would potentially slow the point acquisition of the early game but make the endgame less luck driven.  3. Increase the bonus/penalty that Side effects give.

The Yay!

That’s it.  The game was fun, and with a bit more testing I’m sure we can get the balance of endgame to luck worked out and then it’ll be awesome!

Ok that’s it for now.  Further updates to follow but for now I’m just painting sheep like mad!