Sunday, October 4, 2015

Minimum Viable Product [VR RPG]

When starting a game, it's always a good idea to figure out what you're core product will be so you can layer onto that foundation to create a good product (also might be a good time to mull over logistics before you do a whole bunch of work almost no one will get to enjoy but yourself...) Unlike the MMD project earlier, this game should be a lot more viable for release since I'll be building every asset save the engine myself. Maybe I'll look into getting a pro license so I don't have to deal with the royalties as well, but more or less, I should be able to do whatever I want. Which get's to the goal of the matter.

The primary thing I want to do here is test out my VR control system. I've already outlined it in previous posts, so the question here is how the demo will serve to showcase the system. Goals wise, there are only 2 real "win states" in the game. Either make it to the village and encounter the avatar's lover or reach the top of the cliff and reach the tower.That's it. One route emphasizes combat, the other platforming. Like the control system itself, focus is split between 2 different systems tied into one greater whole.

Simple enough on the surface, but this has to be broken down even further. The control system alone may take 2-3 months to build properly. The world could take just as much time so it's obvious I need a smaller build. So let's break it down piece by piece:

"The game is a VR RPG that will feature the player fighting monsters to escape a dungeon that goes from the base of the sky island to the top of its mountain."


This choice alone really sets up some limits. From a technical perspective, this puts my game at requiring a stable 90hz frame rate running at 1200x2160 in 3d (466560000 pixels/sec). Any graphics, logic, systems, and effects must absolutely NOT LET THIS DROP. If that FPS goes down by even 3 frames per second, it will be noticeable. By 10 and it's harmful. I'd say, I'll need no less than a month to really optimize the game to run to it's best in VR, taking the time to apply things like ambient occlusion, lighting exceptions and so, but I think the best approach I can take will be to design all my assets with as much minimalism as possible. If I really want to avoid any possibility of reduction, I ought to design the game to run at 144 frames per second stably (I have a 144hz Asus VG248QE Monitor) at 1440p DSR (530841600 pixels per second). This is well past the needs of the game itself, but this is what must be done to be absolutely make sure without any doubt the game will be stable.

For the models, I already have a "scheme" in mind where in by I'll be limiting myself to a polygon ceiling of 255 triangles for the overall form. This is a consideration born out of the limitations of Unity and modern game physics where concave meshes generally tend to be avoided like the plague due to physics costs, so I'm trying to deal with said limits by using it as a foundation. If the object can't be adequately contoured to a 255 tri model, then it probably needs some optimizing. or subdividing. Concave models, under this logic, would need to fit in half of this limit due to the need to have an inside and outside, meaning the limit there would be to either  feature 2 meshes at 255 polys or 1 mesh with ~127 polys in the other form. Honestly, this shouldn't be a much of a limit at all, and all things considered, it's really a matter of creating a whole bunch of pseudo-primitives for the sake of more complex models.

In addition, since I'm using game as a test of the philosophies behind a lot of Project Navalusu items, I'm also going to be taking some of my material notions from that project and applying them to this one. There will likely only be a very small set of possible materials for pure elements, with living things like animals and plants having a separate, more complex set and more unique entities like characters and monsters having their own materials. I'm actually going to be avoiding the use of textures as much as possible, opting to use a simplified set of textures based on patterns to help amplify the polygons rather than to take their place. VR just leaves no space for an off texture. If it's noticeable at all, it will be noticed. I've used this example in the past but it needs reiterating. Textures in VR should be used as make up rather than costuming. Draw a six pack on a flat belly and it won't do much. Do so on a slightly toned abdomen and you get more than what's really there.

At most, I think no single model here will feature more than 4,000 polygons for preliminary testing. Final models will only steadily build up on that number, with it being likely some models like the island itself and the characters entering into the range of the tens of thousands of polygons, but performance is king here and I don't want to spend most of my optimization time just decimating model quality down furthered and further, not knowing whether it's the fault of the models or something else that the FPS is brutally low. Furthermore, I can't even reasonably do much performance testing until I buy my new CPU later this month that that is up to par with the set Oculus specs, I can't really be certain if any of my current performance instincts are right. Right now, I can barely keep 3 high res MMD models dancing in  Unity in one scene, but that could very well switch to 20 when I go to Intel. Who knows? No matter what, I just can't let things dip below 90hz.

Core: Build to run at 144hz and 1440p without locked at 2d. This should be comparable to load at VR levels.


This has to be made clear from the get go. Depending on how I choose things here, I could have the workload of either a text adventure or a Skyrim. It's a dangerous rabbit hole to plunder.

At a fundamental level, it has to coincide with the world's laws I've already set, which makes Mana the core item at the center of almost everything here. Mana isn't just a magic meter like in other games. It's quite literally the drive of everything. Your HP is mana. Your stamina is mana. Your magic is mana. Items have mana. Trees have mana. Grass has mana. The breeze has mana. Anything with a script attached will have mana. To figure out mana here is to figure out the system.

The core of mana revolves around how much of it is in a place and how tied down it is there. The more mana, the more strangely an object can and is likely to behave. All objects have a set amount of mana that keeps them in existence. Should mana fall below this line, they disintegrate. If they have more than their base need, they start to behave differently. Initially, this will be applied to additional self preservation. This phenomena could be called an entities HP, though LP would be more fitting. After a point, HP reaches a limit, and the excess of mana starts to be applied towards other, more bizarre functions. This could include growing outwards or multiplying to increase the range of mana gathering. This is what plants do. Animals would take the alternative of finding other mana bearing items and destroying them, to intake their mana. This would be regarded as EXP, though really it's just another form of mana. EXP can be applied to any of the entities properties based on how its activities would demarcate. If the entity needs to move, movement EXP is added. If it needs to resist, Defense is added to bolster HP. Stats, essentially leveled by use. Finally, after a certain level of EXP is gained, really powerful functions can start to appear and we get AI. This is where humans, angels, demons, and monsters come in. These kinds of being are capable of adaptive behaviors and have much more effective means of using their mana to gain more EXP, which should increase the amount of mana that can be received back in return. These means can be called skills. Any expended mana used by skills or redirected towards other stats can be regained over time back to within the initial range of the level.

So far, it's simple. We've got a fundamental basis for HP. EXP is determined by actions that result in getting mana on a per stat basis, adding up to a total level. Once your solid stats are established, skills can be created to take advantage of mana . Simple enough, right? Note that the mana mentioned for the higher level beings isn't "excess" or "extra". HP, EXP, skills, they all draw from the same pool of mana. Your HP can be used to fuel skills. You can reduce your movement ability in exchange for defense. Sacrifice some Defense and you can temporarily up your HP. Burn some HP to get in those last few hits on an enemy. If you use skills too much, you'll probably end up dead. This one item here results in an interesting dynamic where the player should be able to manage their stats and abilities to specifically handle different scenarios as they deem necessary. If you're fighting a fast foe, you may want to up your speed to match or up your defense to deal with the damage. Perhaps you'll want to specifically partition off parts of your mana for specific things like sword arts or magic arts so you can rest easy that your core HP is safe. I know for a fact I'll end up having to rebalance this kind of thing like crazy towards the end, but it's good to know that I'll have to consider the player's ability to alter their stats in as a key item. In all likelihood, this will probably be akin to reseting your skills or level boosts in other games.

Outside of the more RPG elements, how's about the narrative elements of the territory? Well, it's already been established that there won't be much of a story focus for this title, but that doesn't mean that it can be ignored. I won't reveal any specifics here for the sake of giving a surprise, but it should be known that the player's particular role in the narrative will have a massive impact on the flow of their experience and it should provide a rather intriguing perspective on things that traditionally aren't regarded with much significance. I don't believe in using a narrative to be the core driving force of an experience, as many other games in this genre tend to try, for a variety of reasons. To sum it up briefly: I think its inefficient. I believe using interactivity to tell a specific narrative is a very poor methodology as you're essentially trying to create a story without a definite medium. A game is NOT a software execution. That's just one half. Games are a product only completed with the players make use of them. This is as true in board games and playground games as it is in video games. Trying to create a story using a game thus is a poor choice of actions as the final product will entirely depend on which person comes to the table. Most books have an intended output. Game "narratives" work best when they instead ask the player to reflect upon or generate a narrative of their own creation. People can feel free to disagree with me all they want, but I have yet to find a single game in my entire life with a linear narrative where I felt said narrative would not have been better served to me in a film or book instead.

Find me such games and I may change my mind, but till then, I'm sticking to my philosophy.

Core: HP, EXP, LVs, Stats with redistribution of stat points. Let story tell itself.


This element shouldn't be too troublesome as I've already decided that this game will not feature player customization. The question here being, what the player will actually be? Will they be human? Will they be a demon? Female? Tall? Slender? I don't really have much liberty to have a wide range of possible choices as that will take too much development time and I don't want this project to take any more than 6 months tops. At this point. I think I may only have time for 2 characters tops, with only 1 if things get tight. Once I finish out going over what will need to be in the game for certain, I'll have a look at my remaining time and determine the cut off date for the characters. Using a loose estimate of 3 months for characters and controls and 3 months for world and monsters, that would put the cut off date for characters before the end of this year. That should be enough time for me to build the first character. If that ends up being sometime in early November. I'll try to go for two characters. If that ends up anywhere close to December, however, I will just skip the second character and move on to other matters, leaving any excess time at the end for polishing the game.

With that in mind, that makes the choice of what I opt to go for in the first character of a matter of the utmost importance at this stage. There's a very real chance the first character may end up being the only character so if I make a poor choice now, it could hurt the project's schedule, and thus it's release chances, immensely. I'll be up front here, I've got a particular leaning in mind already, but it's probably not going to earn me many fans if the internet's general climate is anything to go by. In all likelihood, I'm going to go with an attractive, female non human for the first model attempt. There are a lot of reasons for this, but I have a feeling that this is going to seem cheap in some matters, so I'll just share my thoughts right away.

To start, the last character model I made was primarily male formatted, so I've been rather excited to try my hand at a female model for my second go round to vary things up. In addition, there's also a bit of a pragmatic reason for this: disassociation and comfort. It's probably been said dozens of times in this industry, but photo realistic graphics are a HARD thing to accomplish, and the closer and closer we get, the more and more easily we can mess up and create something that results in an uncanny image. This, my personal inclinations towards anime, and my experience that it's a lot easier to forgive imperfections in stylized works have me leaning clearly towards stylized trappings. I am better at drawing female characters than I am males in a stylized manner so opting for a female avatar first would better be able to take advantage of my abilities. Adding in the benefit of choosing a non human humanoid as a model choice makes it so I should be able to reduce the uncanny valley's prevalence while still being able to deliver on an appealing character.

Outside of considerations for my particular set of abilities, there is another reason to go for a female character in particular: immersion. This may be a factor exclusive to me, but without a doubt there are two experiences in VR that I've had to this day that have left an indelible impression on me: my first VR session seeing Miku in the Miku Entertainment sphere and my first time using a female avatar in RiftMax Theatre. The former was valuable in that it showed to me that stylized imagery can and is easily capable of being just as immersive as "realistic" imagery. The latter was possibly more valuable as it showed me that the immersion could extend to my sense self. Seeing the large peaks (I'm so sorry to any woman that reads this) bulging out from my chest and keeping in tandem with my movements left an impression on me that I can still feel to this day. I have never had this level of an immediate connection to a character in game since and it's left me wondering how it is that the female model, despite the crude graphics and controls, was able to so immediately and powerfully generate a sense of presence. That sensation of presence was so powerful that I can't help but also want to make absolutely certain that I'm doing everything in my power to get that across to as man people as I can within the VR medium. This may very well only be taking the male end of the spectrum into consideration, but I'm actually also considering this as a consideration for female players as well. By my observations and what reports seem to be indicating, women seem to be having more trouble acclimating to VR hardware than men, possibly do to a difference in the ways our brains/eyes process color information to perceive depth. While the effort of also having a female character model may not be enough to deal with any inherent hardware issues, I hope at the very least that the female model should make the experience at least a bit more bearable by minimizing the amount of abstraction necessary in an already taxed neuro-system. Perhaps I'm misguided in these thoughts, but if it makes you feel any better, I just like playing as girls in RPGs that give me the option. ;)

Core: Building a female avatar first, male second if time is available (Honestly doubting it will be).


Thankfully, I wrote out most of what needs to be noted here in the other post, so I can keep this bit short. The primary things to analyze at this stage are the key strengths of the combat system over others and how I'll be testing this early on.

The biggest oddity of combat in my system is the usage of up to 4 analogue inputs at once to generate interesting combinations of attacks and movements. All of these inputs being analogue, with 2 of them being both positive and negative, gives a greater degree of finesse in all movements as is compared to the digital nature of buttons and the fixed nature of time. I can do a lot by taking advantage of the velocity at which the inputs are being pressed, making attacks stronger or weaker, altering speeds, and other such functions. So at a basic level, finding a way to take advantage of this range will go a long way towards making things feel more immersive. After all, if I make it so moving the analogue stick quickly will always be the best course of action, then it won't exactly be doing anything that couldn't be done with a simple digital input.

Another consequence of the analogue inputs being used for both locomotion and attack now is the ability to attack from any angle in first person. Most FPS games tend to have enemies coming at you from straight ahead so you don't feel cheated from being attacked by an enemy that suddenly came at you from behind. With VR and this control system however, that simply isn't true anymore. Spatial audio and the ability to look any direction makes it rather easy to identify that an enemy is coming at you from behind. In addition, the control system's free focusing ability and turning focus makes it so you don't really have an excuse to be surprised by enemies that come at you from behind. You could choose to climb up the mountain in the game and be fighting enemies from up front, but you shouldn't be surprised when enemies that are recovering from down below and from other parts of the cavern starting showing up and attacking you from behind. I'm unlikely to do this much just to ease people in, but having enemies that attempt to attack the player from all fronts will definitely be in order.

The only other thing my system does particularly well at this point is the ability to take advantage of locomotion and attacking simulataneously, so having battles with mobile enemies that attempt to move about from many locations and who can deal with the player's ability to run along walls or fly will be a matter to consider, but for now, I'll just try to focus on making sure the ability to attack from any angle is available.

Core: No compromises in long run. Just quickly test out principles in the short term.


This choice was relatively simple for me to make from the start. Monsters in this world structure are simply the best choice for fodder as they have the simplest AI save for animals and plants, are powerful enough to pose a threat, and don't require an immense amount of modelling effort to create a convincing entity. This saves me a lot of work and let's me cater them to the needs of the project.

At a basest level, there are several types of monsters in my mind right now for inclusion at this stage. There's are basic cannon fodder, that will be slimes, zombies, boars, and goblins. As the cannon fodder, they'll be used to introduce players to combat since these being bear simple attack patterns that can be easily read and exploited. The stronger follow up are the basic Lizard Man and Skeleton style creatures, which will serve as an introduction to an enemy that can fight in a manner similar to the player. They'll essentially be serving the same purpose as the Stalfos and Lizalfos from the Zelda franchise. I can still vividly remember my first bout with each of these monsters in Ocarina of Time and how much fun they were to fight due to their similar combat potential to Link. At higher levels, we'll have Ogres, Golems, and Minotaurs to act as mini bosses due to their higher levels of HP and power, but still relatively manageable stats. The greater bosses will be the dragons, Skeleton Lords, Goblin Kings, and Serpents. The final boss however, will remain a bit more secretive for now since hey, no point spoiling all the fun right? That being said, you'll probably notice that none of these monsters is original in any way. This is actually grating on me since I'd really love to introduce some weirder entities into this mix, but doing so will increase development time, something I don't have much time to surrender. In addition, there's also one other factor to consider here that familiarity allows us to bring into the table: contrast.

I really want this game to help communicate to players as much of the things VR can offer, and one of the things I believe all VR RPG players are going to have to come to terms with right now is just how different the experience of the VR world makes everything we do, this of course includes the change in the experience of combat. Fighting enemies in VR isn't the same as in a regular game. Klein learned that in SAO. The players from Log Horizon's Elder Tale likewise. And soon enough, we will be learning just how scary fighting as highly maneuverable, dangerous opponent can be when your isolated, alone, and unknowing in a VR scenario. I don't think the early enemies will instill much fear due to their simplicity, but I'm positive that they'll be far more terrorizing than many of us are expecting. Having a slime suddenly envelope you, a zombie run after you, a boar charge you, and a goblin climb on to you, these aren't things to be taken lightly and I can only imagine the horror that having a dragon rapidly whipping your limp body around like a chew toy will bring. Having familiar monsters with generic appearances should serve to amplify things a bit by making taking the beings we're accustomed to slaughtering by the hundreds if not thousands in other titles threatening enough to make them worth avoiding even when alone, all without really changing their actions or the severity of it much. If I can do that, I'll consider it a big success.

Question now is a matter of quantity. The few enemies I already mentioned will probably take no less than 4-5 days each to make. If I had whole days to work this out, I'd go for as many as is possible, but I'm trying to establish a deadline here and I'm too inexperienced to know exactly how much time each will take to implement. I could very well build an enemy a night one week or end up taking a whole week on another. It's too variable to call, so for now, I'll just guestimate my range for the enemies and see where things go from there.

Core: Mooks (3-6), Powerful Mooks (2-4), Mid Bosses (1-3), Bosses (1-3).


As has been mentioned, the goal of the game isn't actually to kill the monsters so much as it is to let the character's lover know they didn't die in the dungeon. Really, this more or less translates to either going to the village or using a flashy spell atop the mountain or tower. That's it. Everything else that is done is only in service of these two ends, so leveling up, killing monsters, finding items, and reaching the tower are entirely optional content should the player decide to only focus on the goals. If you're careful and dexterous, you should be able to avoid or run past every enemy in the game along the easy route and then finish it within a small bit of time. It could very well be beaten within a 30 minute session depending on how the final cavernous layout works out.

Core: Get to point A or Point B


No sense calling it caverns here since really it's just a dungeon all things considered. This is probably the single most important thing for me to get right from a planning stage since it will comprise essentially all the content. At this point, I'm thinking of using a basic floor structure to avoid having too much trouble from a technical perspective. There may be some interconnections between them to keep things interesting, but they should be fairly obviously divided. The question here being how many floors will there be? I don't want the game to be too long, but I still think having a cohesive sense of scale. If I make the mountain too small, it won't make sense why the people didn't just climb up, sky beasts be damned. If it's too tall though, it'll take too long to make the caverns. I thought I'd set about for 25 floors or so, but going off the current time scale of 3 months, that would equate to spending a bit less than 4 days per floor. That's ignoring the world outside and the aesthetics for everything. I'd like to spend no less than a week per floor so that would put things at about 90 days/7days per week to a total 12.8 floors peak. That's not a whole lot, but assuming I use smart design, I may be able to work with it.

As I did for performance, I'll probably re-target down a bit towards a much more manageable 8 "floors". That should give me a little more than a month for purely polishing. That should work well with the amount of monsters I can make in this time frame. This severely hampers the potential height of the mountain, but I think I can work it through with some platforming sections and by taking advantage of the fact the mountain is sloped, having it's exit at a reachable distance at 4-6/10th of it's height. Even 1 kilometer high should be more than tall enough to make most players feel awe at the height. The current tallest building is shorter than that and not even going to be remotely comparable in width or depth. A bit small to be much of a mountain, but still more than big enough for us feeble human sized objects at only about 1.7 meters in height.

Core: 8 floors.


This should actually be relatively simple. The base is mainly composed of a small forest, a few scattered villages, a lake or two, and a bunch of plants and animals. None of this on it's own should be particularly hard to take care of, especially with the amount of experience I'll be gaining over the course of this project, but the village may have to be carefully structured so I don't go overboard. There are 3 races here and having 3 distinct looks could be a bit of a hassle. I'll see what I can do about distinguishing things, but in the worse case, I could just go for a simple solution of having a monoculture where all the groups live in more or less harmony and are relatively similar. I may very well end up having to cut out having a whole bunch of scattered settlements and go for 1 single major settlement if time is short, but I really do want to make the world at least feel like it's a little lived in rather than a barren plain of nothing that easily tends to happen in a lot of smaller efforts like these. I've got an idea in mind to discourage interaction with these other beings anyway so it shouldn't matter too much what the people themselves wind up being like as really, the lover is the only thing that really matters.

Core: 1 major settlement of all races. Small pocket camps for other groups. Not too much variety or detail. It's a small island...

Sky Island

The choice of a Sky Island was very deliberate on my part. It creates a wide range of easy explanations for a variety of necessary evils of game development so it was an easy choice to make. It let's me concentrate everything in the game into a singular setting that can feature a fanciful set of features without needing to be concerned with the logistics implying a larger world would have. In addition, there's a bit of a "twist" I'm working on that takes advantage of the sky island setting that i think will make the setting gain a bit more meaning, but at it's basest, the fundamental meaning, though honestly, the main reason is so I can avoid the need to have invisible walls anywhere in the game. I seriously hate those things. It grated to have to include it in my MMD demo, but what can one do. It's either that or falling off the map or some other much more intensive solution. In addition, I find the idea of items floating in the sky rather beautiful. Sword Art Online's setting of the floating Castle Aincrad was lovely and I likewise find a great deal of inspiration from the Observatory in Super Mario Galaxy in what I do. There's just an elegant beauty to me of the idea of being able to see the sky all around you, whether you look up or down. All in all, the setting here shouldn't require much work beyond me just getting some rough concept art done and modeling it real quick. The bigger question is a matter of managing the colliders for the land. I may end up having to make a bunch of separate mesh colliders that only collide with the player, which will likely require building the island out of a bunch of different meshes, but it can't be helped. 255 triangles is the limit here.

Core: Try to make island out of a bunch of smaller, non self colliding bits rather than as one large whole due to mesh collider limitations.

Top of the Mountain

This is the narrative goal of the expedition. To reach the exit of the caverns, reach the peak and see what exactly is going on with all the ancient technology that still boggles the simple people at the base. The only things there will be some trees, vegetation, the shattered gem and the entrance to the tower. I won't go into this further again, but just gathering a bunch of the gems and scattering them down below should be enough to beat the game.

Core: Just get there.

Really trailing off on energy here. Overall, I think I've gotten a good foundation for a design doc here, though the goal was to establish a minimum viable product. Looking at that initial sentence again:

"The game is a VR RPG that will feature the player fighting monsters to escape a dungeon that goes from the base of the sky island to the top of its mountain."

  • The VR Part clearly establishes that I need to keep my Oculus Rift DK2 enabled throughout most of development as it is a key part of designing the game. 
  • The RPG aspect dictates I need to include some kind of states system, which at this stage, I think a rudimentary, HP, EXP, LV, STR, DEF, MAG, and SPD system should serve.
  •  The player bit needs to be simplified immensely, so I'll probably start off using a sphere for the head, a capsule for the torso, two capsules legs and knees, and a long cube for the arm. 
  • The fighting should just be rotating the arm to swing the sword that faces forward if I move the analogue stick first and is angled up if I press the right trigger first would  be good. If I could establish that circular form or sort of moon dynamic early on now it would be great. 
    • The movement would be the simple rotation system I've already made and a simple addition of a lock on raytrace based system for the second bit would need to be added. The left trigger will also have to to manipulate the lower capsule to be able to jump so I
  • The monster will of course just be a sphere and an algorithm to charge the player and perhaps randomly rotate with a stick or something bulging out to serve for dealing damage.
  • The escape will be served as a function of the level design, with two triggers acting as end markers. Reach one and the game resets with all the stats still in place as a form of testing new game plus.
  • the dungeon will likely end up being two rectangular room floors connected by a platform based passage with exits on either side.
  • The sky island is unnecessary at this stage and the peak of the mountain isn't really needed either.
This says a lot about just how little some of those features I just spent paragraphs writing contribute in the core of the design. So little is necessary to get started, but it's important that this be established ASAP to get this rolling. Honestly, looking at what's listed here, I may be able to do this all tomorrow (technically today at the time of writing), so I may very well skip out on doing a video on this design doc and instead just show the damn MVP here and talk about things there. With that, I'm cutting this post off. Maybe I should lead with this shorter bit here at the end, but alas, writing small books worth of content is kind of my thing.

No comments:

Post a Comment