Archive for the ‘devcorner’ Category

DevCorner: GameDevelop goes open-source

Saturday, July 5th, 2014

Thanks to GamingOnLinux for pointing out that this crossplattform *no-programming* 2D game development suite has gone fully FOSS.
It can export games to HTML5 and native code (x86 Linux and Windows).

Read the original announcement here. The github repository is here.

License infos:

  • The IDE (in the IDE folder) is licensed with GPL v3. 
  • The Core library, the native and HTML5 platforms (respectively Core, GDCpp and GDJS folders) are LGPL v3. 
  • Extensions (in the Extensions folder) are using zlib/libpng license. 
  • The name, Game Develop, and its logo are the exclusive property of Florian Rival.

Here is a small video to get you started:

& you can find some example games here.
By the way: I also recommend to have another look at the Godot engine which has had many improvements since it became open-source a few months ago.

DevCorner: Multiple new platforms for Torque2D MIT

Monday, February 3rd, 2014

I tend to focus a bit on the 3D side of things, but the recently open-sourced Torque2D (note the “2″) engine is pretty cool too:

And in fact it got a whole lot better in the last couple of weeks with it being ported to Linux, Android and your browser (through Mozilla’s emscripten).

So if you are thinking about developing an open-source 2D game targeting multiple platforms, Torque2D has just became a serious contender.

DevCorner: jMonkeyEngine SDK 3.0 (stealth) release

Friday, October 18th, 2013

The maybe most user friendly and complete FOSS game engine jMonkey Engine 3, has recently released the final version 3.0 of their very nice SDK.

Here is a list of the full changes:

- LWJGL base now works on MacOSX 10.7+ incl. Applets
- Hardware Skinning
- Shader Nodes
- Better Character (beta)
New LOD Generator!
TangentBinormalGenerator was refactored
- Better physics debug view
- Now bundles a compatible version of the JDK
- Now bundles a version of Blender for conversion and more
- Shader Node Editor (!)
- Code completion for assets
- Texture Atlas creation and packed texture handling
- External editor mesh updates for j3o files
- Seamless 3DS and Collada import through blender
- Improvements to model import tool, allows to locate and import textures
- Attach custom AppStates to the SDK editor scene
- New help and error log system, look for the monkey in the bottom right!
- Improved Font Importer
- Improved support for using other IDEs for code
- Improved obfuscation support for protecting your applications code

Besides general advanced of this Java based game engine, some changes of the list of new features are especially interesting! I think that for example their graphical editor of GLSL shaders is something that could benefit even projects not using jMonkey3 itself, and it is definitely something that was lacking as a FOSS game-dev tool (the half-heartily implementation for something like this in Blender has yet to reach the level of real usability).

Check out the link above to learn more about this shader node editor!

DevCorner: Open (Game Art) Bundle

Sunday, July 14th, 2013

An interesting mixture to “pay what you want” and “ransom funding” has recently surfaced with the Open Bundle:

You can buy all the offered game art and use them under the CC-by license and if the total threshold is reached (10k, 1 day remaining, 9.3k already pledged) all the game art (2d sprites and music) will be officially released under the CC0. A split of the funds is btw. shared with the EFF and Creative Commons.

For those wondering: no, it is not done by our friends of, but they think it is a good project anyways. Interestingly the creator is also thinking of expanding the idea:

Do you want to host your own “public domain ransom”?
I’d love to help you! Email me at

P.S.: While we are on last day notices: Today ends the registration period for the Unvanquished summer tournament. Also check out their latest Alpha 17.

DevCorner: Underapprechiated game engines

Monday, June 17th, 2013

In my never ending search for a FOSS game engine that is usable for game modding with out having to reinvent the wheel (nor requiring to be a C++ code master) & having decent tools for content creation (because I am spoiled and think that is a minimum requirement for a game engine) I have become quite disillusioned lately. That is because *spoiler alert* sadly there is none so far… but a few are close luckily.

The usual contenders for 3D action games are your mixed assortment of idTech based engines, most notably ioQuake3. There are a few upcoming contenders like Unvanquished’s Daemon engine (which is a mix of ET:Wolf, ioQuake3 and Xreal) and a yet to emerge idTech4 based champion (my uninformed guess is that it will be dhewm3). But all of them lack a decent game-play scripting function.
On the other side of the idTech spectrum, there is the idTech1 based granddaddy DarkPlaces, which while having advanced to an quite impressive feature set, suffers a quite a bit from its nut-bolted & mostly undocumented client side add-on on the already a bit arcane script language QuakeC.

Interestingly the idTech2 based engines get little attention though. I have highlighted a few nice game projects based in it in the past, but it is probably due to the fact that each project is hacking on their own engine fork, that none has gained prominence as a game engine on it’s own. But feature wise the engines behind AlienArena, Overdose and Warsow are probably the most advanced.
The last one of these, has been probably the most overlooked, with the game itself not exactly open-source friendly and the engine being developed more or less behind closed doors. It seems however that this has changed now, although given recent project news it is unclear what made them change their approach. But an all new version of it is now on Github with the main developer mentioning a few really nice changes here. Let’s hope it isn’t just a “source-drop” of a dying project, as after digging into it a bit (the documentation is really fragmented and lacking) I have to say that it includes a few really awesome features not commonly seen in other FOSS engines:
Besides being really performant, it is fully scriptable and has some quite unique multiplayer features like awards, friendlists and persistent game statistics. It also seems to make good process in having easy to edit GLSL shaders, which I have realized is a much rarer feature than I originally thought. Last but not least it has a really modern looking and fully scriptable menu and HUD.

Ah and before I move on to non-idTech based engines I should mention Engoo for those looking for a modernized software rendering engine based on idTech1 (there was some controversy over it, so I am trying to show some support for its further development here).

Ok, that covered, what are some maybe under appreciated non-idTech 3D engines?
First of all I should probably mention the well known ones for the sake of completeness: Cube2, Ogre3D and the new big player Torque3D. All of which are IMHO still failing to provide a good platform for easy game creation (mainly due, following the same order: in-fexibility & lack of scripting; huge mess of independent parts & bad toolchain; lack of Linux port & buggy and overly complicated toolchain).

One of the shining but lesser known examples of trying to improve the status quo is the jMoneky3 engine. Even though it is still a bit bare-bone (e.g. lacking game frameworks) the nicely integrated SDK and the great new node based GLSL shader editor keeps on attracting my attention. Similary the BlenderGameEngine sure has a few great advantages due to its tight integration. Sadly it seems to be the unliked stepchild of the Blender3D project though, which some quite serious limitations and awesome additions like the candy branch never reaching the the main release.

Then there are the still very much alive big names of the past: Irrlicht and Crystal Space. I am not exactly sure why those never quite reached the required mass to become the engines of choice, but I guess the license mess around Irrklang (and other non free but more or less required addons) and the CS Yo Frankie disaster might have to do with it. But at least Crystal Space was accepted as a hosting organization for this year’s GSoC again, so they must be doing something right.

Last but not least, I would like to give a mention to a relatively new contender: Octaforge, which has supplied a steady stream of updated betas lately. The interesting things about Octaforge is that it takes all the good things from Cube2 and combines it with a much updated renderer (Tesseract) and full lua script support. But sadly it isn’t quite there yet, and the move to a scripting language required the removal of all the nice game-code that it inherited from Cube2.

As closing remarks I have to admit that this article was rather lopsided towards FPS game engines (and more general purpose ones). Of course there are many great other game engines in the FOSS sphere that focus on RTS or (MMO)RPG games etc. I do however feel that many of the grievances voiced here probably apply there too, but maybe it isn’t quite as frustrating there as in the FPS genre.
But if you have some better insights into those type of engines feel free to comment below!

tl;dr: the author (as an old school modder) is frustrated that after all these years there still isn’t an FOSS FPS engine that can be modded as comfortably as the Half-Life2 engine or UDK. Don’t miss the new qfusion stuff though.

DevCorner: Liberate some great Blender game art!

Wednesday, June 5th, 2013

UPDATE: First set of files has been released (license CC0) and on my advise he added some stretch goals:

  • 600$ > 3 game ready Enemies! (models, sfx, animations, effects)

  • 650$ > Dynamic optimized lighting system! (rich dynamic lighting with low resource usage )

  • 750$ > 4 new weapons!(model, texture, sound)

  • 850$ > Triple the amount of the actual props! (interactive objects,explosibles, new walls, doors windows etc.)

  • 900$ > New player model (model, textures)

Currently it is standing at 530$ and there are 22 days to go, so chances are we will see some more nice stuff out of this.
Way too many closed-source game projects never see the light of the day, and their code and assets are forever lost. Now at least one developer thought he could at least make a few bucks by liberating this content under the CC0 license:

There is some seriously nice stuff in that pack, and the 500 US $ he is asking for on his indigogo page is a bargain for it.

At the time of writing this, 200$ have been already pledged, so with your contribution it should be easy going to reach the goal. Update: 515$ contributed, thanks to everyone! Maybe the guy should think about strechgoals ;)

But I sure wish more developers of failed projects would release their assets like this.

Looking to fund working on full-time.

Wednesday, April 24th, 2013

Hey folks!

Just a quick note.  I’m looking to fund work on 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:
…or on reddit:



DevCorner: Blender Game Engine

Saturday, January 26th, 2013

While Blender3D is one of the premier FOSS projects out there, its integral part the Blender Game Engine (BGE) is often belittled as not a serious game engine.

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 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.

So where can you get started with developing your own game using the BGE? Well, the sub-forums are always helpful, with some nice beginners video tutorials linked here, here, here and here ;)
There are even some books available (this one in particular is quite recent, which is a plus given the fast development of Blender3D) and there is of course the official Blender documentation.
Oh and a good source of content is (besides our friends of course) Blender Swap (nice interview with one of the creators here).

If you have further questions please comment below or ask over at!

Open Source Handheld Console GCW-Zero: OpenDingux, Kickstarter

Tuesday, January 15th, 2013

GCW Zero Kicksterter is a project to create a spiritual successor to the low-cost Dingoo A320 handheld gaming console.

Thanks to SiENcE for pointing this out!

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,