Archive for the ‘devcorner’ Category

Dev-corner: You don’t know it, but your FOSS game project has a deadline.

Monday, December 17th, 2012

How soon is the deadline on your FOSS game project?

You’re probably thinking that you don’t have one.  And in the sense that a commercial developer would use the word deadline, you don’t.  There’s no date looming above you on your calendar, no boss asking for updates at your next staff meeting, no investor threatening to pull their funding for your project if you don’t finish on time.  As a FOSS developer who is writing games as a hobby, you have the luxury of taking your time, right?

Nope.  Rather, your “deadline” is like the bandwidth limit on one of those cheap “unlimited” web hosting services.  It’s sooner than you think, but it’s not set in stone, so it’s easy to not think about it until you’re already past it.  The deadline for your FOSS game project is when any of these things happens for the first time:

  • You realize you’ve bitten off more than you can chew, and lose interest.
  • Changes in your life (getting married, having kids, getting a new job, going to school, etc) prevent you from spending an appreciable amount of time on your project.
  • The game engine you’re working on that was “feature rich” when you started it is now so badly obsolete that it’s pointless to continue development on it.
  • Any other random circumstance I haven’t thought of that might cause you to stop working on your project.

I don’t have any hard data here, but given the number of dormant and failed FOSS projects out there, it’s probably safe to say that your deadline is under twelve months from the start of your project (seriously, try browsing some dead projects on the various source code repository sites.  For every successful project, there are dozens — if not hundreds — of projects that never really got off the ground).

Now, there are projects out there like Flare and Battle for Wesnoth that have broken the one year mark, but what these two projects both have in common that most lack are that they’ve attracted multiple developers beyond the original teams.  As such, when one developer burns out for a while or has family obligations, other people are continuing to work on and improve the code base, which keeps the code up to date and interesting so that your project continues to gain momentum and attract interest from potential contributors.  As such, your real deadline isn’t to finish your project by the one year mark, it’s to get it far enough along that it’s playable, so that it attracts other developers who want to add on to it.

If you want your project to get to this point, there are some things you can do that will help immensely.

Understand that you’re on your own until you can produce real, compelling gameplay.

Almost every FOSS developer who gets into writing games does so because they have a personal vision of their own ideal game.  Maybe you’re lucky enough that there are two or three of you with a shared vision at the start of your project, but regardless of whether you have a small team or you’re all alone, you probably aren’t going to attract too many more developers to your project without an appreciable amount of gameplay already in place.  Your project might sound great on paper, but there are thousands of other projects that sound great on paper as well, but never got anywhere.  If a developer is looking for something to do, they’re not going to notice your project with no real gameplay; they’re going to go for an established project that is already playable and has real momentum. 

The way to attract developers to your game is to harness the ‘itch’ that people always talk about in relation to open source software.  For that to work, you need someone to play your game and decide they want to add their own pet feature to it, and for that to happen, you need a playable game.

And, since you probably aren’t going to have real gameplay right out the door, the first key to a successful FOSS game project is understanding that, just because you made it open source, it doesn’t mean that developers are going to start coming out of the woodwork wanting to help you.  Be prepared to spend long hours working on your own, getting to the point where you have real gameplay.  (Oh yeah, and I don’t mean just a terrain engine.  People need to be able to play your game, and have fun doing it.)

Keep your ambitions in check.

This is a big one, but it’s something I’ve covered at great length in the past, so I’ll keep this short and sweet.  If you’ve never completed a game project before, or you’ve never written any real networking code, that awesome idea you have for an MMO that’s going to totally be better than World of Warcraft isn’t going to happen

Here, I’ll show you something.  Check out this SourceForge search for MMORPGs in the planning stage.  At the time of this writing, there are 22 pages of results, and everything after half way down the third page hasn’t been updated in at least a year.  Only around 10% of MMO projects in Sourceforge ever make it to production status, and a lot of the projects that do make it that far are engines as opposed to full games.  If you really want to make a huge game and you think you can code fast enough to do it before you burn out, try making a really small game first, as an exercise.  If you can do that, it’ll give you a good sense of scale to determine how ambitious your big project idea really is.

Ugly hacks really aren’t all that bad.

This one is from personal experience.  I’m a reasonably good developer.  I’ve worked on enough projects that I have a pretty good intuitive understanding of the scope of the projects I take on.  My own main problem is that when I see a new feature I’d like to add, I get tempted to re-architect my code to make that new feature as clean as possible, rather than hacking it in.

There is, of course, a lot of merit to clean code.  Ugly hacks aren’t a good thing.  They make your code harder to read and maintain.  On the other hand, if you’ve put a year into your pet project and it’s nearly playable, now is not the time to rewrite it so you can add in some snazzy new feature or optimization.  If the feature is unnecessary for making your game playable, leave it out.  If you absolutely need it, hack it in.

For some of us, this is a pretty tall order.  I personally worry about what people might think of my code.  I’m confident that I can handle most projects, but I’m always worried that there will be some gap in my knowledge that causes me to do something stupid or miss something really obvious.  When there are entire blogs out there devoted to poking fun at bad code (not knocking the Daily WTF, by the way — it’s hilarious and highly educational), it can be pretty scary to release hastily written, hackish code into the wild.

But when you do, remember that a lot of projects never see a playable release at all.  That hackish code you put in there will probably be replaced eventually.  You may even trip over it and curse it later on.  But if it’s the difference between a project that never gets finished because you burned out while trying to do things ‘right’, and a completed project that attracts the attention of other developers because it has legitimate gameplay, your ugly hack was ultimately for the best.

Try some FOSS game project necromancy.

Maybe you already missed the “deadline” on a FOSS game project several years ago, and you’ve got a bunch of code languishing on your hard drive.  If you find yourself thinking of starting up a new project, you might also want to think about resurrecting that old code and finishing it instead.  The deadlines I listed above aren’t absolute.  Even if you burned out on a project at one point, the code is still there, and there’s nothing stopping you from picking it up again.  Most projects stay dead, but yours doesn’t have to.

In conclusion…

Your number one duty to your pet FOSS game project is to get it into a playable state without giving up.  If you miss your deadline, whenever that may be, you’re consigning your idea (and your time) to the graveyard of projects that never saw the light of day.  Make your project playable and get it out there, and it has a much bigger chance of succeeding in the long run.

Bart K,

DevCorner: Professionalize your art asset management

Saturday, December 1st, 2012

Today I thought it might be nice to have a small talk about Digital Asset Management systems (DAMs). Now I have to admit, given the abundance of open-source DAM systems and my general lack of having actually tried them, might make me not really qualified to talk about this. However I think those are actually really useful if you are managing a game project with more than one artist, and I just happened to stumble on one (TACTIC) that seems to be especially geared towards 3D movie and game development (Note: I hope this doesn’t turn into too much of an advertisement post, but this system is after all completely open-source. But if you have other, or better DAMs for FOSS game development, feel free to add them in the comments).

So what are DAMs actually? Maybe this short introduction video of the system mentioned above, will give you an idea quickly:

TACTIC from TACTIC on Vimeo.

The system was quite recently open-sourced under the Eclipse Public License, and has been previously in use by some of the big 3D gaming companies. For an overview of the features head here. Its client interface is completely web-based, and you can easily set up your own asset-repository VM server if you want.

For most FOSS games (which tend to be mostly one-man shows :( ) such a system is probably overkill, but using a DAM might actually help involving more people and make collaboration across the globe more efficient (Just like GIT and such systems did for code collaboration projects).

Maybe someone would also be willing to host such a service for FOSS game projects? However high data-transfers rates would make it probably not possible to offer such a service for free. Feel free to comment on that too 😉

A tale of two Hexagons

Wednesday, November 28th, 2012
This is a guest post by user Hythlodaeus, discussing open source clones, indie game community behavior and developer’s apologies.

Vee Software’s Open Hexagon is a very, very recent game, but even in its short existence, it has already managed to stir up quite an amount of controversy, the matter being that Open Hexagon is none other than a free software clone of the popular iOS/Android game Super Hexagon, created by the equally popular indie developer Terry Cavanagh.

Now, video game clones are not a negative or uncommon thing at all, and have pretty much existed since the beginnings of video game history. However, Open Hexagon developer, Vee, has recently found himself the victim of some serious flak, the reason behind this being that he decided to release his own game clone before the much anticipated PC/Steam version of Super Hexagon. This resulted in a legion of rabid Cavanagh fans rushing in to accuse Vee of being a thief, a liar, and quite a variety of other unpleasant names and insults.

To make a few things clear, Open Hexagon is not only 100% free software, programmed from scratch using C++ and SFML (unlike Super Hexagon which is primarily based in Adobe Flash, with the PC port being completely redone in C++ as well), as it is also available for absolutely zero cost. It is not geared as a competitor for Super Hexagon, and it’s certainly not trying to profit from its original concept at all. If anything it’s actually attracting more attention towards the original game. If that wasn’t enough, the developer actually took the time and decency to ask permission to Cavanagh himself to create his game, while he had no obligation to do so at all.

image: tweets between devs

What ensued was a deep and long-winded apology from Vee, to all Super Hexagon fans, and the subsequent approval of his game by Cavanagh, despite the fact that he was never against the idea, since day one. I guess all’s well that ends well, but even though Cavanagh’s reactions were fairly reasonable from his part, I still can’t stop thinking that issues like this could have been easily avoided altogether, had he, and other indie developers such as him, made habit of releasing the source code of their own games, something that has, in fact, been done successfully in the past with surprisingly positive results.

Call me crazy, but I find it troubling that this new, so-called generation of “indie” developers and their supporters, heralded as the avant-guarde of video game originality, and as a counter-cultural movement that opposes industry stereotypes and its negative practices, shows so little knowledge and sensibility on matters of software freedom, and how it can be used to help and empower other amateur / independent developers such as themselves. The result is the accidental propagation, to their followers, of the gross misconception that for some reason, game concepts are the exclusive property of their authors, and that copying and innovating over other people’s ideas is a wrong thing to do. Coincidently, Vee himself has shown some great eloquence on this matter in his written apology, which really makes me wonder how come there aren’t more people like him in this new indie circle:

As a independent game developer, I wanted to create my own tribute version of the game, not only as an experiment, but also as a completely new experience: I wanted to make the game fully open, both as a free open-source product, and also as a customizable and scriptable game, in order to let people share their creations and have fun.

Now, the game itself is quite simple. You are a triangle spinning around a hexagon. Incoming polygons want you dead, so you have to dodge them. Sounds easy enough, right? It turns out it isn’t. And it could be a lot more if you’re whiling to help, because unlike Cavanagh, Vee crafted his game thinking of customization and the freedom to easily script, paint and construct your own levels in any way you wish.

image: Open Hexagon ad

Version 1.3 is out now, with updates pouring in, on a nearly daily basis, as Vee is still trying to shape his game into a more unique experience, a process in which you can take part as well! So if you have a mind for quick-reaction puzzle games and enjoy crafting your own personal conundrums for later enjoyment, or even showing them to your friends, by all means, download Open Hexagon, play it, and share your own levels with others!

Four persons behind FLARE RPG development

Friday, July 13th, 2012
FLARE has an excellent new website and a series of contributor interviews:

The latest release is 0.16.

Dev-Corner: Inter Quake Model Format and Open Source Gamedev Collaboration

Monday, July 9th, 2012

The following is a guest post by Lee Salzman, a contributor to several open source game projects and the lead developer of such projects as the ENet networking library and Sauerbraten, introducing IQM (the Inter-Quake Model format), a simple model format designed to meet the practical challenge of animated content for Quake(-like) 3D engines and allow more sharing of modeling tools across various engines

As much as players or fans of various open source FPS games might view all these projects as competing, isolated islands, the surprising and hopeful truth is, we developers actually get together and talk about development challenges a lot. And in past discussions, one of those issues that stuck out like a sore thumb was content, especially animated content such as player models. We were all using our own various custom model formats or cast-off commercial formats (like id’s MD5 or Valve’s SMD formats) with related third-party export or conversion tools, with varying degrees of (dis)satisfaction.

Yet, what we all needed in this case was so eerily similar: we all just wanted a no-fuss, binary, skeletal animation format that was quick to load, had relatively small file sizes, and provided the commonly needed mesh data for Quake(-like) player models – not bloated with unnecessary “but what if…” features while remaining just flexible enough to fulfill the artists’ needs. Existing formats like MD5, SMD, Collada, and others had complex textual representations that make them painful to load and often require significant internal conversions of the loaded data to get useful, renderable animation data out of them, often with frustrating omissions such as no ability to directly export vertex normals. Engine specific formats worked around these issues to some extent, but often suffered from poorly supported tooling due to the difficulty of keeping it up-to-date with various modeling tools and artist requirements.

IQM Demo Model, Mr Fixit

Given those frustations, why did we not just throw our lots in together and make one format that could handle our needs well enough, so we all benefit from common efforts on reliable, shared tools? Sanity prevailed, and not much later, after input wrangling from various developers within the community, we hammered out a simple specification for a pair of formats that did just that: IQM, a binary skeletal animation format that provides easy integration into a game engine, and IQE, a textual format that makes it easy to quickly write exporter scripts and easily converts to IQM if one does not wish to write an exporter for it directly.

And what good is a specification without support? So again not much later, we went through the grunt-work of actually making sure the format was well-supported in the key tools our artists used and, of course, the engines we all developed. At the time of this writing, all commonly used versions of Blender have direct exporter and importer support via the IQM development kit, the model viewer and conversion tool Noesis can easily convert from and to the format, and the format has out-of-the-box support in various engines, including but not limited to, DarkPlaces (used in Xonotic, Steel Storm, and more), CRX (used in Alien Arena), Qfusion (used in Warsow), ioquake 3 (used in Open Arena and many more), Remake Quake along with its sibling engine DirectQ, and Cube 2 (used in Sauerbraten, Red Eclipse, and more). To ensure continued and future support by other game engines, the IQM development kit also provides example demos of how to easily load and animate the format, both on the CPU and also using shaders to animate the format on the GPU, for developers that are unsure of how to utilize skeletal animation or just want to see the nitty-gritty details of how the format operates.

Despite the format getting off to a great start thanks to the support of various developers within the gaming community, we still need your help and support to help this format be even more useful. If you happen to use some modeling tools other than Blender (as awesome as it is, people have their preferences) and wouldn’t mind writing a simple IQE exporter script for your modeling tool of choice, or even more sophisticated IQM direct export support, we would greatly appreciate your contribution!

To get started with the format, please check out the IQM development kit and other IQM/IQE format resources at:

LÖVE game programming course for kids/teens in Kansas City (August 2012)

Monday, July 9th, 2012

There will be a Lua game programming class for kids and teens in Kansas City by indie game developer Rachel Morris some time in August 2012.

LÖVE 2D game engine and Tiled Map Editor will be used. Both are open source and run perfectly fine on Linux systems.

Rachel is known for OpenArt and you can check out an interview with her or her GitHub repositories.

Feedback on the existing course materials and of course participants are requested.

Video Talk by icculus: Open Source Tools for Game Development (Devcorner)

Wednesday, June 13th, 2012

Ryan “Icculus” Gordon talked about open source tools for gamedev last month at Flourish! 2012 and we completely missed that. Enjoy the 1h video, he’s a great speaker and I’m sure most of you will enjoy the Direct X bashing. :)

Note: the first 2 minutes of the video have bad audio quality. The rest is crisp!

Liberated Pixel Cup is a go!

Sunday, June 3rd, 2012

This weekend the Liberated Pixel Cup started its art contest, which will run until the 30th of June. You can check out the style guide and the existing assets here (includes a interactive HTML5 demo).

Reasonable prizes for the winners and runner-ups might motivate you to contribute, but judging will be only after the second phase of game prototyping, which ends on July 31st.

But even if you don’t win, you can be sure that your contributions will be a very valuable part of the resulting FOSS game content pack, so every small addition counts.

Good luck!

Dev-corner: JUICE up your game

Sunday, May 27th, 2012

I just happened to come across this nice presentation, and I guess a lot of FOSS games could also take this as a valuable advise:

The “game” they are presenting is playable in your browser by the way, try it here (hit esc for the menu).
Oh and believe it or not, source-code is available too 😉

So don’t forget to JUICE it real good!