Let's make FOSS game content creation ridiculously simple
I'd like to step up onto my soapbox for a moment and address something that I find somewhat lacking in FOSS games -- namely content creation and editing. In one sense, FOSS games have a leg up on the competition because all open source software is innately moddable, which is kind of the point. However, the practical reality of software moddability is that it's extremely dependant on the tools you provide.
Let me give an example. There's a game that came out fairly recently on the PS3 called Mod Nation Racers. It has a built-in track editor that's surprisingly easy to use and produces results in minutes that look like they took hours. When you've tested your track and are satisfied with it, you can upload it to a central server where other players can download it, try it, and rate it. Little Big Planet provides a similar experience. Of course, the downside of all of these things is that they're stored and moderated by Sony, so they tend to be deleted with no explanation the moment someone complains, and you don't "own" your creations, per se. In fact, in all likelihood, the license agreement with the software gives Sony ownership of all of your creations as well as your soul, testicles (or ovaries), and first-born child.
Yet, with all the crazy licensing stuff, limitations, and arbitrary deleting of content, people are still happy to continue creating. Why? It's just so fun and easy. What I'd like to propose is that we, as a community, try to move toward that level of fun, power, and simplicity for creating FOSS game content, and motivate our game players to help build our games content.
Of course, this isn't going to be easy. Writing a good UI is extremely difficult, and the motivation to do so is generally fairly low, since the people who would work on the UI (namely the coders) know their games inside and out and are the least likely to need them. As a rule of thumb, if you want to create a means of editing game content that's usable by regular users, it's best to find a guinea pig who's willing to sit down and try your editor without reading any instructions. An ideal game content editor should be so intuitive that users can start creating content immediately without wading through arcane (and often outdated) documentation. Mind you, I'm not saying that a user should never have to refer to a book or a guide, but you'll lose most people if they have to do it immediately. What you want to do is hook them with easy content creation so by the time they run into something complicated, they'll have designed three quarters of their level, and they'll be willing to poke through the manual so their hard work isn't wasted.
Also, built-in network support is an absolute must. If people can't download user-created content or submit their own content without poking around in the file system, you'll lose a lot of them there, too. In fact, ideally, the user should be able to create, modify, test, play, and upload their content without ever leaving the game, and without having to go through an arcane interface such as a console. A rating system (even a simple "number of favorites" type of thing like we have here at OGA) will help direct people toward the best content and give them something to aspire to with their own work.
What makes this all so challenging is that game levels are complex animals, and that makes it very difficult to allow the user to edit them in a simple way. Some complexity can be reduced by creating a set of default options that are generally true and then allowing the user to change them in a menu. Some things, such as custom logic, can only be reduced so far while still providing rich functionality, and in those cases, it's important to present instruction in the simplest and most accessible way possible, namely instructional videos.
In summary: A great content editor is fun, usable without reading documentation, accessible from inside the game engine, highly capable, and networked. If we really want user-created content in FOSS games to take off, that's where we need to go, and it can be done!
Now, a couple shout-outs to projects that are, in my opinion, moving in the right direction on this:
- Syntensity, and other projects that use the Sauerbraten Engine. I'm not a huge fan of Sauerbraten's editing interface, as I don't find it particularly intuitive, but it's leaps and bounds ahead of the competition in terms of allowing users to modify game content.
- Wesnoth has a good map editor and a large, active community, but when it comes time to create campaigns and scenarios, you still have to venture into the scary realm of text editors. Still, Wesnoth's campaign server allows users to contribute their work, and then players can download it from inside the game with no fuss whatsoever.
- Tiled makes it easier for developers to integrate a full-featured tile map editor by allowing you to write plugins for exporting maps in your own format.
- The Gluon Project aims to be a complete, easy-to-use FOSS solution for creating, distributing, and playing games.
The above is by no means an exhaustive list, so if you think of a project that deserves credit for easy content creation, drop me a line, and I'll add it. :)
Peace,
Bart
Comments
I want to give a shout-out to Thorbjørn over at Tiled ( http://www.mapeditor.org/ ). With the latest release users can create import/export plugins. This means a game developer can make a plugin for Tiled to read/write a game's native map format. It's a good tool that gets the fundamentals right.
I agree to a certain level, but if too much time is spend on creating these tool the actual game might be lacking after all. Also I think it's not bad to have a certain entry level to keep down the noise or crappy creations and to make people actually learn a little bit during the process.
That said, editing could sure be easier in many games. Glest is btw also a good example of having an extremely easy 2D map editor and quick to understand xml files for the rest.
And Sauerbraten, well it's currently hard to find something else than coop editing servers or those damned instagib ones :(
But what I find equally interesting, and maybe even more promising for FOSS games is the quite similar idea of sandbox games where the creation proces is actually part of the game instead of switching to an editor mode.
You hit the nail, This is exactly what's missing in most open-source games. The reason is that it needs a huge manpower alone to create a game and creating quality tools for modding the game at least doubles the needed manpower. Unfortunately, manpower is (besides good art) the biggest missing thing in open-source game development.
As an aside: do you guys prefer a level-editor that is integrated within the game, or one that is a standalone app with probably a native GUI?
@Julius
Regarding the idea that a certain barrier to entry is good because it keeps down crappy submissions, I would tend to disagree, for two reasons:
* Things with a high barrier to entry are generally less fun and intuitive to use. The best interface is one where everything flows naturally enough that you can use it without thinking about it -- that way, you don't have to spend your time trying to find something that *should* be obvious. So by raising the barrier to entry, you're generally making things harder for your experienced users.
* No artist starts out making great work (or at least none that I've ever met). There's always going to be a learning curve, and if you can engage the people who have the desire to learn, they'll stick with your community and become excellent contributors. Furthermore, a rating system is a great way to avoid inundating your players with lower quality work. Have it show up in the "New" section for a day or two, and if it doesn't receive a good rating by then, put it somewhere more out of the way and make room up front for more popular content.
@Pompei
In general, I prefer in-game editors. Any time you can remove an unnecessary step (stopping the game, starting the editor, saving your map, stopping the editor, starting the game, loading your map), you're going to encourage people to make more content.
I also want to acknowledge that what I'm talking about here is hard. I'm not outright saying that every game ought to have an integrated content editor, particularly since if there's no game, there's nothing to create content for. As developers, our time is a limited resource, and we have to prioritize. Plus, you need some existing content to get people to even notice your game (as well as give your users some blocks to build with). But, if you're spending a lot of time on content creation, you might find that making an easy-to-use integrated content editor (complete with network support) actually *saves* you time in the long run.
I'm going to play contrarian a little if you don't mind. The real difficulty with making game levels is... well... making game levels. Sure, good tools can help, but at the end of the day you still need to decide how the level will look, what goes where, what happens when character X hits obstacle Y and so on and so forth. That's a LOT of work even with ideal tools. And then there's the testing and debugging and balancing... My guess is that people who are afraid of "scary text editors" (because scripting is for superhuman geniuses?) are likely to give up long before they turn out a good quality level. And if you give them stuff like enemies with predefined behaviors, they'll complain that every level plays much like every other (which would be true).
That said, content creation tools can help the game's original developers in the first place, so they shouldn't be neglected. But the game proper should come first, because that's the hard part.
First time I hear about Gluon and it sure sounds very interesting and ambitious . I have to keep an eye on this one as I think a tool to quickly create some simple Flash-like games is very much needed in Linux anf FLOSS world.
@bart: yeah the entry barrier should not be too high either ;) Just something that makes it necessary to think a bit about your creation and maybe put an extra step into the publishing process to spare the world of all these: "look world, here is my first crappy box room I have done in 5 minutes, and will probably never bother with editing again, since I am 14 years old and have better things to do"
And it also depends a lot on the game type if it works or not. I think racing games, where you can relatively easily put together a nice new track from pre-made parts are the easiest. But other games simple don't lend themselves very well to this kind of thing.
P.S.: I forgot to add: I also don't think in-game editors are particulary suited to the FOSS development style or many games. Sure in some it might be nice (see track editor for racing games as mentioned above), but IMHO much more focus should be put on using standardized editors for many different games.
Why newly implement a lacking in game editor (Cube2 I am looking at you, even though the coop editing is nice) when we have a really good and mature level editing suite already (GTK Radiant). This is of course not always possible do do technology differences (which is I guess the case with Cube2), but in general the strength of FOSS is in collaboration and reuse of parts or tools.
If (on the other side of the spectrum) the implementation of a game into a editor, like it is sort of done with Blender is a good idea I am still unsure of ;)
> My guess is that people who are afraid of "scary text editors" (because scripting is for superhuman geniuses?) are likely to give up long before they turn out a good quality level.
I'm going to have to object to this on the grounds that I'm an excellent coder, and spend most of my day inside a text editor and don't mind it at all. That being said, if I can edit most aspects of a game level without having to mess around with scripting, I'll enjoy it more. To put it another way, if I want to dabble in level editing (which is what gets a lot of people started), I'm going to be a lot more likely to do it if I can bring the level-editor up in-game and tweak things using a graphical tool than if I have to shut the game down, read a bunch of docs, fire up a text editor, write a bunch of code, figure out how and where to save that code, save it, shut down the text editor, and restart the game.
There's a common view in the FOSS world that I think hurts us sometimes, and that's that you aren't a worthwhile user if you don't dig through pages of documentation and use a command line or a text editor. There are a lot of people out there with talent for art and dialog and storytelling who aren't programmers, and if we're going to tap into those talents, we're going to need to provide these folks with tools that play to their talents instead of insisting that they learn to code.
And just to reiterate, I'm not saying that this is necessarily appropriate for *all* FOSS games, or even a majority of them. However, it would be good to see some FOSS games do this.
There's also "Game Editor": http://game-editor.com/
Hey, pretty decent summery of the problems. I think contributing content is much easier then you describe it but it could be made much easier.
One note, Syntensity as a project is defunct and has been replaced by an 'official' fork called CubeCreate. The fork was because kripken, Syntensity's Developer, wanted to take things in a 'mobile' direction. We're working on creating a modern game engine by cleaning up the clutter Syntensity had and streamlineing the entire game creation process. Our website ( www.cubecreate.com ) still needs alot of work but the project is very much active and our IRC channel is #cubecreate which typically has 10+ people at any given time.
William Chambers / Bios Element
CubeCreate Developer
Just a heads up. www.cubecreate.com leads to a test page. You might want to instead forward it to cubecreate.com, which works. :)
Bart
Ahh bugger, thanks alot for that. I usually truncate the www so I don't notice it. I'll get right on that. :)
Ah, thanks for the Tiled link - I'm now currently adding support to maps created using this program to my game Conquests. Whilst there are advantages to writing a custom tool, I think there's a lot to be said for using existing tools rather than reinventing the wheel. It means support can quickly be added, and users can use an existing, supported, cross-platform tool. There's also a lower learning curve if games tend to use existing applications, rather than all having their own custom UI for the editor.
Rather than writing a plug-in, I'm going the route of making my game compatible with the Tiled map format (which is an easy to read XML file).
Regarding the debate about barriers to entry: I think it depends on whether the kind of difficulty is the sort of skill that's necessary for quality. I mean, if we were modding the AI or other game logic, it's reasonable to except someone to be reasonably proficient with scripting - if they aren't, they wouldn't get far anyway, even if we give them a nice point and click interface.
But if we're talking about artists, level designers etc, it's not clear to me that any inability to go delving into editing files means they would be unable to create good quality work. (The converse is true too - being good at editing files certainly doesn't imply you'll create good quality work - do you really want to limit the set of people who can create content, by this criterion?)
Also we shouldn't confuse lack of desire with inability - people may have the desire and ability to create game content, but have better things to do than fight with editing config files unnecessarily (this reminds me of the attitude that plagued Linux in the past; I'm a geek and programmer, but I still have no desire to spend my time editing config files just to get simple things working).
So for my game, modding the AI or creating a new set of game rules means editing the Lua scripts, which I think is fair enough. But for someone who simply wants to create a new map, I want it to be doable using an easy tool.
(Apologies for posting on an old thread - I wanted to comment on Tiled, and then got carried away rambling.)
I agree with all of what you say mdwh, expect for one point: even the game logic can be made more accessible than in script files. Specifying simple things like "when an entity of type hero enters this region, add 10 to his speed" or "When player picks up item X, create random monster in region Y" can all be done very nicely graphically with comboboxes (for an example, see the WC3 editor). This enables MUCH more people to create simple logic.
I know, for us programmers, choosing those things from a gui is absolutely similar to writing the exact same thing in a textfile but slower, but any non-programmer will fear writing text on his own, but will enjoy to search a list of possible conditions and actions and combine them. This is not just a guess, I observed it on lots of occasions, sometimes it is even a good entry point for some people to learn the language if they want to do "more" than "When A then B and C" game logic.
BUT I agree that it is a lot of work to get that right and I know open source game programmers do not have that much time :) Still, if the game relies on user content a lot, it is worth the time imo.
Argh, the above was me.