More about easy content creation in FOSS games

More about easy content creation in FOSS games

bart's picture

A couple of days ao, I wrote a blog post in which I advocated for the creation of easy-to-use, integrated content editors in Open Source video games.  I got a lot of interesting replies, and I'd like to address some of them here.

One very valid point that was made is that in the FOSS community, we tend to re-invent the wheel a lot, and that there are a number of very good content creation tools (such as Tiled) out there already that people can use to make game content.  My response to this is that Tiled is an excellent program.  In fact, it would be a good start if people who made tile-based games would take a look at tiled before they jump into coding and make an effort to make their map format compatible with it.  In fact, it's important to point out that I'm not calling for every open source game to make an integrated editor -- it's a huge project in itself, and it's more important that you have a game in place first.  The editor can come later.

A couple of people suggested that it's okay for game content creation to be hard because if someone doesn't want to open a text editor, they probably won't be able to make a good level anyway.  I'll concede that by making content editing ridiculously easy, you will open the door to a lot of people who are just fooling around and won't make very good content.  And, if you allow them to upload that content to your central server, you'll have a small amount of good content surrounded by a lot of bad.  The way existing proprietary games deal with this is by having a rating system.  Allow your users to rate new content as it comes in, and then place the highly-rated content more prominently than the low-rated content.  In doing so, you filter out the bad stuff, but at the same time you give everyone a chance to try content creation.  Furthermore, even the greatest artists all start out as beginners.  Thos few faltering steps into creating game content may be the beginning of something huge, even if they don't look like much at the time.

One person pointed out that FOSS games lack coherent art direction and that content editors would make this problem worse.  My repsonse there is that some FOSS games have perfectly good art direction and a consistent style, and some don't.  Regardless, allowing user-created content isn't going to make the problem worse.  In fact, one very important piece of any easy-to-use game content editor is a set of building blocks for making content in that game.  For instance, in Mod Nation Racing's editor, you are supplied with a number of track styles, obstacles, and other details that allow you to put a track together in a style that's consistent with the existing game.  So I wasn't suggesting that people be forced to start with individual pixels and polygons -- to the contrary, you should supply art to your users that they can use to build levels in a way that's artistically consistent with your game.

Finally, there's the issue of inherent complexity.  Most levels are going to need to be scripted in some way.  And admittedly, tying someone to graphical programming is fundamentally limiting, because logic blocks are only going to be as capable as the logic inside them.  Ultimately, this is the hardest problem you run into putting together *any* user interface.  The best user interfaces deal with this issue by being like an onion.  No, Donkey, they don't stink, they have layers

Imagine that you're a user and you want to try building a level for some game.  So you fire up the level editor and poke around for a bit.  The level drawing tools are laid out in an obvious way, so you draw up a simple level and test it out, all while still getting a feel for the editor.  At this point, you haven't touched any logic or scripting, because the editor has cleverly concealed those more complicated functions in a place where you won't go looking until you care about them.  As you wander around your level, you find that the enemies act in a very generic and predictable way.  Maybe you'd like to have one jump out at you when you walk past a certain point, but you're not sure how to do it.

So, you hop back into the level editor and load up the level you just made.  You put an enemy roughly where you want it to jump out, and, just on a lark, you right-click on it.  Up pops a menu that allows you to modify that enemiy's properties.  There's some obvious stuff, like changing the enemy's appearance and stats.  Further down the menu, you see something labeled "Action Triggers", so you click on it.

A dialog pops up.  From here, there's a drop-down box labeled "Conditions".  You browse through it and find one that says "Player enters area".  You pick that one, and are prompted to select an area on the level map, so you do so.  Another pull-down box, labeled 'Actions", has an option labeled "Move this enemy", so you select that, and are then prompted to pick a path along the map for the enemy to move.  You've now successfully added some interactivity to your map without editing a script or reading voluminous documentation.

You play through your map again and are pleased with the result, but you want more.  The map editor has allowed you to do a lot, but you'd like to push the game engine a bit further, and you've come up with a cool idea that the game designers didn't account for in their Conditions and Actions.  On the Action Triggers dialog is a button labeled "Download More Actions", so you click on it, and you see a list of user-created actions along with descriptions.  You find one that almost meets your needs, but falls short in some way, so you download it.  Then, you fire up the game's integrated code editor and tweak the script in some useful way, and upload the new version back to the community so they can use your code as well.

In the above scenario, the developer has made the beginning and intermediate steps (which are, in general, usable to create an entire level) available right inside the editor with no code whatsoever.  And, the advanced step of writing code has been distributed to the community in a way that the Open Source model works in the users' favor.

Call me crazy, but I think it might actually be doable.  We'll have to work at it, though, because it certainly won't be easy.