Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[LegoLord]

I need to do some research on certain topics, and thus far Google and Wikipedia seem unhelpful.  At the moment, I need info on gemstones - preferably a list of them that mentions their properties, the myths and mysticism around them, or both.

Progress on the document:
Weapons types and - cleared
Default weapon list - not yet done (goal: maximum diversity)
Armor types - not yet done (goal: depends on races)
Materials - 9 so far, incomplete data (goal: 15-20)
Magic system description - cleared
List of magic items and their properties - 7 so far, incomplete data (goal: 35+)
Race descriptions - 2 complete
Race artwork - 5 sketched, two of which painted
Race stats - generalized, but complete for 4 species
Combat - not yet done
space travel - not yet done
story/setting - setting more defined, w/ story intro.

Once the design document done, well, we'll just have to see how things go from there.

[qwertyuiopas]

First, you want to have detail.
Then you want a demo, either a crude implementation or at the very least decent concept art.

But to get anywhere with it, you need a decent proof of concept. Something playable.

[DJ]

Can you draw or compose? It's a lot easier to find programmer help if you have skills of your own to contribute to the project.

Anyway, a good start is writing a design document. Do note that a short description does not make a design document. Let's say you're writing one for Starcraft. A short description of the three races and their conflict isn't a design document. A detailed description of their unit rosters, unit roles, unit balance, race balance, race strengths and weaknesses etc, and how it all meshes together is. Basically, you need to imagine the completed game, and describe every single detail.

And when you have a complete design document, there's a minuscule chance that some programmer with lots of free time and no projects of his own will like it and volunteer to help you. So yeah, easiest and fastest way to get it made is to learn programming yourself.

[Uber dwarf2.0]

If you can try making it into a Mod for a game frist.Be sure to limit your team to a small group.Start off with a friend that can program and make sure your core team is only 1-4 people.You can have more devs working on your project, but the bigger the team the more chances of failure.

Slow is better than nothing.

[Duke 2.0]

 I must repeat the idea of doing a design document. Not only does it make people take you a bit more seriously but it shows you the oversights you might have made. I know most game ideas are merely suggestions for features for existing games. This also lets you flesh out what could be a rather weak game/gameplay.

[LegoLord]

Ah.  Well, so far I have already jotted down ideas for several features, including some basic ideas about how a combat and magic system should work in it, among a few other things .  I even have some concept art.  So I suppose it'd just be a matter of expanding on what I already have.  I even have some concept art.

I've thought about doing a mod of another game to make my idea, but I don't really think it would work.  Not to the full extent of what I've thought of, anyway.

[eerr]

what game will it be most similar to?

[LegoLord]

what game will it be most similar to?

Good question.  I don't want to say too much, but it would take place in a futuristic fantasy setting.  That, combined with how out of the norm some faspects of the game would be, would probably make defining just what game it'd be most like.  But I suppose combat would be a bit like DF adventure mode, only with graphics (other aspects of it would probably necessitate at least okay graphics), and maybe a little less graphic.  That's not all there is to it, of course.

And I think some of the ideas I've had since reading Brandon Sanderson's Alcatraz books have been mildly influenced by said books.

[Muz]

Get Construct. It allows you to make just about anything in 2D without much programming skills. It does teach you some decent programming tricks and stuff, but since you're really trying to figure out how to organize a project, it sounds like something you could use.

Assembling a team of anything in the indie gaming world is difficult. Especially when you're not paying them. It's pretty common to make your first game a bit overambitious. OK, not that common, but that's what I'd expect from DF players

You have to rely on doing everything yourself, or at least do enough for people to believe that it's not vaporware. You need to take at least a programming or art role to show something in the first place. Depends on the type of person you want to hire. Not many really want to work on another person's idea, so you'll have to convince them that it's worth it and you're not going to abandon it in the middle, and even if you do, they'll get something out of it.

Like they said, a design document is vital. At the very least, write down everything you want to do in a list. Otherwise, you'll get confused about which to do first. Toady's the best I've seen at sorting out his priorities, you should at least imitate his style.

Once you do that, try and tackle the priorities one by one. If you feel you need more experience, find an easy part of the game and make a game based on training your skills in that part. You could even make it a prequel or something in another part of the world if it's suitable for your game.

[eerr]

I'll get back to you when I've made  something myself...

[codezero]

In my experience, it's usually preferable to spell out your ideas - in your head or on paper - than to implement them, and that's the barrier the game builder must surmount. Every game builder is doing one or the other or even nothing.

The fact that you're unwilling to reveal much about the idea suggests you aren't ready to start implementation. Theorising is proving more rewarding and it always will so long as it takes preference.

[Puzzlemaker]

Modding is the key if you want to prototype.

[alway]

Here are some things I find helpful:

Remember, when implementing, make a to do list. And keep the written version you adhere to nice and short, with just short term projects on it (such as implementing a single system or making a few models/sprites); this should help you from getting to off task and ahead of yourself. Then have your more general design document which you may or may not write down, depending on how easily you forget things, which will have pretty much everything you wanna do on it, prefferably ordered chronologically so as to make transfering to the to do list easier.

[Muz]

In my experience, it's usually preferable to spell out your ideas - in your head or on paper - than to implement them, and that's the barrier the game builder must surmount.

It's a lot better to spell them out on paper, or at least virtual paper. Otherwise, you'll be juggling all of them in your head, which is so not good. One of the biggest reasons games fail is because people keep them in their head; I don't think you can find requiring any design at all being done in someone's head

[codezero]

Yeah no design decisions will have to be culled if you keep it in your head, but what do you think about keeping the gist - the quickest thought of it - in your head? To maintain novelty and keep motivation up..