Short update

More progress on the first stage of the prototype. It’s looking a lot closer to a 3D version of the old game. Little Steve got quite the upgrade, and the floor isn’t flat anymore, which is always good. I’ve still to line up the walls and such, but those details can come afterwards.

But this week wasn’t all just visual upgrades. I’ve been wrestling with UNET’s NetworkManager so that I can override it with my methods. Let’s just say the documentation… isn’t in its top shape. Some stuff in there is completely outdated, and most stuff in there is sort of vague. Something Unity could improve over time, but until then I’m stuck troubleshooting.

I’ve also reimplemented sprinting and the flashlight, and the results are quite something. Also sprinting is unlimited now, but you still won’t be able to shoot (or do anything else, really) while doing so. This results in much more satisfying movement, but still keeping gameplay slow enough to know what’s happening around you.

I’ve also started implementing the final hybrid hit registration model. It’s still quite a ways to go, but I predict it to be as good, if not better, than the previous game.

Stay safe. And tell your girlfriends they’re hot.

“Tell ’em all to go to hell”

Progress has been steady, and a plan has been set: a Prototype with basic mechanics will be finished until the 30th of November, with the sole purpose of “emulating” the old game. Even reusing assets!

This idea came about because I need a first goal to start with. The game I have planned is very ambitious, and a daunting task. So this first prototype is not a bad place to start with.

The first stage was making sure players saw, and could fire at, each other. There were some problems, as you can clearly see in my two previous posts, but they’re fixed now!

On that video above, the shots weren’t being synched to the server. Instead, a boolean was telling the server (and remaining clients) that a player was shooting bullets. As of now, that mechanism has changed, and the server knows exactly when the player shot, as well as the origin point and general direction of the shot.

With that data, the server can make assumptions about how much damage to perform, as well as compare hit-registrations when a client informs that one of his bullets hit another player. Right now, only the server performs such validations, but I intend to have a hybrid solution like I did in the previous game.

Speaking of the previous game, I had lights before. And lights attached to bullets. And shadows and stuff. That’s got to go in.

Learning how to work with Mecanim for the sprite animations, figuring out how to light up the sprite (shadows still missing) and working with UNET’s NetworkTransform component led to that pretty demo. It’s fun to play, altough I still have to figure out a way for all clients to move those cubes smoothly. The host has a speed advantage moving them right now, because he’s the one hosting all of the rigid bodies. The blocks only move when a client is overlapping them on the host’s end.

All in all, some very productive nights. Next step is adding sounds and seeing how Unity’s Audio engine behaves. Also particle effects and a simple score system.

Stay safe. And tell your loved ones you love them.

The first battle has been won

Three posts in a week! Holy smokes that’s a record!

Small status update: finally figured out basic UNET stuff, and now I can do this:

Players spawn by themselves using the “Spawn” button, and can be killed by the bullets.

One small step for Killplex, one giant step for Killplex.

Next steps: clean both the spawning code and make bullet code better. Hit registration is currently being handled exclusively by the server, and bullets themselves are spawned on each client right now, instead of having an event that tells each client where each bullet should be spawned, and which characteristics should it have based on the player’s selected weapon.

Stay safe. And cuddle your dogs and cats.

Unending battles

Posting two days in a row?! Wooooow.

Basically, today I’m frustrated because problems like these still exist in a 2D physics engine:

Why on earth should these bullet Rigidbodies, travelling at 5 units per second (it happens even at 1 u/s), with continuous collision detection activated and turned up to about 20 iterations on both position and velocity, pass through a 1-unit cube?!

These are the problems I’m having at the moment. I was planning on having some sort of bullet penetration on the final game, but not like this.

Stay warm. And buy lots of candies for your loved ones.

EDIT 00:04: solved it. Next time, remember to check if your colliders are too small.

Even more real struggling

On my last post I mentioned that I’d set up a schedule and post regular updates… and I’m proud and ashamed to announce that I royally fucked up in that regard.

A two month delay should be enough proof.

The thing is – and this will sound like a looping cassette – making progress on a side project is hard when work eats up more than 40 hours a week when it should, and when you have even more side projects to carry.

Alas, I haven’t given up!

I’m in a stage of making concepts and writing down ideas. The whole goal I’ve set up for myself is to not let the game grow too much right at the start – because that’s where ideas go to die.

As it’s usual in concept and prototyping stages, there isn’t a lot to show. Most of it because it ends up in the bin, along with the manly tears of promisses unkept, and some of it because I’d like to keep most of it close to the chest for now, lest I change my mind again. Then again, not everything should be kept a secret, and as I’ve found recently, sharing is – sometimes – a good thing for productivity.

The plan right now is to build a functional prototype in Unity: to use and reuse some concepts and code from the old version of the game, but simplify all of that in order to have, well, kind of a mini-game. One with the basic gameplay elements in place.

Then, I’ll clean up that codebase and add the new stuff in.

At the start of this post, you saw a gif. It represents a prototype I’m working on, using Unity, and getting myself familiar with the “new” Networking tools. On my previous Unity prototypes, I had to either build on top of Unity’s previous implementation (which kinda sucks if you want to have full control over your packets) or use an alternative such as Photon (which I cannot afford) or actually implementing my own network layer (even using Lidgren like in XNA, which I won’t do again because it’s a pain to manage).

Next objective in that prototype is to have each player shooting bullets (and finding the best method to do object pooling so the game doesn’t run like shit), and then figuring out if I should do the old (but very reliable) hybrid hit detection, or investigate new ways of detecting collision. This time I actually have a full-blown physics engine, and I don’t have to code the freaking rectangle collision by myself.

Stay safe. And if you have asthma, take your meds when you catch a cold.