Archive for the ‘devcorner’ Category

Just a quick note. I’m looking to fund work on OpenGameArt.org full time (probably via Kickstarter or similar) once my current work project is done, and I’m interested in hearing what people would like me to work on. If you have any thoughts, please join the discussion on OGA:

While the criticism is certainly not completely unfounded and the integration of limited “non-programming” game code creation (via logic bricks) gives it a bit of a “RPG maker” image, it really is a quite interesting platform to work on it seems.Ok, probably as of now the BGE is really more of a rapid game prototyping engine, but previous experience during the Yo, Frankie! project has actually shown that at least compared to some other well known FOSS engines, it is a serious contender (that Blender Foundation project originally started on Crystal Space, and after many problems was implemented in the BGE in a few weeks only).

So what makes it so interesting? Well for one there is the full integration with a creation tool (obviously Blender3D) so that getting your content into the game is only a matter of making it. No exporters or anything needed… it just works. Then of course there is the fully scriptability via Python, also integrated tightly. Basically you never have to exit Blender, and testing your game can be done right in the editor with one click (no compiling etc. necessary). Oh and did I mention the great physics capabilities via Bullet, also build right in?

In addition your created game will be immediately available on any platform the Blender Game player has been ported (all major desktop operating systems, with an Android port under development and a browser plugin, too). In addition you can choose to publish your game as a single .blend file, giving the users a direct access to all the source files of the game; a wet dream of any true FOSS game developer!The tight integration with the GPLed Blender Player, has been a major source of discontent with the predominately propitiatory game developing users of the BGE however. Thus there now exists also a few options to encrypt your game and/or run it on an external engine that can be kept close source (but I will not go further into that here).

You can find a lot of (sometimes really awesome looking: 1, 2, 3) game projects on the Blenderartists.org forum. Now as I said, most of it is sadly closed source with propitiatory artworks, but I also have the feeling that some simply don’t know or care about the legal implications of their “freeware” game (which sadly shows that even many people who use a great FOSS tool, mostly care about the “free as in beer” aspect of it).

One of the more interesting projects right now (which might or might not become a full FOSS game) can be seen in this video:

It shows the most recent work by Martinesh, who is basically BGE’s resident game art guru. Two years ago we already featured previous awesome work by him, but sadly that Air Race project is by now canceled.What he is now working on is however rather a show-case for the really nice new graphical features in the BGE which he and others are developing in the so called “candy” development branch (on his blog there are also more details and nice videos from some time ago).

Another cool recent project it the rewrite of the the logic bricks visual programming idea via nodal logic blocks called Hive.

While not completely integrated into Blender yet, you can already try it via an external editor (the created python code works fine inside Blender). There are also some tutorials and a documentation for it.Since my programming skills also lack somewhat, I find that an interesting tool… however most likely it is rather a nice way to do some level scripting, than actually programming the real guts of a game with it.

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.

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:

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 😉

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!

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: http://lee.fov120.com/iqm

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!