next »

[etodd]

Premise

Launch your spider drone at walls, ceilings, and enemy heads in this pre-apocalyptic philosophical shooter. Explore a vast cyberpunk city. Shoot things in the face. Question your basic beliefs.

Open source

Latest source and assets available here: https://github.com/etodd/deceiver

I retain copyright on the assets, but the code is MIT licensed.

Website

deceivergame.com

Devlog contents

2015
Jul 23: real physics, crawling, Github, asset IDs
Jul 27: font rendering
Aug 01: font design
Aug 03: finish font, trajectory visualization
Aug 05: flattened trajectory, bounce prediction
Aug 06: calculus, binary search, triangular level design
Aug 10: blender level importing, level animations
Aug 23: pathfinding
Oct 07: straight shooting, nav meshes
Oct 08: splitscreen, multithreading, basic combat
Oct 12: disco party police siren
Oct 15: SSAO, shadowed point lights
Oct 16: film grain, edge detection, bloom
Oct 21: range visualization, cables
Oct 28: ragdoll physics
Nov 04: level design, shockwaves, cables
Nov 10: Ohio Game Dev Expo 2015, inverse kinematics
Nov 14: PCF filtered orthographic shadows
Nov 20: skybox, enemy hearing range visualization
Nov 23: rough draft tram, IK improvements
Dec 08: stealth gameplay, playable humanoids, level design, animation blending
Dec 15: Ludum Dare, volumetric lighting
Dec 30: level design

2016
Jan 12: The Poor Man's Threading Architecture
Feb 23: new name, new humanoid model, parkour, turrets, projectiles, particles, Soren
Mar 22: Train Jam, Roscoe, design overhaul and recap on exploration into MOBA mechanics
Mar 30: design epiphany, custom nav meshes, surface parameterization
Apr 14: lead indicators, glitches, AI player, level design, control points
Apr 22: friend/foe colors, crawling, sensors
Apr 26: switch to third-person, ability overhaul
Apr 30: dialogue system
May 03: new terminal system, new health system, control point UI
May 09: teleporters, roll animation, new menus, notes, matchmaking
May 16: level design, stealth upgrade, more health revisions, containment fields
May 19: itch.io refinery, new level
May 26: gamepad aim assist, footstep effect, overworld transition
May 31: cooldown upgrade, AI, rocket pods
Jun 03: abstraction and the fourth wall, invincibility
Jun 12: separating abilities from upgrades, containment field changes, balancing, A* optimization
Jun 18: recoloring, AI improvements, rocket obstacle avoidance, armor pickup particles
Jul 02: new level, water shader, triangular particles, movement cooldown skip, writing
Jul 09: gamepad tweaks, rating system, SDL
Jul 16: LLC, Sony application, reticle revamp, buy period, custom map support, force field changes
Jul 22: scan lines, design changes, logo
Jul 30: dash, danger indicator, splitscreen menu, summer expo
Aug 06: kill parkour mode
Aug 12: crawl nav graph, crawl glitch, sniper
Aug 19: new drone model, new title screen, control points, energy indicator
Aug 24: Ian, movement cooldown, more health revisions, sanding down sharp edges, AI work
Sep 02: health overhaul v9, new maps, teleporters, radial dead zone, story overhaul v10, overworld
Sep 09: more maps, improved culling, messages UI, supersampled edge detection
Sep 16: overworld, new maps
Sep 26: start netcode, PS4 port
Oct 08: netcode, ability overhaul, decoy, health v10, rush mode
Oct 26: design overhaul again, netcode, delta compression, dead reckoning, new culling effect
Nov 03: GDEX, dash and reticle improvements, shields, batteries, first working netcode match, grenades, language experiment
Nov 14: new edge renderer, netcode, bolter, improved decoys
Nov 19: clients joining at arbitrary times, minion attack animation, new character model, slide attack, minion melee attack
Nov 24: WIP terminal, in-game map view
Nov 28: terminal done
Dec 03: trams
Dec 11: collectibles
Dec 21: hacking, Dock level, rope climbing/swinging
Dec 31: new map, parkour animations, animated characters

2017
Jan 03: potential rename, dock level
Jan 21: anxiety attack, hobo, aerial kills
Jan 29: projectile client-side prediction, shops
Feb 20: health v11, master server, new AI shadow system, clouds
Mar 09: rebrand, rain
Mar 22: PAX east, attract mode, clipping, AI, skill shots
Mar 27: HUD redesign, clipping, active armor
Apr 14: assault mode, turrets, sniping, active armor
Apr 25: dash combo, Vector conference
May 22: new core design, force field changes
Jun 03: overworld redesign, new tutorial, promo art, tweaks
Jun 09: nav mesh rendering, promo art, combat tweaks
Jun 15: promo art, new level, new character
Jun 28: cinematic WIP, settings menu, gameplay tweaks, banners
Jul 12: Indy Popcon, gameplay recording, camera culling, cooldown tweaks
Jul 18: title screen redesign, cinematic done, kill cam highlighting
Jul 28: new upgrade animation, itch.io integration, virtual dedicated servers
Aug 02: new NPC (Samsa), damage buffering
Aug 11: team switcher, sniper ricochets, IPv6, minion pathing, UI
Aug 18: smooth camera, UI cleanup, build ID, kicking, map work
Aug 26: shotgun, full auto bolter, drone repulsion, server regions, chat
Sep 01: objective labels, shell casings, audio, map switcher
Sep 04: jaggies, shotgun kick
Sep 11: cooldowns, muzzle flash, spawn effects, linux build
Sep 27: trailer, generators, prepare for alpha
Oct 03: GDEX, website, Steam
Oct 07: dedicated servers, status dashboard, spotting
Oct 10: multiplayer alpha, trailer
Oct 25: ability overhaul, capture the flag, itch and Steam authentication, ticket system, mouse support, netcode reliability
Nov 02: CTF tweaks, story mode progress
Nov 26: story mode changes, combat tweaks, new map, other news
Nov 28: The Poor Man's 3D Camera
Dec 07: Seven, rain audio, reverb voxel, adaptive interpolation, store art
Dec 14: grapple, improved map view, cooldown netcode
Dec 22: trailer animations
Dec 30: trailer work, weapon camera recoil

2018
Jan 06: Kickstarter news, Discord bot
Jan 10: Discord integration
Jan 16: new map, hardware cursor, presets, design overhaul, stealthed rectifiers, suicide minions
Jan 30: server queues, breakable glass, drone collision penetration, attaching stuff to minions
Feb 07: new map, reverb improvements, playtesting, waiting room
Feb 20: The Poor Man's Netcode
Mar 02: demo release, visual overhaul

Original post



Premise

A social experiment masquerading as a video game.

Prototype

The game is very loosely based on a prototype called grepr, which I made for 7DFPS 2014. Play it on itch.io.

New engine

I built the prototype in Unity, which worked great. But now I'm so sick of Unity crashes and performance issues due to C# memory management that I decided to build this game from the ground up in C++, targeting PC, Mac, Linux, and PS4.

First engine screenshot

[ashtonmorris]

Looking good. Glad to see you back at it. Following! 

[Spidi]

Hi et1337!

Long time lurker/follower of Lemma (bit too shy and hesitant to write), big fan !
Nice to see, that you are already working on your next project, continuing "grepr" is a really cool idea .

I'm really interested in your decision of creating a new engine and about your language choice.
When I read your "poor man's" technical posts, it somewhat felt like you are not satisfied with XNA or actually not satisfied with C# and overall with the decision of writing your own engine for the game.
I don't know if this is true, it is only what came through your writing. I would like to know, if the engine for Lemma is not something you would like to continue to use and develop? Did you came to this decision due to C# and/or XNA or MK-ZEBRA has requirements for which your old tech won't be sufficient? Isn't choosing a new language a big/scary one? I'm predominantly asking these questions because I'm a C#/XNA/MonoGame user too, and professionally at my primary job I use C++. Also I have to say, that C# for me is a deliberate choice, since in my experience it's benefits compensate for it's "shortcomings". I don't want to start a flame war about this topic , my intention is to learn your motive behind this choice, because you are experienced in this topic.

If these are too personal questions or there are development secrets which should not be answered yet please feel free to omit replying and accept my apology for being a bit too nosy !

Br, following.

[etodd]

...

Lots of questions! I'll do my best to answer:

I will definitely not be using the Lemma engine for future projects. It's not a very capable engine; it really only works well with voxels. It's very specifically designed for Lemma. And that's fine, but I'm not going to re-use it for future projects.

I decided on C++ because I'm a control freak. I need to be able to see all the code I'm running on top of. I've spent so much time battling Unity problems, and it's just not fun dealing with other people's code. Unity is fantastic for small projects, but I think large projects end up spending about the same time writing custom systems, upgrading to new versions, dealing with broken plugins, etc. It's much more fun to write your own code than to re-import a plugin for the umpteenth time because it's still not working.

Furthermore, most plugins (examples from Lemma: Wwise, Oculus Rift, Steamworks) have a native component with a .NET wrapper which for some reason is usually out of date or just lower quality than the original product. Wwise is fantastic, but I have never once seen the Wwise Unity wrappers work correctly on the first try. Of course I'm still using libraries for MK-ZEBRA, but it's not too bad because I'm building all dependencies from source (one exception will be Wwise, because it's just so darn good).

Lastly, I've recently been following Jonathan Blow and Casey Muratori and their respective projects (Jai and Handmade Hero) and came to realize that memory management is generally the biggest performance bottleneck in games, and C# makes it very difficult to control memory. For Lemma, I had to write a bunch of custom allocation code to work around internal, opaque implementation details of the .NET CLR. I spent days tracking down memory leaks and null reference exceptions. The whole reason managed languages exist is to avoid manual memory management, memory leaks, and unsafe memory accesses, yet I had to deal with all three of those while sacrificing the ability to easily arrange memory for optimal performance.

In general, I'm finding it's better to write your own stuff. For example, for Lemma I spent weeks battling the XNA content pipeline to make it properly import FBX animations. For MK-ZEBRA I spent less than a week writing an animation importer based on Assimp, and it was way more fun. (More on that in a future devlog update!)

[jctwood]

Really happy to see you back with a new project! I consider Mirror's Edge one of my favourite games and having read all of your Poor Man's posts you have inspired me to begin thinking about these things more when playing/creating games (not created anything big yet). MK-ZEBRA is looking really fun so far! I adore stealth games and first person games so this is a really nice balance. Also I wanted to ask what IDE you use primarily? The art style is reminding me of Willy Chyr's Relativity which looks fantastic!

[etodd]

Wow, being compared to Relativity is a big deal! I definitely want to experiment with the colors a lot, but I think the general idea of solid colors and lines will remain the same.

I mostly split my time between Linux and Windows. On Windows I use VS 2013. I use the Ragnarok Blue color scheme, which is still my favorite after like seven years. I use VsVim for Vim emulation, plus Productivity Power Tools. Here's my complete settings.

On Linux, I use Vim, bash, i3 for window management, and Chrome. I freaking love it.



Here's my dotfiles to make your Linux install look like this.

[jctwood]

I'll be honest I held my breath while searching for brace completion and thankfully it was false I have been looking to set up linux for a while now and since it looks so slick in that screengrab I may just do it soon. I like ZenBurn on everything if I can find it. Not sure why it is so appealing though. I think themes are like input schemes you just find one and stick with it. It would be a really interesting feature to have the bot switch the colours it sees in the world in order to highlight different objects but in turn obscuring others. With visuals these nice I would want to be able to shift right through the spectrum.

[etodd]

It would be a really interesting feature to have the bot switch the colours it sees in the world in order to highlight different objects but in turn obscuring others.

For sure, it would be great to have some Splinter Cell action going on.

I'm currently collecting all the crazy awesome ideas into a giant wishlist which will get trimmed down to the most important features.

So, add "some kind of IR vision" to the list. Checkamundo.

Real physics

In the original prototype, the player always moves in a straight line, and there are no moving set pieces. This is to prevent the player from missing their target, flying off into nothingness, and getting into an invalid state where they're not attached to anything.

Well, I want moving set pieces. So now you move in a physically realistic arc, and yes you can shoot off into nothingness. Still have to figure out how to handle that case.

Creeping

Another major upgrade is the ability to creep along walls and ceilings. In the prototype, once you land somewhere, you're rooted there until you shoot off again in another direction. But I think creeping will add a lot to the stealth experience. My plan is to make it so that shooting draws a lot of attention, while creeping is a lot slower. I'm also going to add a cooldown to the shooting ability.

Here's the new creeping controls. It's just WASD plus space and control for up and down. Works how you'd expect, mostly. There are still a few corner cases I need to handle better.

[etodd]

The engine and assets are now available on GitHub: https://github.com/etodd/deceiver

I have to keep the gameplay code private for top secret reasons, but CMake will generate some template game code for you so that it still builds and runs without the private code. Right now, there's not much gameplay code anyway, all the cool stuff is in the engine.

I'm particularly proud of the build process. I enumerate all assets at build time and plop them into an auto-generated source file. This way, I can reference assets by integer rather than cumbersome strings, I get auto-completion of asset names in my IDE, and I get a compile error if I reference a missing asset.

I'm planning on using this system to pre-process a lot of stuff in the future. I already use it to pull uniform names out of my shaders.

[jctwood]

Can you elaborate on why so many keys are needed for creeping? Surely you just need strafe forward and backward? Great to see you are open sourcing some of the engine!

[Spidi]

I'm particularly proud of the build process. I enumerate all assets at build time and plop them into an auto-generated source file. This way, I can reference assets by integer rather than cumbersome strings, I get auto-completion of asset names in my IDE, and I get a compile error if I reference a missing asset.

Really cool idea! Android development with java + ANT does something pretty similar. An R.java (R class) is generated at build time and you can reference your files in your resources directory in the application apk file like:
R.drawables.background -> resources/drawables/background.png
Voilà, compile time resource check and somewhat faster resource lookup.

I "may get" creatively inspired the next time I fiddle with my framework code .

[etodd]

Can you elaborate on why so many keys are needed for creeping? Surely you just need strafe forward and backward?

Well, consider the base case of walking on a flat floor surface. I could get away with just a forward button, but I like WASD controls. I use the same movement code for every surface, there are no special tests for walls or floors. At any rate, I'll need to map the controls to a gamepad at some point, where it makes more sense to use a thumbstick for movement rather than buttons.

Really cool idea! Android development with java + ANT does something pretty similar. An R.java (R class) is generated at build time and you can reference your files in your resources directory in the application apk file like:
R.drawables.background -> resources/drawables/background.png
Voilà, compile time resource check and somewhat faster resource lookup.

Uh oh. If Android does it I should probably avoid it...

Just kidding. I really do hate Android with a burning passion though.

In unrelated news, I'm working on font rendering right now. Nothing bothers me more than blurry bitmap fonts, so I'm experimenting with rendering letters as actual shapes. It's a lot of triangles, but I plan on minimizing the amount of text as much as possible, so we'll see how it works out. I'm once again using Blender as part of the import pipeline. I wrote a simple script that imports a .TTF and exports all the ASCII characters into a .FBX file.



To do any kind of UI work you need dynamic vertex/index buffers, so I rewrote my graphics VM to support that. In the process, I found out that GLSL varyings are not matched up by ordering, but rather by name. Here's what happens when your vertex shader outputs a varying called "out_color" when your fragment shader expects one called "in_color":

[etodd]

I looked for a suitable font but quickly realized that most fonts I liked would probably cause problems with the open source license.

So I made one:



It's heavily inspired by Arame, which you might recognize from the Halo 4 HUD.

[etodd]

Used FontForge to create an actual OTF. "lowpoly" is now a real font, you can install it!



Also, new trajectory visualization. Not sure about colors yet.



The UI aesthetic I'm going for is like a more beginner-friendly version of the HUD of an F-16. My goal is to have a ton of UI elements, but where each one serves a legitimate purpose and is immediately intuitive.

[etodd]

Still not sure about this. I think the huge launch arc is probably too much. Precision shooting is a big part of the game. I also don't like the imprecision of the trajectory indicator; it's really hard to judge distance using it.

Right now I'm trying two things. First, I flattened the trajectory so gravity has no effect for the first bit. It looks like this now:



Second, rather than filling up the screen with useless trajectory points, I only display your crosshair and the projected hit location.



I added back a feature I really liked from the prototype, namely reflective/bouncy surfaces. They serve two purposes: one, you can't attach to them, which is useful for limiting player movement. And two, they're fun.

The trajectory indicator becomes a bit more useful with reflective surfaces, so I added it back in for that case:



Unfortunately the prediction is a bit off. The new gravity-defying trajectory makes the calculus tricky. Still figuring it out.

[jctwood]

Loving the minimal UI and the text rendering approach!

[etodd]

Got it working!

Turns out, my calculus was correct. I just wasn't doing enough raycasts along the trajectory to get an accurate collision location. Like, I needed to do upward of 300 just to match the trajectory at a high enough resolution.

That's a lot of raycasts, so instead I'm doing a binary search to find the precise location of each bounce. Then I back-fill the trajectory visualization up to that point.



I've also been slowly designing this level in the background. I'm aiming for a lot of angular geometry in this world, for a couple reasons. First, triangles convey the hostility and aggression of the world in this game. Second, my last game was voxels. I'm so sick of cuboids, I can't even. And circles and curves are beyond my limited modelling skills, so triangles it is! Third, more angles means more interesting ways to crawl or bounce around the level.

So I'm making an entire level out of a triangle, just to see what happens when I run with it all the way.



(obviously there's also now a noclip mode and a placeholder skybox)

I'm thinking this will be an elevator level. At each stage, you have to hook up power to get the elevator to the next stage. Simple, but effective. The various tunnels in and out of the main shaft would allow other players and NPCs to enter and exit as needed. I want it to feel curated and designed specifically for the player, but also pragmatic.

[jctwood]

I think the approach on level geometry makes a lot of sense. I am looking forward to seeing more of the levels come about. As well as bouncy surfaces have you considered sticky surfaces which you cannot jump from and have to slowly crawl out of?

[etodd]

I think the approach on level geometry makes a lot of sense. I am looking forward to seeing more of the levels come about. As well as bouncy surfaces have you considered sticky surfaces which you cannot jump from and have to slowly crawl out of?

Added to the list of things to check out. I also want to try penetrable surfaces. Similar to glass, but opaque to enemies, so you can crash through it and surprise them.

[jctwood]

That is genius!