Announcing “In Case Of Emergency, Release Raptor”

Did you know?  We’re making a velociraptor game!  Our first 3D game, in fact.  The first of many.

In a nutshell: you get to be a velociraptor, fight robots, and navigate procedural levels.

I’ve been stalling on releasing videos or screenshots for weeks now, and I explained in lots of detail recently what was going on with that.  All of this has been on our forums, though, which is lower-visibility than the blog and social media, so that’s rather short-sighted of me.

After all, obscurity is the big killer. I’d rather show too much too early and get blasted for a few things that are incomplete; waiting until things are polished to a sheen and then not having time for anyone to notice is worse.


Unity Asset Store, The Right Way

Let’s get this out of the way now.  Yes, we’re using the unity asset store for a variety of things.  Does that mean we’re not doing any coding, modeling, animation, texturing, or whatever on our own?   No.  I hate asset store flippers as much as you do.

Also, when you get someone who just buys willy-nilly regardless of style and puts cartoon tigers in a “realistic” (but poorly-textured) town, chased by poorly-animated higher-textured models… yeah, I have a problem with that, too.  It shows a real lack of artistry.

So what are we doing, and why am I not ashamed of it?  (Do I sound defensive?  I guess I am.  Sorry about that.)

  1. We’re using models, textures, animations from the asset store.
    1. But we’re also greatly improving a number of those.
    2. And we’re making sure they actually make sense together.
    3. And we’re doing unique ones of our own.
  2. We’re using shaders and code from the asset store.
    1. But I’m going through with a scalpel and really editing the heck out of these to maximize performance, tune them to our specific needs, etc.
    2. In a lot of cases I’m buying several different solutions to the same problem, studying each one, learning from them, and then merging the best parts of them together.  Or in a few cases just writing my own from scratch after seeing the various pros and cons.
    3. Most of these sorts of assets tend to have a lot to love, and then some other bits to love less, and having the know-how to go in and resolve those things is important.  Otherwise you wind up with an unoptimized hot mess.
    4. It’s also worth noting that the whole “not invented here, so I’ll reinvent the wheel” attitude that some developers have can lead to unoptimized, poorly-tested hot messes, too.  So taking a mix of the two approaches and just using common sense about it is by far the best technique in my opinion.
    5. In general if we buy some code, I’m expecting to have to change a minimum of 5% of it if it’s just absolutely pristine (by general-purpose-asset standards), and potentially as much as 80% of it if it’s a weaker asset.  Why buy it, then?  Because that 20% can be darn clever and something I’d never have thought of.  Each programmer has their special strengths.

Deep Breath On My Part — Our First Screenshot

With all that said, here’s our first screenshot:


I’ll save you the time of sourcing assets from that shot.  The Raptor is this one, by 3dFoin.  The environment that is shown is the exact demo scene from SciFi Industrial Level Kit by Ximo Catala.

The fact that this is in the demo scene from that set is the big reason I’ve been avoiding showing screenshots yet.  We’re going to be making our own procedural levels, and will have assets of our own as well as those from a number of asset store assets, so it pains me to show you this in a demo environment that might give the wrong impression.

So it goes.  Even in that demo scene, though, a ton has been changed.  The lights have been reworked substantially in order to reduce the draw count a crazy amount.  The materials have been tuned a lot, and made to work well in deferred rendering, linear lighting, and with the specific post-processing effects we’re using.  I’m not done hand-tuning all that yet, but it’s coming along well.  The colliders and physics for all objects have been redone from scratch as well, and the particle fields that are shown here are something we’ll be replacing with something more draw-call-efficient.  The walls are all things we’re keeping the textures from, but making our own models for (lower poly, more flexible, a variety of other improvements).  We’re about 30% of the way done with the new walls, but those aren’t shown here.

Raptor Diary: April 14th, 2016

This is something I’m going to start doing, so people can follow development.  It won’t be every day, but I’ll try to keep it pretty frequent.  I want to give you some good video, but I really want to have our own procedural environments before I do that.

Procedural Generation For Levels

I’ve decided not to work on that today or yesterday, because I want to get the individual pieces working better. ProcGen is already pretty decent in the main, thanks to DunGen as a base, but there is a LOT of customization and extension I need to make to what is already a really flexible product.

Incidentally, I spent loads of time a month or so back looking at various dungeon generator and city generator components, and bought a number of them to experiment in their code, and this is the only one I was really that happy with.

Good grief please understand this is a debugging type of shot from the procgen:


I figure it’s fun to show you before and after shots.  That’s the before, and I’ll show you the after shot next week or the week after.

Raptor Animations

Blue is working away on these, for the moment mostly using Skele. That said, she’s running into some severe limitations with that in terms of trying to make realistic animations for walk cycles in particular. I don’t like the prefab animations that came with the raptor model we purchased, so we’ve been working on redoing absolutely all of them. We started with some new attacks (bite, kick, tail swipe), and have a few others to do (hand claw swipe), and a few that are partially done (crouch, lunge).

The interesting thing has been using animation layers and really blending all of these together, etc. For things like the bites, we actually have 6 separate bite animations and it chooses between them at random. The hitbox of the raptor’s head is very precise (although exaggerated), so it moves as you’d expect with how the motion of the animation moves. Very cool. Same deal with the tail swipe, although I have the hitboxes extendfar below the tail in this case, because otherwise you so easily miss on-the-ground targets with your swipe.


The above shows some of the hitboxes, which toggle on and off for various reasons at various points.  The physics layers setup that I’ve designed is super cool, if I do say so.  Bloody efficient and effective.  Bear in mind that’s obviously another test scene shot, and also a Scene View from the unity editor, rather than one with proper effects, etc.

At any rate, Blue was having trouble getting the animations to import properly into Maya LT a few weeks ago, but she’s going to return to that and experiment some more today, since she’s having limitation issues with Skele. After that hopefully we’ll have a new run and walk animation set, a longer idle animation (what is there now is good, but repeats after about 5 seconds).

Then adding more attack variants, and making the existing elements look better, blend from state to state better, and so on.  It’s a lengthy process to animate a character like this so fully and make them feel awesome and organic rather than like some brick that you steer around the level. ;)

Logo?  What Logo?

Yeah, no logo yet.  Picture something awesome right here for the logo.  Man it’s epic, isn’t it? ;)  Or at least passable.

Sound Effects

I haven’t started work on this yet, but I’m really itching to.  I have huuuuuge sound libraries at this point (well over 100k sounds), and a lot of great animal sounds in them, among other things.  Not only am I excited about putting in great sound for the raptor, but I’m also looking forward to really having detailed sound design on movable objects that collide with one another, too.  When the raptor kicks a box over and it slides along the floor, it should make a noise, etc.



All of the effects that make these scenes look so great are achieved with Screen Space Reflections (SSR) by PlawiusScion – Filmic Post Processing by Jove Software (with some customization on this one, and mainly focused on depth of field and then using a LUT for color correction), the Blockbuster 2 LUT from the Amplify LUT Pack (but then heavily modified to get my exact desired effect), Amplify Bloom with a lot of painstaking tuning, Horizon Based Ambient Occlusion by Michaël Jimenez with surprisingly little required tuning (same as the SSR solution), and then — for now — DLAA antialiasing from unity themselves.

I’ve experimented with about 8 other products, customized many of them, profiled them for performance, and so on, iteratively for the last month or so.  The above is the result of that.

You’ll notice that the lighting isn’t right on that scene directly above, though, because it’s super dark in that one big room.  That was partly because the original demo scene was making use of a directional light and then shadow casters, which I didn’t like at all.  So I’m working entirely off of point and spot lights, and since it’s a demo scene I just didn’t bother to re-light the center of that room properly.  A lot of the lighting in these scenes is non-ideal at the moment because they aren’t in levels that have been hand-crafted for the post-processing I’m using.

They’re close to what I want, but the final lighting will look better.  And perform better — though I will say, I’ve already quadrupled the frame rate (currently to 150fps on average on my 980M) in the demo scene, which isn’t really optimized for my needs at all.



One of my big goals has been to have really fun destruction in this game.  Right now you can kick over crates and barrels and so forth and that can be great fun.  But I want to be able to break them apart as well, which will lead into being able to do the same sort of thing to enemies, too.  So that’s the current task I’m working on.

It’s trickier than you might think to do it right, in a way that is efficient and meets all my requirements.  I’m having to pull bits from three different destruction tools, as well as coding quite a bit myself.

Exploder by Reindeer Games is really cool, and it handles all types of meshes really well.  However, it only supports completely shattering objects, not chipping off pieces.  Still, there’s a lot in there in the pooling department in particular that I like.  Originally I was going to pull that code directly and adapt it, but that was proving to be too much of a pain and so instead I’m just recreating my own version.

DestroyIt – Destruction System by ModelShark Studio is excellent in so many respects, and I learned a lot from studying their pooling, too.  They also made an excellent shader for progressive damage masks, which I may or may not use (it may be redundant in my case).  The big issue here is that they also don’t really support partial object destruction unless they are separate GameObjects, and they don’t have their own fracture algorithms in place, unlike the other solutions.  But I learned a lot here.

To my surprise, the core of what I’m doing actually comes from DinoFracture – A Dynamic Fracture Library by Fat Cat Games.  At a glance this seems almost abandoned as a project, and not well supported.  It also does no pooling of fragments at all, which is super annoying.  There are some other annoyances and messiness, too, and their presentation on the asset store is the least professional.  That said, they have a very fast fracture algorithm, and support partial destruction of objects, and have a lot of cleverness going on in there.  And I don’t really need support.  So I took the plunge, and their code is actually really good and clean.  Some of it is in a dll, which bugs me, but I’ll live.

I’m going to spend the rest of my day coding and testing custom pooling for DinoFracture, combining and stripping a number of their scripts for efficiency, and then implementing that on the various objects.  Hopefully I can get all of that done today, but realistically it might take me into tomorrow.


Other Object Assets

After I get things working well with destruction, then it’s on to getting some more assets set up.  The ones I’ve chosen to work with next are Lab interior pack by Silver, and Sci Fi PBR Level Kit / Space Station / Modular Interior Kit by PM assets.

The former of those is meant to be a different level of the complex that the raptor is in during the first areas of the game, so the style is a bit different than the industrial areas on purpose.  However, the overall feel of it will be brought MUCH closer to the visual style of what we have so far before it’s in the game “for real.”

The second asset pack I got mostly for some of the objects, which again will need some altering on their textures and so forth to fully fit, but they have some great models in there.

I’m then going to be pulling in Abandoned Factory by Modular 3D, which you probably think doesn’t fit the visual style of this game at all.  You’re absolutely right! :)  But that’s mostly a texturing thing, and I look forward to seeing if you can even spot these assets in the final levels once we’re done with them.  Martian Base by Illia is up next after that, and overall needs the fewest changes, although the entire color scheme is going to be shifted super heavily.  It will make for excellent accents in the current industrial areas, as well as a great transition to the lab areas.

All the processing of those four other packages will take a solid two or three days for me, and then even longer for Blue when it comes to the new models she creates using their textures, etc, so I won’t be trying to do full integration from them right at the start, not by a long shot.  There’s still at least a week of work left the existing industrial set on Blue’s end, for goodness sake.  So I’ll just pulling the most essential bits to start with.


The above is the raptor in the Lab interior pack demo scene without any alterations made yet.  As you can probably tell, it’s going to need a lot of work — but then again, for being just a drop-in so far it actually isn’t THAT bad.  The post processing helps a lot in tying things together.  Still would make me absolutely cringe to see it like this in the final game, though.


After I get the new assets fixed up, or at least some of them, then I’ll have enough to really start getting into the first rudimentary dungeons with DunGen, and then start changing the code of that around a lot as much as need be.  Then comes the first video of the game in action, the sound effects, then enemies, etc.


Oh right!  Yeah, I’ve hardly mentioned those.  You fight against robots and other machines.  Some big, some small.  Some are more humanoid and you can pounce on them, whereas others are much larger and you can dismantle them piece-by-piece.  I’m very excited about it, and I’ve been doing a lot of prep work for that.

But one thing at a time.  My big priorities first have been making the raptor itself feel awesome to control, making it have environment traversal that is fun, getting the environments to be something we can procedurally create in an efficient way, and then the underlying destruction framework that is for both props as well as enemies.  Full enemy design derives from those other areas in the case of this game.

Stay tuned — and thanks for reading!

Official forum post on this topic.



You can leave a response, or trackback from your own site.

11 Responses to “Announcing “In Case Of Emergency, Release Raptor””

  1. VoodooDog says:

    how about u release Stars Beyond Reach first?

    • Chris Park says:

      Two completely different designers/programmers working on these, at the moment. We did lose most of our staff, but in terms of the structure of who is left we don’t need both of us on either project. Stars Beyond Reach is currently in progress independently of this.

      Whether or not SBR is ultimately feasible to release in a way we are happy with — for reasons of having a prototype that we feel like is what we want in a not-just-on-paper sense, not budget or time constraints — is yet to be determined. I honestly don’t know if that game will wind up being finished or not, but either way it isn’t impacted by the raptor game or any of our other titles.

      I set aside SBR because I was absolutely stuck on it, and burned out with it. After months off and working on Starward Rogue, I found nothing had changed. Yet more months later, working on the raptor game, still nothing has changed — I don’t have ideas on how to fix the issues we had with SBR during the private alpha, and I am still extremely worn out on that project. Believe me, I wish it wasn’t so — I invested over $400k of my own money into it.

      Anyhow, after Starward Rogue came out, Keith has taken up the mantle of SBR and has been working steadily on figuring out if he can make something cool with it. He’s gone through a number of prototypes that sounded good on paper but turned out not to be all that fun, same as I did. He seems to kind of be onto something now, but it depends on how exactly all that comes together (or fails to come together) with some last systems he’s coding right now.

      If SBR doesn’t gel in the next week or two, then most likely it will be put on ice indefinitely, since neither Keith nor I would know what to do with it. Which would be a huge shame, but it may happen. IF that does happen, then Keith STILL won’t be working on the raptor game, but rather will be working on a different strategy title.

      In essence, once doesn’t affect the other. We’ve switched away from having just one pipeline to instead having two, even though we have a smaller team. Since all of the non-programming/design work for SBR was completed last year, that makes this possible.

      • Bormac says:

        Putting it on ice forever after spending that much money on it seems awfully wasteful.
        Perhaps putting out the version you had the most fun with would be a better expenditure of your time, and what doesn’t work based on player feedback you can tinker with from there, rather than trying to DNF it by making it the “perfect game” because there is no perfect game, what you think sucks, other people might really enjoy. If you are unsure you could always put it as a pay to play beta test sort of deal, open beta preorders for the game? That would invite more feedback from the player base. But really don’t just let it become vaporware it looks good to me and if you had more eyes on it maybe you could make it look good to you, too.

        • Chris Park says:

          Yep, there are a lot of ways to look at something like this. One way is certainly to look at all that past money and consider what a waste it would be not to release it.

          Another way is to look at it in terms of what it will cost to release it and then support it, and if that would be even a revenue-positive thing on its own. Right now I don’t know. If we get in the habit of knowingly releasing products we don’t believe in, that really harms our credibility in the market, too.

          Chasing perfection is definitely a fool’s errand. That said, there’s a certain bar of “this is fun, even though it’s not perfect” that has to be met. We’ve never hit that point with all the aspects of this game. Some of them, sure — but then that would leave some gaping holes in the expected gameplay.

          With Valley 1, we released it and reception was mixed. We felt it could be better, and poured 3 more months of full time work into it. Salsa tapered off and that wound up being a net negative for us. I don’t want to get into that again.

          For me, personally, I’m just also burned out on the game still. It’s hard and I don’t know what to do with it, and I spent a year of my life plus a lot of money on it, and I’m frustrated with myself for not being able to figure it out and a bit heartbroken that this awesome thing I had planned turned out to be so cursed. I really have a strong aversion to go G back into those waters right now. Keith is trying to figure out things in his own distinct way, and if he does then I’ll be overjoyed and very proud of him, but still won’t want much to do with developing it (though I’ll happily play it). I’ve given that particular baby up for adoption.

          Again speaking personally, if we’re just looking at money and nothing else, the fact that I spent x amount on SBR is irrelevant. Sunk cost fallacy. Taking our current staff and looking at what we can do, there are easier ways to make the money we need in order to stay alive. The raptor game is one of them, and what’s more I go to work all excited and happy each day to work on that one. It’s a different kind of challenging work, but I’m really happy about that.

          I don’t know what to make of SBR, but I basically see a few paths:
          1. Keith finishes figuring it out and things go an ideal way and we release.
          2. Keith finds that his final prototype is still lacking, sets it aside, and the project is on ice until who knows when.
          3. Keith sets it aside as above, but then someone else with fresh ideas is brought in and revitalizes it.
          4. Keith sets it aside but then we make it some sort of community project, or even some sort of open source donationware thing, or who knows.

          I’m really not sure. I think I’ve contributed some really cool things into the area of that game, but I don’t personally have what it takes to turn it into a final product now. That’s tough to say.

          • gnodab says:

            You know, I never thought I’d say it, but maybe Early Access/an open beta would benefit SBR?
            As much as I liked SR and am looking forward to Raptor, I can’t help but feel they are mere distractions, while we wait for SBR. I wasn’t this excited for a game in a long time. Maybe your perception of the game is just so tainted by burning out on it that you exaggerate its flaws and getting a lot of outside perspectives could recalibrate your own? Or maybe I am just unwilling to accept that the stars are beyond reach? :(

            Also I still wish you could get Tidalis and Bionic Dues on Android, they seem perfect for it.

          • Chris Park says:

            Cheers — it’s a possibility. The main thing is that the game has never been in a finished, “able to really play all the way through” state. We’ve had the military and citybuilding aspects there, but getting in fun and engaging trade and politics or whatnot for non-military interactions has never passed the prototype stage. Each version of that we did was always underwhelming enough that people just kept staying military.

            There’s a lot about the game I love, but I’m not the one to work on it anymore. If Keith feels like he can make it work, then we’ll go ahead with it. If not… then perhaps there’s someone else who might want to take up the mantle of this particular game, we’ll see. Either way, though I’ve contributed a lot to this game (as have a lot of other people), I can’t think of anything more to add to it at this point from my perspective. Someone else would look at it a different way, I’m sure.

            The problem with Early Access is that once we do that sort of thing, we’ve taken your money and are committed to it. So we can’t go “oh, nevermind, that actually was a bad idea and we’ll stop development now to avoid bleeding money while we finish something unsatisfactory.” We just have to instead rush it out as fast as possible to get it to a state that we can call done, to cut our losses while at the same time hopefully minimizing fallout in our reputation with you. You’ve seen other developers do this, and it’s not because they are bad people — it’s the situation they put themselves in, accidentally. I don’t want to put myself in that situation.

            Same sort of deal with Android and iOS development. If the right developer or partner comes along who wants to do those sorts of ports, then I’d certainly be open to that. But I don’t own any Android devices at the moment, the fragmentation of that market is huge, piracy is rampant, the market is dominated by free to play games, etc, etc. iOS has huge discoverability problems and is dominated by free to play games, and is getting more fragmented with time as more screen aspect ratios have been released, etc. Those are tough markets that I don’t have experience in, and moving to them doesn’t sound fun or profitable.

  2. […] Announcing “In Case Of Emergency, Release Raptor” […]

  3. […] Announcing “In Case Of Emergency, Release Raptor” […]

  4. Freykin says:

    On using code assets, I completely understand wanting to use them. I use a code library called Juce all the time at work, and usually when I think of something that I’d like to do with variables or user interfaces, it’s either already there or implemented soon after. No point in making my own text buttons when someone else has already made ones that do what I usually want, and are easy to derive from if I want something more custom.

    This looks like a neat concept! Looking forward to following the development.

  5. akeley says:

    Hearing about SBR likely fizzling out sure is disappointing. However what continues to impress me is your honesty, transparency and immediate communication regarding your various projects.

    Given how many other indies do not adhere to these simple values and instead put up smokescreens, obfuscate or just lie/disappear it is sure something worth mentioning and the second main reason I like your company (first being the games obviously :)

    Good luck with the Raptor game, hope it will turn out well and looking forward to all future projects. Stay procedural/rogue-ish and original above all ;)

    • Chris Park says:

      Thank you very much, it really does mean a lot. And we are still hopeful about SBR, but it’s in no way certain for sure.

Leave a Reply