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?

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 am a firm believer that if the core mechanic is simple, it is your duty to do the secondary functions in greater detail, and vice versa. With such ambiguously defined gameworld anything is possible in theory. In general, the blacksmith's quests range from getting the materials for him to forge you weapons, an example could be getting him a piece of leather so i can make the handle of your first sword. You could buy the piece of leather, you could go and hunt a deer for its hide, you could go kill a bandit and loot his own leather hood or something. All that may sound overly complicated, but in a gameworld this simple, its all summed up to sprites and a few attributes, i believe.

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.

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.

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.

This is the point of prototyping. It's not for us, it's for you. When I'm working on a new game design, I don't consider any of my numbers or equations as fixed until they've been prototyped and tested. You can theory-craft all you want, but at the end of the day it's how the game plays and feels that really matters. Prototyping is what gets you there.

I really like your idea of playing a non-magic-user in a fantasy world. I think you've found an interesting situation that hasn't really been addressed in games before. As you said, most RPGs would make you the meat shield for your own spellcasters. But if you're on your own, what kind of tactics would you need to use? Very interesting!

Thanks for the feedback. I've been having exams so I couldn't find some time to work on this. In any case, since two days ago I've been greatly expanding the Design Document, adding descriptions and numbers for all tiers of armor and weapons and abilities effects, among other things.

I really think it's getting almost too big, but I'll see how it ends before anything else. I haven't done the prototype, and yeah I know that's just being lazy.

However I would like to ask your opinion on one topic: In regard of single player RPGs, there is this concept of goal and freedom to really call it a sandbox.

In the most general sense, I want my player to go and clear the 7 dungeons located all over the gameworld before going to the final one to defeat the Dragon (smells like Ganon, i know). But this kind of progression would mean having to go to the dungeons in the right order and going to towns in the right order to get the Quests that would open up the needed doors and obstacles to proceed to the next part of the world. Does this take away from the exploration/sandbox experience? Is it ok to make the player go through the entire game before really letting them wander around? Or would it be better to let the monster's difficulty teach the player where he should not go until later?

Also, I would like to know in a direct, sharp "Yes"or "No" (You can elaborate if you wish) if finishing this document with ALL POSSIBLE needed information would be enough for me to present it to a programmer and an artist so they help me actually making this game (I could make the music and advertising... am I still the "Idea Guy" only?)

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)