My solution for this is rather simple. You simply focus and categorize melee into sub branches and apply those "Elemental" or "Different rules" to each kind of physical weapon and put it on par with a magic counterpart. Allow me to give you an example.

Say you have a shield. Well that could be pretty much it. My kind of focus would be to ask, what kind of shield? is it a wooden shield?
A wooden shield would be very poor when defending against melee... but perhaps it can be useful when dealing with Energy/Electricity-based magic users.
Then it comes the problem of fire magic! a whole world opens when you "Corner" your player in the non-magical role.

Sounds pretty good, I think in combination with the different abilities you mentioned that this is a pretty solid concept. Whether or not it's actually fun will depend on the specifics of your actual implementation, but it's certainly a foundation with the potential to be very fun.


As for your difficulties with making a prototype, if you have trouble with coding I normally recommend looking at tools such as Construct 2 or Game Maker which can allow you to do some or all of the work of putting together a simple game without coding or with only minimal scripting in a highly simplified language. In the case of this particular idea you might even be able to create the final game with such a package, but even for more complex games or those with more difficult performance requirements it can still be good to put together a small prototype to play with your mechanics. As an added bonus it can also help with explaining and marketing the idea later on.

You're right about "the idea guy" though, and I think what you're doing by working to fully detail and document the idea and begin creating content is an excellent step in the right direction.



Can you elaborate on the non-combat quests a bit more? They sounded like a reasonably important part of the concept, but aren't really detailed at all -- will they be mini-games, simple "reach the place and pick the dialogue options" mechanics, or something else entirely?

I have made some games in Stencyl, if that counts; i could probably make a prototype in there, yes. However, i would hate having my final product being done in there. A browser game or a standalone .exe would be a perfect scenario for me.

Stencyl can output Flash games which do run in the browser if I'm not mistaken, so there's no real reason it couldn't be used for your final product. Similarly, Construct 2 outputs HTML5 to run in the web-browser, and can also export executables via Awesomium.

Putting that aside though, if you're uncomfortable with using such packages to produce your final product that's absolutely your decision, but they can definitely still provide value in that you can easily get a simplified prototype working to try out your core mechanics -- you can then really test out all those numbers and equations for your documentation, and will be able to show a potential programmer exactly how it should work rather than describing it.

Hi there Lexadrik!

So I know you asked for a defined yes or no in finishing your design document before approaching programmers, but I just want to say that a design document should be a living and breathing thing. It should grow and change based on the needs, wants, and ideas of those involved.

For a direct answer, I'm going to say yes AND no. If I were you, I'd finish as much as you can think of, but knowing that it isn't set in stone and you have the ability to change, tweak, edit, and even re-write the whole document if you and your team wants.

As for having trouble with picking up programming, it's okay. Not everyone has a knack for it. I'm no programmer, but I learned skills and knowledge that helps in the process of game creation and did pick up enough programming to spot a syntax error or two and some logic basics. Being able to diversify is good; there is no doubt there, but not everyone can program. If everyone could, there would be a hell-of-a lot more games out there and being a programmer would be a minimum wage job similar to a fast-food dish-washer.

Find the things you can do and like doing. Find your passions (hopefully they fall within the industry). Focus, train, and nurture those passions and you'll add value to yourself. I think that's the best way to break free of that "Idea Guy" stigma, even when it is self-imposed.

If I may suggest, try out some of the "programming free" engines like Game Maker or Construct2. You should be able to make a quick mock-up of your game and focus more on the "fun factor" than the code.

All in all though, I like your idea. A little bland in the sense that you're asking the player to glean that magic isn't on their side to make things easy and that might not come out well unless you spell it out (see what I did there? ) for the player or make that a pivotal part of the story. Like the world is 99% wizards, witches, and other magic-users and they're all jerks to the player because she/he can't use magic. Then maybe it turns out that the end boss dragon is immune to magic, making everyone but the player character useless in fighting it. I really think the game-play will need to be solid and responsive in order to get players addicted to your game.

Just my two cents; hope it helped.

There is magic in the world, in the form of NPC's such as enemies, allies and magical creatures, however; the player CANNOT use magic.

this is a great idea IMO, one I'll be using in my game (except my game has much less magic all around, think Game of Thrones -like). This way magic feels unique (and therefore, more "magic"), as opposed to having a game world where everyone and their sister can throw fireballs around.
And later on if you make a sequel/alternate where the player can use magic he'll feel more unique too (specially if there's only one or two other wizards in the realm)