next »

[etodd]

Cooldown upgrade

I had an upgrade that sped up the movement cooldown by 25%. This is a quantitative change, not a qualitative one. I think that makes for a lame upgrade. Now I'm experimenting with a new upgrade: add 1 to your max HP. This is also a quantitative change, but it's significant enough that it changes the game. Of course it has to be quite expensive.

AI

I've been optimizing and bug-fixing the AI. I've been having trouble with the triangle rasterizer. I want it to distribute points evenly across all surfaces, but sometimes it doesn't do that.

Actually fixing the problem sounded like too much work, so I first deployed some mitigation measures. The biggest issue was the following scenario:

• AI bot tries to pathfind from point A to point B
• AI system tries to find the navigation graph node closest to point A
• The nav graph is missing nodes near point A, so it turns out the closest node is actually on the other side of a wall
• AI system happily calculates a path from that node
• AI bot gets stuck trying to get to the other side of the wall

I "solved" this by also storing a normal for every node. In the scenario above, the system will now ignore the bad node since it's facing the wrong way.

This duct-tape patch still wasn't enough, so I also went and actually fixed the rasterizer. It now works on all but the very thinnest of triangles. I think I'm okay with it.



Even with a perfect nav graph, the AI can still get stuck due to the low sample rate. I put in more mitigation measures:

• Normally the bot tries to crawl toward the next nav node before shooting toward it. I made it stop if any further movement would obscure the next node behind an obstacle.
• If the bot can't see the next node, it might be a bit off from the node it's currently supposed to be at. I made it crawl toward it in this case.
• If all else fails, the bot goes into "panic" mode after a few seconds, swinging the camera around and shooting to the first suitable target location.

I did a lot of work on the behavior trees as well. They keep falling into loops, where behavior X gets triggered, executes successfully, but for whatever reason doesn't actually do anything to change the situation, and so it gets triggered again the next time around.

The bot actually has three loops, two of which run in parallel at any given time. This is another place where repetition can creep in, because the two parallel loops can preempt each other in certain situations. You're running behavior A, behavior B interrupts it, but as soon as it's done, behavior A starts up again. If the two behaviors are at odds (going different directions for example), the loop will repeat forever.

Right now each behavior has a hard-coded priority index, but I think I might need to alter it randomly, or decrease it every time the behavior runs, in order to avoid situations like this.

Goodbye teleporters, hello rocket pods

Teleporters were just not fun. Plain and simple.

Also, getting caught in an enemy sensor field was not scary enough. The enemy gets points for it, and they might be able to track you down better, but they might not even be looking for you at that moment. You end up with "alarm fatigue", walking around constantly being tracked without worrying about it.

So I trashed the teleporters and replaced them with single-use rocket pods. Each rocket is dirt cheap and takes 1 second to spawn. I'm expecting people to build arrays of these things.

Here's a gif. Ignore the cramped UI, it's a lot less crowded in 1080p.



Right now the rockets just head straight for the target without regard for the environment, but I'll probably have to put some simple obstacle avoidance in.

[etodd]

Abstraction and the Fourth Wall

Did some more playtesting and got feedback from a fellow gamedev (thanks Steve!). He brought up a very good point. The game has a lot of arbitrary numbers with no physical counterpart: hit points, credits, etc.

Originally, every game element was explained by the story. Over time things have become more abstract. Which is fine, except that it's more difficult and less impactful to think about "credits" than something more concrete like "ammo".

The reason for the abstraction is that I plan to break the fourth wall pretty severely in this game. In fact, at the moment, there really is no fourth wall. Everything is unapologetically arbitrary and "video gamey".

My friend made me realize that in order to break the fourth wall, you must first establish it. Otherwise you're just non-fiction.

So I'm backtracking a bit and bringing in some of the fiction elements that previously played a larger role. This way, there will actually be a fourth wall for me to break later in the game.

I'm starting with simple stuff. Instead of "HP", it's "armor". Instead of "earning credits" by "capturing control points", it's "collecting energy" from "energy ports". I made this a little more concrete with a simple animation showing your sensor pod collecting the energy:



I have a lot of world-building and backstory built up for this game, but I dropped it in favor of more self-aware, fourth-wall-breaking stuff. I didn't want anything in the way of the mechanics and character arc. But now I'm realizing that world-building is super important for immersion.

Invincibility

The other major feedback I got was that the health/invincibility mechanic was confusing and frustrating. It made no sense that just because someone has higher HP than you, you can't damage them at all.

I need some kind of mechanic for this though. I don't trust players to run away and live to fight another day. And I don't want games to end in 2 hits.

Here's what I'm trying now:

• When you get hit, you are shielded for 8 seconds
• If someone hits your shield, the shield goes down, but they become stunned and unable to move for 3 seconds
• If you are shielded and hit someone, your shield also goes down

Here's what it looks like in action. I show the remaining shield amount as a progress bar. The "SH" is the first two letters of the world "SHIELD".



Hopefully this slows things down and encourages people to buy upgrades to gain an advantage.

I leave for SF on Sunday and then NYC a week later. Work will continue, but updates will probably slow down a bit.

Anyway, here's a funky color scheme I liked because it felt a bit 70s

[etodd]

Separating abilities from upgrades

Previously it worked like this. There were three abilities: Sensor, Rocket Pod, and Minion. Each ability had two levels. You had to buy level 1 before buying level 2. You started out with Sensor level 1 already purchased, since sensors are how you collect energy.

I realized that the level 2 upgrades were completely unrelated to the level 1 abilities. Furthermore, enforcing a certain order of upgrades limits the number of meaningful choices you have. And having the player start out with an ability by default is like making a choice for them; there should be many viable ways to purchase upgrades.

I flattened out the leveling system, so now you can buy any upgrade as soon as you can afford it. And if you don't want to buy the Sensor upgrade, you can buy something else and rely on other ways to get energy.



I also changed "Sensors" to "Collectors". Makes more sense within the new fiction.

Containment field changes

That brings me to containment fields. I made them work both ways, so you can use them to keep an enemy in or out, depending on the situation. I'm just calling them "force fields" now.

Anyway, previously you would buy an upgrade that would add these force fields to your minions. The problem is, minions are cheap. I wanted them cheap because they're super fun and cool, but this made it easy to suddenly fill the level with a confusing smear of transparent spheres. I decided to make force fields another spawn ability, just like collectors, rockets, and minions.

Here's the new spawnable force field. I'll redesign the model later.



New problem: I now need to map four spawn abilities on to three gamepad buttons: X, Y, and B. I already tried the "press Y to switch active ability" system, and hated it. I really like the three buttons, not least because three is a major theme of the game.

I decided to limit the number of spawn abilities you can purchase to three. I map the abilities to buttons in the order you purchase them. I thought this would be confusing but it's actually not bad. We'll see if it sticks.

More balancing

I realized that minions were seriously over-powered, because they were the only way to destroy enemy collectors. If your enemy captures all or most of the energy ports on the level, you have to buy the minion upgrade to re-capture them.

I made it so that you can destroy collectors on your own. They're pretty tough to hit, so the minions are still really helpful. But to make the minions even more useful, I made them attack the enemy, where previously they would only attack enemy collectors. I had to slow down the projectile and the attack cooldown, and add a cooldown UI bar. We'll see if all that sticks as well.

A* optimization

A* was taking up to 20 seconds in some cases, causing the AI player to sit still in the middle of combat and think really hard. Turns out, I didn't have an efficient way of determining if a node was already in the A* search queue or not. It was just a linear O(n) search. I already had a data structure to store per-node metadata, so I added a boolean flag indicating whether the node was already in the queue, and that brought the worst-case A* search time down to 1 second.

[etodd]

Just a quick update today!

Ponos recolor

I recolored this map (now called "Ponos"). I will always try to squeeze more purple into a scene.



AI improvements

The AI still has a long ways to go, but it now beats me on the regular, which is a good sign. Now, on the rare occasions when it encounters a bad nav path, i.e. one that is in the nav graph but cannot actually be traversed, it removes the path from the graph. This prevents loops where the AI gets stuck repeatedly trying the same invalid path.

Rocket obstacle avoidance

The rockets now use four "whisker" raycasts to avoid obstacles while they track their target. Makes them a much better value proposition since they're less likely to end up in a wall.

Energy bonus changes

Previously you would earn energy bonuses for things like damaging the enemy, killing one of their minions, etc. These bonuses just coalesced out of thin air. Made no sense. Now I actually steal the energy from the enemy and give it to you.

Armor pickup particles

Armor pickups are the most "gamey" thing in the game. There's no physical explanation or real-world analogue for them. A friend suggested making them look a bit more magical and powerup-esque. Thus:



Other stuff's going on, but nothing screenshot-friendly. Lots of writing.

[hexdie]

Just a quick update today!

Ponos recolor

I recolored this map (now called "Ponos"). I will always try to squeeze more purple into a scene.

This is looking great! I especially enjoy the colors in this screenshot. Keep it up! 

[etodd]

This is looking great! I especially enjoy the colors in this screenshot. Keep it up!  

Thank you! <3

Everyone go check out Glow Flower. It's rad.

Okay, update time!

Moros

This is a new level I'm working on. It also includes a simple water shader. Water is basically "out of bounds" at the moment. Maybe later I'll do something else with it.



Triangular particles

This was driving me nuts. Everything in the game was triangular, except for the particles, which were diamonds. Most particle systems assume particles are quads, so to make a triangle I'd have to use a texture. Well, I refuse to use textures in this game. LONG LIVE VECTOR GRAPHICS!

TL;DR: I wrote a custom particle system that creates triangles instead of quads. All is right in the world.

Movement cooldown skip

This is an experiment to enable high-level play. It works like an active reload system. The cursor flashes briefly and you have a chance to skip the cooldown if you aim quickly enough and nail the timing. It can be fun to chain a combo together and get a rhythm going.



Writing

In my last game, I tried to use branching dialogue to provide choices to the player. I wanted every choice to mean something. I also wanted to avoid one-sided conversations with lots of reading in between player choices. Unfortunately I ended up arbitrarily sprinkling choices into each conversation that amounted to "BE A JERK? (Y/N)"

The theory was, I would keep track of your level of jerkiness, and unlock different dialogue options accordingly. The reality is, I never did that, and anyway, simplistic morality systems aren't all that interesting.

Now I'm doing simple dialogue branches based on in-game actions. For example, when the player loses a match, Penelope consoles them before moving on with her normal conversation.

All that to say: the writing is moving forward. It's better than the last game. More interesting character traits, less pretentious drivel. But still a little bit of that.

NYU Playtest Thursday

I had the privilege of attending the playtest event at NYU Game Center on Thursday. Got to see Ian Snyder's new game. Didn't realize who it was until afterward.

I arrived late but did manage to playtest one game and have someone play mine. The game was not really their type, but they had a lot of useful insight. Looking forward to future events!

One nice thing about NYC is the steady stream of gamedev events. There's so much going on! I'm trying to take advantage of my time here as much as possible.

Tile Risers

As a side note, a mid-sized YouTuber picked up Tile Risers this week, bringing a sustained number of simultaneous players to the game for the first time. A few free game sites have also picked it up. Right now there are at least 10 people playing at any given time, which is enough to make it interesting. Check it out here!

[etodd]

This week was a lot of future planning and tangential work surrounding the game. I did manage to do a couple things though.

More gamepad tweaks

One problem with the gamepad aim assist discussed earlier was that it would actually adjust your aim away from the target in some cases. I put in a simple check to prevent that. It would also adjust the camera far too noticeably if you were aiming nearly straight up or straight down. Another check fixed that issue.

Even so, some players are still struggling with the gamepad controls. Today I tried a cubic response curve rather than the quadratic one I've been using, but it felt too wild. Then I found this incredibly detailed article about gamepad acceleration in various popular FPS titles.

Turns out that in addition to a response curve, they all apply some form of acceleration. So in Call of Duty, one of the twitchier titles, even if you mash the stick all the way, it takes 0.2 seconds for the rotation to reach full speed. Halo actually employs two acceleration curves: fast for the first 0.2 seconds, then a slower buildup of speed through the 1 second mark.

For now I went with the Call of Duty acceleration model. I also decreased the FOV from 80 to 70 degrees (FOV slider is on the todo list). We'll see how it fares in playtesting.

Rating system



The rating system determines your standing on the leaderboard. Right now, the only two factors that matter are a) whether you won, and b) how much energy you had left over. Could maybe add more scoring incentives later.

SDL

GLFW's gamepad support was simply broken, so I switched to SDL quite some time ago. I've been battling it ever since. On Mac, the fullscreen support just doesn't work. Granted, fullscreen on Mac is totally bonkers. I'm not sure what the expected behavior should be, but I'm pretty sure what I have now is not it.

On Windows, it works fine except on my laptop, where the DPI is 120 instead of 96. I've tried every combination of calling / not calling SetProcessDPIAware(), asking for fullscreen / windowed / borderless fullscreen window, etc. It's 100% a tossup as to what window resolution you end up with. I'll keep fighting it, but if anyone has any SDL tips, I'd love to hear them!

[sidbarnhoorn]

This looks awesome. Following! :-D

[etodd]

This looks awesome. Following! :-D

Thanks Siddhartha! Loved your work on Antichamber. :D

Update time! Lots of stuff happened this week.

LLC

After doing business under my own name for two years, I finally registered Helvetica Scenario, LLC in Ohio. The name is an awesome reference I've been wanting to use for a while.





What finally won me over was the discovery that helveticascenar.io was up for grabs. (currently just redirects to my personal website)

Sony application

The whole purpose of forming an LLC was to be able to join the PS4 developer program. I applied this week and am waiting to hear back. Fingers crossed.

Reticle revamp

A few testers played for a good five minutes before realizing the triangle at the center of the screen was a reticle.

I revamped the design a bit. It has to communicate FIVE different states without getting too visually noisy.



Buy period

Also in response to tester feedback, there is now a 10 second buy period at the start of each match, where movement is disabled, allowing time to buy upgrades.

Custom map support

I'm now shipping the level importer executable alongside the game executable. This will allow players to put .blend files in a special folder, run the importer executable, and play their map in the game.

The main motivator behind this feature is actually the possibility of facilitating other map makers working on the game before release. More on this later, hopefully.

Force field update

I encountered an issue with the force field: player A can spawn a force field around player B's base. If player B does not yet have the necessary upgrades to destroy the force field, they can never return to their base.

Right now I'm solving this by putting a limited lifetime of 15 seconds on the force fields. The idea is, it runs on "battery". If you place a force field near an energy port, it will last indefinitely. Then all I have to do is ensure there are no energy ports near the bases.

We'll see how well this works in practice. Force fields are definitely not as well integrated as the other mechanics; they probably need more time in the oven.

Soteria design

"Soteria" is the tutorial level. Like in most games, it has received the most attention. I'm still redesigning the scripts and triggers, rewriting the text, and rearranging the level geometry.

[etodd]

Back when I was doing gamedev part time, I had a hard time starting work on large features, because I only had blocks of a few hours when I really needed much longer periods of focus.

I'm experiencing that same problem again; there are a number of things I just can't start without a solid 8 hours to think about it.

Fortunately, I only have three weeks left in NYC, and there's a ton of minor stuff to do in the meantime. I'm also taking advantage of the many gamedev events here. The game has received a ton of playtesting in the past few weeks. One playtester, after listening to me explain the game, said "That's... kind of stupid." The game seems to really resonate with people.

On Wednesday I was able to show the game at a tiny IGDA meetup at a venue that was way too fancy for the occasion.



Scan lines

One playtester suggested that the game needed more "texture". I said goodbye to film grain a long time ago, but I decided to experiment again, this time with scan lines.

Version 1 looked like this. Vertical lines every other pixel. I used a weird blend mode which darkened the scene via multiplication, and brightened it via addition. It was odd.

(Click to see full res)



Version 2 incorporated some suggestions from Twitter: switch to horizontal lines and animate it. I also changed the density to 1 line every 4 pixels.



Then Matt Gallais, art director on Deus Ex Mankind Divided (woah), suggested I modulate the intensity based on depth, making it a sort of "scan line fog".



Pretty nice, but still a few issues to solve.

• I dropped the weird alpha blending and switched to white lines with additive blending.
• The lines were sampled via nearest-neighbor. This caused jitters once I started animating the lines. I did some manual filtering to smooth this out.
• The filtering looked great in most cases, but caused the whole screen to flash noticeably sometimes, especially on TVs. I'm still experimenting with this, but for now I'm biasing the sampling towards one pixel rather than mixing the pixels evenly. Seems to be working okay so far.

Here's how it looks now:



Design changes

Playtesting revealed that no one knew how to collect energy, so I decided to merge the armor pickups and energy ports. Now you earn energy based on how many armor pickups you own.

Force fields suddenly become more useful, because armor pickups can now power them indefinitely. You can capture an armor pickup, then set up a force field to protect it. Only an enemy minion can destroy the force field.

Another somewhat big change was the way players bounce off each other after doing damage. Previously, the camera instantly swung around to face the drone's newly reflected trajectory. Now I keep the camera facing the original direction. I also fudge the reflection vector so that the player bounces a reasonable distance away. This helps prevent the awkward scenario where two drones are right next to each other.

Logo

Someone suggested that the pyramid symbol made them think of the Illuminati, or a dollar bill. I mostly picked it as a fairly direct interpretation of "yearning".

Right now I'm experimenting with flipping it upside down:



This was a nifty but nearly unreadable idea:



Someone suggested that I hire a graphic designer, but I am a) too cheap, and b) too much of a control freak. So I'll just keep iterating until I find something acceptable. This was basically the process with the last game as well.

Also, this devlog turned one year old yesterday! Thanks for sticking around and reading my nonsense.

[Jesse Ko]

Congrats on the one year anniversary!

I really like the new graphic changes you've made. I especially like the horizontal lines. Also the new logo with the bar cut in middle looks really cool, it's unfortunate that it's more difficult to read though =(.

The only suggestion I have is to go full Illuminati and put an eye in the middle of the triangle. 

[etodd]

...

Thanks man! Yeah you're right, full Illuminati is definitely the way to go. I just need to ask the powers that be (Rihanna I think?) for permission to use the symbol.

Here's what's new this week!

Dash

I have this system that grays out everything behind the surface you're currently attached to. I do this because you can't shoot backward through the surface; it doesn't make physical sense. However, a significant number of players (probably 50%) get confused when they aim at the wall they're currently attached to, and they can't shoot there.

So I added a "dash" move. When you aim at the attached surface, the reticle changes to a chevron, indicating that you will dash a short distance. This gif demonstrates:



It still takes some getting used to, but at least it avoids the frustration of pressing a button and seeing nothing happen.

The only problem is, I'm not sure what to do with the spider-bot's legs during the dash. Right now they just sort of fold up a bit. No one has questioned it so far, so for now I'll just leave it as-is.

Danger indicator

Players often charge into battle with only 1 hit point, not realizing that they were in danger of losing the entire game in a single hit. Losing a match should not be an unpleasant surprise.

Also, 3 total hit points is a bit low. I wanted 3 because there are 3 of everything in this game, but 4 is more ideal.

I solved these issues by increasing the player health to 4 hit points and hiding the first hit point in the UI. So you have a base health of 1 hit point, but you don't see it in the UI. At the start of each match, you'll see a flashing red empty health indicator, ensuring that the first thing you'll do is look for health.

If you get down to 1 base hit point, you'll also see a flashing danger indicator when an enemy is in range. You can see this at the end of this gif, along with a few other new features. Players now leave trails of tracer particles, making them easier to follow. You can also see what happens when you damage a player and bounce off them; it's much less jarring and disorienting.



Splitscreen menu

The menu for setting up a splitscreen match used to be pretty bad. Each player had their own screen. You would press A to join and switch teams. You had to constantly glance over to the other screens to see which team everyone was on. I got this setup from Call of Duty, but it doesn't really make sense for local multiplayer.

There's a standard solution to this problem. Not sure why it took me this long to switch to it.



Not pretty, but much more functional.

Summer Expo

On Thusrday I got to show the game at Playcrafting NYC's Summer Expo. There were apparently 110 games, over 800 people, and most importantly, free pizza.

It was tough to draw people with only a laptop and some business cards, but a decent number played and really enjoyed the game. However it really hit me that this game's appeal is much more narrow than my last game. A typical conversation went like this:

Person: "This looks cool, what is it?"
Me: "A 3D shooter. Want to play?"
Person: *turns away* "Look, a mobile game!"

"Core" gamers (sigh) absolutely loved the game. Not sure how to feel about it. I would love to make highly accessible games that anyone can play. I would especially like to make games that appeal to both men and women, because doing that almost always results in a better game.

I don't have enough skill for that yet. So for now I'll rationalize by pointing out that the genre of indie 3D shooters is in pretty bad shape right now. The only quality, innovative titles I can think of at the moment are by David Pittman and Terri Vellmann. Plus, there's the tired old saying: "make the game you want to play".

Whatever it takes to make you feel okay about yourself, right?

Anyway, the other takeaway from this expo is something I've been thinking about for a while. Namely, it's nearly impossible to explain the game to people. Being able to explain your game in a sentence is super important. I've been working on it since day one, and I still can't do it, because it's basically two games mashed into one.

So I'm removing one of the two games. No more parkour.

I realized that the parkour mechanics have nothing to do with the rest of the game. In fact, it's so disconnected that I can pretty cleanly remove it without changing much. The important part is telling the story, and I can do that via other means.

The plan is to go back to the roots of the original "grepr" prototype, which had a nifty terminal emulator between levels, where the (very miminal) story unfolded. I won't be going full terminal this time (it needs to be gamepad accessible). It should be fun to come up with a neat seventies-ish UI though.

[etodd]

Small update this week.

Parkour mode completely gone

Like I promised last week, this entire mode is now gone. Cutting big features like this used to hurt, but I've somewhat retrained myself to view it as a good thing now. It's probably just Stockholm Syndrome.

The only problem is that parkour mode was super colorful, and without it I'm left with an extremely restricted color palette. The visuals feel more cohesive now, but I would like to find some way to incorporate those colors again in a way that fits in with the rest of the game.

Look sensitivity, Y axis inversion

This is one of the most important features of any FPS. Can't believe it took me this long to add it, but there it is.

Playtesting

The game is testing much better at this point. For most of its life, the game has been super confusing to people. They only played for one round before quitting. I think the main changes that made it more intuitive were:

• Scan line fog - improved readability and depth perception
• Aim assist
• "Tutorial" (really just starting on a small, simple map with no special abilities)

Whoops, no screenshots this week! Here's a gif:

[Babar]

It looks great ! I like the parkour mode idea, it would be fun to have some jumping puzzles. Too bad you cut it out 

[etodd]

It looks great ! I like the parkour mode idea, it would be fun to have some jumping puzzles. Too bad you cut it out 

Thanks. Yeah, it's always nice to have more features, but I think it's important to make the game feel focused and cohesive.

Devlog time.

Crawl navigation graph

So far the nav graph has only contained data for shooting from point to point. The AI crawling was basically fake. I wanted the nav graph to allow the AI to crawl intelligently.

I started by simply connecting points together within a certain radius. I had some bugs at first, but you can see what I was going for:



Next, I wanted to do some raycasts to ensure there were no obstacles between points before connecting them.

For co-planar or concave surfaces, a single straight-line raycast works fine. For convex surfaces where the AI bot needs to crawl around a corner, two raycasts are necessary. This image illustrates the case I was planning for:



Here the AI bot would be crawling horizontally around the triangular shape. It should be able to crawl around two of the corners, but the third corner is blocked by another piece of geometry.

When connecting two points on different surfaces, I ended up calculating the intersection line between the two surfaces, picking the closest point on that line, and doing two raycasts from that point to each of the two candidate connecting points.

Here's a screenshot of the results inside the triangular geometry. The points on the obstructed corner on the right are not connected.



Here's how it looks when it's all working.



Corner cases

The movement code works by placing the player a small distance away from the surface and raycasting toward that surface. I realized you could leak through the geometry by shooting and landing very close to a sharp angle like the one beneath this ramp:



Here, the attachment point could be flush with the floor while the player's position is actually inside the ramp.

I've been beveling and removing these problematic angles, but I realized the code needs to handle this case because it's possible for players to create arbitrary geometry by spawning force fields. The fix is thankfully pretty simple. I just do a few dot products and nudge the player away from the corner.

Crawl glitch

This issue has been looming since the beginning of the crawl code. It happens when you're on a corner and you try to move adjacent to both surfaces:



Here we're trying to move upward, but the movement vector gets clamped against the surface we're currently on. The code transitions you to the other surface, which then clamps your movement vector in the opposite direction. You end up jittering back and forth between the two surfaces. This can also happen with concave corners.

I solved this by preventing the player from transitioning to a new surface if the new clamped movement vector would send the player back toward the original surface. Now it just slides smoothly along the edge.

Sniper

Not much to say here. I added a sniper ability. It increases your range and allows you to attack without moving. Each bullet costs 10 energy, and your position is immediately revealed to the enemy after firing. It's particularly potent when combined with force fields.

[Frogs_Milk]

Crisp aesthetics.I like your idea of NPC's believing they're human.

[etodd]

Crisp aesthetics.I like your idea of NPC's believing they're human.

Thanks! Yeah, definitely going to be exploring that topic more in depth.

I'm back in Ohio! And back to full-time development. Yay.

New drone model

Somebody on the stream pointed out that the drone had three legs, while its body had five sides. This was a holdover from the original model I made for grepr back in 2014.

Fear not, the error has been rectified!



New title screen / logo

GDEX is coming up, and they emailed me asking for assets to put on their website. I realized I needed to figure out the logo and come up with a reasonable title screen to attract people at the expo.

Here was my first quick attempt:



Serviceable, but boring. I also wasn't happy with the composition. I looked at a bunch of main menus in video games and realized that a lot of them put the menu items right in the center of the screen. This frees up the frame to allow for a more interesting composition:



I had to mess with the scan lines and tone them down a bit to reduce flickering. I tried using just a regular texture sampler to create the effect, but that actually flickered even more than my math-based solution.

One thing I'm still not sure about is the way the scan lines interact with the UI. The scan lines are modulated by depth, and the UI renderer doesn't write to the depth buffer at all, which means that you can see faint geometric outlines in the UI. This was completely accidental, and I kind of like it because it's almost like transparency, but I'm not sure if I should keep it or not. It would be a relatively easy fix.

Here's the background without the menu in the way:




Control points and energy indicator

Last night I was thinking that the levels needed more interactive objects or "goals" in them. There were only the health pickups, which also passively give you energy. I also didn't like the hard cap on energy collection; since you can only own up to three health pickups, you can only earn energy so quickly. I was also worried about a new use case I wanted to support, which is the possibility of more than 2 teams. Each team needs its own spawn point.

I solved all of these problems by allowing players to capture each other's spawn points (or "bases"). There are two reasons why you might capture a base: 1) to earn more energy, and 2) to gain another location from which you can buy upgrades.

Each map now has 3 or 4 bases on it. If there are only two teams playing, the other bases start out neutral.

Here I am capturing a base. It's a non-cancelable operation. I also added a timer indicator in the lower left to show when your passive energy gets applied every 15 seconds.

[etodd]

Ian Cuslidge

Ian is working on the game for at least the next month, doing some level design and general consultation. Say hi to Ian! He's already put together some interesting new designs.



Movement cooldown

There have been nothing but complaints about the movement cooldown. Ian suggested replacing it with a "charge" system similar to Tracer's "blink" ability in Overwatch.





I thought this was a good idea. So now, instead of a single cooldown, the player has three "charges", each with a separate cooldown. Here you can see me burning through all three charges in quick succession, leaving me vulnerable at the end.



I also nearly doubled the crawl speed. Another common complaint.

More health revisions

Another problem was the fact that the game started players with no health. This gives them something to do right away, namely run around the level capturing health, but if players ran into each other early on it was usually game over much sooner than my target match time of 10 minutes.

At first, I tried starting the player with the closest health pickups to their spawn already captured. This made them less vulnerable in the early game, but without any health to collect, players would start looking for each other immediately, again ending the game sooner than I'd like.

I ended up increasing the health cap from 4 to 6. I also start players with 3 "free" health points, i.e. they are not tied to a physical health pickup on the map. This means that once you lose those points, you can't get them back unless you steal the enemy's health. Basically, the overall amount of health in the game goes down over time, which is exactly what I need.

I think this is about the 8th version of the health system. We'll see if this one sticks.

Sanding down sharp edges

This is a constant process, but I thought I'd share one simple example.

Normally, the ability spawn buttons are edge-triggered. Meaning, if you hold down the button, it won't keep spawning. You have to release and press the button again. This means that if you happen to press the button while it is deactivated (for example, while you are in mid-air), the button will not recognize your input. However, you might press the button just before it becomes active, maybe just before landing on a new surface for example. The button will never register your input because it's edge-triggered. This is frustrating.

I put in some code specifically to handle this case. Things are less frustrating. The end.

AI work

The AI can now spawn rockets and force fields. It has a very basic concept of saving up money for upgrades, and it compares the priority of each purchase with the possibility of future upgrades.

I also noticed the AI making jerky crawling movements, so I made the nav mesh generator connect diagonal points as well as adjacent ones:

[Jesse Ko]

Hi Ian! I am excited to see what new levels or level changes happen!

I really like the new jump system with charges, I think that is a great direction to go in! Maybe have empty triangles when a charge is used, instead of deleting the full triangle (more similar to tracer's blink ui) and have it charge back up by filling up the empty triangle from bottom to top and maybe flash a little when a charge is back. I think that would clearly communicate to the player how long they must wait and when they got a new charge.

I think these new movement changes (increased movement speed and jump charges) will make the game even more intense! I wonder how the new movement changes will affect the match length? Will the players get to each other quicker and kill one another or will the players dodge each other more so it lasts longer. Also that nav mesh looks beautiful, great job! 

[etodd]

...

Thanks for the feedback Jesse! I did end up tweaking the cooldown UI a bit. And you're right, the movement changes definitely ratchet up the intensity, which leads into a serious problem I've been having...

Health overhaul v9

The problem is, matches still end far too quickly. For some reason I thought of the regenerating health mechanic in many modern shooters, and how people complain that it encourages you to cower behind walls for a few seconds instead of running into the action. That behavior is exactly what I need in this game!

I took out the kludgy shield-and-stun mechanic and replaced it with a single special health point that regenerates after 8 seconds. It works well enough that I'm fairly confident it will exist in the final game in some form.

Another problem Ian pointed out was a lack of variation between early-game and late-game play. I addressed this issue with a band-aid patch for now by separating the abilities into two tiers: cheap, defensive, early-game abilities and more expensive, dangerous, late-game abilities.

New maps

Ian has been working hard on new maps. Check it:





I think they're pretty nifty.

Teleporter redux

I brought back the teleporter as one of the tier one abilities. It works a bit different now; it almost instantly teleports you to the farthest friendly control point. Useful for escaping dangerous situations. If you spawn minions, they can also make use of your teleporters.

Radial dead zone

Drew Van Camp commented in my stream, posting a link to a great article about thumbstick dead zones. I was previously using a square dead zone, but no more! Gamepad controls feel even better now.

Story overhaul v10

The story is the only thing that's been through more revisions than the health system. I started looking for a new story when I threw out the parkour elements. When I say "new story", I only mean a different way of communicating the same idea that has been constant since almost the very beginning. As I've mentioned before, Story v10™ returns to the roots of the 2014 7DFPS prototype, which brings us to...

Overworld

The story now unfolds mainly in the overworld. The story is closely tied to the overworld interface, so I decided to flesh it out and reassure myself that I can make it do everything the story needs.

I thought about the interface for about a week and came up with a three tab system:



When a tab is "minimized", it will show a compact summary of its contents, and a notification will flash if something needs your attention.

The overworld will be a separate lightweight management game. You'll be capturing zones, managing resources, etc. You'll be able to deploy a drone to automatically capture zones, but when an opponent intervenes, you'll have to decide whether to risk more energy and manually pilot the drone, or chalk it up to a loss and sacrifice the drone.



The zones are simple shapes built out of triangles, and though you can't see it in the gif above because there are no buildings, the zones recolor all the geometry inside them. I do this by modeling the zones as volumes, like this:



Everything inside the volume will change color with the zone. I use some simple depth sorting and culling flags to pull this off without a stencil buffer.

The zones generate energy over time. Bigger zones generate more energy, and there's a bonus for capturing multiple zones in a chain.

AI

Despite all these new features, most of my time has actually been spent improving the AI. It now handles force fields correctly and can even snipe sometimes. It mostly works, but there's still a lot to do. Once I have a decent baseline implementation, I'll move on to creating multiple AI personalities.