Skip to content


Weekly Development Update #6

This is gonna be a short one. I didn’t do much development this week at all, but the work that I did do on Friday was very satisfying. The camera, movement systems, and user interface systems are all implemented, bringing the project to feature parity with the pre-Ogre version!

I’m finding that putting development off until late at night is a terrible, terrible idea. By then I’m often tired, distracted, or otherwise preoccupied, and the work simply does not get done. The main reason I’ve been putting it off that long is because I try to work “normal” hours at my day job. However, since I work from home and control my schedule, I think I’m going to search for a time slot that works better, earlier in the day. Given that my job is ending soon and school starting, a time block that fits with my class work is best. With luck, it’ll be easier to motivate myself to work when I’m lucid enough that I’m not ready to collapse!

Posted in Game Development, SPX.


Weekly Development Update #5

This one is going to have some holes in it, but this was ultimately a good week. Lessons learned, progress made, etc and so forth. Without further ado:

Wednesday August 18th

First time this week I’ve had a chance to work on SPX, but I FINALLY fixed my issue… turns out that I was creating my ogre window and updating it in different threads, which screws things up. I also got my precompiled headers set up, DRASTICALLY shortening compile times. I am a happy man.

Friday August 20th

Didn’t get into any code today, but I am working on a detailed development plan that I can follow for the next week or so. I’ve been thrown off track by work commitments and that godawful bug I was struggling with, but now it’s time to get moving again. My main priorities, going forward, will be to rewrite the rendering, input, and camera systems, in that order, to achieve feature parity with what I had before the engine port. Afterwards, I’ll begin focusing on making a game prototype.

Saturday August 21st

Started trying to implement graphics. Most of my time was spent on the architecture for managing graphics assets. Nothing to show… yet.

Sunday August 22nd

Eureka! Finally have something to show! Temporary ship graphics, and everything is working again!

Okay, so apparently I’m an idiot.

In the process of switching to Ogre, I made a few game architecture changes without testing them in order to adapt to Ogre’s way of doing things. All this time, I was assuming that the actual game was still intact under everything, but between getting the client and server threaded and altering how the frame-to-frame updates were being done, I cocked everything up. The server was quitting because the client thread hadn’t had time to start running yet, and none of the game objects were updating because the change to the updating cycle meant that the "currentFrameTime" wasn’t being calculated anymore. Both of these were one-line fixes, but I spent a huge amount of time trying to figure out if I screwed up the game OR screw up on the Ogre port, when I could have focused on tracking these bugs down.

Lesson learned: in any large overhaul, do whatever changes you can without breaking the system FIRST so that they can be tested, THEN start breaking things.

At any rate, I can start moving on to other aspects of the port. Once input and camera control are back in, it’s over and done with, and I’ll be able to start working on turning it into an actual game!

Posted in Game Development, SPX.


Weekly Development Update #4

Time for another weekly update, but I’m not going to go with a day-by-day breakdown, since I’ve been struggling with the same issue all week. My window is being tagged by the OS as “not responding”, despite the frame function and the windows message pump being called regularly. I’ve posted to the Ogre3d boards in hope of help, and messed around on my own attempting to isolate the cause, but I can’t see anything in my code that differs from the Ogre test app I wrote except that the update loop is now in its own boost::thread.

I’m going a little bonkers, but them’s the risks when you start programmin’.

Posted in Game Development, SPX.


Weekly Development Update #3

I was much better about keeping logs this week. Starting to get into the daily development habit, and about damned time.

 

Monday August 2nd

Started delving into Ogre tutorials. At least on a basic level, the library appears very straightforward. It’ll be interesting to see how complex it is to work with in the end.

Tuesday August 3rd

I think I’ve got enough of a handle on Ogre to really begin porting SPX over in earnest. I’ll start by splitting off a branch in the repository, as a precaution.

The major sticking points in the port are going to be changing the game to wait for frame and input callbacks, switching from SFML’s Vector2f to Ogre3D’s Vector2 (which, hopefully, will just be a rename + removing the helper functions I needed to write to make SFML’s Vector2f class usable), rewriting the camera system, and rewriting the graphics code. It’s fortunate that none of these tasks seem too herculean on their own, but it’s going to be a while before the game is back in fighting form, as it were.

There’s also the issue of the file structure of the project, which the necessary Ogre files will need to fit into. I’m only including DLLs, libraries, and includes, so that’s fairly straightforward, but I suspect I’ll need to juggle it a bit until it’s something I’m happy with. It’s a good opportunity to rethink the file structure, though, so I’ll make the most of it.

Wednesday August 4th

While it was inevitable that a port of several thousand lines of code to a new graphics engine would cause snags (the act of ripping out SFML and replacing with Ogre has left me with 164 errors and no functioning program) I’m finding more issues than I anticipated (which–in a line of reasoning doomed to go in circles like a merry-go-round—is exactly what I anticipated).

For starters, Ogre3D redefines all the STL containers into the Ogre namespace as structures with the original STL templates as members, which is something that I find utterly mystifying, since it isn’t even retaining their interface. The lines "using namespace Ogre" and "using namespace std" results in a lot of ambiguous symbols that the compiler feels obliged to choke and die on. I can’t think of any reason why this would be done, save driving me nutty, so if anyone can enlighten me that would be appreciated!

At any rate, it’s high time I got rid of the using namespace calls anyways, they’re bad form, and there’s only a few places where the extra characters are more painful than the potential errors… those can be dealt with using typedefs to get rid of the namespace.

By the end of the day I’ve gotten to the point where there are no compiler errors. I had to gut all the graphics code, and there isn’t a WORKING piece of software, but it’s a good position to begin Ogre implementation.

Thursday August 5th

Unexpectedly, the switch to Ogre has necessitated a change in the main() function. I previously ran two separate GameManager classes on the same machine in a serial fashion, but the way Ogre handles frames (hit go, wait until it returns instead of hit go, then run an update loop) means that I needed to put each of those classes in their own thread. This was the eventual plan anyhow, so it’s hardly wasted effort, but it did require me to do some research. I had to learn the boost::thread library, but it’s a fairly straightforward piece of software and I’d been meaning to learn it anyways. Hopefully the process of threading won’t bite me in the ass.

Friday August 6th

Finished off the Ogre initialization code… kinda. Crashes when OIS (Ogre’s Input System) loads, need to find the source of THAT error. Haven’t been able to figure out if the threading works as designed yet.

Saturday August 7th

I’ve got a window rendering, and the threads all seem to be cooperating. It’s now a matter of getting basic functionality back into the game so that I can move forward from there. However, the program currently crashes with OpenGL, so that’s a point of concern. However, since I can run with DirectX, it’ll do for now.

Sunday August 8th

Basic input functionality is in. Mouse moves around, application quits when you hit escape. Not perfectly happy with the mouse behaviour… it’s locked to the window, so you can’t click anything outside it, so that will need fixing. I’m also running into strange issues where it won’t receive mouse inputs if I run it without the debugger active, but it WILL if I do, so I’m going to need to dig into Visual Studio and figure out exactly what changes when debug mode is on… the configuration hasn’t changed, so it’s executing the same code.

I did, however, spend much of the day struggling with an error caused by erroneously linking to the debug dlls in the release build. Talk about a dumb mistake… lesson learned: doublecheck that release AND debug builds are both properly set up!

 

That’s it for this week. If anyone is actually reading these, it’d be great to know if the format and content of these logs are at all interesting. Let me know in the comments!

Posted in Game Development, Game Systems, SPX.


Weekly Development Update #2

Slightly delayed, because I am easily distracted by Starcraft 2 and shiney new graphics libraries.

What I’ve found this week is that I haven’t been very studious in terms of keeping this habit. There are extenuating circumstances, but it’s best not to use those as an excuse. Going forward, I need to make daily work more consistent.

Continued…

Posted in Game Design, Game Development, SPX.


Weekly Development Update #1

One of the problems with hobbyist game development in your spare time is that it’s easy to become distracted. There’s no shortage of other tasks that need doing, or ways to find excuses to avoid a piece of tedious development. It’s not uncommon to suspend development for weeks or months at a time if enough is going on to serve as a rationalization.

This doesn’t serve my purposes. Every day I spend not working on game development is another day delay on me doing it professionally. It’s imperative to be working every day, to make it habit.

As such, I’ve resolved that I’ll do the following:

  1. I will make one commit to the source repository each day.
  2. I will keep a log of my progress and design decisions, and post it on a weekly basis.

“One commit a day” is a nice metric to use. It gives me a lot of flexibility as to the size of the commit, but it’s also very easy to measure and very clear as to what I need to make a daily habit: I have to make progress—any progress—on my code daily. Because the metric is clear, it’s very easy to turn into a habit. The weekly update is a little harder to make a habit of (this first one is already a little late), but is nice as a way of making me keep good logs of my work… and giving me content to post on this blog!

Yeah, I’ve been bad about that lately, haven’t I?

At any rate, I figure I should start by outlining the project I’m working with at the moment. The project is using the temporary name “SPX”, an acronym I can’t even recall. It’s completely utilitarian in the sense that it’s meant to be convenient to refer to but not something I might get attached to. The basic concept of the game itself is a 2D, multiplayer top down strategy game set in space revolving around a single large capital ship, its weapon systems and its fighter craft. The specific details are completely up in the air, since the actual kind of gameplay that will be involved is going to be fully explored only once a working prototype is available to tweak, but it will involve huge, heavily armed vessels blasting holes in each other with space-age weaponry.

On the technical side, the game is using SFML for graphics, input, and sound, and RakNet for network functionality. SFML is a library that I was unfamiliar with, but which looked full-featured enough, and RakNet is something I’ve worked with before (and found to my liking). Both libraries are free to use and multiplatform, which are useful aspects to have!

But enough about that, on to the logs.

Continued…

Posted in Game Design, Game Development, SPX.


RUSE Impressions

So, RUSE, the upcoming RTS from Eugen Systems, has an open beta on steam. Me, being all for the playing of freely available and frankly awesome looking games, took her for a spin. And I’m loving it.

And no, as much as that sounds like a sales pitch, they aren’t paying me to say that.

Now, for those who aren’t familiar with the game, a brief overview is in order. It’s a strategy game set in WWII, with a rather impressive scale. You can look at the whole battlefield or zoom all the way down to infantry fighting their way through a town, and the engine scales between the views much more elegantly than Supreme Commander ever did. The game’s main hook, as you might guess from the name, is misdirection and surprise, and boy, are there ever a lot of opportunities for that

I don’t play a lot of RTS games these days. Often, I find that I just don’t have the knack for it. Too many rules or relationships to memorize, or the whole thing is so micro heavy and my goldfish-short attention span too limited to keep up. I would generally spend more time managing an army than engaging in actual… I dunno, strategy? RUSE is a very different kind of RTS in that respect. It’s slow paced… units take time to move around, and once fighting is actually started it generally takes too much time to retreat: you’re committed the moment bullets start flying. There’s almost no micromanagement to speak of, just the big decisions of what you’re producing, where you’re putting it, and how you’re going to pull the wool over your opponent’s eyes while doing so. Continued…

Posted in Games.

Tagged with , , , .


Dwarven Mounts, Bladed Fortress

If you’ve been paying much attention to the independent gaming scene, you’ll probably have heard of Dwarf Fortress, the absurdly deep fantasy world simulation by Bay 12 Games. Gameplay involves guiding and developing a group of dwarven settlers in a world that keeps track of everything from geological phenomena and climate to the individual dirtiness, injury, and mental state of each dwarf. Developed by a single programmer with writing from his brother, it’s been something of a cult hit, attracting a small but utterly rabid group of fans. You might also have heard of a game called Mount & Blade by Turkish developer TaleWorlds, an ambitious open world game set in a medieval society. It started as a garage project from a husband and wife team, and grew as time went on and funding became available.

Both of them have proven successful financially. A steady steam of user donations is the only stream of income for the creators of Dwarf Fortress, yet it grants them an impressive monthly tally, which they publish regularly on their forums. Mount & Blade instead opted for discounted pre-orders that gave access to beta builds, and this was enough to fund development until Paradox Interactive picked them up. Now their game is available at retail and recently went on an 85% sale on steam… a sale which was so popular that steam burned through all the serial numbers TaleWorlds had provided them and needed to procure more! These two companies are pursuing very different paths to financial success, but they’re both obviously doing well! How the heck are they pulling it off, and are there any common threads?

The most obvious similarity—and perhaps most impressive, given the scale of the games in question—is that the development teams have been quite small for both games. TaleWorlds started as a husband and wife team, and remain quite small even now that they have publisher support, while Dwarf Fortress has only ever had a single programmer and a writer… a fact which continues to make my head spin, given the infamous scope and depth of the game. I suspect that the small size of the teams involved have been helpful to their financial success. After all, labour is the greatest expense in game development, and with only one or two developers a small revenue stream can still be enough to pay them a decent wage. Of course, the less developers you have the longer it’ll take to create things, but if you work smart there are ways to strike a solid balance between profit generating product quality and the number of cooks in the kitchen.

There’s also something to be said about the kind of games these are. They’re both “open world” games in many respects, though their approach is very different. Dwarf Fortress is an all-encompassing simulation with a disturbing level of detail, and playing around in that sandbox and doing crazy stuff is the whole point. Mount and Blade’s open world aspects, by contrast, are mainly an excuse to set up a series of fights for your to hack and slash your way through. M&B’s focus has always been on a realistic representation of medieval combat, along with their extremely well done third/first person combat system. They both have areas where they’re very weak, as well. Dwarf Fortress is entirely ASCII art, Mount & Blade’s open-world aspects tend to be lifeless and pointless, and both games have learning curves that feel like running headlong into a brick wall. The appearance is that they have neglected secondary aspects to perfect their core features. What this tells me is that, at least for independent games, players are willing to forgive poor production values or neglected gameplay elements as long as the main hook of the game is implemented well. M&B’s titular mounted and melee combat is brilliantly done, and Dwarf Fortress managed to out-Will-Wright Will Wright… if that ain’t an accomplishment, I don’t know what would be.

So, lesson one: Focus on your strengths. If you do what makes you unique very well, you can get away with not doing quite as well on the rest.

The revenue models of these two companies seem very different on the surface. Bay 12 Games offer their products free of charge, and merely ask for donations. Essentially, their games are as cheap or expensive as you want or need them to be, and their funding is entirely dependent on the gratitude of their players. TaleWorlds, on the other hand, is closer to a traditional retail model with their use of pre-orders. So far as I can tell from reading interviews and digging around the net, the creators never thought they’d be able to make it to a finished product. Instead, they elected to offer a “pre-order” at a significant discount that guaranteed access to the beta builds, thinking that players who bought in wouldn’t get burned as hard if the final game never materialized. In other words, you pay for access to all current and future builds just like you would with a normal game, with the removal of the expectation that you will receive a finished product. Users are therefore paying for a PROMISE that a finished game will eventually appear, instead of the end product itself. Bay 12 is banking on their fan’s generosity and gratitude, while TaleWorlds is banking on their trust.

I’ve got to say I like both approaches. It provides precisely the right fiscal incentives to the developers, and even for people of enormous integrity it’s always better to have your economic model support your principles. Both models demand that not only that you deliver a fun experience, but you deliver updates in a timely manner and treat your fans well. If you break that trust, your revenue will disappear, but if you keep that promise you are duly rewarded.

That’s lesson two, then: Set up your incentives to support your principles. Perhaps not a necessity to success, and possibly even a barrier to making money, but I can’t imagine a better way to hate your job than to be forced to abandon your principles just to pay the bills. Not only that, but I think some credit has to be given to the fans as well. They recognize when a creator has their best interests at heart, and many of them are all too happy to reward that. When they can see that the developer has nothing to gain by jerking them around, it becomes that much easier to trust them.

Still, neither of them would have gotten off the ground without some form of marketing. If nobody knows about  your product it doesn’t matter if it’s as fun as two barrels of monkeys; it just won’t sell, and you’ll have to live in a box. Since boxes are inconvenient places to develop games from, you’ll presumably want to get the word out somehow. Dwarf Fortress and Mount & Blade (at least in its early days) never had big, noticeable marketing campaigns. They were indie projects nestled deep into the dark and gloomy cracks and fissures of the internet, relying only on those who had crossed them and lived to tell the tale to spread their names. Or, to be less of a dramatic twit about it, they relied on word of mouth… the cheapest and probably most effective marketing technique there is. Eventually, they both gained a lot of recognition in the press, but I’m inclined to chalk this up to same community forces that got their names out in the first place.

Speaking of communities, the fans for the two games in question are pretty impressive! The Dwarf Fortress forums are filled with people exploring the game mechanics, telling stories, and otherwise being ridiculously hardcore about the game. Mount and Blade has a HUGE library of mods for a game as obscure as it is, indicating an impressive level of involvement on the part of the community members. In both cases the communities are thriving and active, with lots of dedication from participants. This seems to me like the thread which ties everything together. I believe that it’s this community aspect that allows them to get away with their unorthodox revenue models, and which allows the pervasive word of mouth advertising.

I’ve long believed that online communities are capable of achieving awe-inspiring feats. Wikipedia is a textbook example, as is social media like Facebook or MySpace. It’s amazing what you can get the intertubes to do for you if you point it in the right direction and tell it to sic’ ‘em. Collaboration is a powerful tool we neglect at our peril, as is the inherent social nature of the human animal. It seems obvious in retrospect that putting effort towards building a strong fan community would make alternative funding and advertising mechanisms much more feasible… for starters. If one were clever, they could do things like employ some kind of collaborative development scheme do help develop their game assets!

Take away number 3, then, is that a cohesive, involved community is a powerful tool. Taking the time and effort to build, develop, and maintain it will pay dividends in the long run. The details of implementation are another issue entirely, though. Perhaps in another blog post.

That’s all I could come up with. Anyone else have any insights on the success of these two games? Or perhaps another game that would make a good case study? Leave your thoughts in the comments!

Posted in Business and Marketing.

Tagged with , , , , .


Design of a Skeletal Animation System

When I explained the evolution of John Smith’s animation system, I provided the broad strokes of the system and the overall feature set. This article is mainly focused on the technical aspects of the system, and will include a fair amount of source code snippets. I’ll be publishing snippets of the source code to get the thrust across, because the code is dependant on the graphics and physics engines used in my game, making the full source pretty much useless without substantial work. I developed this system in C++, so that’s what I’ll be presenting it in, but it shouldn’t be too hard to replicate in another OO language. However, if you’re still interested in looking at the full source as well as the source to the editor, pop me an email at ian@aimlessdevelopment.com and I’ll pack it up and send it your way, along with the instructions on how to get it going..

Without further babbling on my part, let’s dig in.

Continued…

Posted in Game Development, Game Systems, John Smith.

Tagged with , .


Evolution of John Smith’s Animation Systems

In my last article I mentioned that I had overhauled the animation system in my game. In the hopes that it might be useful to others, I’m going to go over the details of the original system, the issues that prompted a rewrite, the shift to a skeletal animation system, and the current state of things.

Continued…

Posted in Game Development, Game Systems.

Tagged with , .