Hello, game devs!
Today I’ll be talking about the basics I’ve implemented so far to Project Navarre. The Camera, Movement, and a few things I’ve been tinkering with.
Cameras!
The first order of business is the camera. For an ARPG we have all sorts of option. The traditional isometric view for a Diablo-Like, first-person view like Borderlands, or third-person like Dark Souls.
For our purposes third-person is the way to go. The plan for our combat is to allow players to use a mix of melee, ranged, and ability-based combat. This view allows for smooth transitions between these combat types, allow for a nice middle ground of situational awareness between first-person and isometric views.
This situational awareness and smooth transitions between combat types emphasize the pillar of player skill. Speaking of pillars, what’s the point of character customization if you can’t see them? That’s one of my biggest problems with titles like Destiny. You get to make these awesome looking characters and spend the bulk of your time staring at their forearms!
We’ll be adjusting this in the future to get the best position and distance from the character.
Controllers!
Second on our merry train of shenanigans is the decision of a player controller.
Previously I’ve only ever made the player controller be built directly into the character. So I did some research to see if this was really the best practice. Short version? If there are a lot things handled by your character it is a better idea to allow a Player Controller to handle user inputs. This avoids any delays that might occur if a player character is on the heavy side of things, which may end up occurring, given the nature of our game.
But that wasn’t the only reason for this decision! It turns out this is common practice for the purposes of making a game where the player can control different kinds of characters and hop in and out of vehicles. For our first release this will be great with the three initial characters. For future releases, vehicles are supported by the table tops rules and I am excited to make them work.
Not going to lie though. Flying vehicles and making AI for them is a bit intimidating at this point but we’ll cross that bridge when we get to it!
Movement!
Last and least exciting of all is movement!
This was primarily ensuring that the controller actually communicated with the player character. All this worked fine and dandy without issues so I was able to move on to tinkering with things that are obviously going to need some refinement.
The first was sprinting. Simple stuff but I hadn’t built a similar system on blueprints before. C#, C++? Easy peasy. Blueprints? I had some things to figure out, mainly the stamina consumption. At the moment I’m using a convoluted mess of wires that is just not clean at all. Part of the problem is that functions don’t seem to support any nodes dealing with time. These clear and invalidate timer by handles along with set timer by event nodes are not the most elegant solution.
So I will be polishing this later. The good news is that the basics of sprinting are in working order for a prototype and I can expand upon them for things like sliding to a stop when crouching at a sprint.
My second experiment came from a conversation over the tabletop’s expansion, Broken Strand. Turns out parkour is going to be added, allowing players to run on walls and the like. So naturally I started experimenting with how to do implement this!
The original implementation involved a collision box generating an overlap event with surfaces that were tagged as “WallRun” Simple enough, works for running along a wall but not up a wall. At this point I started thinking about a more dynamic system. That involved a lot more math than I thought it would to prevent things from going all kinds of wrong but I started using line traces from this with my implementation.
So when I take another crack at this I think I will make a system that uses physics materials to enable wall running with the help of line traces. This way the character knows if the wall is on their left, right, or right in front of them. With the current system this works on literally any surface, other characters included, so the inclusion of physics materials will help a ton, and removing all of that complicated math will give us as designers more control over where the player can wall-run and prevent hilarious things like running up an enemy mesh.
Alright! Next on my to do list is implementing the player progression system. Experience points, ranks in attributes, skills, etc, purchasing or removing ranks, getting the stats to preview their affects, adding and removing experience and so on.
But that’ll be my next post! I’ll catch you all again next time.
Add a Comment