More Progress

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.

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]

 

Third Time tis the Charm

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.

 

Daily Progress update.

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. ..

Building Better Tools

So, basic progress is in swing.  There’s a bunch of stuff I can port over from the GarageGames Torque Game Builder version that I was working on, however, there are a bunch of things that I didn’t need then or just do not have access to in Java or just don’t integrate with Slick very well.  So with that in mind.. I’ve been digging  into Pre-Pre-Production.

To that end I’ve stated building a toolbox. Figuratively, of course.  Here’s a few of the silly things  that are a pain to write but very useful to have.

  • AssetLoader – based on the slick tutorial this little thing lets me have a loading bar on a title screen while the game loads every asset it needs.
  • OptionsController – manage loading and saving user settings and profiles for resolution, sound, and player name.
  • InternetFile / InternetString – for pulling a string (current version) or file (updated assets)  This makes keeping the user informed of latest news/ updated versions a snap.  Since Minecraft came out with an auto updater, it’s been glaringly obvious that at minimum having a latest version check is a MUST Have feature.
  • Movement Library – a pile of functions to take two points, and interpolate between them,given a method speed and time elapsed and whatever else that comes up.  I expect this to grow for some time.
  • ImageCounter widget – display a number with a series of images. Like hearts in zelda. Supports horizontal and vertical orientation, whole and partial increments etc.
  • Basic Image Button – yup it’s a simple little button made out of a bunch of images, it’s self contained and easy to use and change.
  • State Based Button – also called a modal button.  Essentially displays several options on a button bar and you can select one.
  • Text Block – an angelfont based text block widget , hand it a block of text, an AngelFont, and give it a max size.  It auto animates the display, pagination etc.
  • Text Entry – an angelfont text entry widget.  easy and simple..
and as I find things that would be handy in future projects I’m adding them to it.
So it turns out that making little widgets is actually really kind of fun.  Much like building the IrisEdit level builder tool that I’m using to build the levels.
And with those tools in hand, I’ve created the game Launcher / Version Checker,  Here’s what it looks like without the Launch Game button (it goes in the middle)

 

Tech Choices: Walls

Assuming you’ve decided to build a 2d engine for a non side-scroller you quickly come face to face with one of the biggest decisions you’ve had to make so far.  How are you going to represent the game world? Basically there’s two choices each with their own benefits and issues.  There’s the ‘Walls are a block’ approach where everything is a block and the ‘Walls are an attribute’ approach where walls are things that are part of a tile and appear on the edge of a tile.  Here’s a little Pro/Con info that I jotted down while deciding on which way to go for BSDDoD.

Walls are a block.

Example: minecraft, zelda This is probably the most obvious approach to building a 2d world.  Everything about the world construction is handled in a simple array of blocks letting you quickly build a map.

Basic implementation:

It’s essentially a lardge 2d array that contains the structure of the world.  With each location in the world represented by a number.  For pathfinding you can easily implement floodfill tests and even weighting the passability of tiles is pretty trivial.

Upside:

They’re easy to implement and fairly lightweight, make a whole bunch of visibility / raycasting real easy and fast.

Downside:

Aesthetically they’re not as nice/real looking as what can be achieved with thin walls.  Destructible walls are more unrealistic and the wall type is determined by the block that is the wall.  So if you want blocks with different wall textures you have to create and track many more entities. Windows are pretty much out of the question and doors tend to look a bit odd.

Walls are an attribute

Example:  X-com, project Zomboid, old Gold box D&D games, the Sims

Basic implementation:

Every game tile has 4 flags associated with it used for indicating if there’s a wall. This means that there’s a bit of extra overhead but it comes at some interesting benefits.

Upside:

Aesthetically having walls look like walls is a big bonus.  Also the ability to do things like have windows, half height walls, one way doors and portals is nice too.  Also the ability to have different textures for a wall regardless of whats in the neighboring tile is nice (but there’s workarounds for tile based maps for this as well).

Downside:

Complexity.  Pathfinding, line of sight and collision detection all become significantly more involved, not necessarily slower,  just more complicated.

What did I choose?

Well since I’ve got a bunch of the art assets already created for a straight on view, I eventually settled on the Block based walls with the Straight on view (right side of the image above).  Really that was the deciding factor.  The straight on Blocks as an Attribute would just wind up looking odd and I have no need for windows or doors since it’s essentially an arena based shooter.

For the next project I’m leaning toward an isometric Block based map, however with blocks being smaller than the characters, so that will give thinner walls and hopefully a more enjoyable dungeon building experience… but that’s still way off in the distance, percolating on the back burner.

Enchanting Cadence launched for Slick contest!

The Must do’s got done.

Several of the ‘Wants’ got done.

However Mac support looks impossible.

However, at this time I’m proud to announce It’s live!!!


http://www.enchantingcadence.com

10 levels. Java applet w/ facebook integration.

It’s been on helluva learning experience.  Will digest a few things for a bit and have a postmortem up before too long.

Will update with a link for voting once voting begins next week.

 

Elements

Whoo.. what a week.. not very much dev time, unfortunately.

I’m beat so I’m going to keep it to a short what got done list.. followed by a screenshot..

  • Bolt splitters are in and work.. (except for the rotation is a bit wonky)
  • the Level editor and Level group editors are almost done
  • The core applet is almost ready to parse all data from external sources.
  • Tweaks to some particles.
  • all the  Elemental nodes now are renderable in-game and have their proper graphics.

Here’s a screenshot of where things are.

And here’s the list of priorites for the week:

  • All the ajaxy and facebook <–> applet communications need to get wrapped up asap.
  • Player object for storing scores
  • back to level select button
  • more particle effects
  • SOUND!
  • LEVELS !!!!
  • and so much more!!! Yikes!

At this point I’m getting pretty nervous weather or not I’ll even make it to complete by the contest end.  Its looking like Some things are going to have to wait to be finished afterward..  Yeesh.. well.  hopefully the baby will cooperate and I’ll be able to get stuff done in the evenings this next week or two.. cross yer fingers.

 

We Have Gameplay

A couple of days late but much the wiser 🙂
Gameplay is now functional.. in that.. you can start a level and win it.

Here’a quick rundown of some of the new features.

  • The most important (that you cant see) is the new background simulation of the gameplay.  This ensures that bolts and enchantments are registered properly.. even if the framerate goes to hell.
  • Items are now fully enchantable.  They have a start and end state with misc metadata for use later on down the line.
  • The formula track represents the bolts needed to enchant properly.
  • We have a speed selector, this was a nice ‘free’ bonus of separating out the logic from the display.
  • Levels have names, a constructor and can be passed from state to state.
  • We have a text writer with a nice font.
  • Oh yeah more final artwork is falling into place.

Next up:

  • splitters.  gotta stop pushing that off.
  • rotator modifiers
  • sound for bolts when they hit enchantable object.  and to add a playback button on the formula. So you can hear the CADENCE of the ENCHANTABLE item.. get it?  I thought this stuff through eh?   That and it makes troubleshooting your placement easier.
  • The toolbox area needs graphics.
  • The dialogs need graphics.
  • placeables need graphics.
  • particles need gra… well you get the drift.
  • oh yeah.. more levels.

Wish I could take a week sabbatical to do nothing but this.. but for now a couple hours here and there is all I’ve got.

We’re halfway through the contest… and I’ve just now got the essentials done.. Looks like there may be some long nights ahead.

Screenshot Saturday

Good week!  Lots of nerdy stuff fixed and resolved.  Here’s the picture and more details in extremely nerdy speak below.

The biggest things that got done this week are :

  • applet -> javascript -> applet communications are now working.  Which is pretty awesome.  The biggest challenge was that sending outbound communications need to be triggered from a seperate thread to prevent the JVM from stopping and waiting for a response and that Inbound connections needed a custom version of appletGameContainer that exposes the StaeBasedGame object (more details on all of that can be found here).
  • More per puzzle gameboard abstraction, so now the gameboard knows what things are where on the board, this made implementing a board rendering based on the Y coordinates a snap, so things now appear in front of the things they need to.
  • The beginnings of a more robust image/particle manager system.
  • A passable Level Manifest.  A game Level can now be passed between the different Game States and (eventually) populated from the database via JSON jquery calls.

The biggest problem that popped up has definatly been the particle systems.  The slick ParticleIO.load(xmlfile) works great locally however on a deployed Jar it really grinds things to a halt.  This lead me down the path of trying .duplicate() on a set of master particles.. to no avail.. I also tried just loading them all at startup into a great big MagicBoltBucket… that worked but the applet startup went to ~2min  …

What I’m winding up doing (still in the process of) is a) have an image manager that loads all the images needed ONE time at init and passes them out as needed.   b) a great big bucket of pre-made Magic bolts that I can take and put from.   c) Create all the particle emitters programatically.

Not entirely done with that, but the intial tests have the Initial filling of the BoltBucket down to about 2 seconds for 120 bolts.  Eventually There’ll be about 400 bolts in the bucket at level init.

EnchantingUpdate

Not as much progress as I’d like, or on the bits that I’d like.. but that’s kinda how it works 🙂

Here’s the Screenshot and some more sordid details below.

Highlights of the week are:

  • Applet integration started.. The basic functionality now works in a web page
  • Mirrors  (and indeed all placeables) now ask and respond properly to queries about their facing
  • Lots of new particle effects on Magical bolts (trust me they look way better in action)
  • This lead to some serious stuttering issues when creating all the bolts.  This has been fixed by creating all the bolt objects at level init and just flagging them as no update / no render.

The big issues to tackle:

  • Java to Javascript to Java communication.  Because I really want to be able to send data from the database / facebook requests directly into the game.
  • An update glitch that causes bolts to not register hits with mirrors.  The solution to this is to just skip the ‘per pixel’ detection stuff and have the bolts just run a check against the game Board’s entity mapping table and see if the bolt is going to hit something and then find out if it needs to change it’s offset and direction or magic power type.     This is a bit of work, but the initial stuff is really just taking too many calls and calcultaions to be done if I want it to start checking for positions in between update calls.

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.

Facebook Slick Contest And More

So not quite a screenshot Saturday… how about a paper prototype pass?

A quick paper prototype for Something exciting

Does time fly or what?

So ‘Interesting’ stuff is happening

In a bizarre twist I’ve wound up having to dive head first into the world of facebook apps.  So I’ve made a couple apps.

First up is a Simple Level Counter for use in card games… Like Munchkin (though I’d recommend their mobile phone App for that.. it’s awesome)

Next up, is much less useful (for now) a proof of concept Swiftthought Demo app.   This is an actual Slick applet that’s running inside a facebook frame.  Now that’s got potential.

So much potential that I was looking for any excuse to give it a real go.

And then a Slick2d contest started.

So I guess that’s that.  Now I’ve got a pile of consulting work to get wrapped up by contest start of the 15th so that should work out just fine.  But I’ve gone ahead and started thinking and planning a bit last night, which is what the paper prototype is all about.

I have a couple family things to do this weekend but other than that it’s crank out website goodness 🙂 Pretty proud of it actually..

Screenshot Saturday

Managed to get the web editor exporting tileframe data nicely, and with a few modifications was able to get TGB to import the new map data and render the maps in the existing tilemaps.  🙂 yaay.

New tilemaps in Game Engine.

Now if I can only find out what makes it crash when you touch the mouse……

*scratch head*.. well at least it’s progress..

Oh and we have new and very awesome epic in-game music now from www.indiegraphics.net

So it’s  been a good week overall.

[Edit::]  Found the Crash.  it was to do with the checks for various player positions on the tilemap for shooting.  Which is totally obsolete, due to the new tilemap, so it was crashing.