Monday, July 4, 2016

VR RPG Status Log [7-4-2016] - Shifting Gears

Been a while since the last update on the game or this blog for that matter. That's not to say there hasn't been much going on, however I've come across more development stumbles than I'd anticipated and am in the middle of reevaluating my targets for the game to best take advantage of the effort being put in. Toiling away in silence is fine by me, but I think it's about time some kind of update was given considering that I have been more vocal in the past on the project.

For starters, I suppose I'll get into the main problem facing the project at this point: the controls don't feel good. Every movement solution I've attempted to implement either doesn't interact with the world properly or winds up feeling absolutely awful to use. Arm movements for attacks don't feel right at all at this stage and it may require a major change in execution to be viable at all. Being that the main goal of this project was test out how the control system worked and whether or not it was viable for a full game, this is a VERY big problem to be facing as it just plain old implies that the answer to that question is no. I'm not quite ready to give up on it as I think that many of the problems facing the control system at this point in time are founded more in my poor execution than in issues with it fundamentally and I'm working hard to find solutions.

The movement system has 2 modes: the free mode and the lock on mode. The free mode is the one that is giving me the most trouble. In it, I've attempted to have a form of tank style control system where vertical analogue inputs move you forward and back while horizontal inputs turn you left and right. While this is okay for some instances, it doesn't really feel all that responsive and doesn't really allow for as much fine control as I was hoping. In addition, the Translate/MovePosition method of movement that I was using initially has the problem that it doesn't interact with the worlds physics properly and lacks momentum. Trying to use an AddForce for movement is problematic because it can easily add so much force that it sends the character moving at faster speeds well outside the bounds of movement that I intend.

At this point, the idea I have for trying to resolve this is to now go into direct modification of the Velocity of the player character. This is normally not advised by Unity since this can lead to unrealistic results, but it's looking like the only practical manner of getting the job done while still having even the slightest air of effectiveness in my systems. This is a rather recent idea though so I'm still working on getting it right. I'm hopeful that it will work out though since it should enable some rather interesting movement executions, such as running towards an enemy, ducking below their project weapon, sliding on the momentum, jumping up into the air from that slide and then activating an attack art to deliver a killing blow.

Outside of the physics of movement, the idea I have in mind for direction is going to be troublesome to an extent since it's a slight change to the controls dynamic. I'd retain turning being a primarily horizontal axis feature, however I'll be adding in the implementation that tapping that left analogue stick in the direction you wish to face will turn you there quickly. Predominantly forward vectors will still be mostly based on turning by tilting the analogue stick slightly left or right, but you will now be able to quickly turn left or right by tapping left or right. Double tapping will do a full 180 and double tapping forward or backward will activate a movement skill like a flash step or burst sprint.

An extra undercurrent in all of this is the consideration of steps as a logic and the potential benefits this may have for nausea in some plays and towards adding to immersion. Rather than smoothly executing accelerations like the left and right turns or running forwards, I'm thinking of having those be implemented in timing with an extra steps dynamic that works in conjunction with the animation system. So if you held the left analogue stick for 1 second at a -0.4 tilt with a 45 degree/second turn rate, you'd turn 18 degrees smoothly in that time. Instead, I think a better implementation would be to apply the acceleration of the analogue stick into the matter and act out the step based on that. A slow tilt of about 1 seconds from 0 to .4 would have a slow step rate of about 1 step per second (step being an turn animation cycle here). By comparison a fast acceleration of about .2 seconds would take .5 seconds to execute the steps. I'll have to refine this as I test it of course, but it's a rough idea of the process. This quick turning process enables a much wider gamut of motion since it means the player can make sharp turns that a slower tank style system doesn't allow.

In a way, I'm just taking a more standard third person movement system, and slightly tweaking it to better conform to some of the standards of VR. Having a more standard third person system where the player faces the direction of the tilt isn't as viable here since there isn't a fixed axis of viewing so turning the character turns the axis of turning as well and that kind of dynamic can be wonky enough in third person games when the camera tries to follow the character's back, let alone in a VR title.

As for the combat mechanism, this is a bit more troublesome. Arts are still a go since their execution is rather simple, but the larger problem is the control of the arm that I'm going for in regular attacks. Like with movement, I haven't been able to get this to feel good to use. Apart from the unexpectedly jerkiness of analogue stick inputs, there just isn't that kind of punchy feeling of getting an attack in with the system currently being used. I think this is partly because the current dynamic, while somewhat engaging for interacting with your VR hands, isn't all that good for snappy movements that occur with things like slashing.

Outright changing the attack dynamic is going to be rough since one of the core elements of this control system is being able to both move and attack freely in the first person as you often can in third person action games like Devil May Cry, Ninja Gaiden, and almost anything made by Platinum, while still being able to have a fine control over the direction of your attacks like what motion controls can allow. This being the case, I think the best solution for now is going to the somewhat tedious one of having to set up animations for even regular attack slashes. This will probably involve having slashes along the horizontal, vertical, and diagonal axis, as well as swipes along 8 or so 45 degree range of the right analogue stick, with maybe an extra here and there for a full circle or semicircle. The swipes are good for attacks coming at the sides or from above while the slashes can cover the forward range rather well and take advantage of openings in the enemies defenses.

This just leaves guarding as another difficult are. At this point, I think I may end up just setting up a loose or more forgiving guarding mechanism since I find trying to get precise guards in particular angles is difficult when the angle of defense is as variable as it is in this system. Similar to swipes, there will probably just be a different guard position for 8 or the cardinal directions. This of course doesn't provide much defense for moves that attack in an opposing cardinal direction or from behind, but it should still be capable enough of for decent play.

I suppose the last area that's turned out a bit tricky is world design. I'm aiming to make the world feel somewhat massive with a limited amount of space. A large factor in the size of a world is how long it takes to traverse. Using jogging speed as a metric, at level 1 you jog at 2.5 meters per second. If I made the terrain 2 kilometers long on it's long sides and 1.5 kilometers long on its short side, that would mean it would take 800 seconds (13 minutes and 20 seconds) to go along one longer side or 2800 seconds (46 minutes and 40 seconds) to go around it. The problem here is that at this size, I'm going to be forced to make some significant changes to the view distance of the character to account for the problem of Z fighting that occurs between models when the near clip distance and the far clip distance have a great disparity. This incurs a need to either make the world smaller, work around the issue by modding the engine, or accept that the world view is going to be small. I've opted for the latter in the sake of brevity, easing development and avoiding having to use massive amounts of fog to cover for the problem.

Thus, from the 2km x 1.5km size we originally had, we are now looking at 1km* .75km. At that size, the far clipping distance can sit nicely at 1000 with a closer near view distance of around. I'd like to make that near view distance a bit larger, but my concern with that revolves around a trait of VR I want to take advantage of, namely that some of the most immersive VR content occurs right up in front of you when things get up in your face. It's a bit of a cliche in 3d films to have something come out of the screen into the audience, but it cannot be stressed how awesome that can be inside of VR, particularly with particulate effects (that word play!) Anyhow, this winds up dropping our 800 seconds on the long side to 400 seconds (6m 40s) and 1400 seconds (23m20s) for the overall perimeter. This is somewhat disappointing for the scale of the world since higher level play at around level 100 may have a "jogging" speed of 12.5m/s for reference, that's about as fast as Usain Bolt's top speed when he set the world record. At that speed, 1000 meters can be covered in 80 seconds. 2000 wouldn't be much better admittedly, but it's still goes that extra little mile towards making the world feel a bit more sizable. I may opt to compensate for the reduction in overall flat area by taking advantage of more vertical level design, which brings up a few other relevant points.

For starters, the time frame for this project is obviously going to be a lot longer than I was initially aiming for. Part of this stems from poor forecasting on my part of course, but also from a slight change in focus I've made recently. Were we to go by my initial goals, I could theoretically have finished this months ago. Testing out the control system, testing RPG tropes in VR, and finishing in 6 months could have technically been done by around January at its basest level. The main element here that I've added that makes this kind of problematic now is the desire for quality. I actually want to make a good game now. This started as a bit of software for testing out a control system and is now steadily turning into a much more quality product. I've realized over the course of this development, which was initially meant to be much more open, rough, and gruff that I still have a bit of artistic integrity left in me and that there are some things that I just can't budge on in what I do. I don't like the idea of taking money for an incomplete product by releasing alphas with a price tag in Early Access, I don't like presenting the barely formed zygotes of features in the vlogs, I don't like the idea that I'm just working on the project for learning. I didn't understand these parts of myself properly and through this development cycle, I've steadily started to change the focus on a lot of the features of the game to reflect this.

At this point, I suppose the last question that needs to be asked is how this is going to affect release. I'm still very much focused on the development of the title so there's no worries about cancellation on my part, however, with the amount of features that need to be implemented, I'm very uncertain on when the game will be released. At this point, I'm confident that it won't be ready in time for the beginning of the new school semester. Add in my vacation coming in at the end of November, balancing work and my social life, and I wouldn't be surprised if I wind up finishing in October of next year. From 6 months to 2 years. If there's any solasce on the circumstances, I'm feeling happier as I work on the game now compared to a couple of months back where I was rushing with everything in the middle. I'm going to tweak some aspects of my asset creation plan today and maybe get started on it later, but I'd say the final product now is should hopefully be a game worth the wait.

No comments:

Post a Comment