Monday, June 27, 2011

Dev-corner: How to request art for your FOSS game project (and how not to)

During my tenure thus far as the head of OpenGameArt.org, I've run into a lot of different requests for art by various projects. I'd like to start out by saying this: Please, if you need art for your FOSS project, don't hesitate to come ask us! That's why we're here. :)

That being said, there are ways to ask for art, and ways not to. Unlike some places, we'll never yell at you for not asking correctly, but there are still some things you can do (and avoid doing) to make your request more likely to be filled. I'd like to go over these today.

Be specific about what you want.

By far the biggest challenge in making art for FOSS games is that projects will have artists come and go, and because of that it's difficult to maintain consistency between pieces of art. It's possible to have a bunch of art elements that are all individually excellent but have a game that looks horrible because the art elements don't go together well.

The first thing you need to know is what general theme you're looking for. Describe it and provide examples and references. That will give your artists a general idea of what to go for.

If at all possible, you'll also want to provide a color palette for the artists to use. Your palette doesn't need to be enforced with an iron fist, but it does need to be enough to give artists direction so that whatever thematic elements they make will fit into your game. If you're making a game with a dreamy pastel theme, dark, gritty colors aren't going to fit (and vice-versa).

Provide design guidelines. This is particularly important for your user interface icons. Tell us how thick you want the outlines to be. Tell us if you want things to be angular (and, if so, what angles), or rounded. Should we use gradients? Pixel art? Vector art? Digital painting? If possible, write up a short document describing how to produce the general look of what you're going for.

Now, that's a lot to think about, and it applies a lot more to large requests than small ones. If you're only asking for a couple of things, you can get away with a few general bullet points describing what you want. If you've got a large, ambitious project, your design guidelines really ought to be part of your design document.

People have expressed hesitation in the past about making these decisions because they'd rather leave them up to the artists. That's a valid concern, and we'd love to help. If you don't have a set of design guidelines, come talk to use on IRC (#opengameart on freenode) and we'll walk you through the process. We may even draw some up for you by request, as long as you're willing to take part in the process. :)

Make it easy.

Art is like code. It takes a lot of time and effort. If you're asking someone who doesn't have a vested interest in your project to spend their spare time making you something, you have to meet them half way. Make a list of the specific pieces of art that you want, and make sure that it's up to date. Many projects keep wiki pages that show their art assets. If you have such a wiki page, it's absolutely imperative that it be updated with the art that you already have, so artists know which things they ought to be working on.

Don't expect artists to poke through your code repository to figure out what you need versus what you already have. A lot of artists aren't familiar with version control systems (nor should they need to be). In general, it's not a good idea to ask an outside artist to do legwork that you're capable of doing yourself. Even if you find an artist who's willing to do that work for you, the hours they spend organizing your project's existing art will be hours not spent utilizing their artistic talents, which is a waste.

Be nice.

Hopefully I'm preaching to the choir here, but be understanding of the fact that a lot of artists don't code. Many of them don't use Linux. This doesn't mean they're dumb or that they lack talent -- they like to work in an environment where they're the most productive. Artists (and other people) will tend to gravitate to projects where people are polite and accepting

Mind you, it's perfectly reasonable to ask that your art assets be created with FOSS tools, but be aware that it's a trade-off -- on one hand, it's a badge of pride for your project to have a 100% FOSS workflow, but on the other hand you shrink the pool of available artists. If you're going this route, explain yourself politely, and many people will be willing to work with you on it.

Be realistic.

If you're coming in with a very ambitious project (like an MMO) and requesting very specific resources, be prepared to produce several hours of real gameplay. This isn't a hard and fast rule -- we make exceptions from time to time, based on circumstances. If the art you're requesting is something that would be generally useful to a lot of projects, we'll be more likely to help you out, because we know the time won't be wasted even if you don't end up using it yourselves. With one exception, we've turned down art requests for MMO projects that don't yet have solid gameplay. This isn't out of spite -- we just have limited resources, and need to put those toward projects that are more likely to succeed.

If your project is one or two people with a concept for a great MMO, you're not ready for art assistance yet. Expand your team and build a game. If we have the necessary resources, we'll try and help you once you have something that runs with real gameplay (quests, etc).

On the opposite end of the spectrum, some projects are essentially finished (playable, with placeholder art), and come in with relatively small requests. These are the types of requests that we'll address first and with highest priority, because we know that the art will be used almost immediately. If you have a mostly finished project with programmer art (or art lifted from unlicensed sources), we'd love to help you! Come talk to us. :)

Trade.

If you have a talented artist (or musician, sound effects person, etc), and you need some art that's outside of that person's comfort zone, find out if they'd be willing to help out another project in exchange for one of their artists helping your project. There's a lot of art talent out there in the FOSS community, but there's not quite enough to go around for every project. Trading art between projects is a great way to get your requests filled. If your game project has talents (art, coding, audio, writing, etc) that you'd be willing to trade for other art, note that in your request, and someone on another project might see it and be willing to help you out.

Buy.

I think the anti-commercial sentiment in the FOSS community is starting to subside a bit, but it's still out there. Artists have to eat and pay rent too, and if you'd like good art for your project, sometimes the best thing to do is just spend money on it (particularly if OpenGameArt can't help you for whatever reason). There's nothing wrong with spending money on a Free project -- remember, it's free as in speech, not as in beer. If you believe in your project and have been willing to sink a lot of hours into it, you might want to consider sinking some funds into it too, if you have cash available. I've commissioned a lot of art myself and I have a good idea where to look and how much people generally pay for good art, so I'd be happy to talk to you if you have questions concerning doing your own art commissions.

Other caveats

If you're requesting art from OpenGameArt.org, be understanding of the fact that some resources are harder to provide than others. Pixel and vector art, and untextured, low-poly 3d models are relatively easy. Sound effects, music, and concept art are somewhat harder. High poly 3d work, particularly with textures, takes the most time. Given our limited resources, we'll be more likely to spend our time where we can be the most effective. You can always feel free to request anything, but be understanding of the fact that some requests are easier than others.

In conclusion...

Art isn't easy, and as a community we're still figuring out how to integrate artists into the FOSS movement. I'm kind of rare in that I'm a good coder and a decent artist -- not great, but enough to have some understanding of the issues that artists and coders run into when trying to communicate. If you don't know how to make a request, come talk to us, or make a post in the OpenGameArt.org art requests forum. If we need more information, we'll ask for it. :)

Thanks for reading!

Bart K.

(BartK on irc.freenode.org -- again, you can find me in #opengameart).

Monday, June 20, 2011

Some thoughts on commercial FOSS game development

It's been a while since I last stirred up controversy on the freegamer blog, so I thought today I'd talk about -- gasp -- developing FOSS games commercially.

There's a common misconception out there (although I'm guessing a majority of the readers of this blog are aware of it) that software can't be both libre and commercial (I use libre here instead of free to make it clear that I'm referring to free as in speech and not as in beer). This is a problem that the FOSS community has struggled with since the very beginning. Writing FOSS full time is difficult because, let's face it, your internet connection costs money (not to mention other minor things like food and rent). As such, a lot of FOSS development, particularly game development, is done as a hobby.

The Open Source development model is somewhat difficult for a small developer (such as an indie game studio) to make money at. The current practice is to make the game code open and keep the game content (graphics, sound, levels, etc) non-libre in some way. This is a known business model that's being used right now, so I'm not going to discuss it in great detail in this particular blog post.

Instead, I'll be asking this: How close can we get to a 100% libre game and still make money while we're developing it?

The big problem here is that people tend to be more willing to spend money if they get something immediate in return. Take, for instance, the first Humble Bundle, which made over a million dollars. A fairly significant portion of that money was from people who wanted to see the code for the games contained into the bundle open sourced. On the other hand, open source projects that accept donations tend to get a slow trickle of cash (if any at all) -- certainly not enough to fund a single full-time developer, let alone several. Yet, if you consider it, the folks who work on FOSS projects have already put the time and effort into building their games. Aren't they equally deserving of payment?

Now, I'm not trying to guilt anyone into running out and donating to FOSS game projects (although I'm sure a lot of them would appreciate the help). The point I'm trying to make here is about human nature -- if you want sustained, significant income, people need to receive something in return when they give you money. Unfortunately, open source software is somewhat resistant to this kind of business model. While you're not technically obligated to give your source code to anyone who wants it, you are obligated to give it to anyone you give an executable to. Then, that person is free to distribute the source code that you gave them. Hence, one person could buy your code from you and then give it away to everyone else. And as a FOSS enthusiast myself, that's how I prefer things to be.

So, to summarize thus far, in order to pay the rent, you have to make money. In order to make money, you have to sell something. In order to viably sell something in any reasonable volume, the thing you're selling can't be libre. So where does that leave us?

I've been pondering some ideas for a while ago, and I wanted to throw them out there and get an honest discussion of their advantages and disadvantages.

My first thought is that a commercial FOSS game developer could release both their game and their game media (graphics and sound) into the libre ecosystem, but keep their glue code (game scripts, levels, plot, etc) non-libre. This method allows people to build whatever mods they want, and use your code and media to create their own games, while still putting you in a position to sell the substance of your game. The disadvantage here is that there's still a fairly significant portion of code and data that's not really free -- so you miss out on the benefits of having a completely libre game. For one thing, if you do this, you can't get your game into a number of major Linux distributions. The other issue is that people will be less likely to submit patches for your glue code if that code isn't really FOSS. So, while you've established a revenue stream, you lose out on certain benefits because your game isn't 100% libre in all respects.

Another possibility is the idea of a source ransom. Let's say I write a game (including the game data, glue code, and media) and release it all under the GPL. At this point the game is fully playable, but there are definitely some places where new features could be added. If I wanted to follow a ransom model, I could code up version 1.1 and not release it immediately. Instead, I would release screenshots and preview videos of it, then ask people to pay some arbitrary sum of money for the version I just created. Since the code is 100% mine, I'm not bound by the GPL, so I can send them the binary (or even the source code) under a more restrictive license, preventing them from distributing it. When the number of donations reaches a set amount, the new version is released under the GPL. Rinse, repeat. Any user who has already paid for the software receives the new version early, and the source is released when you recoup your development costs.

Doing the above, we've solved the issue of getting into the major linux distros (although the latest version wouldn't be eligible), but we've essentially closed ourselves off from outside contributions, since we have to own the copyright on all of the code in order to keep it closed, even for a limited time. Outside contributors could still contribute, provided they signed the copyright over to the main developer, or contributed the code with a BSD-style license that doesn't have a share-alike requirement.

As a variant of the above, you could accept GPLed patches from people and simply not release the code to anyone until the funding goal has been reached. The downside to this, though, is that you still can't really get outside help developing the latest version.

Understandably, there's always a lot of suspicion when dealing with commercial interests. As such, I imagine the reaction to this sort of development model wouldn't be uniformly positive. However, I'd like to point out an up side that people may not have considered: FOSS game development, as I said, is a hobby for most people. If you're lucky, you can spend maybe 5-20 hours per week doing it, often with long periods of downtime when real life happens. As such, FOSS game development is often slow, and the developers themselves tend to come and go, sometimes taking promising projects with them. On the other hand, if you can turn it into a viable business model, you can suddenly reliably spend 40-60 hours per week working on your project, which opens up a world of possibilities. With enough cash flow, you can even hire additional full time artists and developers, and build games that are much larger in magnitude than normally possible under the traditional FOSS devlopment model. And while this may require that you keep the most recent version closed source, the overall benefit to the community may be much higher, since your game will most likely progress far faster than it otherwise would, meaning that more code and media would be released into the libre ecosystem sooner.

Anyway, that's it for today. I'd be curious to hear what people think. If this ruffles your feathers, please be very specific as to why. If you have more ideas, I'd love to hear them. If you see problems making the above ideas work, tell me about them.

Peace,

Bart K.

Assorted bunch of news

Yes... slow days here on FreeGamer... so we will try to give you a bunch of smaller news and projects to check out:

First another Minecraft clone (this time for the PSP, but with GPL code): Lamecaft (which is a title I approve... generally ;) ). Then we have a open-source reimplementation of the famous jump&run Cave-Story: NXEngine. Maybe it is something nice to make your own platformer with too?

A bit more high profile I guess is this game I recently cam across: Turtle Arena, which you might have guessed is another game based on the ioQuake3 engine. Its goals are pretty ambitious (it wants to be "not annoying"...but with those hideous turtles that might be next to impossible :p ). Artwork is CC-by-SA too, but obviously a bit IP tainted.



Another offspring of the ioQuake3 project are the ioWolf (RTCW and ET) engine upgrades, which seemed rather dead all the time. However some people actually forked them and are working on their own versions, of which especially the COOP single-player enhancement of RTCW seems news worthy (the others are here and here). Staying with Wolf:ET, the previously mentioned ET:Xreal now has a nice presentation page too.

That's all for today... but stay with us even if news come only slowly :)

Monday, June 13, 2011

Release Changelog Bullets: Los, SaR2, HoA, NatR

Lips of Suna - 0.4.0

  • Lots of sound effects.
  • Master server and server browser.
  • Climbing over obstacles.
  • Merchants and trading.
  • Attacks can be charged by holding the attack button.
  • Projectiles and sword swings have speed lines.
  • Controls can be customized in-game.
  • Basic blood effects and beheading.
  • More flexible map generation algorithm.
  • Improved aer female, android female and kraken models.
  • New items: crossbow, musket, revolver, barrel, bookcase, dewspring leaf, fruit.
  • New spells: berserk, dig, firewall, light, travel.
  • New quests: Brigands, Mining Guild, Sword on the Stone.



Search and Rescue II - 2.3.0

  • Copyrighted Guadarrama scenery textures replaced with public domain ones in order to avoid licensing problems
  • Small bugixes
  • OpenSuse packages have been updated as well



Hero of Allacrost - June 2011 Unstable Release

  • Two brand new maps with many scripted events that develop the beginning plot of the main story
  • Enter/exit sequences in battle to smooth the transition from map exploration to battle execution
  • Better display of battle damage and status indicator text and images
  • Receiving damage causes a brief stun on the stamina bar, allowing you to delay opponents actions slightly
  • New skills available to use, some of which can target an entire party
  • Attack points have specific stat modifiers (for defense and evasion)
  • Targeting certain attack points may invoke status effects. For example, targeting legs to reduce agility
  • Enemy's are no longer "leveled up" to match the party's strength
  • If the player loses a battle, they have the option to restart the battle from the beginning, taking a penalty on XP/drunes earned upon victory
  • Two new enemies to fight, one of which is a boss-type



Nikki and the Robots - 0.3 + 0.3.1

  • Prettier on-screen display elements
  • Editor bug fixed
  • Slowdown bug fixed on many systems

Sunday, June 12, 2011

Minetest-c55

Minetest-c55

Minetest-c55: it's kind of like m*nec*aft, but:

  • C++ & Irrlicht
  • technically simple, stable and portable
  • lightweight enough for a laptop with Intel 945GM graphics
  • GPL

Saturday, June 11, 2011

Ardorcraft AI

Got Pot?
TeamTeapotCraft

Ardorcraft is now an API for Ardor3D.

Fortunately, they follow the philosophy of having biiig screenshots on the project's main page.

Unfortunately, as a non-Java-savy person I don't know how to quickly test it.

Fortunately, a video of its impressive AI/NPCs is available:

Friday, June 10, 2011

Tales of Maj'Eyal and T-Engine4

My greatest desire worst nightmare* is being answered realised! Long have I desired a graphical roguelike that was less savage than IVAN, and a nicer play than the standard 'land in random dungeon, and head off' fare that comes with the likes of Vulture's Eye and Lambda Rogue (trailer) - both good games but just missing something for me.

* These things can swallow days and weeks of a man's life!

The first thing to notice is that TOME4 is gorgeous. It has lavishly detailed sprites and stunning particle effects. Movement is smooth, and the UI is shaping up nicely.

T.O.M.E. is not a new game series and is one of the better roguelikes. It looks like they are merging the depth of a traditional roguelike with the atmosphere of modern graphics in TE4/TOME4 and we are in for a treat if the latest betas are anything to go by.

The last release, TOME4 1.0.0 beta28, was on the 4th of June. It is already a fairly polished experience, with a nice tutorial mode (Charlie approves of tutorials!), good music, and plenty of the aforementioned graphical panache. There are still a few ascii-style sprites but it is still beta, so that's to be expected. (Unless I am wrong and it will be a gorgeous graphics and ascii mix, which would just be a bit odd.)

*waits with baited breath for future releases*

Thursday, June 09, 2011

FOSS game engines put to great use

Disclamer: Yes I am fully aware that the following two game do not have libre media, and that one of them will never have unless they get away from the copyrighted IP!

That said... the following two gems are really nice examples of what can be done with FOSS engines if some skilled artists work with them.. and they are free as in beer too :p

The first one has been mentioned before on FG, and is a Mod for the nice FOSS RTS Megaglest (Did we mention that one had a small new release too?). Annex: Conquer the World, doesn't seem to have it's one website yet (link goes to Moddb), but check out this awesome new video of that game (gives me a nice Starcraft vibe!):


Actually I don't know anything about the media license on this one, and it isn't released yet, but the closed development process makes me doubt we will have much luck in regards to the media (source must be GPL just as Glest), but hey... you never know!

The second one is as previously mentioned a bit tricky in regards to their media, but at least is is all publicly accessible in their SVN, and maybe you can ask if some parts of the media can be free-ed for other projects to use. Ok well which game am I talking about? Well ZEQ2lite ;)
Have a look at this video and I am sure you will recognize the copyrighted IP:


ZEQ2lite, has a longer history of different mods for Quake3, but this new version is based on a highly modified ioQuake3 version and is completely stand alone from Quake3. Not a big fan of the IP otherwise, but it looks nice and has cool effects :)

Oh and one quick last unrelated news... OpenWolf (a fork of Wolf:ET with Xreal renderer... long story) seems to be making some nice progress in updating this awesome (free as in beer but with FOSS code) multiplayer FPS classic, as you can follow here. And the original Xreal project seems to be somewhat alive too and a release is promised soon... looks like some healthy competition is going on there ;)

Nongame: Killer

Killer

The Killer is a flash/as3-based nongame. Talking more about it might spoil it so if you're OK with that, there's a discussion going on at TigForums.

The source is "what you want" and hosted on github. Perhaps this could be ported to Haxe/Fixel.

The developer has an interesting "support me" implementation. Exclusive updates and postcards. :)

Wednesday, June 08, 2011

Strategic Initiative

Strategic Initiative

Strategic Initiative is "a semi real-time strategy game played over the Internet where the objective is to seize cities on islands". The technology used is Java. Have an alternative description:
Strategic Initiative is an online multiplayer military strategy game played over 10 days where the objective is for you and your ally to control the most cities on the map.
The code is available here under GPLv3.

Tuesday, June 07, 2011

Naev 0.5 released!

Naev 0.5


A new release of the 2D space trading and combat game Naev is out and available as binaries for Lin/Mac/Win here.
For those using Ubuntu (or other Debian-derived distributions), Naev is available from PlayDeb. Naev is also available in Arch LinuxGentoo, and from the openSUSE Games repository.
 Have a changelog:

List of changes since 0.4.2:
For Players

  • Larger universe
  • Expanded Dvaered, Frontier, Empire and Pirate territories
  • All-new Sirius and Soromid territory
  • Big systems
  • More planets per system
  • Much larger planets, many new planet and station graphics
  • Players must fly to jump points before jumping to another system
  • Overlay map for in-system navigation
  • Mouse interactivity
  • Planet, ship and jump point targeting
  • Contextual click actions (board, hail, land, etc.)
  • Optional mouse-controlled flying
  • Electronic warfare
  • Ships have cloaking and detection abilities
  • Sensor range depends on cloak vs detection
  • Turrets no longer track all ships equally
  • Time model changes
  • In-game time progresses in real-time
  • Dynamic time compression speeds up long journeys
  • On-map security rating abandoned in favour of faction presence indicators
  • System backgrounds (nebulae, stars and more!)
  • Fancier new GUI
  • Brand-new tutorial that is independent from the main game
  • Outfit slots now have sizes
  • Weapon sets allow easy configuration of different weapon combinations for each ship
  • Ship and weapon heat system
  • Weapons start with perfect accuracy, and become inaccurate as they overheat
  • Severe overheating causes rate of fire to drop
  • Damage absorption and penetration system
  • More diverse planetary inventories (see the tech system below)
  • Random bar NPCs
  • Sound system improvements
  • Smarter autonav behaviour
  • … and plenty more (new missions, ships, outfits, portraits, etc.)

BlendSwap Hacked

Time to swap... passwords

Oh my. Two weeks ago Librivox. Now Blendswap. Read the story here. See their twitter for live updates.

Remember to use strong !P4$$w0rd5%_.

Hm, OpenGameArt appears to be down, so it can't be hacked right now at least. :)

Monday, June 06, 2011

Battle for Wesnoth Architecture

The popular open source game Battle for Wesnoth has been featured in the new free online book The Architecture of Open Source Applications.

We believe that the beauty of the Battle for Wesnoth as a program is how it made coding accessible to a wide variety of individuals. To achieve this aim, the project often made compromises that do not look elegant whatsoever in the code. It should be noted that many of the project's more talented programmers frown upon WML for its inefficient syntax. Yet this compromise enabled one of the project's greatest successes. Today Wesnoth can boast of hundreds of user-made campaigns and eras, created mostly by users with little or no programming experience.

Read the full section online for further insight into the design and design decisions of Battle for Wesnoth.

Wednesday, June 01, 2011

bfxr = sfxr + flash + omg awesome

bfxr

Sfxr is a simple retro sound machine. It has undergone some iterations and the latest software based on its principle is bfxr, which also has valuable management tools.

Their feature list:

  • 5 new waveforms : triangle, breaker, tan, whistle, and pink noise.
  • 3 new filters : compression, harmonics, and bitcrusher.
  • Ability to lock parameters during mutation/randomization.
  • Expanded pitch-jumping abilities - good for arpeggiation effects.
  • Visualisation
  • Mixer
  • Keeps your sounds and mixes in persistant lists.
  • Can reverse synths
  • Ability to link directly to sounds
Needs flash. Might be a problem. Can anybody with free flash implementations run this?

Provide feedback:

Due to SPAM issues we have disabled public commenting here.

But feel free to join our forums or easily chat via IRC with us.