Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1142136 Posts in 48125 Topics- by 39385 Members - Latest Member: G.M.M.

July 29, 2015, 06:04:56 pm

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsFeedbackDevLogsMK-ZEBRA
Pages: [1]
Print
Author Topic: MK-ZEBRA  (Read 771 times)
et1337
Level 1
*



View Profile WWW
« on: July 21, 2015, 08:48:30 am »



Premise

Story-driven stealth FPS with multiplayer elements à la Dark Souls or Journey.

Prototype

I built a prototype called "grepr" for 7DFPS. Play it on itch.io.

You're a robot that bounces around attaching to walls and ceilings, finally shooting through someone's head like so:



More gifs:


Goals

I hope to work on this solo for at least 9 months before seeking outside help and possibly a publisher.

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#'s memory management that I decided to build this game from the ground up in C++. I already have something building and running on PC/Mac/Linux, complete with a content pipeline, entity/component system, and physics engine. Here's where I'm at.

Devlog

I'm hoping to make this devlog much more interactive than my last one. I have a fairly strong vision for the final game, but there are a lot of unresolved details for which I'll be soliciting your feedback!

Open source

https://github.com/et1337/mkzebra

Once again I'm trying to release as many components as possible under an open source license. This time there will be a larger chunk that I can't release due to top secret reasons, but I'm pretty excited about the core engine.
« Last Edit: July 23, 2015, 01:52:43 pm by et1337 » Logged

ashtonmorris
Level 1
*



View Profile WWW
« Reply #1 on: July 21, 2015, 11:21:13 am »

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

Spidi
Level 0
**


View Profile Email
« Reply #2 on: July 21, 2015, 12:09:23 pm »

Hi et1337!

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

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 Who, Me?Beg, 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 Embarrassed!

Br, following.
Logged

et1337
Level 1
*



View Profile WWW
« Reply #3 on: July 22, 2015, 04:23:38 am »

...

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!) Smiley
Logged

JctWood
Level 5
*****


programmer/jammer


View Profile WWW Email
« 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

@jctwood  |  programmer/jammer  |  jctwood.uk
et1337
Level 1
*



View Profile WWW
« Reply #5 on: July 22, 2015, 01:59:47 pm »

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

JctWood
Level 5
*****


programmer/jammer


View Profile WWW Email
« Reply #6 on: July 22, 2015, 02:07:45 pm »

I'll be honest I held my breath while searching for brace completion and thankfully it was false Wink 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.
Logged

@jctwood  |  programmer/jammer  |  jctwood.uk
et1337
Level 1
*



View Profile WWW
« 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.

Logged

et1337
Level 1
*



View Profile WWW
« Reply #8 on: July 23, 2015, 01:42:25 pm »

The engine and assets are now available on GitHub: https://github.com/et1337/mkzebra

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

JctWood
Level 5
*****


programmer/jammer


View Profile WWW Email
« 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

@jctwood  |  programmer/jammer  |  jctwood.uk
Spidi
Level 0
**


View Profile Email
« Reply #10 on: July 26, 2015, 10:43:29 pm »

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" Roll Eyes creatively inspired the next time I fiddle with my framework code Wink.
Logged

et1337
Level 1
*



View Profile WWW
« Reply #11 on: July 27, 2015, 09:36:31 am »

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. Smiley 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: July 28, 2015, 06:52:53 am by et1337 » Logged

Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic