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.
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.
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:
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 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]
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. ..
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.
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.
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.
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.
They’re easy to implement and fairly lightweight, make a whole bunch of visibility / raycasting real easy and fast.
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.
Example: X-com, project Zomboid, old Gold box D&D games, the Sims
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.
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).
Complexity. Pathfinding, line of sight and collision detection all become significantly more involved, not necessarily slower, just more complicated.
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.
Time for a little progress update, eh?
Ok so some more sheep have been done but it’s time to assess the situation and get a firm grasp of where exactly I stand. But first a picture of the prototype tuckbox that the game will be shipping with (some assembly required)
Why Include something as silly as a tuckbox, when it will surely impact the bottom line One might ask. Well the answer is simple, with the last couple playtests it’s become obvious that the system of green tokens to track the value of the current place is massively cumbersome. So I decided to put in a little track sheet that you can just put a couple counters on to track the value of the current place as it is eaten. And the price difference between a 4×4 board and a board big enough to have a tuckbox to be cut out is negligible. So the tuck box is almost free.
But anyway… back to the current state of the game development process. So it turns out that 85% of the time it’s taking is art. That’s right. It’s taking much much longer to draw silly sheep than it is to creating the game and the cards and exporting them and uploading them and writing / editing the rules etc. etc.
Crazy eh?
As of RIGHT NOW, I have Drawn and Painted 60 of 125 sheep. Of those 50 have been placed into their final art location in the inDesign files that are the decks.
I have 65 sheep left to Draw, ink, and paint. A happy estimate would be that if I totally buckle down I can probably do a sheep every 2 hours, maybe a bit more. So let’s call it 90 min. So that’s just a hair short of 100hrs of ART work left to do. Not too terribly bad.
Other than that I probably have 6 hours of editing and tweaking on the cards’ text to make sure they’re clear and are easier to understand.
Then toss in the other little things like re-writing the rules and finalizing the web and packaging art, realistically it’s probably closer to 120 hrs of work.
That’s some really long weekends in my immediate future if I’m to hit my goal of having it launched by my birthday.
Time to buckle up, it’s gonna be one helluva ride to see if I can do this.
Well, some development progress.
The in-game map now reflects a proper mow branching randomly generated maze based on Prim’s Algorithm, the trickiest bit was adapting it to do without proper arrays Toquescript is a bit funny about that. After that, I created a basic start for a tileset etc etc and got it rendering properly in the engine.
Tonight I got the tilesets to properly interpret the door and trigger tiles and render the proper animated tiles for them (after creating said animations of course). Spent a little time trying to figure out why shooting seems to crash the game on the tile based level but didn’t get much beyond making it not crash.. but not showing the shots either..
So that’s the next step, and after that activating the triggers and shutting the doors to indicate the start of a wave of enemies.
On the webby front, some minor tweaks galore to the theme with some more changes planned. Over the weekend I put up the site www.wenderflonia.com for GFW and she’s putting it to great use already.
Well things are now settling down here on our new server.
Got a handful of old and new domains consolidated across the board and some nre goodies lined up.
Most notably would be the start of development on the dream wars. Got a good start on the dsesign spec and some of the data modeling up and running. It’s an ooold idea I had a long time ago but with the new png support that’s universal plus a bunch of new nifty ajaxy2.0buzzwordladen tools at my disposal it actually might be doable now. The biggest concern is how browsers support 3-400 pngs with 8bit transparency. I hope pereformance doesnt just suck.
anyway.. more layout changes and general tweaking still needs to be done all over the place. But it’s a beginning.