Recent Posts


Taking a stride

2019-11-08 14:48:50, Worked for 3 hours.
Click to open full image.

The post before the last before the last I definitely thought I had things figured out.

Turns out I'm pretty stupid, and to get something to work well in Unity requires a metric fuckton of knowledge about the physics engine, which is pretty whack.

But nevertheless after messing about for 3 hours at 4:00 AM on a saturday with a lot of code, I came up with a decently simple little movement system.

The simplest way to do Unity movement is using the built in Axises (Horizontal and Vertical).
Maybe more familiar as X and Y.

Now we just need to translate inputs of X and Y into world movement of X and Z at a fixed rate for every frame, seems like a trivial task.

But then we start taking into account friction, rotation and if we are grounded and then all of a sudden we have a task that resembles climbing K2 during winter time.

Thank the gods the Unity people on Stackoverflow have been making the path up to K2 visible with fucking glow in the dark rope and safety rails so that we never go off the endlessly deep cliff that is Unity's wankstain of a physics engine and stay within the confines of the kiddy pool.

You may wonder why I am so worked up over this, and it's because I just spent the last 12 hours or so not taking any code from Stackoverflow and instead just doing whatever I thought would work.
It didn't, or well, it didn't feel right.


So this is what I came up with.
Generally not adviced to use straight up velocity on the rigidbody, but I'm cool like that.
RigidBody being the physics component for any given object in a level.

Now I have some really basic movement which doesnt go over a set speed sv_max_speed, sweet.

Now I just have to add some friction *shivers.
Til next time.


Comment

Taking a gander

2019-09-17 23:02:10, Worked for 2 hours.
Click to open full image.

Probably the most important part of any FPS game is the feel of the movement and camera.
It's actually surprisingly difficult to get it to feel just the right way, and Unity most certainly has a tendency to make all movement feel "airy".

But I thought I should take a swing at it, so I added the Camera Component to my Capsule aptly named "player" and began shitting out code. None of which worked.

But then I consulted the glory that is the legacy Unity Code of the wiki http://wiki.unity3d.com/index.php/SmoothMouseLook.

Now this behemoth looks terrible, feels terrible and is terrible.

So I stripped out all the smoothing crap no one ever asked for in a game, and created this.

What?
Code that works and is concise? In Unity?

That's right.

Now it's not the greatest thing ever written, but most certainly does the job, and moreover it actually takes the movement of your mouse and translates it 1:1 into rotation.

Next I had to tackle the movement, the most frustrating thing to get feeling right.


Comment

Creating a Console System

2019-09-17 01:35:30, Worked for 4 hours.

Every cool game needs a console system.
Somewhere I can slap all the variables I use for everything.

Work began on this with foundations from previous games, so basically we would have a class ConVar responsible for handling the variables themselves and parsing them out to different types.

Then we would have a separate class Console for interacting with these from inside the games.
Then a global system for interacting with it from within the code.

Now this seems pretty trivial, and it kind of is.

We create the ConVar constructor, it should take the name of the variable as a string and a default value.

So that's what I did.

Then I added, like a lot of parsing functions to get values of different types.


And then because it was pretty horrible to do .ParseFloat(); every god damn time I needed to get a value I created a super reduntant wrapper class to handle specific types.

I called that class ExplicitConVar which was a generic class with the ability to keep the last parsed value to spit it out when you want it and to update from ConVar when the ConVar value changes. Fan f- tastic.

If you cared, here's what that looked like.


Now with that out of the way, work on the game could begin, which it really should have before this. Damn I waste a lot of time.


Comment

Starting on 'Grapple Guy'

2019-09-12 01:01:26, Worked for 1 hours.
Click to open full image.

Working title, I know, funny right? no? yeah it sux.

Despite the hate for Unity I've grown to know it would probably be very simple to toss something kind of nice looking together for this project in it.



It just won't look as good or play as well, but I hope that tweaking the entire physics engine to what I need might fix it.

So after loading the project I'm met with a familiar sight.
The unity default scene, completely gray and empty

So after I added the standard plane (basically a 2d rectangle in a 3d world, ideal for movement testing). A Capsule component, my so called "Player" it looked something like this.


Created a simple folder structure, and a script called Movement.cs, a C# Unity Script file.


Set up my default editor Visual Studio 2019 (Preview).


And opened up Movement.cs and this is what I see, a dreadfully empty document that contains this.
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Movement : MonoBehaviour
{
private void Start()
{


}

private void Update()
{


}
}


Now, if you don't know any programming, don't worry, it's all pretty explanatory.

The Start() function gets called once by Unity at the start of the scene.
The Update() function gets called once every single frame that the game renders, i.e. somewhere around the neighborhood of 60 frames per second(fps), but I'm going to target somewhere around 144 fps for this project because it's so much nicer.


After sitting and twiddling my thumbs for a solid 15 minutes searching for something to listening to I decided to just kind of write from memory what I though the https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/game/shared/gamemovement.cpp source engine movement code looked like, but in C# and not in source engine and not using vectors in the same way.

I came up with this little devil.
Stole the acceleration values straight out of https://github.com/id-Software/Quake-III-Arena/blob/master/code/game/bg_pmove.c but since they are for a completely different, (and much superior) physics engine, they won't work in unity.

But testing and tweaking will, tweaking not being the meth kind of tweaking, but software one.

Plus this, this was very helpful, thanks stackoverflow from 6 years and 9 months ago. https://gamedev.stackexchange.com/questions/45639/implementing-strafe-jumping

I'll continue tomorrow, just gotta do some git magic to get this spaghetti on the interwebs.


Github Commit
Comment