Welcome to the forums,
@Nirvanna21! It's great that you're posting your ideas early on, and asking for feedback.
To be honest, I think there's a lot that can be improved here. Brace yourself for a ton of critique and advice, and keep in mind that it's all for the purpose of helping you design a
great game rather than just an adequate one.
The Document Itself
First of all, about the Game Design Doc itself - while it certainly can be a helpful way to store notes and ideas for yourself, the main purposes of a GDD, as I understand them, is to be able to clearly present information to team members (to ensure everyone is working toward the same goal), to companies or financial backers (to prove your game is financially feasible), and/or to trusted feedback-givers (to chip in with ideas or concerns before you even need to create a bit of actual content). I don't see a lot to work with for any of those parties.
"Adventure RPG" isn't a Theme; it's a genre. "Theme" is essentially the unspoken message you want your player to take from the game. Sometimes there is none.
Super Mario Bros. doesn't have a theme.
Undertale's theme is that your assumptions and your power fantasies will blind you to the truth.
Forrest Gump's theme is that a simple, earnest man can change the world. Disneyland's theme can be encapsulated in a single word: Reassurance.
Your "Description" will be meaningless to anyone who hasn't played all four of the games mentioned. For the build system, it will even be meaningless to people who
have played the two games you mentioned, because they won't know what you're pulling from each game. Focus instead on using this section to highlight what makes your game
special. Think of it like an Elevator Pitch.
To use an example for my own game
timeblazer, here's what I might write up in a GDD Description:
timeblazer is an RPG focused on speed, forward motion, and interesting decisions. When a happy couple gets sucked into a virtual isekai-like world, they have to play through the levels of the game with their lives on the line in order to find a way out. Each level presents an action-packed series of 60-second minigames that test the player's reflexes, perception, and strategic skills - and success in these minigames grants the player advantages in the climactic turn-based boss battle against a huge monster at the end of each level. Along the way, the characters develop their relationship and learn about the strange physical laws of the virtual world. timeblazer is an intentionally fast and narrow experience that eschews plot flags, backtracking, and getting lost - it's an RPG that "gets straight to the good bits".
Your "Story" consists only of backstory/setting. And while that setting is pretty cool IMO, it's useless in a vacuum. Your GDD should include the
major story beats and very high-level (low-detail) flow of the plot. Essentially, try to spoil the entire plot in 60 seconds. You should also list the Characters (perhaps in their own separate section), with a
short paragraph each describing their personality, role in the story, and role in combat (or other gameplay).
Your "Skills" section doesn't serve any purpose; it's essentially just a bloated list of Names. Names won't help you design good games, nor will they give your reader the slightest idea about your intentions. The reader won't have any idea what the difference between "Cleansing" and "Cleansing!!" is, or what the difference between "Gale!!", "Shock!!", and "Fire!!" are. As an avid RPG fan I can assume they deal different types of elemental damage, but beyond that, I have no way to tell. A much better format would be to have a
short chart which describes each element, and what the spells of its type tend to do. Fire - "Deals AoE fire-elemental damage". Ice - "Deals ice-elemental damage; spells can slow or stun foes" (note I said
stun rather than
freeze - focus on function rather than aesthetics). Water - "Cleanses harmful status effects". Put the names of spells in the program itself, or in a supplementary document. Take a close look at sentences like
"For the sake of current point simplicity, Concentrate and Expand will be used for both Technique and Spell paths; where as, Aura will be Spell specific and Multistrike will be Technique specific." That's a fine note to yourself, but for a GDD that you're presenting to someone, couldn't you leave details like that out? At the very least, reduce the verbiage. "Technique Path also includes: Concentrate, Expand, Multistrike. Spell Path also includes: Concentrate, Expand, Aura."
"Weapons & Armors" section looks good, for the most part. Use tables to reduce verbiage if you can. The one thing that is bad in this section is your blurb on enchanting:
"In order to bring balance to the idea of theory crafting items for encounters, I will introduce a three slot enchanting system to each item except for Music. The enchanting system uses Essences, which are energies that can be derived from enemy leftovers. With three slots per item type, that gives nine enchants at any one time which should cover for the Second Skin alternative." I have no idea how your enchanting system works from this description. Give a clear explanation of the
mechanics that the player uses to enchant armor.
"States" section might as well not exist. Naming things is not helpful, and while I'm an RPG Maker user and I understand what those states do in-engine, many readers will not. More importantly, though, is that you should be describing the role of states in your game - how they are applied, how they are removed, who specializes in them, and especially the general role that "states" have in the nature of your combat. An overall view of the role states play in your game is far more important than a list of states (or even what each state individually does).
Sorely missing from your GDD are sections on the mechanics of the
combat system (how does a combat encounter start? how does the ATB work? how do you select actions? how is damage calculated, and why? how many party members and enemies are there? what is the goal of combat? you have to spell these things out), and
places in your game (not a list of names, but quick notes about their role in the game [dungeon, explorable area, sidequest zone, small town, large town, etc.], their role in the story, and their artistic direction).
Overall, you are assuming that the reader knows about the games and tools that you know about.
I recommend checking out Scott Rogers' book "Level Up". He has a really beefy chapter in there about the Game Design Document, and while Rogers has never worked on an RPG, I still think his examples and advice are more useful than most GDD stuff I've seen on the Internet. I think you'll learn a lot from reading it.
Game Design Issues
So aside from the issues with the GDD itself, I think that the content reveals some possible flaws with your game design that you may want to rethink sooner rather than later.
The first and most important thing I want to point out is that you're trying to mash up a lot of RPG subgenres. "
An adventure RPG with a Pokemon map direction, a Grandia battle system (ATB ) and a build system that draws inspiration from Diablo 2 and Path of Exile." Have you sat down and considered what's great about
Pokemon's map system and orientation, and why it works for a game like
Pokemon? Have you considered what's great about
Diablo 2's character-building options, and what's maybe not so great about it, and what's great but only works for a game like
Diablo 2? Figuring out a game's
Aesthetics of Play is a great tool to use when you're trying to examine
why something is so fun. And more importantly - have you considered how all of those systems will work in unison, to become something more than the sum of their parts?
I'm not saying that mashing up these specific games in this way is doomed to fail. It could create something brilliant. But to give yourself the best chance, you want to think through why you enjoyed those parts of those games so much, and you have to think through what a player's player experience will be like when they have the freedom to play around with build systems like
Path of Exile's skill trees in a (perhaps linear) Adventure RPG that uses a
Grandia-like battle system.
Sometimes you have a lot of great ideas and you have to separate them into different games because they don't mesh that well.
The other issue I can sort of see at this early stage is that a lot of the gameplay mechanics sort of lack a purpose - an intent, a direction that drives the design. Without that, it's almost impossible to create a great game, because anything that "works" will work basically by accident.
It's the most clear in your Skills design. The Skill Tree skill-learning system sounds decent, but the skills themselves lack any kind of purpose or diversity. I'm going to assume (for lack of better information) that 90% of the non-core elemental 'classes' of skills are simply of the Weak Damage - Strong Damage - Very Strong Damage (or maybe AoE Damage) - Add Element to Weapon variety. Essentially you are creating 64 skills, and requiring animations and bug-testing for each one, when you are really only creating 4
different non-core skills for people to try and enjoy. Because unless there's an obvious weakness to Fire (meaning that you should
only use Fire skills - not that interesting), then what is the interesting decision for the player to make when deciding between "Fire!!" and "Frostbite!!"?
I always get a little sad when I see a design that uses Elemental weaknesses and resistances without really thinking through what they bring to the game. A ton of developers do it, amateur and professional ones alike. I've done it before as well. I make the case against Elemental Weak/Resist systems for their own sake
in this post from last year, but to bring it to your game specifically - I compare the amount of guess-and-check and mental bookkeeping that the player will have to do to utilize weaknesses and resists properly, plus the way it inflates the number of skills you can learn but narrows the number you can feasibly use in a given battle, against the only positive dynamic I can spot, which is that needing to be ready for a diversity of enemy resists forces an interesting skill-tree decision between going directly up the tree vs. spreading out into multiple elements. I don't see a compelling reason to keep the elemental system as it is now.
On the other hand, when you have a unique or otherwise "featured" core system in your game, elements and other systems can be great side-systems to build around the core system. For example, you want to include a
Grandia-like Faux ATB system, which (if I remember
Grandia correctly) allows characters to build up "points" (represented by the timeline-thing) toward a turn, and take a turn whenever their points fill up. Different types of elemental magic (or weaponry) could represent different ways of interacting with this system, and then each specialty feels really new and interesting. For example, maybe Wind magic specializes in knocking opponents back in the turn order (taking away their "turn points"), Ice magic is super-powerful but tends to have a long "cast time" between choosing your spell and actually having it cast, and Lightning magic deals less damage but has very quick cast times, as well as a few spells which can interrupt an enemy's cast. Maybe spells from different elements, if they finish their cast at exactly the same time, also create a power "combo spell" that both of the allies cast together. Stuff like that.
The more your systems interact with each other, the more depth you can create without a lot of bloat.
Was
Grandia's battle system really cool
because of its elemental system (and if so, why?)... or are you just taking
Grandia's elemental system because you liked the game so much?
Maybe you can come up with something that not only offers a lot of interesting choices and interacts with your larger systems, but also ties into the magical sci-fi nature of your setting.
States are another place your design seems to show a lack of intention. The "included" RPG Maker states are just examples - they are there just to show you how easy it is to make some of the common states you've seen before in RPGs! But think about it some more - is having your party member be Asleep or Paralyzed or Confused (until cured with an item) fun? Does it add a lot to battle strategy? And on the flip side, do you have any way to allow characters to use these states and maintain good combat balance, without relying on frustrating RNG rolls and making bosses immune to most of the statuses? These included statuses are easy to make, but they're harder to include in a great game. I generally aim to make status effects that can be inflicted at 50+%, or even 100%, success rate without being overpowered, and I ensure the effects have multiple ways to play through, play around, or remove them (not just Items). As a couple examples of well-designed negative status effects:
- Daze: ATK slightly down and cannot land Critical Hits
- Marked: DEF down and much more likely to be attacked by enemies
- Burn: Healing received is reduced by 60%
- Leeching: Steals HP from their lowest-health ally every turn
- Backfire: Takes damage after casting a spell
- Petrify: Can't act; removed when the enemy that inflicted it dies (and the enemy will only Petrify one character at a time)
Each of those states can change the complexion of the battle (or a character's role in it), without screwing the player for bad RNG or stopping the player from being able to "play". And with the exception of Petrify, they are effects that you could feel okay about allowing the player to toss onto a boss for a few turns, which will give you a lot of latitude for coming up with interesting skills.
Finally, let me say that your initial ideas for Enemies look pretty cool. It is a very, very good thing to give gimmicks to "families" of enemies, like how you are going to give Slime-type enemies "Consume"-style moves. This significantly reduces "battle fatigue" that players feel by making sure that encounters will feel different from each other (rather than "pound on enemy with damage until it dies"), and it also allows for a bit more strategy because it lets players come up with tactics the first second they see a new enemy ("oh, that's a slime!" "oh, that's a golem!") from a family they've fought before.
Assuming you're gonna stick around the site, I highly recommend checking out (and participating in!) the
Game Mechanics Design threads. They cover a lot of really interesting and thoughtful topics, and we have several experienced designers here who can think things through from the player's perspective.
I've written a GDD-sized post of my own here, but hopefully it helps you consider what you need to consider before you dive into creating things in the engine itself.
P.S. - Is your last name really McStay, as it shows in the GDD? That is an awesome name!!
