FreeGameDev Planet - Development

FIFE - More Weblate details

2013-05-17T12:44:00+00:00

Heya! As promised, a more detailed blog about what's new with our recent Weblate migration, what changed and what didn't. First of all I'd like to address a question raised on IRC: Your user da...

BennuGD - Royalty Free Music by Erkosone.

2013-05-16T15:16:56+00:00

Erkosone is making available many songs of his creation in this post in the forum. There are different styles of music in many tracks that you can use in your games, no matter if they are free or commercial projects. The only condition is for you to give the credit to him for his music.

Bookmark/Search this post with

Royalty+Free+Music+by+Erkosone.&subj=Royalty+Free+Music+by+Erkosone." title="Publish this post on Barrapunto.com" id="service-links--es-barrapunto" class="service-links--es-barrapunto" rel="nofollow" target="_blank">

OpenXcom - Globalizing the X-COM organization

2013-05-16T14:54:10+00:00

I’ve also noticed we get a lot of views from all sorts of countries I can’t even begin to comprehend. Maybe you’d like to help spread X-COM around the world and contribute a translation or soldier names for your country?

OpenXcom - This one is going in the record book

2013-05-15T08:55:46+00:00

Wow, it’s been quite a week hasn’t it? I quickly put out a release and leave the website half-updated, figuring it’d give me a break as I needed to make way for university work, and before I knew it the website was bursting with activity. It’s like I had invited you all to dinner, but you show up early so everything is still dusty, my clothes are all over the floor the roast is on fire. And aliens burst through the bathroom and catch me with my pants down.

Anyways, first things first. Thanks to everyone who’s been spreading the word, especially Alec Meer and Phil Savage who wrote very nice articles about us and really helped boost our views. Usually I manually contact every press site and get nothing, but this time it all just happened organically. It really shows how much I don’t get this fancy Web 2.0 you kids are using. On that note, I should point out all the globe icons on the right that people miss. They take you to our various contacts/social networks! Try them! And if you have better ideas on how we should be using them let us know.

The website has now been fully updated to reflect all the new information and how the project has grown since its early days. Gone are the days when this was a mere one-man project!

The About page has been completely revamped to cover all the new questions you guys have, and the Screenshots page has new content highlighting all the cool extra features, so if you still have doubts, check them out.
The Downloads page now has fresh Windows and Mac OS X builds, as well as various Linux distros I never even heard of, so no platform is left behind. Thanks to all the port maintainers for getting them updated fast.
To deal with all the new people reporting new issues, we now have a proper fancy Bug Tracker. Please, please, if you experience any problems, let us know! Don’t just mention it “just crashes”, sigh at the first bug you run into, and leave it at that. We can’t fix the problems if you don’t tell us about them! Also the Forum is a much better place for discussion than just commenting on the latest news post.
By popular request, you can now Donate to the project. OpenXcom will always be free, but a lot of people expressed interest in giving us a little something for our troubles, so now you can.

Finally for everyone experiencing scrolling bugs and other issues, try the nightly builds and see if they solve your problem. And if you really want to increase the Battlescape viewport you can try increasing the baseXResolution but it’s highly experimental.

That should cover most of your issues, but I figure I should also answer some of the bigger debates here:

What?

A lot of you still seem confused what OpenXcom’s real purpose is. Put simply, it’s a love letter to the hardcore fans of X-COM. The ones that don’t mind dusty graphics and a baffling interface, as long as they still get the gameplay they’ve always loved. It takes away the need for DOSBox, gets rid of all the nasty problems, makes it more accessible to more platforms, and tops it all off with various improvements to make sure you can keep on playing the original as long as you want.

It’s not meant to be the one remake to rule them all or a spiritual successor. I think we got enough of those, thank you very much. If you wanna mod it as such, that’s up to you.

As for why it’s 0.9 as opposed to 1.0, well, that’s just to give us some breathing room. It’s “feature-complete”, yes, but there’s always plenty of bugs that pop up when these things come out. And we’d actually like to take the time to go back and fix and refactor and improve everything, instead of keep on rushing features, before it becomes too messy to handle.

Why?

But we already have the original X-COM, there’s even patches like XcomUtil and UFO Extender, what more do you need? Isn’t it just kinda redundant and pointless? Maybe. Maybe.

Let me tell you this. How long have you been an X-COM fan? Been in the community? How many dozens of remakes have you seen flash past before your very eyes? I’ve seen a lot, for years and years. I remember when EDF was still new and fresh, and I was even part of the Xenocide development team at one point. But in the end, what’s the universal constant?

“It’s just not the same as the original”, everyone says. “They changed the gameplay too much, it’s not as challenging, it’s just not the same”, they say. “Why doesn’t just take the original and fix it up, instead of constantly screwing up the formula?”.

Well, that’s what we did. We took all the combined knowledge of the original X-COM community, and made something out of it. A fixed, improved, open-source version, for all to try. And we didn’t make another overambitious unfinished abandoned project in the process, and disappoint the community once for. That’s what OpenXcom is for. Maybe you’re happy enough with UFO Extender and XcomUtil. That’s fine. We’re not really trying to beat them, specially since it’s really hard to reproduce features just from looking at them and hoping we get it right, since everyone who develops these things vanishes into the ether leaving nothing to go on behind.

Maybe that’s not enough for you, you want a brand new HD state-of-the-art spirital successor remake-type thing. That’s fine, too. I like remakes. But I’d rather let someone else do that. I can tell you, from experience, reproducing X-COM from scratch is one hell of a challenge, and I imagine that’s where most fall apart once they realize this. But now they’ve got a stable open-source codebase to start from. They don’t need to worry about reproducing X-COM all over again anymore, they can focus on the important part, making their own unique vision and interpretation of it, making their own remake. So maybe we’ll see a lot more bold successful remakes now. At least I hope so. The series has a lot of potential, and it’d be great to see a lot more choices and variations for people to try, instead of the string of projects left to rot.

@#$&%?!

Apparently a lot of people are having this reaction when they play OpenXcom. That they wanna go back to the “easier original X-COM”. Let me put this bluntly. What in the actual fuck. I don’t wanna live on this planet anymore.

First, we can’t just port the original AI wholesale, we don’t have the source code. We had to write AI from scratch based as closely as possible to X-COM’s design. You can’t just turn a switch on and off to make it different, it’s a really complex system, and everyone has a different view on what consists “challenging”.

Second, “easier original X-COM”? Really? I never thought I’d be alive to hear such a statement. I don’t know what X-COM you were playing, but I can go back to the original and get half my squad killed on my first crash site on Beginner in a snap. Perfect visibility, ruthless aim, brutal reaction shots, that’s how it’s always been. In all my years as an X-COM fan, the original has been highly lauded for its brutal punishing difficulty, and every other remake has been massacred for “just not being difficult enough”. And now this. Maybe it’s different times, I heard people even had trouble playing the new XCOM on Normal. But for me, once X-COM is “easy”, I will never return.

Yes the AI is better. It no longer decides to just wonder aimlessly or get stuck inside some building somewhere. You can no longer reload the same game ten times until your shot finally hits. That didn’t seem like it was worth reproducing. I dunno, I haven’t seen any veterans have any trouble playing the game, a bunch of them have beaten it already. Maybe you just need to brush up on your tactics. Psi is still totally overpowered though, go nuts.

Castle Game Engine - Development: transitionComplete, Debian packages, network tutorial, data URI, MultiTexture tests, more

2013-05-12T12:00:00+00:00

Various new features developed for next Castle Game Engine and view3dscene:

NavigationInfo.transitionComplete support. Demo model transition_multiple_viewpoints.x3dv shows how to use it to make an animated transition between a couple of viewpoints.
Thanks to Abou Al Montacir we will have packages with Castle Game Engine and view3dscene in Debian! Most of this software was developed by Michalis using Debian, so having my software in the Debian repository would feel really great for me :) See here for our forum thread, and here is the Debian bug marking ITP (Intent To Package) for engine: #706408 and for view3dscene: #707932.
For developers, new chapter of our tutorial describing network support is available.
Engine examples contain a simple tool examples/tools/to_data_uri.lpr that can generate data URI (to embed your texture, audio, model, etc. inside a VRML/X3D model, or a webpage, or other documents) from any file. It gets the file and guesses MIME type using our existing CastleDownload unit, so it supports local files as well as http links, and MIME type is retrieved from server or guessed based on file extension.
There is a demo data_uri.x3dv showing how you can use data URI to embed all kinds of things inside X3D file: textures, sounds, other 3D models (to Inline or Anchor to them), scripts etc.
MultiTexture.function support (forces shader pipeline rendering for given shape; there's no way to reasonably implement this using fixed-function pipeline). Demo in functions.x3dv.
A set of X3D multi-texturing tests is available, testing support of view3dscene and other VRML / X3D browsers for multi-texture features. This is part of my ongoing effort to improve X3D MultiTexturing specification.
There is a progress bar showing the process the downloading. The download is still blocking, but at least now you see what's going on :)
If you load or save image sequences using the syntax image%d.png, for example inside our extension Movies for MovieTexture can be loaded from images sequence: the new syntax to indicate counter inside the URL will be @counter(4), where 4 is the padding. For example image%d.png has to be changed to image@counter(1).png and image%4d.png has to be changed to image@counter(4).png.
For loading, you will have to use new syntax with @counter(<padding>) with new view3dscene / Castle Game Engine versions. You will have to update your VRML/X3D models, old syntax will unfortunately not work anymore (reasons below). For saving, the old syntax %d will continue to work for some time (along the new @counter(<padding>) syntax, and you're encouraged to upgrade to new syntax).
The reason for this is that MovieTexture.url is now correctly treated as an URL, and this means that percent character % needs to be escaped to %25. Inside URL the sequence %4d has to mean letter M (ASCII code 77, which is 4d in hexadecimal). So there is unfortunately no way to avoid breaking compatibility — we want to correctly support URLs, which implies that %4d must be interpreted as letter "M", not as a magic counter.
Looking back, it was an unfortunate choice to use percent character to indicate images sequence, since percent is special inside URIs. It was done for consistency with ffmpeg, that supports things like image%4d.png on the command-line (but not when using URLs; for example, ffplay /home/image%4d.png works, but ffplay file:///home/image%4d.png does not work, neither does ffplay file:///home/image%254d.png). So, one can say that it was ffmpeg that made a bad choice, but then ffmpeg did it for consistency with common string formatting functions (C sprintf, ObjectPascal Format)...
Comments about this change are of course welcome, through forum or any other means. Right now, I just don't see a way to avoid breaking compatibility. We made a bad decision to use %d to indicate image sequence, and it has to change in order to correctly support URL encoding in new versions.
A couple of bugfixes. Including bugfix to a quite horrible mistake in ShaderPart node, in some circumstances the shader code would be reloaded from file at every frame, causing a horrible slowdown. It's fixed now of course.

Allegro - Allegro 5.1.7 (WIP) released!

2013-05-12T01:55:19+00:00

Irrlicht - Monthly Screenshot Contest – April 2013

2013-05-10T18:00:28+00:00

Here is the winner of the Screenshot of the Month contest for April: Zprg with his ”’Simple little logolike interpreter for voxelgraphics” screenshot. As always, you can find the screenshot and all contestants in the forum and the gallery.

jMonkeyEngine - Old promo video resurfaces: Prototypes & Alphas Mashup

2013-05-08T15:33:20+00:00

So, a fairly long while back (almost a year? oh my god I’m so sorry!) we asked the jmonkeys for video clips of their prototypes an alphas, and as always, our fine community didn’t disappoint. However, the Stable release kept being held up by a crucial bug, and after a while we were suddenly out of “release mode” again, and the promo video never happened.

Way back when hopes were high, I quickly put together a simple video of the collected videos for just the team to look at, since we’d soon have a proper release video to share with the public. Alas, it didn’t go down that way. Instead, I’m sharing it now (look up).

Silver lining? Many of these games are still in development and look 10x better today! Way to go monkeys.

In closing, I think it’s safe to say now that 3.0 Stable is less than 2 weeks away. If we don’t make this deadline, something absolutely terrible must have happened and we’re all probably gonna be more occupied with fending off the alien invasion or building arks than worrying about some 3D engine getting a nice and shiny “Stable” sticker slapped on it.

OpenXcom - It’s finally here, version 0.9!

2013-05-07T03:43:15+00:00

Oh yes, fully playable 0.9 is officially here! Spread the word! Tell your friends! Get rid of all your old versions and saves, this one is gonna top them all! If you’ve been using the Git builds, then changing the save version to “0.9″ should still work.

Currently only Windows downloads are available, other platforms/versions will follow, in the meantime you can build from the source. Here’s the full changelog:

New features:

General:

Intro cinematic.
Game can now be completed, game over screens for winning and losing.
Randomizer for “New Battle” mode.
Your settings in “New Battle” mode will be saved for next time you play.
New translations: Ukrainian, Bulgarian, Portuguese (Portugal), Spanish (Latin American), Danish.
New soldier names: Italian, Hungarian.
Aliens progress their equipment levels, races and aggression over time.
Added “Alien Weapon Level” button in New Battle menu.
Added “Right Click to Delete” function in save/load menus.
Added various display filters to the game, including HQX and various OpenGL shaders.*
The game can be dynamically resized to a new display resolution when in windowed mode.*
The default windowed mode position can now be edited in the configuration file.*
Modular Ruleset support.
Added “Controls” menu.
Added “Advanced Options” menu.
Added button to Restore Defaults to options.
Pause Game on Loss of Focus.**

Geoscape:

Live alien capture and interrogation.
Psionic training.
Hyper-wave decoding.
Alien base handling.
Scoring for both aliens and Xcom.
Funding nation decision making.
Multiple dogfight handling.
Graphs screen.
Base Defense screens.
Full research tree.
Alien UFO Mission Generation.
Alien retaliatory attacks on Xcom bases.
Show radar-range lines on the globe after pressing R key.
Show funds above the time.*
Added the number of soldiers allocated on craft equipment screen.
Custom initial base layout.* (requires a new game to take effect)
Building Queue: Can place buildings next to uncompleted buildings.*
AutoSell Production state for a manufacturing project by a right click on the increase button.*
Allowed multiple items to be produced per hour when very large numbers of engineers are assigned to a project.*
Upper limit for alien captures per containment facility.* (visible on Base Info screen)
Captive aliens can now be sold in the same manner as dead aliens.*
Can transfer crafts while airborne.*
Increase/decrease buttons now respond to mouse wheel scrolling when the cursor is above them.*
Allocate Scientists and Allocate Engineers screens now respond to mouse wheel scrolling.+
Debug mode now enables drawing of country and region borders.

Battlescape:

Battlescape melee unit AI.
Unit conversion for chryssalids and zombies.
All missing units implemented, both alien units and xcom tanks.
All missing items implemented.
Psionic attacks implemented.
Units dual wielding single handed weapons is now represented on the battlescape.
The game now dynamically replaces sprite colours in order to represent soldier ethnicity and hair colour.
Equipment loadout saving.
Show more stats in inventory view.*
Proper A* pathfinding.
Battlescape RMB scrolling changed to MMB, renamed to Drag-Scroll, improved.
Landing Ufos/Ground Assault missions.
Ruleset support for multiple-stage missions.
Certain units now “Yell” when engaging another unit.
Enemy unit stats and armour are now affected by difficulty.
Grenade explosions now properly credit the previous owner of the grenade with the kill when a unit dies.
Units can now “fall” off edges by walking off the side of a roof or platform, and other gravity-related features are implemented.
The game now centres on the active soldier when the player closes the inventory screen.
Reapers can now reaction-attack soldiers that move into a tile adjacent to them.
Aliens will attempt to avoid areas where other aliens have died, except in base defense missions.
Various AI improvements.
Debug mode now has tile colourisation to represent AI evaluations.
Debug mode now has a time-slowing feature, which can be used for graphical or voxel debugging.
Alien Bases can now be neutralized by destroying the control room.
Mission can be won by mind-controlling all remaining units.*

* These features are disabled by default but can be enabled in the advanced options menu or by editing your configuration file.
+ These features are enabled by default but can be disabled in the advanced options menu or by editing your configuration file.
** These features can be altered by editing your configuration file.

Bugfixes:

General:

Updated translations.
Added support for more Unicode letters.
Fix for extra mouse buttons.
Various cursor
related bugfixes/improvements.
Support for Haiku folder paths.
Fix for 8 KHz WAV file (in SAMPLEx.CAT) playing.
Fixed various memory leaks.

Geoscape:

Fix for a crash bug involving an edge case where several craft were sent to intercept a single UFO.
Adjusted the length of the date column on the saved game screen to allow room for translated text.
Research consumes items properly.
If necessary, craft will now always rearm after refuelling.
Fixed error in great circle calculation.
It is no longer possible to assign armour to a soldier while they’re away from the base.
Up/down buttons now need to be held for a quarter-second before they increment by more than one.
Items are no longer removed from stores when they are researched.
Cut off input to dogfight screens when your craft is destroyed or the UFO decides to disengage.
“New research available” popups should now only display the first time you research a technology that will unlock a new branch of research.
Fixed: Can’t dismantle ANY facility if some of the attributes is overflowed!
Fixed: Busy people weren’t getting paychecks
Fixed radar detection calculation.

Battlescape:

Battlescape buttons are now unavailable during alien turn.
Fixed bug in map generator regarding nodes outside the map.
Improved map generation of alien base assualt missions.
The player no longer reveals the tile an alien is standing on when they detect an alien on an unrevealed tile.
The camera resets after non-reaction shots.
Camera now correctly centers on explosions, and properly detects explosion visibility.
Projectiles are now visible when they fly above an unrevealed tile.
Fixed various display bugs with projectiles.
UFO walls can no longer be seen through from certain angles.
Reaper Corpse tiles now arranged correctly.
Doors should no longer close on top of large units.
Players can now recover large unit corpses if the northwest piece is intact, as per the original game.
Units on stairs will now correctly reveal tiles on the level above.
Opening doors now uses time units correctly.
Fixed strange spawn behaviour.
Undiscovered aliens are no longer factored into pathfinding.
Applying stun damage to unconscious units increasing the time they will remain unconscious.
Stun damage should no longer damage items.
When units are auto-equipped for battle they will now assign as many items to their belt slots as will fit instead of stopping after 1.
Motion scanners now detect motion on all different levels in addition to the level of the scanning soldier.
Various bugfixes for large units.
Various psi-related bugfixes.
Various clipping issues fixed.
Various pathfinding bugfixes/improvements.
Various sound-related fixes.
Ethereals can now fly as intended. You have been warned.
Added some more robust behaviour around what happens when a unit is forced into an occupied tile.
Fixed a bug where items with unlimited ammo would weigh twice as much as they should.

OpenXcom - Welcome to the new OpenXcom.org!

2013-05-06T22:36:58+00:00

Boy, that was a rough ride wasn’t it? Pardon the dust, still trying to work out all the kinks, but didn’t wanna leave you all in the dark forever. You know how these things go, you promise a thing, technical issues arise, yada yada yada.

But here it is. The wiki has been updated, and we have a Twitter now to complete the social circle. However the subpages still all need to be redone, and the new version 0.9 (yes, 0.9) will come shortly. Watch this space.

OctaForge - OctaForge 0.2.0 Beta 1

2013-05-06T18:37:12+00:00

Forums:

Announcements

After a slight delay of several days, OF 0.2.0 Beta 1 was released.

This release is the result of a year and half of accumulated changes. That means there are lots of new things. This release is however not "production ready" - it's more like a taste of what you can expect later by now. I'm however switching to biweekly scheme again, so a new release will be here in roughly two weeks, addressing many of the things that are unfinished at the moment.

Let's get to the changes.

Win64 support

OF now supports Windows 64 bit builds. That means x86_64 is covered on all OSes that OF supports - that is, Windows, Linux, Mac, FreeBSD.

Tesseract

There was a migration from Sauerbraten base to Tesseract base. Tesseract is a new engine based on Cube 2 created by Lee "eihrul" Salzman. It utilizes a dynamic, deferred renderer, which means all the lights you create and manipulate are dynamic, including their shadows. That opens up new possibilities. It also supports many other nice features, such as screen space ambient occlusion, global illumination for sunlight, separate directional and omnidirectional shadowmaps, proper shadowed spotlights, HDR rendering with tonemapping and bloom, screen-space reflections for water, screen-space refractions for water, glass and alpha cubes or many antialiasing methods including SMAA (+ spatial and temporal antialiasing), FXAA, deferred MSAA/CSAA. Tesseract runs on both legacy (2.1+) and core (3.0+) contexts and doesn't use any deprecated APIs.

New Lua core library and Lua glue

The library of Lua scripts was rewritten entirely from scratch. The new API is designed to be as comfortable as possible while retaining performance. For now only the core is rewritten and the extension library is deprecated and scheduled for replacing. The new library makes heavy use of closures rather than tables, because LuaJIT can inline them - that leads to great performance and high degree of encapsulation. Where object oriented design was selected, it's prototype based, which gives you a large amount of flexibility. Every module of the new library was written with performance in mind.

The core lib is rather comprehensive and makes sure you can build on it further with ease. It includes things like a complete entity system with state variables for properties, pre-defined core entities, a signal/slot system, an action system, timers, Lua utilities (including math utils such as vectors, string utils and functional table utils).

Note that the new library is not yet completely stable, but it mostly is. It'll still undergo some changes and there are about 3 small parts still scheduled for replacement. The extension lib will undergo replacement as well.

Besides Lua-side changes, there were also changes in C++. The new glue code is simple, maps well to Lua C API and allows you to define new API functions anywhere in the code.

New GUI

The new core library also features a brand new OF widget set written directly in Lua. The new set is extensible, allowing you to write new widgets directly in Lua and also manage HUD, which the old GUI couldn't. The version in the release is more like a preview. It's complete, but it doesn't have high level widget variants and lacks a visual theme. There are also very few pre-defined menus. The next release in two weeks will bring great improvements in this regard. Generally, the new GUI is modular and prototype based. It's partially state based in that sense widgets make a tree and thus some kind of state but only exist while a window is shown.

LuaJIT

OF moved completely to LuaJIT, which means fast scripts as well as new modules such as bitop and FFI. Thanks to this performance intensive parts can be now written in Lua. The first such part is the GUI mentioned above, which wouldn't run well without the JIT. It also brings other advantages such as portable bytecode. Note that LuaJIT is the sole Lua implementation supported at this point.

Build system changes

The build system now autodetects things like architecture depending on what the compiler reports. That allows for easy crossbuilds.

SDL 2.0

We're now using SDL 2.0 exclusively. That means besides other things better input handling and native clipboard support (in things like fields/texteditors).

Removal of the run scripts

OF can now be run from both the bin_* directories and the main directory simply by launching the binary.

Return of Cubescript

Cubescript made a glorious return, now being used for configuration files of all kinds, such as models, texture packages or shaders. That means direct portability from Sauerbraten/Tesseract.

Removal of old map format support

Only the latest map format is supported now. That removed a lot of old cruft, but makes many existing maps incompatible. Please convert them through Sauerbraten first and then you can load them.

OFTL is gone

This means OF no longer requires C++11 and can be compiled even with very old compilers.

And many others...

There were many bugfixes of course, as well as lots of little features not worth naming. This time there are no binary builds available except for Windows. You can easily build on your own though. Stay tuned for the next release in two weeks.

Some screenshots:

Dan

FIFE - Weblate replaces Pootle for managing translations

2013-05-06T09:55:00+00:00

Hey everyone, few days ago we finally pulled the plug and decided to shut down pootle since apparently it didn't work for us and we invested way too much time compared to its benefits. As luck would...

BennuGD - BennuGD Packager updated.

2013-05-06T01:11:42+00:00

BennuGD Packager, the tool for generating Android's APKs from your games by Josebita, has been updated and is available for Ubuntu and Windows.

Between the changes, one of the most interesting is the inclusion of a recent fix for an incompatibility with the Andreno GPU based devices, which was published by the user herve_02 in this post on the forum. Needless to say, it's an important fix, given the quantity of devices using this GPU.

Bookmark/Search this post with

BennuGD+Packager+updated.&subj=BennuGD+Packager+updated." title="Publish this post on Barrapunto.com" id="service-links--es-barrapunto-1" class="service-links--es-barrapunto" rel="nofollow" target="_blank">

OpenGameArt - Check out Heroine Dusk

2013-05-01T17:39:21+00:00

Hey Folks!

Lead Flare developer and OGA contributor Clint Bellanger has just completed his April OneGameAMonth project, Heroine Dusk. Heroine Dusk is a fun, casual, retro first-person dungeon romp with about an hour of gameplay. Here are a few screenshots to give you an idea of what it's all about:

FLARE - 20130430

2013-05-01T00:03:00+00:00

Heroine Dusk My April One Game A Month game is complete! It's called Heroine Dusk. The sun hasn't risen in days and creatur

DusteD Games - maximumCuriosity postmortem

2013-04-30T03:25:27+00:00

Disclaimer:
As a professional software developer, my approach to software development is very different from the freestyle hackings I'm doing in both my entries and personal games, they are my venting, my getting away from keeping in line and doing things right, it's the place where I break the rules, where I explore how to do things the wrong way. These hacks are not representative of my work as a professional, I am sure the arrogant argue that people are inherently messy or tidy, and that this quality will always reflect in any work they do, I disagree, I believe there is a place for both and that exploring one benefits the other, only in chaos and noise can we truly learn to appreciate order and silence.

The LudumDare48 Entry

My second LudumDare48 ended, LD26, I once again participated in the 48 hour one-man-army compo. The minimalism theme was one I rooted for, and while at first excited about it, it soon became obvious that I did not have any idea at all what to do with it.

I don't want to spoil the game by showing the ending.

Even if I am in many ways more pleased with the result than last time, I will first focus on what when wrong.

The megashort version:

Wrong

No software design
No idea about what to do
Sleeping to much
Working too little
Silly crash bug (Related to first item on list)
No inventory (Related to first item on list)
Very little gameplay (It's more like a shared experience than a game)
More fail-states (Only time running out can give you game over)

Right

Neat little wireframe models fit the theme
Emptiness and strange music satisfies my idea of surrealistic minimalism
The game is completable and fully deterministic
If you only play it through one time, you won't ever see that it is
Very little code written
Good use of engine-functions to generate content

Different next time

More clear idea what to do (Make a design spec of sorts)
Design the clientside framwork before creating gameplay
Add more gameplay

The long and ranting version

I have never played myst, and I've always been facinated with it, maybe more the idea of myst, I'm too adhd to get into games like that, but I think they allow the developer to focus much more on story and content creation, and the style of a point and click game lends itself well to the minimalism theme in my opinion.
I started with.. A ROOM! Knowing not what to do, I added some pictures to the wall, and started the program, I found that I had forgotten to turn on texturing for the pictures. An idea.. Clicking the pictures could do that! And that's the premise of maximumCuriosity.

While the theme should be considered quite forgiving, a lack of inspiration should not. Here in Denmark, the theme was announced at 04:00 Saturday morning after a hard week at work, so I was sweetly asleep when all that happened. Waking up and realizing that "my" theme had been chosen, I went back to bed, hoping a dream would bring to me the necessary inspiration, it did not. Waking up after oversleeping left me in a confused and unmotivated state, not exactly my expected state-of-mind, as I had been looking forward to participating the whole week! Nevertheless, Jenkins was prepared, and the skeleton code was waiting. The first (and quite obvious) thing I learned was that one should not rely on discrete states for complex progression behavior. I did not really know what to expect of the game, where it was going or what one should be able to do, so implementing some kind of state-machine never really came up.. There is no one state telling that the camera is now looking at this picture, or that to reach that state, other pictures need to be activated. Instead there is a mess of "If this picture has been clicked this many times while the room is blinking and the tree is spinning" sentences, NOT at all how one should do it..
And quite frustrating to debug too. This became harder when I decided to delete one of the pictures while the game was running. The next thing that went wrong was not really spending 3 hours learning to model the tree, it was that I did not continue to model more things, much more time could and should have been spent creating content, and the task of creating content for this type of project is a quite rewarding one, however again, a complete lack of direction did nothing to help me. Creating something you do not know what is is a frustrating and interesting experience. I though it could be a freeing experience because "hey, it will be whatever it becomes" but nothing comes out of truly nothing. The next thing to go wrong, where a series of strange and random crashes.. The first one I found was that I had forgotten to protect a (particle-system scope wide) variable containing the top datastructure of all particlesystems, this was an engine bug, I've called it psys, and much fun ensued when I created an array of structures called... psys in the game, this not-so-particle-related datastructure was overlaid ontop of the particle systems, but C, being the forgiving language it is, gladly did as it was told, and wrote particle-data into this memory-space, and all was good in the word, until ofcause, I took grab of one of the (game-scope) psys structures and wrote data into it, poof, particlecode crashed hard (who can blame it). Next up: Double-freeing data, this one was not really that difficult to find, I had removed a picture from the game-world at one point, then during the transition to the portal, I removed ALL pictures (including the one I already removed). Next up: random crash bug.. I've yet to find this, and not really sure what it is.. I did run the game through valgrind a few times, and apart from a few invalid reads (corrupting not-used uv maps during model loading), I did not found anything, and I also did not encounter the bug, I hate that kind of bugs.. However it seems less common with debugging symbols, so it's probably overwriting internal data, not good, but well.. Can't have it all, bugs are difficult to find when they don't show up consistently. The engine is kind of crap, but that's part of the fun! ;) Next time I will definitely spend some time coding a basic framework for progression of gamestate. I may start building something into the engine to allow easy management of player inventory, atleast have the GUI support addition and removal of objects to a auto-resizing widget.

Not that much to say, I still believe that walking through the game is an interesting experience (the first time!).

jMonkeyEngine - The HeroDex GUI – jME3 User Interfaces

2013-04-27T21:12:57+00:00

The HeroDex GUI – jME3 User Interfaces

Table of contents

Nifty is no longer the only choice for creating a GUI within jMonkeyEngine 3, however it is the oldest and the most fully featured GUI library.

The three main choices are:

Nifty – A very long running and highly featured library with a good track record for support and maintenance. The API can be cumbersome but it works well when you work with it and the results are impressive. There is also a new update coming soon which looks likely to give a large improvement to performance.

TonegodGUI – The most recent entry to the GUI options this library already has an impressive range of features and very active and enthusiastic support, although no proven longevity as yet.

Lemur – The main selling point of Lemur is the ability to embed GUI elements into the scene graph, allowing them to exist in the world. It shows much lower activity levels than either TonegodGUI or Nifty but the modular nature of its components means that you can choose to use just some sections of it as required.

These libraries are not exclusive, you can mix them in order to get the strengths of each. For example our GUI is primarily written using Nifty, however there are some areas where we needed panels displaying in the scene graph. For those we took one of the components from Lemur and used that for the embedded panels.

For HeroDex Nifty was the only option available when we started, so the choice was simple. For a new project we would recommend that you evaluate all three libraries keeping in mind the requirements of your project. It would not be impossible to switch afterwards but it would involve a lot of rewriting, as all three libraries have very different APIs and design philosophies.

This article has been split into a number of sections. For the most part each section is self contained so please feel free to jump to the section that interests you.

GUI Design, Look and Feel

When designing a GUI you need to think about the overall style that you are presenting. It needs to tie in with the feel of the game while also presenting the information in a clear and consistent way. Do not be afraid to experiment with a few different looks until you find the correct one, but when you have settled on something then make sure you update everything to be consistent.

For HeroDex we experimented with a few different approaches, for example the metallic panel with glowing border from the main logo looks good. Perhaps that would work for the in-game GUI too?

In fact when we tried it the results were not so good. It was hard to make it work well at variable resolutions, scales, and aspect ratios. It also tended to dominate the screen rather, which while it is good for a title is not so good for an in-game GUI.

The final design we settled on was much more minimalist and can be seen here. It is actually mostly built up from just a few images, and then a few icons. The main images are:

and

Can you see how these Images are used in the screenshot above? Through use of the Nifty ImageMode parameter these are stretched out to form the various buttons and panels on the screen.

The first pair are the buttons in their un-pressed and pressed states. By having a consistent look and feel for every press-able item it immediately lets users know where to try clicking.

The second set of images are used to build vertical, horizontal, and rectangular panels. You can find examples of all three in use on the screen above.

These images are copyright Zero Separation and are part of the look and feel of HeroDex, so we are sorry but no you can’t use them The nifty style libraries though present a range of different images that you are free to use in your projects.

In these examples you can see how by using the ImageMode parameter you can use really very small images to form your User Interface and have the results look impressive. You can also use them to build transparent interfaces very easily by using PNG images with transparent areas for your panels.

Nifty comes with a number of built in styles such as NiftyStyleBlack which include a range of panels and buttons that you can use for your project. These styles work well and look professional so I would suggest using them to start with and then you can always modify them over a time to customize the look and feel to your liking.

Architecture: App States and Screen Controllers

Ideally only one part of the system should be deciding what your application is doing at any one time. Unfortunately Nifty and jME3 both provide their own unconnected mechanisms, in the form of Nifty ScreenControllers and jME3 AppStates.

We tried a few approaches but the final pattern that we settled on and that we recommend is that Nifty controls the process via gotoScreen. When the screen is started we then attach the appropriate appStates for that screen.

We create a singleton class to be both an AppState and a ScreenController.

public class ExampleState extends AbstractAppState implements ScreenController {

    private static final ExampleState instance = new ExampleState();

    public static ExampleState getInstance() {
        return instance;
    }

    private ExampleState() {
    }

We do not use the singleton pattern for every AppState but we find it very useful for these cases where you have one specific state of the game and then want to access it from anywhere in the code. It also avoids potential synchronisation problems where you end up with multiple versions of the AppState and or ScreenController in various parts of the code. Instead you know there is one and always one.

To make sure Nifty knows about the screen controller you need to register it before loading any screens or XML:

nifty.registerScreenController(ExampleState.getInstance());

Now we allow Nifty to control which is the current screen by using the nifty.gotoScreen(“example”) method. In our case we created a central class that knew the names of all the screens and we call a method in that class with an enum in order to issue the actual change. We find that removed the risk of potential typos in the names of screens, particularly ones that you might go to from multiple points in the code.

When the screen starts from Nifty it calls the callback method onStartScreen in the ScreenController. That method then attaches the state to the state manager (or enables it if it is already attached).

public void onStartScreen() {
    stateManager.attachState(this);
    screen.getRootElement().startEffect(EffectEventId.onCustom, null, "startScreen");
}

public void onEndScreen() {
    stateManager.detachState(this);
}

You will note that we start a custom effect called “startScreen” in the onStartScreen handler. This is because the onStartScreen method is only called when all start-of-screen effects inside Nifty have completed. This means for example if you have the GUI fading or moving into position then the AppState change will only happen once the start-of-screen effects have completed. Instead create custom effects with “startScreen” as the custom key and this call will trigger them all after the screen has switched.

The End of Screen effects work the same way, but fortunately in this case that is the behaviour we desire, so the sequence becomes:

nifty.gotoScreen(“example”);
Current screen end of screen effects play
Once the effects have all finished onEndScreen is called and the AppState is detached or disabled
Nifty switches to the new screen
OnStartScreen is called, the new AppState is attached or enabled
The custom “startScreen” effect is triggered and starting effects are played

The big advantages of this architecture is that you do not have any interdependencies between screens, or any special transition logic. You don’t need to know what the current screen is, you just tell Nifty which screen you want to be displayed now and then everything is handled automatically.

Mixing GUIs: Lemur and Nifty

One of the main limitations of Nifty is that all its elements are always drawn on its own GUI node and always after the scene and before anything added to the jME3 GUI node. This is fine for 99.9% of use cases, but occasionally you need more fine control.

In this screen shot we actually have both Nifty and a small component from Lemur working together. The main interface is provided using Nifty, but the two floating panels in the center are using tbtQuad from Lemur with a jME3 billboard control attached to them.

Why are they done like that?

This screen shot demonstrates why. If they were done as standard Nifty panels then they would always appear in front of everything else, whereas in this case we needed them to be visible but we also needed the cards to be able to pass in front of them. You can see that by applying the same image to the tbtQuad and the Nifty panels and by using the same font for the text we were able to make them look the same, even though they were using a completely different mechanism behind the scenes.

You can mix elements of the different GUIs and keep a consistent look so long as you take care to do so. Ideally though you would find one GUI and use that everywhere you can as it helps with maintenance in the long run.

XML Versus Builders

One of the big decisions when using Nifty is whether to define your screens using XML or using builders. For single-developer projects the XML does not really add any large advantages, although it does help define the structure of your project by laying out all of your screens ahead of time to then allow gotoScreen to be used to switch between them.

What we found worked well is to define all of the main screens using XML, however for all the popups and more dynamic elements that we show we use Builders to construct them dynamically. This gives us flexibility where we need to while having the main screens defined ahead of time.

It also removed the link between popups and certain screens, allowing us to open up our own popups from any screen and even when required recreate them after a screen transition.

NiftyPopupState is how we provide our own popups, unfortunately our implementation is too tied to the HeroDex look and feel to be published. However we will outline the basic principle with some source snippets to get you started. The basic concept is to have an AppState that handles the custom popups. When adding a popup it creates a layer on the current screen if it does not already exist – and then adds the popup as a panel inside that layer.

Whenever the screen changes it creates a new layer (deleting any previous one it might have created on that screen) and then recreates any popups that are still needed on that new layer. All the popups implement an interface:

private interface NiftyPopupInternal extends NiftyPopup {
        long getId();

        /**
         * Called to create the popup for the new screen whenever the nifty screen
         * changes.
         * 
         * @param s The screen to create the popup for
         * @param layer The layer to receive the popup
         * @return true if the popup was created, false if it should be removed
         */
        boolean createForLayer(Nifty nifty, Screen s, Element layer);

        /**
         * Actually handles the deletion of the popup when it is no longer needed
         */
        void remove();

        /**
         * Called each frame to allow the popup to update. Do not remove the popup
         * in this method. Remove will be called for you if you return the correct
         * UpdateResult.
         * 
         * @param tpf
         * @return An update result to say whether the layer needs a relayout,
         * and whether this should be removed.
         */
        UpdateResult update(float tpf);

        /**
         * If a panel with id "NiftyPopupState_"+getId()+"_"+button is placed in
         * the popup and made visible to mouse then this callback will be called
         * automatically with the extracted button name whenever the button is
         * clicked.
         * 
         * @param button 
         */
        void notifyButtonClick(String button);

        /**
         * If a textfield with id "NiftyPopupState_"+getId()+"_"+button is placed in
         * the popup and enabled then this callback will be called automatically with 
         * the extracted field name whenever the text within the field is changed.
         * 
         * @param button 
         */
        public void notifyTextFieldChanged(String button, TextFieldChangedEvent event);

        /**
         * If a checkbox with id "NiftyPopupState_"+getId()+"_"+button is placed in
         * the popup and enabled then this method is called whenever it is checked
         * or unchecked.
         * 
         * @param button 
         */
        public void notifyCheckBoxChanged(String button, CheckBoxStateChangedEvent event);
    }

public enum UpdateResult {
        CONTINUE,
        RELAYOUT,
        REMOVE
}

The update loop in the App State looks something like:

public void update(float tpf) {
        if (getNifty().getCurrentScreen().isNull())
            return;

        if (currentScreen != getNifty().getCurrentScreen()) {
            createLayer();

            for (Iterator&lt;NiftyPopupInternal&gt; it = popups.iterator();it.hasNext();) {
                NiftyPopupInternal popup = it.next();
                try {
                    if (!popup.createForLayer(getNifty(), currentScreen, currentLayer)) {
                        popup.remove();
                        it.remove();
                    }
                } catch (Exception ex) {
                    logger.log(Level.WARNING, "Failure creating popup for layer", ex);
                    it.remove();
                }
            }

            currentLayer.layoutElements();

        } else {
            Element layer = screenLayers.get(currentScreen);

            boolean relayout = false;
            for (Iterator&lt;NiftyPopupInternal&gt; it = popups.iterator();it.hasNext();) {
                NiftyPopupInternal popup = it.next();
                try {
                    UpdateResult result = popup.update(tpf); 
                    if (result == UpdateResult.RELAYOUT) {
                        relayout = true;
                    } else if (result == UpdateResult.REMOVE) {
                        popup.remove();
                        it.remove();
                    }
                } catch (Exception ex) {
                    logger.log(Level.WARNING, "Failure updating popup for layer", ex);
                    it.remove();
                }
            }
            if (relayout)
                layer.layoutElements();
        }
    }

We wrote an abstract implementation of the interface that provides utility methods to do things like construct buttons, etc. It also provides a method:

public String buildButtonName(String button) {
            return "NiftyPopupState_"+id+"_"+button;
        }

If any clickable panel or control is added then its name is built using buildButtonName – a number of NiftyEventSubscriber methods (don’t forget to subscribe the AppState to Nifty for annotations!) then pick up those actions and forward them to the appropriate popup for processing.

@NiftyEventSubscriber(pattern="NiftyPopupState_.*")
    public void buttonClicked(String id, NiftyMousePrimaryClickedEvent event) {
        try {
            int index1 = id.indexOf('_')+1;
            int index2 = id.indexOf('_', index1);
            long popupId = Long.valueOf(id.substring(index1, index2));
            String button = id.substring(index2+1);

            for (NiftyPopupInternal popup: popups) {
                if (popup.getId() == popupId) {
                    popup.notifyButtonClick(button);
                    playButtonClickSound();
                    break;
                }
            }

        } catch (Exception ex) {
            logger.log(Level.WARNING, "Error processing popup button click for "+id, ex);
        }
    }

Conclusion

Nifty has its quirks and limitations but nothing stops you producing responsive and professional looking user interfaces using it. With the growing competition from TonegodGUI and Lemur the possibilities and options are improving all the time, so you will be able to find something that suits you. jME3 has a rich selection of interface options available so you are limited only by your imagination and your design skills, not by the engine!

FIFE - Spam in the forums

2013-04-25T21:18:00+00:00

Hey everyone, We're sorry to announce that we had to disable user registrations on our forums again. The reason is the huge amount of spam registrations every day. If you'd like a personal account, ...

OpenGameArt - If I could work on OGA full-time, what would people want me to code (or do)?

2013-04-24T18:44:39+00:00

Once my current project is over, I'd like to start looking into ways to fund work on OGA as a full-time job, which will require several thousand US dollars per month (I've got a baby on the way, so I need to be working for more than subsistence wages in order for this to go over okay with my wife). There are a lot of feature requests and bugfixes that have been pushed to some indefinite point in the future that I call "when I have time," many of which you can see in the feedback forum.

OctaForge - OctaForge beta 1 coming soon

2013-04-24T09:56:35+00:00

Forums:

Announcements

We're finally doing it - OctaForge beta will be released on May 1. It includes numerous new features, the largest one being Tesseract, a brand new dynamic (deferred) rendering engine, as well as redesigned scripting lib, LuaJIT, fully scripted GUI, SDL2 and various other changes all over the place. This release will include all the work accumulated since the last release very long ago, so expect this to be a big one.

A detailed announcement will come with the release itself, showing a better list of changes. Also, after this release new ones will come on regular basis again - most likely biweekly or monthly scheme (depending on how things go).

So yeah - unless things go terribly wrong, expect a release in a week. I'm not yet sure how I'll resolve binaries, but expect it to be working on Windows, Linux, Mac and FreeBSD at least, on both 32bit and 64bit variants (Solaris may work as well, but it's untested).

Dan

FIFE - Pootle downtime

2013-04-22T20:09:00+00:00

Hey everyone,just a quick shout to everyone working on the translations: As you may have noticed our translation server Pootle has been down all weekend. We are having some trouble getting it back to ...

OGRE - Ogre 1.9 RC1 is here!

2013-04-21T21:56:17+00:00

Good news!
Some days ago we finally tagged our official source code repository with “v1-9-0RC1” which of course means to we reached a development state that we consider feature-complete for Ogre 1.9. As usual we first release a Release Candidate (RC) version that – if no major issues are found or any upcoming issues were fixed – will be declared final/stable and then become the official current Ogre version. So please: Wherever possible switch to the new version to give it a try and report any issues you find to our Ogre JIRA tracker so that we as the team can tackle them.

The download section has been updated to point to the newly created Ogre 1.9 RC1 SDKs that can be downloaded by those that do not want to build the new version from source themselves. Otherwise, as usual follow these instructions (you need to grab the source directly from our BitBucket repository since we did not prepare any source bundles yet).

Lastly, the mandatory changelog. We will just list some of the major points here, the detailed list can of course as usual be found in the wiki.

Changelog highlights:

New LOD Volume Rendering Component with LOD from GSoC 2012

Terrain Improvements from GSoC 2012

Android platform support

Windows Phone 8 platform support

Windows Metro / WinRT support

OpenGL3+ Render System (still experimental and under heavy development)

Improvements to all Render Systems, e.g. DirectX11 from GSoC 2012

multitude of bug fixes

…

What’s next?
With Ogre 1.9 out of the way we can now focus on the upcoming, major release Ogre 2.0 which will entail a lot of internal core optimizations to get Ogre’s speed up to the levels to be able to compete with other rendering engines. Quite a bit of profiling and brainstorming was already done to get us started. One other big step in that direction will of course be this year’s Google Summer of Code where we will concentrate on those areas (for additional topic proposals see this topic list the dev team compiled). If you want to help, just join into the discussion. We are glad about all the support we can get!

BennuGD - How to port your games to OUYA

2013-04-21T19:24:26+00:00

Great news for those who are looking forward to OUYA!

PiX Juegos just published 2 of their games made with BennuGD into OUYA's game market, which means OUYA compatibility is guaranteed :)

Bookmark/Search this post with

How+to+port+your+games+to+OUYA&subj=How+to+port+your+games+to+OUYA" title="Publish this post on Barrapunto.com" id="service-links--es-barrapunto-2" class="service-links--es-barrapunto" rel="nofollow" target="_blank">

Castle Game Engine - Development: better Mac OS X support, networking, CAD level 2, more

2013-04-19T12:00:00+00:00

Hello everyone!

There is a contest for best open-source project on Polish portal http://www.spinacz.edu.pl/. Please take a moment to vote for our Castle Game Engine!
Our engine was submitted to devmaster.net, with lots of information and screenshots. You're welcome to review and rate us there!
We also want to remind that we have a Google+ page about our Castle Game Engine, you can follow it to see (a little more frequent) news about our engine development.

New engine features in development:

Mac OS X with native look. This is already much more user-friendly than our previous GTK-based releases for Mac OS X. See development details. Hopefully, this will allow us to release next view3dscene as normal Mac OS X application, that will be trivial to install for Mac OS X users.
Network (http) support. Most "FileName" parameters and properties are now URLs. You can use protocols like file: and http: and data: everywhere, and of course http will be automatically downloaded. Try view3dscene from snapshots, enable "Preferences->Download Resources From Network" and then use menu item (Ctrl+L) to load URL, or pass URL on the command-line.

This is a little user-unfriendly, as the downloading is blocking (the process waits for the download to finish, instead of letting you enjoy the game and download in the background; there isn't even any nice way to cancel the download, or even notification about it, except for --debug-log message). For this reason, it is disabled by default: you have to explicitly allow it by "Preferences->Download Resources From Network" (in code: CastleDownload.EnableNetwork variable).

For some test scenes on the Internet, try e.g. Inline demo or Texture demo or AudioClip demo. (from ConformanceNist X3D Examples Archive). Or see our demo models through http, by browsing through SVN http link.
view3dscene automatically downloads the model, as well as all linked resources (textures, inline models, sounds, scripts etc.). You can also use VRML/X3D Anchors to jump to any URL (for example, you can jump from a local file to a model available through http). Also data: URI handling is now more uniform. Also the engine uses now MIME types more, instead of merely file extensions. This makes us work with http transfers, and improves cooperation with data: URIs.
In a game, you could also use URLs inside files like level.xml and resource.xml. For example, you could distribute now a level.xml file that contains URLs to levels on your server, downloaded each time.
Clipboard (Ctrl+C, Ctrl+V, Ctrl+X in message boxes, especially handy to copy/paste URLs). For developers: use Clipboard.AsText property. Implemented for CastleWindow WinAPI, GTK, LCL backends.
CAD level 2 support (CADXxx nodes).
Improvements to 2D rendering. They also workaround crashes on some Mesa 9 drivers.
Support for 8 and 16 samples for anti-aliasing, there are (at least NVidia) GPUs supporting it.
Renamed our event Idle to Update.
This reflects our implementation and usage of this event clearer. This event is for continuous tasks, called even when the application is not "idle" (when application is processing something, like mouse moves). Our Update event doesn't correspond 100% to normal (as used by LCL or GTK) meaning of "idle" (which is also evidenced by code if TCastleWindow LCL and GTK backends, that cannot simply use LCL/GTK "idle" concepts to implement our Update).
TCastleControl.AggressiveUpdate* are removed. The (simplified and improved) version of this mechanism is now always "on" and automatically makes mouse look work better. It's still not perfect (it seems LCL event loop is just too slow to process events during mouse look fast enough), but it's better now. If you want perfectly smooth mouse look, you should still consider TCastleWindow instead of TCastleControl.

OpenXcom - New website, new build, full playability

2013-04-17T17:37:26+00:00

Coming within the next two weeks, stay tuned.

FLARE - 20130417

2013-04-17T16:02:07+00:00

Flare Minions I recently approved code (contributed by Ryan Dansie) that adds basic Minions support in Flare. This will all

OGRE - Ogre3D’s guest post on “Sourceforge Projects of the Week”

2013-04-17T14:43:55+00:00

As Ogre3D had been selected as one of the “Sourceforge Projects of the Week” we were given the opportunity to write a guest post on their blog, and of course we could not pass on that. So head over there, to have a look, especially at the part “what is going on right now” for some Ogre3D news:

→ Guest Post: Ogre3D – a quick overview

As part of it, we also created a new collage showcasing some of the eye-candy powered by Ogre. Hope you like it!

FLARE - 20130412

2013-04-12T18:01:55+00:00

Upcoming Tasks Everything is coming together for the Flare engine. It's an exciting time, and there's so much to do! If you

DusteD Games - Making Solder of Fortune run with any resolution on Linux

2013-04-11T14:34:07+00:00

So.. I wanted to play some SoF, a game I enjoyed many years ago.
Loki made a Linux-Native binary, and, with the update, it actually still works pretty well!
Two things:
1. The resolution is limited to 1600x1200.
2. If you are using pulseaudio you need the padsp script.

After messing around in gdb, I determined the structure of the video-mode datastructure and wrote a hook to LD_PRELOAD which allows you to use any resolution you want.
Be aware that the menu is not looking correct in wide-screen resolutions (reading mail and such requires you to change into a 4:3 resolution), but the game works just fine.

You can download the small hack at dusted.dk/SofResolutionHack.tar.gz
It is only 2 kilobytes. Both the source-code and the compiled version is there, along with readme telling you how to use it. This hack also includes the pulseaudio fix.

SoF running at 2560x1440.

And now.. back to what I wanted to do in the first place.. play the damn game in full-screen (yes, I have a screen that can ONLY run that resolution..)

FIFE - Project Management Change

2013-04-10T20:47:00+00:00

Hey everyone! We'd like to inform you that there was a change in the project management and give you a short, general update. Project Management First we want to thank Nightraven for his efforts an...

jMonkeyEngine - Eric Potter @iwgeric joins the core team

2013-04-10T11:24:15+00:00

It’s been a while

We’re closing in on almost 2 years since we last admitted a developer into the core team. There were some pretty simple reasons for it. Firstly, the team has been working really well as it stands, so we didn’t want to mess with that vibe. Secondly, we didn’t want to initiate another member of the crew just as we were closing in on a stable release, err…

Monkey vs Droid

Aaanyhow, in essentially all aspects except labeling, we’ve been stable for a while now, and it’s in no small thanks to Eric, better known as @iwgeric on the forum. You’ve probably seen him in almost every Android thread. And that reminds me of a third reason why we took our sweet time, because we’ve tried to get Android developers more involved with the jME3 core before, and they’ve always been short-term relationships with messy endings. Android can be a tricky little bugger, but Eric has overcome every obstacle the droid and monkey combined could throw at him.

Please join us in a big congratulations to Eric for being the prime example of a jMonkey that he is.

Leave your comments in the forum.

Irrlicht - Monthly Screenshot Contest – March 2013

2013-04-10T07:14:17+00:00

Here is the winner of the Screenshot of the Month contest for March: Simson with his ”Project Crash Car Jungle map test” screenshot. As always, you can find the screenshot and all contestants in the forum and the gallery.

Crystal Space - GoogleSummerOfCode2013

2013-04-09T07:48:02+00:00

We did it again! Crystal Space got accepted as an organisation for Google Summer of Code 2013 (http://www.google-melange.com/gsoc/homepage/google/gsoc2013). Google Sumer of Code is a yearly event where Google gives students a chance to do a paid summer job for Open Source projects. So if you are a student and are interested in earning a bit of money during the summer then you can apply for any of the 177 accepted projects. More specifically you can apply for Crystal Space. You can apply (both as a mentor or as a student) at the Crystal Space Google Summer of Code site (http://www.google-melange.com/gsoc/org/google/gsoc2013/crystalspace). From there you can also visit the ideas page. But of course you are free to suggest your own ideas too.

We're looking forward to working with you!

FIFE - Summer of Code application rejected

2013-04-08T17:04:00+00:00

Hey everyone, we are sorry to inform you that this year, Unknown Horizons and FIFE were not accepted as a mentoring organization for Google Summer of Code. Students who were planning to apply for ...

BennuGD - Play OGG/Theora file formats with mod_theora module

2013-04-07T00:43:21+00:00

Josebita has been working on a new module for Bennu that allows you to play Theora videos in 16 and 32 bpp. The great news is that the videos can be manipulated as any regular graph loaded in Bennu!

Here is a demo of how it works: http://vimeo.com/63441778

You can download an axample here: https://www.dropbox.com/s/rs7hx4w9twz9oa6/bennugd-module-theora_preview.... and follow the forum topic here: http://forum.bennugd.org/index.php?topic=3524.0;topicseen

The library is released under BSD license, which required only to mention the credits in a readme file.

Bookmark/Search this post with

Play+OGG%2FTheora+file+formats+with+mod_theora+module&subj=Play+OGG%2FTheora+file+formats+with+mod_theora+module" title="Publish this post on Barrapunto.com" id="service-links--es-barrapunto-3" class="service-links--es-barrapunto" rel="nofollow" target="_blank">

FLARE - 20130405

2013-04-05T22:01:56+00:00

Change in the flare-game repo We made a big change to the flare-game repo today, hopefully to help distributors/packagers i

iodoom3 - Migrated to GitHub

2013-04-03T01:44:31+00:00

I was talking with Zakk the other day and we decided that neither of us wanted to maintain the Gitorious site. Gitorious proved to be hard to maintain and even after several hours worth of work, our Gitorious installation was still somewhat broken. Considering there are several other free sites that are dedicated maintaining Git repositories, it no longer makes much sense for us to do it too.

In recognition of this, we decided to move iodoom3′s repositories to GitHub! The release repository is located at http://github.com/iodoom/iod3. All new branches should be forked from this repository and all pull requests to should be submitted to this repository.

Effective immediately, git.iodoom.org is read only. You can clone, but you should not be able to push. The Gitorious on git.iodoom.org will be shutdown on April 30th, 2013. Please use GitHub instead.

All 22 repositories from git.iodoom.org have been cloned to http://github.com/iodoom-gitorious/. This GitHub organization is just for hosting the old Gitorious repositories. If you want to modify them, please fork them. To switch to GitHub from your existing clone, type in the following:

git remote rm origin
git remote add origin git@github.com:<username>/<repo_name>.git

We recognize that not a whole lot has been happening with this project. Fortunately, Zakk informed me that after the next ioquake3 release, he plans to start pulling changes from your repositories!

jMonkeyEngine - 4Realms proudly presents CHAOS

2013-04-02T18:24:35+00:00

Hello Monkeys,

I would like to present our project called CHAOS, which is built using this awesome engine: jME3.

First of all, I wish to thank both the jMonkey community and the jMonkey core team for your great support and your amazing stuff. CHAOS could not have been raised from the ground without your help. Thank you all for the billion of wise advice!
Since 1 year, we have discovered that Java could be used to produce nice games and have since chosen to build our project on the jME3 SDK. (amazing platform btw !)

We are now able to play our own game and although there is still a lot of things to do, it is time to share some of our results !

A quick presentation of our team :

- Who is 4Realms ?

4Realms is an independant game development studio, created 2 years ago by 4 friends : one Game Developer, one 3d & Animation leader, one 2d artist leader, and one Network engineer.
We are proud to present our first video game CHAOS !

- What is CHAOS ?

The game could be called an Action/Role Playing Game, in a Heroic fantasy world.
The closed beta is still on going.

CHAOS is from a Rogue-Like inspiration, with random generated dungeons and a dynamic game experience.
We were looking for a user friendly game structure, making the game interesting, unique and easy to play but of course, the challenge will also be present in CHAOS.
The story takes place in Silmerie, where men have to fight against an overpowered enemy. It is a round trip into the Darkness!
The game starts in Fort Merals, the first place you will have to defend, through some awesome and innovative quests, which lead the player deeper and deeper into the Nimde’s Fault.

For more details about the game, I recommend you to take a look at our web site.
For lastest news, screenshot and vids, see our blog.

- Let’s talk about Game play…

CHAOS will offer dynamic and tactical actions.
Some skills demands positional gameplay technique as they take care of your target’s position, moreover, short skills cooldown have been implemented in order to really give rhythm and intensity to the game.
The book of Skills allow the player to customize everything relative to its skills, in an original and advanced way.

- The Craft, interactive, at the earth of Power

In CHAOS, the craft will be very important for players who care about optimization and quality of its equipment, but also for everyone who wants to feel the mastery flowing through their hands.
Several crafts will be available, such as Weaponsmith, Enchanter, or RuneMaster.
Brand new and original, these crafts will offer liberties, experiments and the pleasure of creating powerfull unique items, shaped by your own hands.
Keep in mind : you will have to rely on your own strength alone to be the most famous crafter !

- PvP ? Yes ! This is WAR !

Players, splitin 3 balanced teams, will fight for realms objectives on random instanced battlefields.

A lot of stuff will be offered as PvP rewards, like unlocked skills, equipment, character bonuses etc…
Obviously, PvP contents can only be accessed with a broadband internet connection.

- Why working with jME ?

We were looking for a free game engine for our first video game, supported by a large and active community. It helps !
When we heard about jMonkeyEngine, we decided to give it a try and whoua!!
In a few days, our team had fun on a generated heightMap, at moving some blue cubes on mountains. I guess everyone have tried that !
Watching some amazing projects achieved with the jMonkeyEngine convinced us that this engine was the right one.

- JMonkeyEngine feed back

CHAOS is fully developed with the jME3 SDK, which is user-friendly and really fits all our wishes.
An easy models and textures management through the awesome J3o format also helps us a lot with assets libs.
Then, as far as we are concerned, the only weakness of this engine is its lighting system, but something is going to be done for improving that stuff.
By the way, we used some simple tricks to get a nice workaround and avoid most of lighting limitation.

- So How CHAOS works ?

CHAOS can be played solo or in multiplayer mode.

It works with 2 programs, a Server and a Client.
You can run the client on the same machine that is hosting the game, or on an other PC, while server is hosted on a dedicated machine.

For our graphical stuff, we have chosen to use NiftyGui for our HUD part (many thanks to Void256 : NiftyGui does a very nice job !)
For 3D part, all models are created and animated with Blender.

Here is some of currents implemented techniques/gameplay features :

- Networked game (from 1 to 4 players) using the famous SpiderMonkey.
- Full working GUI & HUD powered by NiftyGui 1.3
- Simple ParticleEmitters for all game FX. (we are not friendly with shader programming )
- Dynamic lighting added to FX

- Custom AI for NPC
- Random built dungeon for each new game
- Third person ChaseCam
- Multiple characters classes for multiple gameplay
- GameMaster settings to choose the general game difficulty and length (for the moment, using Swing libs)
- and more…

We planned to produce a demo on the next 3-6 months, when we will reach the Open Beta state !

As it’s commonly said, stay tuned !

Crystal Space - IndieGame

2013-04-02T06:14:49+00:00

I am planning to start an Indie game project. The plan is to go commercial but keep all assets and source code free. I'm looking for people to help me with this. Artists and coders. Read all about it here on my blog:
http://projectares.blogspot.be/2013/03/going-commercial.html

Ember - Exporting and importing in Ember

2013-04-01T21:56:27+00:00

The last couple of weeks I've been working on improved authoring capabilities in Ember and Cyphesis. One of the most important features is the ability to both export and import entities from and into servers.

This allows a world author to save a snapshot of the world to local disk, and later on restoring the world as it was in the snapshot. There are multiple usage scenarios, but one that immediately springs to my mind is the improved ability to perform iterative world editing. By being able to reset the world back to a known working state it's much easier to try out new configurations and behaviour.

All work is currently being done on separate branches of both Ember and Cyphesis. The following video shows the status of this feature some weeks ago; it has progressed even more since.

OpenGameArt - OGA to Purchase, Monetize Battle for Wesnoth

2013-04-01T16:22:53+00:00

We here at OGA are pleased to announce that, in response to incredible user demand, we will be purchasing the rights to the popular FOSS (Free and Open Source Software) game Battle for Wesnoth in order to address the frequent user complaint that Wesnoth is insufficiently monetized.

Users are already very excited about this development.

FLARE - 20130331

2013-04-01T04:01:35+00:00

Flare v0.18 Released Release Summary 10 Equipment Slots, up from 4 (and easily configurable) Starting "Class" choic

FLARE - 20130330

2013-03-31T02:02:55+00:00

v0.18 Release Candidate I'm putting this link up temporarily for testing. You are welcome to try it. If you get any issues

Bullet Physics - Bullet 3.x teaser and GDC 2013 talk

2013-03-28T16:23:35+00:00

Bullet 3.x will feature a 100% GPU accelerated rigid body pipeline with various parallel broad phase algorithms, convex and concave triangle mesh and several parallel solvers. Here is a teaser video for my GPU rigid body talk at GDC 2013 this Thursday March 28, 2.30PM.

See http://schedule2013.gdconf.com/session-id/822773 for more details.

When will this be available? Soon!

Spring - Spring 94.0/1

2013-03-26T13:08:06+00:00

Release Message
<singing>Step by step ...</singing>

Kudos
Again, thanks everyone for your contributions!

Download links:

Major changes:

more random UnitIDs again
many bugfixes
some new Lua functions regarding weapons
Assimp fixes
ETC1 support for ground textures
...

Full changelog here.

Statistics: Posted by jK — 23 Mar 2013, 20:19 — Replies 99 — Views 5584

Allegro - Allegro 5.1.6 (WIP) released!

2013-03-24T05:15:15+00:00

OpenGameArt - Voluntary Copyright Expiration

2013-03-22T20:29:52+00:00

Many of us who are involved in the discussion about copyright would like to see copyright law in America as it was back in the early 1800s, shortly after the founding of the United States. The shorthand for this is the "founder's copyright", and it's a counterpoint to the media cartels stretching copyright 70+ years out past the death of the original author so they can keep people paying for what is clearly our shared culture at this point (for instance, Winnie the Pooh, and the song Happy Birthday).

OpenXcom - Jade stream later tonight!

2013-03-22T20:24:24+00:00

What better way to make sure there are no bugs left than a Jade Stream? As usual no specific time, but it should happen in a few hours. I’ll post a link here when it goes up and page you if you hang around IRC.

Update: And the stream is over, Jade finished OpenXcom without any crashes! Some bugs were still found though…

FLARE - 20130321

2013-03-22T05:01:53+00:00

String files update for bug fixes Today I approved an update of the translation files related to various bug fixes -- our e

OpenGameArt - Let's put away the forks and dongles and talk this over like civilized people.

2013-03-21T22:30:55+00:00

An opening note: This blog entry isn't directly related to art or gaming, but I think someone needs to take a stand for the middle ground, and I have this soapbox here. Apologies to many of you who didn't come here to read this stuff. Feel free to ignore it as you see fit.

FLARE - 20130319

2013-03-20T05:02:01+00:00

Iron Buckler Besides splitting armor into more slots, we've also added additional armor tiers into Flare v0.18. This new Ir

OpenXcom - Feature freeze

2013-03-18T20:42:35+00:00

To make sure the next release comes out within this century, we are instituting a feature freeze. The priority right now is to fix all remaining bugs and finish any remaining features. Any new feature additions, code improvements, suggestions and whatever else will be postponed until the next release.

To help speed this process along, please test the latest Git Builds in a variety of platforms and scenarios. Don’t just keep loading the same old saves, but make new saves, new missions, new setups, etc. Prioritize reporting any critical bugs and crashes, and save any cosmetic problems for later.

FLARE - 20130317

2013-03-18T07:02:42+00:00

Animal Figurine Artifacts I finally finished up this set of four animal figurines. In Flare these are powerful artifacts th

FLARE - 20130315

2013-03-15T21:02:27+00:00

Flare v0.18 ready for Translators The string freeze is now in effect for Flare v0.18. This just means that we won't change

Spring - Spring 93.1 / 93.2

2013-03-14T22:42:49+00:00

Release Message
You may not believe it, but this is a brand new Spring version, and although it may have problems under the surface, it has been high-gloss polished with many extra layers of varnish

Kudos
Thanks everyone for your contributions!

Download links

Windows installer
Windows portable
Linux32 static (note: updated to 93.2 hotfix)
Linux64 static (note: updated to 93.2 hotfix)
Source (tar.lzma)
Source (tar.gz)
MacOSX

Changes

Mostly bugfixes
Changelog

Sometime in the near future, even bigger battles may appear on an unsuspecting computer screen in your vicinity. Stay tuned for Spring MT.

Statistics: Posted by zerver — 12 Mar 2013, 22:21 — Replies 118 — Views 5170

FLARE - 20130313

2013-03-14T05:03:10+00:00

Flare v0.18 String Freeze and Release Target The deadline to get string changes into Flare (and flare-game data) is by the

Irrlicht - Monthly Screenshot Contest – Februari 2013

2013-03-11T08:11:55+00:00

Here are the winners of the Screenshot of the Month contest for Februari 2013: Devsh with his screenshot “Sodan Design – Build a World” and Suvi with her screenshot “Gekkeiju Online”. As always, you can find the screenshot and all contestants in the forum and the gallery.

jMonkeyEngine - Call for improvements in Java for games

2013-03-09T07:08:15+00:00

As many of you have proven together with us, Java is great for game development. But a great thing can always be better, and recently a crack team of Java-for-games advocates got together and discussed just that. The result has been posted on the Badlogicgames blog, by Mario Zechner, founder of LibGDX.

I’d love to see Oracle realize that there’s an oportunity there. It’s hard to tell what their strategy is. One day JavaFX and with it a JVM for mobile seem to be about to be released. The next day an interpreter JVM plus PhoneGap are presented as the final solution. And then you stumble across this JEP and don’t know what to think. Could this indicate an AOT solution? Or a less useful Zero based solution?

I still believe that the JVM could be a strong player in the mobile domain, for both apps and games. The community that build around the JVM would go to great lengths to guarantee that with both open-source and commercial contributions.

Nate and I talked about all of this for quite a bit. We actually assembled a large portion of the Java gaming community, including folks from LWJGL, Jogamp, jMonkeyEngine, as well as figures like Caspian Prince and Michael Bayne. We had some intense discussions on a mailing list we setup, on what could be done about the current state.

Whatever the result, we can always move forward, with or without support from the JVM’s stewards. It seems to be in the DNA of our community.

Read the full article and leave your comment here.

We wholeheartedly support this bold endeavor. Whatever ends up happening, we’ll keep working on the technical side of things on our end. It’s great to see Java game developers coming together to champion our favorite development platform. Please do your part by sharing this news as well as answering this question with whatever medium you’d like: Why did you choose Java for game development? #javaforgames.

#javagamedevelopers Why did you choose Java for game development? Please ask other Java gamedevs you know. #javaforgames

— jMonkeyEngine (@jmonkeyengine) March 9, 2013

FLARE - 20130308

2013-03-09T07:02:07+00:00

Stealth The Ranger tree got a new power this week: Stealth. We created it by abusing the "transform into a creature" code.

jMonkeyEngine - Interview with PerBlue, developers of Boardtastic

2013-03-08T07:53:30+00:00

About a week ago some fella on the forum, all cool like, dropped us a quick little note about this game called Boardtastic 2. It just so happens it’s powered by jME3 and runs on Android, and it’s got one of those funny 7-figures download counts as well. If you’ve been wondering what it really takes to make a top-tier Android game with jME3, we’ll be talking about just that right here.

So PerBlue kind of popped out of nowhere with a jME game in the 500’000-1’000’000 downloads range on Google Play. How come we didn’t hear from you guys sooner? (don’t worry, we’re not mad)

We’ve been making mobile location-based MMORPGs for about four years now. Our flagship game, Parallel Kingdom has 2 million registered user accounts. Within the last six months we’ve shifted gears and have created a few 3D mobile games. Which put us in search for a 3D engine to enable our pursuit. We found jME and we’ve been so busy coding we didn’t take the time to shout and greet.

We saw an opportunity to fill a gap in skateboarding games for the Google Play store. There were a few skateboarding games (both side scrolling and 3D), but none were very deep or easy to pick up and play.

I creeped your blog and read an impressive little snippet stating “Members of our team have worked at Google, Microsoft, Cisco, and GE”.

What size was your team when it started off, how big is it now, and what’s the programmer / artist / designer / manager ratio like?

Our team started really small. We bootstrapped the business out of my college apartment for about a year and a half. Back then it was five of my college friends that I had somehow convinced to work for free. We were squeezed into a working space of about 700 sq ft.

Today we have 30 full time employees working for PerBlue. We have six artists, of which three are dedicated to the Boardtastic project. I am the project manager, and then there are two full time (Colin and Eric) and one part time (Peter) developers.

The rest of our team is split among our location-based titles, Parallel Kingdom, Parallel Mafia. We’ve got a really diverse pool of talent; marketing and public relations, artists, customer service, and developers.

I know you’ve made mobile games from scratch in the past. Why did you make the switch to jMonkeyEngine 3? Any prior experience with it (current or older-gen)?

The biggest reason we made the use jMonkeyEngine 3 was to assist our 3D capabilities. This was our first 3D game and leveraging what JME has to offer (e.g. scene graph, 3D model loaders, skeletal animation) saved us a lot of development time. There are some great 2D Java game engines out there for Android, but it has still not gotten a lot of love in the 3D space.

Boardtastic has been PerBlue’s first experience with jMonkey, so it has definitely been a learning experience. Most of our knowledge of jMonkey has come from learning as we went developing Boardtastic, although a couple of us on the team had toyed around with jMonkeyEngine 3 in our free time prior to the project. One of our developers had actually developed a game in an independent study class back in JME 2 days.

What about game development in general, what was the team’s level of experience like with that when it was first starting out, and then later when you started working with jME and Boardtastic?

My co-founder Andrew, and I made two little games in college together completely just for fun. Parallel Kingdom was our first commercial game. But by the time we started Boardtastic we’ve had 4 years of experience, with almost eight commercial pursuits, and 10’s of toyish game pursuits.

How long was Boardtastic 2 in development? I guess you might want to start with Boardtastic (1), as the sequel appears to have continued where the first one left off.

Six months was our development schedule. Initial brainstorming for Boardtastic started in September, and the first version on Google Play was released in December. We’ve since gone through several rounds of major mechanic updates, and have added a bunch of new gameplay features. Boardtastic 2 launched last month (February) and this update includes all of the multiplayer elements. We hope to release the third skatepark this month.

I played your game (had a great time!) and noticed that you’re using microtransactions as your only revenue stream. What has your experience been like with this business model thus far?

Making a great game is the first step to making a successful product. We’re confident that if players have a beautiful experience playing the game, they will be willing to pay for our groceries.

All of our titles are free to play, and monetize with a combination of virtual currency and subscriptions. We’ve had success with this model across several titles. The secret is creating fantasy and an emotional attachment around the items players are purchasing with the paid currency.

With Parallel Kingdom and Parallel Mafia we’ve had very good response with this model. With Boardtastic, it is still too early to tell. But as a company, we love this model because it keeps us motivated to continue to love our products and love our customers. Rather than just moving completely on to another game and leaving it in the dust.

Your game’s aesthetics is certainly top-tier and a major selling point. I learned that you made all your artwork in-house using Autodesk Maya 2013. What was your import pipeline like? Any pains?

We started out using the OgreMax Scene Exporter for Maya which can export the skeletal animations we needed for our skater, and then using the jMonkeyEngine SDK to import and convert to the j3o format we actually load in our game. Problems in the import pipeline are very painful to figure out because it’s a little bit of a black box moving from Maya → Ogre XML → j3o. Each step in that process can have it’s own issues, and issues can easily be overlooked if it’s only a small difference.

Maya can’t export into Ogre XML everything that is used to animate the character (i.e. inverse kinematics, set driven keys, complex animation paths, etc), so we end up losing animation information in the process. What this means for us is that the animations in game don’t end up looking exactly like the animations our artist sees in Maya.
We feel that if jME would start to support parts of the FBX format would be a HUGE win for the commercial usage of jME.

Did your artists have any experience making models for PC games before getting into mobile? If so, are there any major differences? Harder/easier? Any big pitfalls to look out for?

Boardtastic’s lead artist has worked on games for the Playstation Portable and the Nintendo DS as well as other mobile games, including other PerBlue titles, like Parallel Kingdom and Parallel Mafia. Many of these games have assets that are 3D renders, flattened down into sprites. While not “mobile” in the sense of Android vs. Apple, the PSP and DS are still mobile platforms, so the workflow remains the same. We aim to maximize the aesthetics, while keeping the polycount and texture resolution as low as possible.

To what extent did you use the jMonkeyEngine 3 SDK?

We used jMonkeyEngine 3 for graphics rendering and the art pipeline. We wrote our own UI, audio, network, and gamestate code. There are several parts of the game that take advantage of Android-specific features, like the in-app billing, character clothing manager and audio manager. We wrote interfaces to connect these Android features to the jMonkeyEngine sdk. We generally spend most of our time in Eclipse, only going into the Netbeans SDK when we need a Netbeans / jME-specific feature.

What OS did you use for development, and how did you do your builds?

The short answer is that we use Windows, and we create our builds in Eclipse. As we build, we frequently go back to the Netbeans jMonkey sdk to clean the jars, as Eclipse sometimes does not update the jMonkey assets correctly. We’ve also modified our build process fairly significantly to include code obfuscation and our changes to the jMonkey engine.

How did you test your game? Were any special applications (AppThwack, Testdroid) or outsourcing/crowdsourcing services (Testology, uTest) involved or was it purely home brewed and in-house?

For Boardtastic Skateboarding, all testing was done in-house, and generally involved a lot of coffee and grumbling. We generally have a version of the game running on our desktop computers, which is used because running an application on Android takes much longer. The fact that jMonkey supports a desktop environment in addition to the Android environment has helped speed up the testing process.

We also added several special build options to the game to speed up testing, like giving the developers fast trick experience. Testing a game like Boardtastic is a challenge, because there are several versions of the game published – and all of them are talking to our multiplayer servers. In the future we might consider beta testing or crowdsourcing, but our current development pipeline is so fast that it may be difficult to do.

You’ve already started contributing back with some of the changes you made to the engine on your end during development: Awesome! Can you tell me a bit about what more you’ve got in store for us on that end?

We love to contribute back to the jME community, especially around Android jME. As we make changes to jME for our games, we’ll give those contributes back to the community for possible consideration to be added.

We’ve already contributed Anti-Aliasing, which Nehon is in the process of adding to jME. Hopefully this will help make all Android jME games look better. Other ideas we have to contribute include improvements to hardware skinning, ETC texture compression to better handle graphics memory, Android audio changes, and possible additions to the art pipeline. One of our biggest challenges has been the art importing pipeline, and we would love to work with jME team to improve this. We’d also be happy to help implement and support the FBX file format, which we think would greatly improve the ability to use jME for commercial products.

Thank you to the jME community for everything they have built! We look forward to sharing our feedback and ideas for improvement with the jMonkey community, and hopefully inspiring other jMonkey games that are even better! (Of course we have a few sweet new games in the pipeline, so there is plenty of fun in store for all in the future.)

My sincere thanks to the PerBlue team for being very forthcoming and directly engaged with the jMonkeyEngine project. We’re incredibly excited to have these developers in our community as well as their game in our showcase, and we’re already in discussions about their impending patches. Now go play their game!

FreeGameDev Planet - Development

FIFE - More Weblate details

BennuGD - Royalty Free Music by Erkosone.

OpenXcom - Globalizing the X-COM organization

OpenXcom - This one is going in the record book

Castle Game Engine - Development: transitionComplete, Debian packages, network tutorial, data URI, MultiTexture tests, more

Allegro - Allegro 5.1.7 (WIP) released!

Irrlicht - Monthly Screenshot Contest – April 2013

jMonkeyEngine - Old promo video resurfaces: Prototypes & Alphas Mashup

OpenXcom - It’s finally here, version 0.9!

OpenXcom - Welcome to the new OpenXcom.org!

OctaForge - OctaForge 0.2.0 Beta 1

FIFE - Weblate replaces Pootle for managing translations

BennuGD - BennuGD Packager updated.

OpenGameArt - Check out Heroine Dusk

FLARE - 20130430

DusteD Games - maximumCuriosity postmortem

The LudumDare48 Entry

The megashort version:

Wrong

Right

Different next time

The long and ranting version

jMonkeyEngine - The HeroDex GUI – jME3 User Interfaces

The HeroDex GUI – jME3 User Interfaces

GUI Design, Look and Feel

Architecture: App States and Screen Controllers

Mixing GUIs: Lemur and Nifty

XML Versus Builders

Nifty Popup State

Conclusion

FIFE - Spam in the forums

OpenGameArt - If I could work on OGA full-time, what would people want me to code (or do)?

OctaForge - OctaForge beta 1 coming soon

FIFE - Pootle downtime

OGRE - Ogre 1.9 RC1 is here!

BennuGD - How to port your games to OUYA

Castle Game Engine - Development: better Mac OS X support, networking, CAD level 2, more

OpenXcom - New website, new build, full playability

FLARE - 20130417

OGRE - Ogre3D’s guest post on “Sourceforge Projects of the Week”

FLARE - 20130412

DusteD Games - Making Solder of Fortune run with any resolution on Linux

FIFE - Project Management Change

jMonkeyEngine - Eric Potter @iwgeric joins the core team

It’s been a while

Monkey vs Droid

Irrlicht - Monthly Screenshot Contest – March 2013

Crystal Space - GoogleSummerOfCode2013

FIFE - Summer of Code application rejected

BennuGD - Play OGG/Theora file formats with mod_theora module

FLARE - 20130405

iodoom3 - Migrated to GitHub

jMonkeyEngine - 4Realms proudly presents CHAOS

Crystal Space - IndieGame

Ember - Exporting and importing in Ember

OpenGameArt - OGA to Purchase, Monetize Battle for Wesnoth

FLARE - 20130331

FLARE - 20130330

Bullet Physics - Bullet 3.x teaser and GDC 2013 talk

Spring - Spring 94.0/1

Allegro - Allegro 5.1.6 (WIP) released!

OpenGameArt - Voluntary Copyright Expiration

OpenXcom - Jade stream later tonight!

FLARE - 20130321

OpenGameArt - Let's put away the forks and dongles and talk this over like civilized people.

FLARE - 20130319

OpenXcom - Feature freeze

FLARE - 20130317

FLARE - 20130315

Spring - Spring 93.1 / 93.2

FLARE - 20130313

Irrlicht - Monthly Screenshot Contest – Februari 2013

jMonkeyEngine - Call for improvements in Java for games

FLARE - 20130308

jMonkeyEngine - Interview with PerBlue, developers of Boardtastic