Finally closed on a new house so it’s going to be quiet around here until mid Feb when I’ll have settled in.

Then it’s time for a facelift to the site and some exciting project work

Just some Random Sprites I was playing around with while eating my leftovers at lunch. No real planned use for them just practice.

Happy Holidays.
Tons of family fun was had and much food was eaten and celebrations were celebrated in glorious style.

However, we’re leaving 2011 behind with an impending close and consequent move to the new house in the next 45(hope hope hope) days and a 22month old with a broken leg. So I’m just going to abandon any pretense of having ‘fun project’ time untl March 1. (outside of any lunchtime coding I can squeeze in)

This totally sucks but, alas, is unavoidable.

Catch ya on the flipside..

So while it’s only 2 new tasks complete, there’s 2 more that are 80% there and others are planned out.

Here’s a recap of new stuff:

• PCs and monsters now shoot and damage each other with functioning ranged combat!
• PCs can die!
• Monsters can die!
• Monster spawner behavior is 90% there
• PC equip-able items / attacks are close to being there.
• New portraits are almost done.. then we’ll have 3 different PCs
• Project title finally announced:

• Project has it’s own Website http://www.irismel.com (granted for now it’s just an import of this swiftthought.com RSS feed.
• Irismel is listed over at http://www.indiedb.com/games/irismel-the-silverlake-chronicle
• Swiftthought etc has proper Desura / indieDb accounts made for eventual alpha release.

And Here’s a new Screenshot showing some of the things that you can see:

Minor but important progress. Holidays (and Skyrim) were not as conductive as hoped to progress.

Map entities (monsters and PCs) now scan for the nearest visible targets within their field of view and as within LOS on the level map.

Monsters now have a new behavior available on spawn which is to start stalking a Random PC.

The goal is to have several behaviors available for monsters to utilize what cna be mix and matched during levels.. (patrolling.. random walking, waiting,) and then have events and triggers switch them out asin-game events etc..

Next up.. either monster spawners or starting the prep work for combat mechanisms.

Good progress.. A little slow.. but progress nonetheless.

PC icons (as seen below as the Tokens with Wizard faces on them) can now be selected, and told to move to proper spots on the map and assigned a facing location.

Also good progress on the whole monster spawner Behavior.  Still some thinking to be done on how to do some of the details but I must say it’s really nice to be making tangible progress again.

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]

Well I’ve been hobbling along on a crippled system for a couple weeks now. My SandyBridge system motherboard got smacked with the defective Intel drive controller and before you know it I’m having all sorts of problems. So dev work is pretty limited.. I should know about getting a RMA in the next day or two (according to MSI’s website.. so I’m not holding my breath)

Other than that, consulting work has been a steady stream of little projects helping a client get ready for a couple tradeshows. So that’s been nice.

Add in a handful of general household stuff and you have pretty much a perfect recipe for exhaustion.

October is looking good though, and I’ve got some more stuff jotted down on a design doc, ready to be implemented.

Yesterday was a down right beating and tonight is pretty much just simple recovery.

I got some basic Tool Tips in place for the various pc heroes health bars ,functions to manage and intialize them  and some general cleanup and organization of the whole game and level initialization process.

You know, it is kinda odd how many game tutorials, engine demos, books on programming etc etc that totally ignore the fundamental importance of getting the foundation right.  The basic core logic, update loop, memory management, debugging, maintaining player data integrity and all those un-glorious details even though utterly essential get just a few words here or there.   The best book I’ve found that goes into all those nitty gritty details is this Game Coding Complete,  By Mike McShaffry.. some of the content is out of date ,but oh my god .. it covers all the icky dull essential things that you NEED to know. [edit.. I only have the 1st edition.. he's now on the 3rd]

Now a Lot of us are using 3rd party engines these days… (‘Im using TGB, Slick and flash mainly) .. and it’s easy to shrug it off thinking that it’s ok to rely on the engine to make the decisions about all the nitty gritty and dull as hell details.. and for the most part you’d be right.  However….  When it breaks, or you push it too far, or you try and do something ‘not according to best practices’  and you’re lucky enough to have access to the source (thanks GarageGames and Coke&Code!) you can understand HOW it works and how you want it to work and arrive at a functional compromise.

Anyway I’m straying from the topic at hand and I’m still trying to formulate the whole ‘Why you should build your own engine and never use it’, blog post.

So consider that a preview of sorts.

Oh yeah and I knocked out another GUI mockup.

Ok, needed a bit of a fresh mental break from typing and numbers for a day or two so I started the beginning of the large pile of character protraits that I’ll need to make (somewhere between 10 – 50)   That’s the joy of doing things as an indie developer.. I can put on whatever hat I want to today.  Granted at some point I’ll have to put on the businessperson hat and then it’ll not be so much of a joy.. and when time comes to put on that 400lb steel and barbed wire hat labelled accounting I’m sure it will be no fun at all.  But today… today I’m wearing a paint spattered cartoony beret.

Oh and I also got a large chunk of the UI implemented.

Looks a lot like yesterday’s post?  Well it should.. except this one works and lets you scroll the map etc etc.

I know… updates two days in a row??!  What madness..

Manged to get A* following objects to automatically turn and adjust their facing while maintaing their portrait’s orientation.   Also increased the basic map tile size by one so things aren’t as cramped.  The remainder of the evening was spend working on the following Mocup UI:

As you can tell I’m targeting a baseline 1280×768 resolution.  (obviously.. doesn’t everyone count the pixels on every image they see?)  The different thing is that designing for widescreen (6:9 / 6:10) and then making it work in old school 4×5 instead of doing it the other way around, lets you make some design decisions that you usually probably wouldn’t do.   With Widescreen you can essentially forgo the old L shaped UI frame and just settle for a thicker | shaped sidebar.. and still have plenty room left over.

I think we’ll be seeing more and more of this as the old 4×5 proportion fades into obsolescence. ..