ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Other Software > Developer's Corner

DC needs a fun game project that multiple people can contribute to

<< < (7/13) > >>

Renegade:
I think the main point to keep in mind is exactly what mouser said: User generated.

For that, the key, crucial factor would be the level editor (or whatever it gets called) and just how easy it is to use. While many games have editors, they are often MAJOR undertakings to create new levels or maps. You have to set aside a few days to get one done.

That's a real barrier. To gain a quick user-base, and get more UGC, the game would need to be simple enough to allow a very quick and easy level editor that lets you create new levels in minutes, not days. Some AI in there could help by auto-generating content.

e.g. For a TD game, an editor could let you create the path(s) then take care of creating the monster levels automatically and fill in the terrain automatically. Further editing could let you tweak the monster levels and terrain, but getting the basic stuff done would make it faster, easier and more fun.

i.e. The editor must be a "casual" editor.

Anyways, just my $0.02.

Deozaan:
That's exactly what I was trying to say earlier. :Thmbsup:

mahesh2k:
Okay, adventure game or TD ?
or cody as angry bird ? :P

I'm with idea of .NET based game (non-xna for crossplatform touch) because that way we can add multiple languages and can even port it to other OS. Let's first decide - type of game then plot and then tools. hussh!  ;D

mouser:
Although it seems completely logical to say we should first pick a type of game, then choose the right tools for the job, I'm not sure that will work.

I think what we have here is a case where:

* It's find to brainstorm multiple potential games that could be created.
* To actually get a game coded, its going to require a single coder to step up and say "I like idea X and will lead this project" and "It will be coded in language P since that is the language I'll be doing most of the coding in"
So in other words, the primary driving factor here is having a program champion an idea+language, and take charge of getting it done, with help from the rest of us.  And there is no reason there just has to be one game idea that goes forward.  The key is finding and inspiring the lead programmers for the games though!

Renegade:
Although it seems completely logical to say we should first pick a type of game, then choose the right tools for the job, I'm not sure that will work.

I think what we have here is a case where:

* It's find to brainstorm multiple potential games that could be created.
* To actually get a game coded, its going to require a single coder to step up and say "I like idea X and will lead this project" and "It will be coded in language P since that is the language I'll be doing most of the coding in"
So in other words, the primary driving factor here is having a program champion an idea+language, and take charge of getting it done, with help from the rest of us.  And there is no reason there just has to be one game idea that goes forward.  The key is finding and inspiring the lead programmers for the games though!
-mouser (January 21, 2011, 02:19 AM)
--- End quote ---

That's likely key.

With a volunteer group, it's unlikely that people would be willing to learn a new language/platform.

I would be willing to contribute, but I can't be the lead or main.

I suppose defining roles and what people can contribute would be a start to find out what's out there.

e.g.

Programming
Graphics
Story boarding
Mechanics/algorithms
etc.

Then what level of commitment,

e.g.

Lead/main
Supporting role
Occasional help when requested

Leads should make the main decisions.

Another thought...

If we find out what skills people have, then it might be easier for people to say what role they could fill in. For example, if there are a lot of guys with Fortran game programming experience, then one of them might be willing to step up and say they would lead if the others could support. Conversely, with 1 guy volunteering to do the game in Haskel or Erlang, it might not be a good idea (I doubt many people here are well versed in Haskel game programming...)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version