Year: 2011

Posted on by

Yaay Death and Stuff

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:

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

Posted on by

LOS Targeting

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.

 

Posted on by

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.

Posted on by

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]

 

Posted on by

RMA / Small jobs

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.

Posted on by

More UI work and little things

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.

Posted on by

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.

 

Posted on by

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

Posted on by

The Fall Season!

Whoa.. after what feels like an absolutely morale crushing infernal heat wave that has more or less sapped all willpower for the last several months… it’s time to get the show back on the road.

Here’s a peak at what’s been worked on.  More details as soon as I get more gameplay things put in.  And after a break to Javaland  it’s back to good ol TGB.  The upside is that things make so much more sense now.   Many more thoughts on the matter later on.

Posted on by

Not Dead

Nope not dead, or forgotten.. just trying to survive the heat.
As it turns out, today, the day when the temps didn’t reach 100 for the first time in 40 days I finally get the initial map renderer working.. and it’s very good news.. The FPS hit on rendering even in full 1920 x 1280 is almost negligible.
So to celebrate.. here’s a screenshot!

Posted on by

Bits N Bobbins

Short post on progress things.  Things have just been lots of grunt work and non pretty things.

Will have things to show real soon.

Honest.

  • basic player object ..er.. exists and rotates properly.. mostly.  need to knock out some better test sprites and stuff to be able to make things actually ‘work’ together, but the fundamental concept of 8 direction independently moving head, torso, arms, lowerbody seems to work and will look pretty cool.
  • monster entities can be spawned and basically kept track of.. no AI or whatnot but still it’s a start.
  • Implemented basic box2d physics for player and monsters. this will have all sorts of fun payoff later I hope. Force waves, shapnel etc 🙂
  • Got the macro tiles wired for a* pathfinding.
  • Got the World generating a Maze and then replacing it with matching macrotiles that randomly match the exits of the cell.
  • started on map rendering
  • camera instance screen objects so I can have a smooth moving controllable camera that chases the player.
See.. lots of neat stuff… however nothing that you can actually look at other than a bunch of  diagnostic log output.
Performance wise it seems to be running at ~240 fps on the low end test machine and ~somewhere over 3,000 fps on the new machine.
So I might need to add in a ‘laptop’ mode which disables the whiz bang pretty stuff I hope to get put in.
and damnit .. http://www.garagegames.com/products/torque-3d the introductory price will be ending soon.
So I’ve got to grab that soon.
Posted on by

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)

 

Posted on by

Setting sail against the winds of whim and staying the course

Wooosh… that’s the sound of another gale force great idea blowing around.
Yup, they’re pretty much everywhere at this time of year. Annoying, persistent, unformed, and generally really exciting!

The thing is, they’re always much more exciting and enticing than what you’re doing ‘now’. Especially if what you’re doing now is rewriting something you’ve done before, in a new engine. In the last 3 weeks I must have changed my mental description of what I’m working on half a dozen times. Each new project, idea, or whim is a terrible distraction that’s so much fun to just dive into.

Because for me the best part is the initial rush of putting ideas and framework into place and start various parts gestating. So when I haev nothing but a couple months of grunt work (asset managers, re-inputing pathfinding algorithems, importing graphics, dealing with text input etc) it is so easy to want to start over and tackle an enticing problem and find out how various systems would interact.

Hell, at this point I’ve practically convinced myself to ditch BSDDoD! and hop into making ‘Irismel’ – the fantasy village simulator instead.  I’ve even started making some basic tiles and mock screenshots.

That’s gotta stop.

It’s time to get excited about BSDDoD! again.  So I’m laying off the big coding for a bit and painting some assets, concept art and visually interesting things.

The upside is that I’ll have things to show before too long and I can get the show back on track.

I am, however, thinking of changing the title from Blood Soaked Deadly Dungeons of Doom! to something more palatable and url worthy.

 

Posted on by

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.