Oops, meant to post last week’s Screenshot Saturday.
As pennance here’s 2 screenshots from the in progress Android game, that’s coming along nicely.
(yes Irismel is taking a little development break while I work on some of the mechanics in spreadsheet and paper form. The RTS elements weren’t working right. Now I’m leaning towards something a bit more Tower defensish)
Look its an Android application
So with an absolute lack of time to make any kind of forward progress until we all get settled into the routine of the new house, things are taking a little sidetrack from the ‘milestone milestone go go go!’ mentality for a bit.
That means two things.
1. Character sketches, concept art and little paper mockups. Ie anything I can do not in front of the development pc.
2. Tools development. Little things that I know I will be needing, but don’t need to be dependant on the whole application to function. Things like getting http://editor.irismel.com to export maps and support the little things I will need in my map editor, like monster spawners etc etc. Also all the little widgets (button classes, text dialogs and so forth) and asset & option managers that I plan on eventually releasing
as a standalone jar file to help other java Slick developers. I’ve got the javadoc of what I have so far up at iristool.irismel.com.
So lots of little things but no real time to sink deep into the development mindset for now. But I should have some pretty pictures and scribbles up before too long.
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:
And Here’s a new Screenshot showing some of the things that you can see:
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]
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. ..
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.
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.
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.
Well… lots of stuff really.
I managed to turn a paper prototype into a fully functional game in two months. Overall, game play grew and changed organically through the development process as low hanging fruit features were revealed. Taking a project from A-Z in Slick was very educational (which was the primary reason for the whole thing).
The facebook integration worked (albeit their documentation leaves something to be desired) for the most part seamlessly.
The back-end level creation and management web tools worked and the general process of back and forth data between the webpage and applet worked as anticipated..
The multi threaded stuff to send and catch javascript communications works and once the basic process was understood was easy to implement.
Graphics and Music. Visually the game managed to capture the look and feel that I wanted. I was able to work out an efficient workflow to take concept /programmy placeholder art and iterate it to the final art. No assets were lost and not a lot of dead ends or un-used art was created. Overall the music worked nicely as well.
It was a nice first version, however not something I’d call mainstream release ready yet.
The first three weeks were spent having the enchantment process be based off of what visually was happening on the board, this caused massive issues as framerates turned out to be really unsteady once the game was in an applet form. The fix was to have a logical representation of the game board where the simulation was run and then just have the rendering update it’s assets from the virtual model.
It turned out that applets have a massive overhead when instantiating any sprite as they check the applet’s remote filesystem path for the files. This lead to the implementation of a boltManager object which pre-creates 500 bolts and tosses them to the game logic as needed and returns them to the source pool when taken off the board. This fixed the issue .. until I added particles.
Particle systems create an image loading hiccup as above even if it’s pre-created on their first .render call. The fix was to change the applet call to isolate the applet from the webpage with <param name=”codebase_lookup” value=”false”> .. The downside is.. this effectively killed the idea of loading level specific assets from the website.. so suddenly everything needed to be included in the jar file.
Java <–> Javascript communications are paaainfully slow.
Gameplay wise, it reaaaally needs a tutorial level, ease of use features, and a better dialog box system.
Level design really did not lend itself to the whole 1-3 stars for each level completion. Usually there was just ONE solution.
Not enough time to build good levels. By the time I’d gotten enough features to behave stably enough, I had to cut several features and wound up with still only a week and a half to build all the 10 levels. (remember there’s a fulltime job, consulting work and family with baby who all come first) As a result several of the levels are pretty shoddy.
Applet communications don’t work in Safari on mac, and the game rendering doesn’t work in other browser on mac (but the communications do)
The primary reason for making this was essentially a way to motivate myself to finish a project and learn a crash course in SLICK and java. In this sense, this was a roaring success.
Perhaps it was a bit much to take on as my first real Java application… naaah.. just because I spent 2 days wondering why my string comparisons never worked. (even went as far as building enums and value catalogs to avoid having to compare strings) … then I discovered ‘string1.equals(string2)’ … sigh..
Applets are too restrictive to be viable. Pretty much every benefit of having a web program work in java (other than the openGL) is overshadowed by a downside. Heck just getting it up on the user’s screen means they’ve clicked through several very scary warning prompts. And if you want to do any kind of network communications behind the scenes (bypassing javascript comms) means asking people to punch holes in their firewall rules. All of which make applets un-usable for general mass consumption. JNLP’s seem better but they’re not very user friendly.. (they don’t ask you where you want to install.. let you know you need to un-install etc..)
In the future I’m leaning towards wrapped jars into exe files for Slick and java applications.
Thank goodness this was a 2 month test project, eh?
SLICK is a lovely codebase and java really is a dream to work with. Any concerns I had about java being slow or whatnot really have been blown away. If I un-meter Enchanting Cadence it easily runs at several thousand FPS. Actually it runs so fast that the math behind the simulation can’t measure the time between cycles correctly and it all falls apart. (that’s pretty cool)
The SLICK community and the java-gaming.org guys are really helpful and there is a wealth of tutorials and training out there.
Full on crunch mode.
Progress was excellent this weekend and the core gameplay , saving scores, dialogs and all the ajaxy interactions are working. Bugs… however… bugs and edge cases abound..
Other than that, I’ve got a pile of assets to generate.
Add to that a bunch of actual gameplay tweaks.. It’s a bit too hard… and way too hard to determine what went wrong when you mess up the formula. I’m still not sure how to fix that yet…
