next »

[etodd]

It doesn't look like much, but it's actually a major step. Up until now, I've been spawning objects into the scene manually via code. But this scene is imported entirely from a .blend file.

I'm representing the entire level as an armature, just like you might have for a skinned model. I can attach metadata to each bone to specify what kind of object it is. I can also move parts of the level around with Blender animations, which will be crucial later on.

Also, did you know Blender has a "flymode"? Hit Shift+F and you can walk around your scene with or without gravity. Super useful for getting a sense of scale. Hopefully I'll be able to do more modeling soon to flesh out this level more.

[jctwood]

Woah that is a pro tip! I had no idea it was so simple to walk Around a blender scene!

[etodd]

Turns out the "levels are just armatures" idea did not work at all. Things broke down somewhere in the Blender -> FBX -> Assimp pipeline. Meshes scaled up by 1000x, quaternions randomly rotated, animation channels randomly missing... eventually all my workarounds started to interfere with each other.

So I wrote a 40-line script to export the scene graph into a simple JSON file. It even supports custom properties. The only problem is that now I can't animate pieces of the scene like I could before. I'll figure it out later.

The level importer also automatically generates a navmesh using Recast. I livestreamed part of the process here, although the stream kept dying so it got split into multiple videos.

Here's the super smooth and natural pathfinding in action:



Pathfinding is the last absolutely required system before jumping into gameplay code. Would really love to work on ragdoll physics, lighting, and post-processing, but this needs to reach a playable state ASAP to avoid wasting time going in the wrong direction.

So yeah, up next: actual gameplay!

[etodd]

I had to take September off to do contract work. Such is the life of an indie developer.

After much hand-wringing, I took out all the gravity and curved trajectory code because:

• It made aiming more difficult
• I had to lower the player speed way down in order to limit the range
• Slow player speed made it hard to hit moving targets

In the end, I realized that one of my favorite parts of the prototype was figuring out how to get from point A to point B given the limited range. It adds some very light movement puzzle-solving.

So we're back to straight-line shooting for now, with an arbitrary range limit. One problem with this model is that it's frustrating and difficult to tell what's in range and what's not. I plan on solving this with a nifty shader to somehow gray out areas beyond reach.

That decision out of the way, there's another dilemma coming up. I'd like to show the game at the Ohio Game Dev Expo in about a month. The dilemma is, do I trim down and update the Unity prototype, or do I try to get the new C++ version to a playable state? I'm leaning toward option 2 because I hate going backward, but I know it won't look nearly as polished and won't get played as much. And it might be educational and eye-opening to jump back into the prototype for a bit. I'm really not sure.

Almost forgot, I never actually showed the nav meshes from last time. Take a gander:



I also have very simple AI, vision cones, etc. And the player and enemy can kill each other. Really I could polish that bit up and use it for the expo... but that goes against my manifesto of focusing on gameplay over polish right now. Not sure what to do.

[etodd]

My first real day back on the game! I think I'm going to keep pushing forward and get as much done as possible for the expo. With that in mind, I added splitscreen support:



I also split the physics out to a separate thread, which brings the total to three (update, render, physics) plus one more to eventually be added for audio.

Here's some super exciting combat.



I'm really interested in displaying visibility information to the player, so I'm thinking about using shadow volumes to allow me to do shadowed "lights" everywhere representing vision cones/spheres. Still in the early research stage. I can't even find any games that use shadow volumes anymore. These days it's one or two shadow maps and a whole lot of environment lighting and tricks to cover up the lack of accurate shadows.

[etodd]

Glitched AI vision cone = disco party police siren



I know it's boring, but I am seriously excited about my content pipeline. I just added Wwise audio integration. The build system has Wwise generate the sound banks automatically and copy everything into place, on both Mac and Windows. Only the most automated pipeline of all time for the most lazy developer of all time.

I'd like to write more about the build system, but there's still some ugly bits, and I haven't fully had time to settle in with it. There are most likely still a lot of lessons to learn. But I'll do a full write-up soon!

[etodd]

Added SSAO and shadowed point lights. Also grayed out areas outside the movement range.



I'm having a bit of a problem with information overload. I want to communicate a ton of information (different material types, enemy visibility) while also showing accurate lighting and vibrant colors. Which basically just means I'm gonna be tweaking the color scheme for a long time.

Next up, film grain and edge detection. That should bring us up to the level of the Unity prototype, minus ragdoll physics.

[etodd]

Film grain, edge detection, bloom. I was hoping to switch to a very different color scheme from the prototype, but I haven't found it yet, so I'm sticking with this for now. It's decent enough to show at the expo I think, which means I can spend the rest of the next three weeks focusing on gameplay.

[etodd]

Pink is always a good idea.



I've also got basic AI that can attack you, spawn sentinels, kill your sentinels, etc. Hard to show at the moment though. Might post a video later.

[etodd]

Lookie, you can attach things together now

[etodd]

Accidentally implemented ragdoll physics.

Here's how I did it. I started by creating a bunch of Empties in Blender, parenting them to their respective bones, and scaling them appropriately. Like so:



If the name of the Empty starts with "box", it's a box. Same for "capsule" and "sphere". I pull all this info out using Assimp (relevant code here).

When I create the ragdoll, I first get the location of each bone, then spawn the corresponding physics entity (relevant code here). Since I already have access to the bone hierarchy, I know which physics entities need to have constraints between them. I do raycasts between the entities to find out where exactly the constraints should go. Ideally, I would have a way to define the limits of the constraints, but the automatic constraints are good enough for now. And this way I can ragdoll-ify a new model in about 5 minutes.

I'll write a more in-depth overview soon, but that'll have to do for now! Expo next week.

[etodd]

Playtesters

If you want to playtest a top secret build, contact me on one of the disparate networks I'm on and I'll send you a top secret link. I really need playtesters.

Level design

Here's one of three complete levels so far. Also, the compass rose is back.



I found a quick way to build those walkways using Blender's Skin modifier. I only had to draw a few edges, like this:



Shockwaves

People had a hard time finding each other in the old prototype, so I added a "shockwave" visualization that simultaneously shows how far your sound is propagating, and helps other players find you.



Cables

I also implemented cable physics and a power propagation system:



I introduce the cables by having you shoot through existing cables to cut them. Then I give you the ability to link sockets together with your own cables. It's not super interesting yet, but it fits mechanically, and there are a ton of possibilities I could use it for in future.

The cables also allowed me to make more interesting pickups. In the prototype, every interactable item was just a colored square on a wall. You shoot and land there, and the item activates. It was awkward because a switch is not somewhere you want to land on and stay on for more than a split second. Furthermore, the mechanics of the game are about shooting through things, which is more interesting because you have to worry about what's behind your target.

Cables solved this problem:



Now you shoot through the target and land on the opposite wall. Much more satisfying, fun, and interesting.

Engine update

I now have basic sphere-frustum culling, and the graphics VM now supports simple geometry instancing. I'm using it to render the cables, for now at least. Bigger technical post incoming, I promise.

[Cranktrain]

This is all quite interesting, both your approach to the development as well as the game itself. I think you'd be in the minority on these forums writing everything in C++ and open-sourcing it, but it's nice to see. As someone who's also been following Jonathan Blow and Casey Muratori, and generally agree with their thoughts, yet am stuck for a variety of reasons with Unity for now, so it's good to see others pursuing the high-performance side of things. Are you finding development is progressing quite speedy?

[etodd]

...

Of course there's been a long ramp-up time, but I'm surprised how fast development is going. One factor to think about is that I'm able to write better code than I could in Unity. Unity makes it easy to create a lot of state, and hard to write data-driven code. For example, MK-ZEBRA has path indicators for your AI sentinels that look like this:



To accomplish this in Unity, I would probably create a script, attach it to the AI mob, and have it spawn cube prefabs and position them along the path, keeping track of them in an array. This is a huge amount of unnecessary state, and it opens the door for a ton of bugs, including the indicators getting out of sync with the path, indicators not being added or deleted properly, etc. Eventually I'd run into performance problems and make a manager with an object pool to pull the indicators from.

Compare to my little C++ engine, where I have the ability to just insert a few draw calls into the render loop. No state necessary. Here's the entirety of my code, 23 lines. With a few more lines, I could batch it into a single draw call.

Code:

for (auto i = World::components<SentinelControl>().iterator(); !i.is_last(); i.next())
{
	SentinelControl* sentinel = i.item();
	if (sentinel->get<AIAgent>()->team == team)
	{
		for (int j = sentinel->path_index; j < sentinel->path_point_count; j++)
		{
			Cube::draw(params, sentinel->path_points[j], true, scale, Quat::identity, color);
			if (j > 0)
			{
				const Vec3 next = sentinel->path_points[j];
				const Vec3 prev = sentinel->path_points[j - 1];

				const Vec3 diff = next - prev;
				const float length = diff.length();
				const Vec3 dir = diff / length;
				const int count = ceilf(length / interval);
				for (int x = 0; x < count; x++)
					Cube::draw(params, prev + dir * (x * interval), true, scale, Quat::identity, color);
			}
		}
	}
}

There's probably a way to do something like this in Unity, but nothing jumps immediately to mind. Unity wants you to take the bad route.

TL;DR, I save a lot of time by cutting out state. Something I couldn't easily do with Unity.

I'm curious if this applies to Unreal as well. Maybe someone with UE4 experience can shed some light.

[etodd]

Ohio Game Dev Expo 2015 complete. Here's my booth:



The actual booth was $200, plus I spent $50 on the cabaret table. Everything else I had already.

As usual, my level design proved to be lacking. People didn't feel motivated or drawn toward the next area, which is something that should be possible to accomplish entirely without story.

People like the aesthetic and the movement, though. I just realized I've never posted about one of the coolest new features: simple inverse kinematic limbs.



It's not real IK, just some simple trig. So there are some issues and corner cases (literally), but it's a compelling effect most of the time.

I'm excited about where the game is headed. Lots of stuff to cut, lots of stuff to add.

[etodd]

Quick Screenshot Saturday update: finally got around to adding cascaded, PCF-filtered orthographic shadows.



A dab of volumetric lighting, and this renderer will be on par with the one I used for Lemma.

Other things... I trashed the entire "bounce off walls" idea. It was never as cool as I thought, no one ever did it on purpose, and it was extremely disorienting. Good riddance.

Also trashed most of the first level. New design in progress...

[jctwood]

Loving the aesthetic more and more! Exciting seeing this come to fruition.

[etodd]

This may feel like a bit of a Journey rip-off, and it is, but I don't care. I need a way to visualize the player's ultimate goal. (still very WIP by the way)



Fun side note - I cranked the far plane out too far on this level and ran into some depth buffer issues, like this one:



Other fun stuff - you can now see the hearing range of the sentinels, visualized as a faint spherical outline. The reticle also turns red if landing at the target location will alert a sentinel to your presence. Like so:



Still struggling to communicate so much information visually. Starting to get a bit noisy.

edit: the compass also went from four points down to three. Such an obvious choice to fit the triangular motif, don't know why I didn't think of it before.

[etodd]

First tram ride is complete. I am now ripping off Journey and Half-Life AT THE SAME TIME.



Also tweaked the IK algorithm. Legs will now reach around corners.

[etodd]

Stream: For those interested in coding, I've been streaming a bit on Twitch, although not at regular times. Whenever something comes up that I think would be interesting to watch, I stream it. Mostly C++ code. Here: twitch.tv/emt1337

Dishonored: I played this game for the first time last week. Accidentally beat the whole thing in a single 8-hour play session. I had completely forgotten about the game, and now I come to the obvious realization that my game is basically the Blink ability. Not a bad thing, certainly.

I learned some things about stealth. My AI bots now follow predictable patrol routes. And footsteps now emit sound which I visualize in-game like so:



But mostly, Dishonored just made me wish I was making a normal FPS with a human player character rather than a spiderbot. So, the big reveal is:

Humanoids: you can now switch back and forth between humanoid and spiderbot.

I always planned to do something like this, but it was going to be more of a "possess this character" thing. But I think it needs to play a more central role, so I think you'll be able to switch back and forth at will. We'll see. The controls will be exactly like Lemma. I've already got rough jumps, wall-jumps, mantles, wall-running, a decent acceleration curve, a non-horrible placeholder running animation, and wall sliding. All this was pretty straightforward since I've done it before.

Here's the tricky thing about humanoids: they can walk even on pink surfaces which are inaccessible to spiderbots. But spiderbots can climb on walls and ceilings. Several movement puzzles immediately come to mind.

Level design: still struggling with this. My goal is to bring a demo to GDC and find a world-class level designer willing to collaborate.

In the meantime, I decided to steal a design from Dishonored and use it to test the humanoid controls. See if you can place it. There are two Sentinels guarding the entrance...



I also removed edge detection on the out-of-range (pink) geometry. It cuts out some unnecessary noise, but also makes it harder to see stuff in the distance. We'll see if I keep it. Visuals are very much subject to change.

Engine stuff: The armature component now supports multiple blended animation layers. Silky smooth motion. I'm also nearly done with a major refactor which will enable saving/loading games. My goal is to basically fread a bunch of data into memory, hit "go" on the simulation, and have it work. Pretty much that boils down to: IDs everywhere rather than pointers.

Looking ahead: Been reading up on behavior trees. AI is a major shortcoming in my games, it's always been simple FSMs. I'd like to level up this area of my development expertise.