ashtonmorris







Level 2 Re: MK-ZEBRA « Reply #1 on: July 21, 2015, 11:21:13 AM » Looking good. Glad to see you back at it. Following! Logged



Roah * Bomblsinger * Goliath * Wings of Vi * Lemma * Bit Heroes * Star Command Galaxies





http://www.ashtonmorris.com



Twitter: Ashton Morris - Composer & Sound DesignerRoah * Bomblsinger * Goliath * Wings of Vi * Lemma * Bit Heroes * Star Command GalaxiesTwitter: https://twitter.com/ashtonmorris

Spidi







Level 1 Re: MK-ZEBRA « Reply #2 on: July 21, 2015, 12:09:23 PM »



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. Hi et1337!Long time lurker/follower of Lemma (bit too shy and hesitant to write), big fanNice to see, that you are already working on your next project, continuing "grepr" is a really cool ideaI'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 nosyBr, following. Logged I Am Overburdened (@blindmessiah777 Steam ) | KREEP

etodd









Level 3 Re: MK-ZEBRA « Reply #3 on: July 22, 2015, 04:23:38 AM » Quote from: Spidi on July 21, 2015, 12:09:23 PM ...



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



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!) 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!) « Last Edit: February 26, 2016, 05:32:50 AM by etodd » Logged

jctwood









Level 10 Re: MK-ZEBRA « Reply #4 on: July 22, 2015, 05:39:06 AM » 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! Logged PHOGS

jctwood









Level 10 Re: MK-ZEBRA « Reply #6 on: July 22, 2015, 02:07:45 PM » 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. I'll be honest I held my breath while searching for brace completion and thankfully it was falseI 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. Logged PHOGS

etodd









Level 3 Re: MK-ZEBRA « Reply #7 on: July 23, 2015, 06:08:01 AM » Quote 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.



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.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.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. Logged

etodd









Level 3 Re: MK-ZEBRA « Reply #8 on: July 23, 2015, 01:42:25 PM »



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



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. 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. « Last Edit: February 20, 2017, 05:11:44 PM by etodd » Logged

jctwood









Level 10 Re: MK-ZEBRA « Reply #9 on: July 26, 2015, 01:18:04 PM » 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! Logged PHOGS

etodd









Level 3 Re: MK-ZEBRA « Reply #11 on: July 27, 2015, 09:36:31 AM » Quote from: JctWood on July 26, 2015, 01:18:04 PM 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.



Quote from: Spidi on July 26, 2015, 10:43:29 PM 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







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":



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.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": « Last Edit: April 22, 2016, 01:05:41 PM by etodd » Logged

etodd









Level 3 Re: MK-ZEBRA « Reply #12 on: July 31, 2015, 10:58:59 PM »



So I made one:







It's heavily inspired by 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. Logged

etodd









Level 3 Re: MK-ZEBRA « Reply #13 on: August 03, 2015, 12:42:09 PM »







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. 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. « Last Edit: February 26, 2016, 05:31:48 AM by etodd » Logged

etodd









Level 3 Re: MK-ZEBRA « Reply #14 on: August 05, 2015, 05:36:16 AM »



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. 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. Logged

jctwood









Level 10 Re: MK-ZEBRA « Reply #15 on: August 05, 2015, 05:47:30 AM » Loving the minimal UI and the text rendering approach! Logged PHOGS

etodd









Level 3 Re: MK-ZEBRA « Reply #16 on: August 06, 2015, 12:43:39 PM »



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. 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.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. « Last Edit: August 10, 2015, 09:39:16 AM by et1337 » Logged

jctwood









Level 10 Re: MK-ZEBRA « Reply #17 on: August 06, 2015, 12:57:41 PM » 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? Logged PHOGS