f13.net

First, any one have examples of successful Open Source games.  The only one I can think of is DCSS. Sure it start as a fork, but its taken on a life of its own with active development.

I am inclined to go the route of OSG but there seems to be a lack of active OSG to join, or good examples to follow if I started my own.  I would like some ideas on how to avoid it because just another itch-scratching, dead-on-the vine project that is so common.  Some thoughts I had were:

1.  Low art requirements.
2.  Easy to build.
3.  Common development languages.

Umm, there are a shitton of fairly successful OSG games.

http://en.wikipedia.org/wiki/List_of_open_source_games

https://sourceforge.net/softwaremap/?type_of_search=soft&pmode=0&fq[]=trove%3A80&sort=num_downloads_week&sortdir=desc&limit=25

Come on guy :)

Nethack leaps to mind.

When you come back with a list that has TuxPaint, how can I argue with you?

EDIT: nethack's last update was 2003.  I agree it was success, but it's not exactly alive.

How do you define sucessful?

There certainly isn't much money in it, but in regards of fame, there are some.

Nethack indeed is the first that leaps to mind, but yes, apart from ports to other systems there is not much happening it seems.
Angband as well, but with the bazillion variants the userbase for that is quite spread around.
Battle for Wesnoth is still in active development and quite popular.
And Freeciv, of course.

I think a major issue with open source game development is that a game needs a very clear design. Throwing more manhours at a game doesn't necessarily make it more fun, while a spreadsheet application can always benefit from having a few bugs crushed because comparatively, a game is rather little heavy engineering (at least, in one that can be finished by a team of volunteers) and rather a lot of design work. Sadly, design commitées usually make the absolutely worst games. Letting just about anyone "chip in" isn't going to work, I'd think.

Do remakes count?
OpenTTD (http://en.wikipedia.org/wiki/OpenTTD)

I think remakes count if they move past the initial remake. 

My definition of success is quite modest.  "Don't be one of those zombie Open Source projects you see everywhere." and "Game is fun."

I was thinking that I should go to the beginning and look that what kinda games are not represented in the market.  (Probably because it doesn't look profitable)  I feel this part of the reason DF(closed source, but independent spirit none the less) got so much traction.  It's not like anything else.  Blue water, so to speak.

http://en.wikipedia.org/wiki/Net_trek

Forgot about that one, apparently still going.

Honestly, I think you would find it more satisfying to work with an indy game studio who's looking for cheap talent. If you are willing to work OSG for free, someone who wants to make money on their small studio project should want to scoop you up!

The benefit to you is that you have someone acting as Producer and setting a direction. The weak spot in anything by-committee is that it's by-committee.

Or pull a toady and grow a neckbeard that rules over the children of pride.

This.

Every open source project I have ever been on was a mash of disjointed design, and bad communication. There IS a such thing as to many chiefs. Design by committees is bad, m'ky. So much so, I vowed never to be a part of one again, this goes double if no one on the "team" has ever made a game before. Scope becomes a real issue, REALLY fast. I dare you to count the number of game projects that are incomplete on source forge, dare you. This goes for "Awesome" engines too. If your first game ever is "MMO", you have failed before you even started. I absolutely love reading design documents for things on source forge, my favorites by far have to be the MMO's that state: "Quest Design: Like WoW, but better!".

http://en.wikipedia.org/wiki/Tremulous (http://en.wikipedia.org/wiki/Tremulous)  Too bad I suck at FPS.

I think DCSS benefits from OSS's Million Monkeys typing because the breadth and complexity of game mechanic interactions is really far beyond what a small dev team could handle.

So project management is the major hurdle.  I was thinking art.

It is that too, but mostly because, especially in groups that want to make an entire game engine from scratch (Rendering, is not the same as game player) if the programmers and rendering pipeline guys can't agree on (and then add and finish!) the features available to artists, and if it does not translate or integrate with the artists software, then there is no way to get art in.

Static models are vastly less complicated to create (Rendering/game layer support) than say, a fully functional player class with all the support needed for the features you intend to have in your game. Players are where most programmers crumble when it dawns on them just how complicated, and how many subsystems are required when you make an engine from scratch. The player model, and class is the single most complicated piece of any engine, and of any game.

Also, any programmer that uses the word "easy"... I walk on by.

If a project uses ioquake like Tremulous, how much of your art pipeline is done? In your leet red-name off-the-cuff opinion.

Anything based on ID software tech has the benefit of many years of tool refinement, and documentation, open source or not. Its technically a middleware at that point. Then, all that would be left is "quality" of art. Of course, that is if the game design stays within the capability of the engine its based on, large re-factoring may cause issues. Someone on the committee may want long flowing hair.  :oh_i_see:

Of course, most open source engine that are derived from previously commercial packages will for the most part be forever locked into that era (by tech, or accessibility or legal issues with use of librarys, some open source engines only provide things like the script layer, leaving the compiled EXE un-editable). That's not necessarily a bad thing though, on the low requirement art consideration front.

Also, I'm not leet, I'm just speaking from years of working with this or that project, many early attempts being open source endeavors, Something I wish on no one.


^^

Go dig out a copy of an Unreal engine game, launch the editor, and study how they handle the actor class, the player pawn, and cameras.  That's your hurdle to overcome, not rendering.  A person that can replicate what Sweeny does is worth a fucking fortune, and you will be lucky if you can find someone who can who isn't employed.

Most hardcore hackers don't have persistence for game programming. It's also why there's a dearth of open source calendar (at least in terms of polish and quality) and productivity apps.

Most of the really gifted programmers I've worked with and/or known just are not enamored with games. Maybe to tinker and play a bit, but a far cry from passionate gamer. Code a skeleton or CLI mockup OK, but to spend the iterations required for something with wide allure is not typically in the cards. Nor is attention and devotion to warm and friendly UI.

Thus, is why the best open source gems are the likes of NetHack, NetTrek or DwarfFortress.

Or knockoffs of successful commercial games — like FreeCiv (which incidentally, the FreeCiv team has developed an HTML5 version that runs in the browser, though it takes forever to cache all the art on my machine…).

So so true.

Although it's rather unfair to blame the coders for bad UI. It's not, after all, really their job or part of their skillset other than by historic necessity. Programming gives you very little intrinsic knowledge of UI's (probably no more than anyone else technical in the team) so the coder is unlikely to be the most suitable person for the job anyway, he/she just knows how to implement one. Designing and prototyping it should ideally be done by someone else. It's a big job, regardless of who does it, so it shouldn't be expected to happen "automatically," especially since it has massive upkeep. It needs to be given proper focus if it's to evolve beyond "programmer UI."

It's not applicable to very small teams, but UI is certainly the responsibility of several people. UI is hard (not to mention repetetive) to design and very easy to criticize.

Edit:
I have to clarify - for example, in solo endeavours, users are very accepting of bad art (DF?) but can get very testy about bad UI (DF.) I can sympathize, but as mentioned, UI isn't some marginal job that lazy coders just won't do just because it's boring. Although, God knows I have produced some crappy UIs out of pure laziness. :-)

http://www.wesnoth.org/

UI is not just artwork though.  UI (in my mind at least) also deals with the processes users go through in order to complete a task in the game or application.  So in an MMO, you can consider how the user mines minerals and gets feedback about that a UI issue.  It has nothing to do with the graphics for the interface to be pretty, but how the user goes about actually performing the issue. 

And this is an aspect of UI that programmers also aren't the best at, which confuses me.  Most programmers get too caught up into the internal implementation and don't take a step back and see the system from the user's perspective.

My boss' lab has a lot of comp sci students because he does molecular simulation.  We invariable see they don't care if the programs they write give back usable data, only that it "works".  Once it spits out a number, they think they're done.

Comp Sci programs never train them to use programming as a means to an end.  Programming itself is the end as far as they are concerned.