Chat with us!
Active Forum Topics - (view more)
- Building a Library of Images for Everyone by Eric Matyas
- Indie music discovery service using some OGA artwork by numonkeys
- Change Username Requests by cottonball
- Sharing My Music and Sound FX - Over 2000 Tracks by Eric Matyas
- Game Jam - Team Matching Program by inog
- Any rules for user profile pictures? by Airos
- game of the month by blue_prawn
- Search Favorites by KobatoGames
Recent Comments - (view more)
- Re: Synthetic Farts by dklon
- Re: Alien Bug Animated by SteveSmith
- Re: The Beautiful Swan by lametta
- Re: Super Dead Space Gunner Merc Redux: Platform Shmup Hero by programmer2005
- Re: Bossfight by Frenchyboy
- Re: Waves by Frenchyboy
- Re: Dramatic Cinema by Frenchyboy
- Re: The Beautiful Swan by Frenchyboy
Legal notice regarding NFTs:
WARNING: Taking art from OpenGameArt.org to be sold as NFTs? You may be committing FRAUD. Visit this link for legal details: https://opengameart.org/content/warning-taking-art-from-opengameartorg-t...
Note of caution to NFT purchasers or those interested in trading NFTs: You could be getting scammed! Please visit this link for more information: https://opengameart.org/content/note-of-caution-to-nft-purchasers-or-tho...
Popular This Week - (view more)
Latest Art - (view more)
Latest Art by my Friends - (view more)
Featured Art - (view more)
Hi folks!
Just a quick heads up. On the home page, immediately below this post, are two new blocks. One of them lists the top submitters in the last 30 days, and the other one lists the most popular art in that same period. I've removed the old "most popular" block, as it was self-reinforcing and pretty much always showed the same stuff. :)
Anyway, this is a competition, and unless you're in first place, there are people ahead of you. Are you okay with that? No? I didn't think so. Better submit some art! :)
Bart
P.S. Kudos to WeaponGuy, who is in the lead at the time of this post.
- bart's blog
- Log in or register to post comments
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.
- bart's blog
- Log in or register to post comments
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
- bart's blog
- Log in or register to post comments
Hey folks!
We've come to the decision that all the art that OGA commissions (are that OGA paid for) from here on should be licensed CC-BY, in addition to CC-BY-SA and GPL. We figure that not having the share-alike requirement will make it easier for indie projects to include our art without worrying about the legal implications of a share-alike license. Some of our older commissions (namely the anime base sprites) have been changed to include this option as well. Over the next few weeks, we'll contact the artists who worked on other commissioned works and ask them for permission to make this change.
For those of you who aren't intimiately familiar with the various CC licenses, CC-BY only requires you to include an attribution in your credits (including a link to OGA), which should be easy for everyone.
If you use our CC-BY art in your games, we would of course appreciate it if you contributed some art back to OGA, but that is by no means required. Just a link in your credits is enough. :)
Peace,
Bart
- bart's blog
- Log in or register to post comments
One of the most important (if least mentioned) aspects of game design is how smoothly the game operates. Your game can have snazzy features and a great concept, but for it to be really fun to play, it can't handle like a constipated tank. Unfortunately, avoiding this issue isn't exactly easy. Smoothness of a user interface is something that's difficult to quantify, but I'm going to give it my best shot.
First off, let's take a quick look at a game that gets it right. A couple weeks ago I raved briefly about the delightfully smooth experience that is Frogatto. What is it, exactly, that makes Frogatto so smooth? There are a couple of things. First, the engine runs well on typical modern hardware, so it has an excellent framerate. Nothing feels smooth when you're chugging along at five frames per second, and Frogatto avoids this issue entirely. More than that, though, it's Frogatto's design that makes it smooth. For instance, if you've downloaded the game already, try walking around, and watch what happens when Frogatto changes directions. Seriously, go try it right now. I promise this blog entry will be here when you get back.
Now, did you notice the amount of time it takes for Frogatto to turn around? It's not abslutely instantaneous, but at the same time, it's very responsive. If it took him too long to turn around, the game would be annoying to play -- that much is obvious. But here's the kicker. If he turned around instantaneously, the game would feel klunky. That small amount of time it takes for him to decelerate and begin moving the other direction adds a level of immersion to the game that wouldn't otherwise be there, because Frogatto acts physically the way you might expect him to in the real world -- a way your brain is already hard-wired to understand. As a consequence, Frogatto's controls feel very "real" and natural.
Some of you may be thinking, well, my game is a turn-based strategy game, so none of this applies to me. If that is, in fact, what you are thinking, then you are incorrect. That touch of physical realism that makes Frogatto fun to play can also be applied to your user interface. Consider the lowly drop-down menu, for instance. The easiest way to implement a drop-down menu is just to have it appear instantly when the user clicks on a certain item. Unfortunately, this is also the least pleasing to the eye. If you want the menu to feel natural, you need some sort of transition, perhaps sliding it out. But that's not quite enough! Not only does the menu have to slide out, it has to slide out in a believable way. This means that it can't just slide out at a constant velocity, but rather, it should start slowly, get faster, then slow down again, and finally stop, and it should do all of this quickly enough that the user doesn't feel like they're waiting for it.
Now, perhaps this is all just glitz and flash -- and you can certainly make a pretty amazing game while ignoring these things altogether -- just look at Dwarf Fortress, for instance. People don't spend countless hours playing it for the smooth and intuitive gameplay. Nevertheless, if you want your game to have that finished feel, take some time to work on making the controls and UI as smooth as you possibly can. Keep your transitions fast but not instantaneous, and you'll do well.
Bart
P.S. We're still looking for 4 more new subscribers this month. If you can spare 3 bucks a month and want to help us buy new art for the community, hit the "Donate or Subscrube" button on the right. :)
- bart's blog
- Log in or register to post comments