Writer needs Coder

[gorbeh]

Hello!
Let me introduce myself first.
I am a (new) biotechnology student who is fascinated by ASCII graphics.Before roguelikes,I played alot of fantasy games,like the elder scrolls series and the gothic series,but as my age has increased,the interest of gaming altogether has faded.Except,of course,the interest in roguelikes.I have played DCSS,Poschengband,FAAngband,ADOM,and dwarf fortress.Two of them I managed to win.I loved the spell system and the beautiful balance of dungeon crawl,and the endless dungeons of the Angband variants.The seemingly endless monster unique list of poschengband was awesome too.Well,I could go on,but lets stick to the subject matter :-).

I had reached a point where I wanted to make a new Angband Variant,or a Frankenstein from the codes of Crawl and Angband together.I spent a couple of days learning C++,making good progress,but after some time I realized that no matter how fast I learn it,I can't reach a high enough proficiency level in Coding(In the time span I have) to realize my ideas.I started then to write down my ideas regarding a roguelike,both because as a means to not forget them,and also to show them in a roguelike website,with the hope of catching the attention of a coder who likes my ideas.

So,that was the introduction and explanation part :-).I hope you take time reading it.I wrote it in a format so as to adress the reader
Its too big to paste here

http://m.uploadedit.com/b039/1410686901357.txt

Please make sure you have time to read it,because it takes atleast 20 minutes,for a fast reader.


If you want to give it a shot,send me an email (abazariakram@gmx.com),or a private message.Have a nice day!

PS:It would be easier on the eye if you copied it into a txt file and activated word wrap,i forgot to do that @_@.

[mushroom patch]

lol

[Kevin Granade]

Seconding mushrom patch's derision in more detail.  Ideas are easy, the design and implementation are 99% or more of the work.  You have a much better chance of powering through studying coding and doing it yourself than having a competent programmer make a game from your ideas.

[koiwai]

I will give you a few ideas how to proceed in you project

1. Since you are probably a young game developer, you will learn a lot more if you start programming the game yourself. Without such experience, your design will always be weak and shallow. In general, unless it's a commercial project, be ready to do everything yourself.

2. C++ is an ok choice only if you already know this language well. Otherwise, I would suggest LOVE engine (LUA), or pygame (Python). Especially, if you don't know much about programming.

3. > "animations should have a playtime of 2 or 1 milli seconds"
It would not work. Many screens update just 60 times per second, that is, they update once every 16 milliseconds. The human eye and brain are also not that quick either. Animating actions in turn-based games is actually rather tricky, if you think about it. Example. You are surrounded by 100 mobs (it's feasible, it's just a square 10 by 10), do you want to animate their actions one by one or do all the animations simultaneously? If you want to do them simultaneously, what if some mobs are faster than the other? You have to think about such details beforehand.

4. The idea of multi-screen cities is ok. But try to implement such city generation yourself to see what are the possible problems. Procedural generation of a city is significantly harder than making random caves with random monsters. This is why in the majority of roguelike games, the village maps are not random but predesigned. Of course, randomly generated cities is a great thing, but make sure that you can pull it off.

I did not read the rest of the document, it's too long.

[mushroom patch]

Seconding mushrom patch's derision in more detail.  Ideas are easy, the design and implementation are 99% or more of the work.  You have a much better chance of powering through studying coding and doing it yourself than having a competent programmer make a game from your ideas.

Unless you're prepared to pay them, of course.

[Samildanach]

As a rule, programmers with the know-how to make a game usually have plenty of ideas of their own - more than they have time to work on. It sounds harsh but they're unlikely to volunteer to bring someone else's idea to life.

I'm not knocking the value of ideas - I'm an ideas person myself - but 99% of the graft is in actually programming the game (or writing the book, or painting the picture, or whatever, depending on the creative medium in question). That's where the act of creation takes place. It's where the problems arise, and by extension where all of the problem solving has to occur. Someone who is capable of doing that will prefer to exert on their own projects, not someone else's. I'm not trying to shoot you down, just trying to manage your expectations.

Realistically you have three options: 1) learn programming and make the game yourself; 2) pay someone to program for you; 3) rope in a friend who can program and is willing to help out (by this, I mean someone who already knows you and will help you from good will and friendship, not a stranger).

I know you said you tried learning programming and felt it was too slow, but someone you ask to program for you will already have put it in all of that time to learn, and you deciding it's too slow a process could easily come across as "I can't be bothered, I want you to do the work for me". No one wants that.

Additionally, as koiwai mentioned, the document is too long. If you're going to keep pitching your idea and hope that someone is so impressed by it that they really want to create it for you (long odds), you need to make it short and punchy. You know the phrase 'elevator pitch'? That.

[Krice]

If someone has designed a original rpg system (+content for it) and it looks like serious stuff then I'm ready. But in this case it doesn't seem to be so.

[TheCreator]

As a rule, programmers with the know-how to make a game usually have plenty of ideas of their own - more than they have time to work on.

There's always an exception to a rule. Me, for example. I love programming, but I'd prefer that someone else was doing majority of design in my game. Unfortunately, it is nearly impossible to find a good designer for an existing project.

[Krice]

it is nearly impossible to find a good designer for an existing project.

I think I'm a good game designer.

[TheCreator]

I think I'm a good game designer.

Everybody thinks he's a great designer. This doesn't make the search any easier. Just the opposite, I would say.

[Krice]

Everybody thinks he's a great designer.

I'm also experienced.

[TheCreator]

I'm also experienced.

There's no doubt about it. I remember, though, that you have been developing a game (or two) for quite many years without a playable release, so the game is probably not that great, either design-wise or code-wise, or both.

[Krice]

you have been developing a game (or two) for quite many years without a playable release, so the game is probably not that great, either design-wise or code-wise, or both.

How would you know?

[Bear]

If you want to code a game you need to learn to code.

If you want to write a spec for a coder to implement, you need to learn to write.

It is clear from your message that you have not done the first.  It is clear from the text document that you linked, that you have not done the second. 

I think most of the ideas presented in your document are irrelevant to game design and belong in a separate category, "interface choices."  The little that *is* relevant to game design is unclear, or presented without discussion of its effect on players and game balance.  All of it is unorganized and not laid out in any logical order or sections.  And many places have references to things "elsewhere in the document" that you did not in fact put anywhere in the document.

The short version of the story is that if you do find the nearly-mythical "coder looking for a writer", what you have written here will convince them that they do NOT want to work with you.

Most coders while not working for pay don't care much about somebody else's ideas.  So your odds of getting someone to work with you on creating a game are slim to start with.  In order to convince people that it'll be worthwhile to collaborate with you, you need to have your ideas well thought out, well presented, and well organized. Because otherwise, it's really a whole lot easier to ignore your ideas than to find your idea for a particular thing buried somewhere in your document and figure out whether it's a good idea or not.  Remember, the point for a coder in having someone else do the writing is that it's supposed to HELP.  If extracting meaning from the writing is hard, it isn't helpful.

So if your file of ideas isn't at least as well organized as, say, this guide to rogue, then posting it is going to actively discourage people from working with you.  But you even have more things you need to cover, because that's just a player guide.  An implementer's guide must also explain why each thing is a better idea in terms of game design than the alternatives.

[mushroom patch]

I appreciate the careful elaboration on my first response given by other posters.

I would like to comment slightly more seriously on one aspect of what the OP puts forth. While there's no way he's going to get anyone to do anything on a new project of his own, it's quite possible that he could find a development team of an existing angband variant or a crawl fork that would be sympathetic to his broad notion of combining the two somehow (although I think this is mostly a bad idea, maybe a pulpier, more linear angband-like game with crawl mechanics could work... or something).

Basically, if you don't know how to program and you don't have the requisite skills or leadership ability to start your own project, there may yet be a future for you in angband variant or crawl fork development. Start small by trying to get contributions accepted. Over time, you'll be able to insinuate more of your unique ideas into the project through discussion and persuasion, as opposed to raw coding. (You'll still have to code a lot yourself though.)