next »

[Schluppy]

I was hoping to see this at the utah indie games night last night but it wasn't there I would have made an effort to check it out even though I was bus with my game and wasn't able to realy make the rounds

Yeah, sorry about that! We were actually planning on bringing a couple of computers with our game on it; unfortunately, I lost track of time and was still moving features from my build into the main build when we had to leave. We'll definitely be bringing the game to the next meeting, though!

[Nicholas Lives]

Hey everyone! So this week we thought we'd do something kinda fun, and have a series of Shark Week-related devlog posts! Every other day this week (meaning today, Wednesday, and Friday) there will be a new post regarding information about how we're going about doing enemies in our game. So I guess technically it should be called "Enemy Week" in our case, but that's not as catchy.

Alrighty so in today's Shark Week update, I wanna tell you folks a bit about the Enemy Class System.

Inspired a bit from the way Left 4 Dead handles enemies, and the need to have consistent rules in our game regarding enemies, we came up with a Class System for our enemies.

The goals of the class system are to A. Help teach enemy rules to the players in an easily explainable way, and B. Make it easier to design enemies based on function over looks first. To give an example, here's an enemy I drew a while back back before the enemy class system was established:



Does it look unique? Sure, but what does it do? One may presume that the shell can't be attacked, but how on earth does this thing go about attacking players? Well after drawing it, I decided it would be a projectile enemy. Problem solved, yeah? Well no, not quite. Because in this case, I decided that he would shoot projectiles out of his mouth. But given how much space this guy has to turn his head, coupled with the fact that players can only shoot him in the same spot that the projectiles are coming from, makes this an oddly designed and potentially frustrating enemy. This comes from the fact that I decided to draw something cool BEFORE figuring out what it should do. The Enemy Class system helps us address this problem, and helps us as designers decide what role each class can play in the game, and how they can best be taken advantage of. And in this case, it helps form follow function.

So let me give you folks an example of how the class system works, and how it has helped streamline the design process. Here are a few example enemy "classes" in our game:

Biters - An enemy that swims near the sub and bites it when aggro-ed, causing a break or breaks in the sub's hull.

Grabbers - An enemy that swims toward the submarine when aggro-ed, and grabs onto the submarine, causing the submarine to move slightly slower due to the added weight. Cannot be removed via cannon, can be knocked off by bashing the sub against a nearby wall. It may also be logically removed via destruction of any invaders that act as its appendages.

Invaders - An enemy that invades the submarine's interior space. Whether it be via tentacles, barnacles, crabs, etc.

Chargers - An enemy that swims around the submarine when aggro-ed only to occasionally stop and build up a "charge" which, when unleashed, sends it charging like a rhino in the direction of the submarine. When a charger hits the submarine with its charge, it jolts the submarine as if the submarine had hit a rock wall, stunting the sub's movement momentarily.

Shooters - An enemy that shoots projectiles at the submarine when in range. (As a general rule, this range should be within the submarine pilot's view so that players can know ahead of time where the projectiles will be coming from.)

Sappers - An enemy that is attracted to the electric field that the submarine gives off when its shields are on. If the players' shields are on this enemy can "sap" the power from the submarine momentarily.

More class types are created as we progress and as we find interesting ways to intercept the players' progress and strategies on their voyages, but one of the cool things about this system is that it allows us to create new enemies quite easily by simply combining some of these class types together! For example, a charger-sapper combo would create an enemy that only starts to aggro and charge the submarine when the shields are on, but whose attacks would not only cause the sub to lose power, but would also jolt the sub's movement as a regular charger would. Similarly, a shooter-invader might be an enemy that shoots projectiles that cause invaders to appear on the sub's interior when hit. With function established, form can follow more easily. In the case of the shooter-invader combo, logically the projectiles could be eggs of some sort, that hatch inside the submarine once a projectile hits.



The HammerHead Shark: A typical Charger.

While this system may seem stupidly obvious to some more experienced designers, the extent to which this system has helped us streamline the enemy creation process should not go without mention. And more importantly, it forces you to really assess the rules in your game as they relate to enemies. For example, if we want any enemy to be able to grab the submarine,  we can't break the rule of being able to knock the enemy off the sub by bashing the sub into a nearby wall, but what we CAN do is increase the number of times one must bash into a wall before knocking the enemy off, and if the enemy in this case looks like its got a tougher skin, then it makes sense in the internal logic of our game, and no enemy should come off as "cheap" to the players so long as they are consistent with the game's internal logic and rules.

[Heterogeneous Misogynist]

Our enemies have been iterated upon many, many times. Each time we rewrite them, it’s for one of two reasons: 1) they are easily outwitted, or 2) they look hilarious. Our first version of sharks had the behavior of always pointing at the submarine, and either performing a built-in Gamemaker motion planning function called mp_potential_step, or performing a linear step to the other side of the submarine. This was just functional enough, and looked good enough that we actually kept enemies this way for about a year as we continued working on other features. At its worst in action, it could look like an invisible God-like child smashing a toy shark into the submarine.




As you can see from the gif, it’s normally not too bad. The biggest problem came in when the enemies could easily be avoided completely by going around a rock corner quickly. They’d get stuck swimming right into the rock and have no idea what to do, and this is simply because the motion planning functions in use were not meant to solve problems more complex than dodging cones in a driving course. We needed a better solution.


The next big rewrite of enemies came when we found A* pathfinding functions implemented right into Gamemaker. A* is significantly more capable of solving pathfinding problems, and can actually scale its complexity for better paths, but more processor load (and vise versa). Soon enough, we had some simple behaviors implemented on our enemies, including roaming, chasing, and charging. They could start attacking you, follow you through the rocks for a while, and if you could pilot yourself far enough away, they’d leave you alone and go back about their day-to-day business (of pathfinding to a random point really slowly). The downside is that this looked like garbage, and not even in a funny way as it had before. There wasn’t a particularly good way to get the sharks to angle in the direction they were swimming, and this is largely because our A* only works in 8 orthogonal directions. Our sharks would snap at 45 degree angles if not worse, and heavily lerping these angles could make their swimming behavior look even stranger! [I have no gif for this as the build has since been overwritten - my bad!]


The current iteration on enemies came when Nick proposed an object that would run in front of enemies and drop a trail of breadcrumbs for the enemies to follow. Now, an invisible object shaped exactly like the enemy it represents runs about 20 frames ahead of the real enemy and runs all of the actual behavior code, dropping a breadcrumb every 4 frames or so. The enemy only worries itself with getting to the next breadcrumb (with far less lerp on the angles) and keeps swimming toward it. This has smoothed our angling problem significantly, and in many cases looks pretty good. It still has its problems (i.e. the shark flips too often in tight quarters), but this is the most functional version so far.



The invisible navigators have been turned red to showcase thier behavior in a full-room view of our game. All 3 enemies are exhibiting simple "roaming" behaviors. The enemy swimming through the tighter rock formation on the lower portion of the screen is a good example of the significantly better pathfinding.


One final note I’d like to add is that this system also makes networking significantly easier. We are inherently already looking into the future with the breadcrumb system, meaning “dead reckoning” is nearly unnecessary when individual breadcrumb points can be sent over the network.


Radical.

 

[Schluppy]

As most of you already know, we at Deli Interactive take pride in how hyper-realistic We Need to go Deeper is. To quote one of the greatest people I know, "We Need to go Deeper is the closest thing anyone could ever get to a submarine simulator. The art, AI, and animation is simply too realistic" (me, 2014). For example: below I have two pictures, one of a real Great White Shark in its natural environment, and one of a shark in our game. Let's see if you can determine which is which.

OH MY GOD ARE THOSE TWO REAL SHARKS COMING OUT OF MY SCREE -- Hoo! Sorry about that, the illusion is often even too much for ME!


I was recently asked to extend this hyper-realism to our shark gore. Without hesitation, I boldly accepted this challenge. But what does it look like when a shark is hit by a torpedo? Do Xs replace its cold, dead eyes? Does it suddenly speak in tongues before bursting into flame? Do its hundreds of victims climb out of its now bursted rib cage? I needed to consult with an expert. Luckily, I happen to know a completely legitimate Marine Biologist.

His name is Dr. S. (I've always assumed the 'S' is for 'Shark'); you may know him for his roles in famous documentaries such as Megaladon: The Monster Shark That Lives, Voodoo Shark, and Darkness: Wrath Of Submarine. I asked if he had ever seen justice brought to a shark by method of torpedo. Naturally, he had. "The skin instantly disintegrates," he explained, "which exposes all of the random and mysterious chunks of meat and bone that comprise the shark." Following this, he gave me real footage of a shark being fed a delicious torpedo sandwich. I warn, this is somewhat graphic.

Stunning.

I immediately went to work on recreating this masterpiece. Hours, days, months -- I don't know how long I was sitting in front of my computer working on this. Probably an hour or so based on the time stamps. When my eyes had the pleasure of being exposed to the final product, tears were shed. Take a look:

Completely indistinguishable from the original video. The illusion was successfully maintained, and our hyper-realism remains persistent throughout the game.

You're welcome, world.

[Slader16]

Wow, just wow. I can't even tell the difference between the real life version and yours! 

[Nicholas Lives]

So starting this Screenshot Saturday, we decided it was about time we started showing off some of the music that one of our composers, Jake Lives, has been developing for us! Check out the preview below and let us know what ya'll think!

https://soundcloud.com/deli-interactive/mud-giants-lair?in=deli-interactive/sets/the-marvelous-music-of-we-need



EDIT: New and improved version of track uploaded, at our composer's insistence. It's good guys, check it out.

[Nicholas Lives]

Got a new track to share this week - this time it's the music for The Quadken boss- a four-limbed monstrosity that is also responsible for laying eggs containing a common in-game enemy, The Duopus. Check it out and see what ya'll are thinking of our composer's work!

https://soundcloud.com/deli-interactive/release-the-quadken

[Erik Schröder]

In my honest opinion, the music is pretty decent but it doesn't seem right for this game.

[gambrinous]

Keep up the fantastic work :D

[Nicholas Lives]

In my honest opinion, the music is pretty decent but it doesn't seem right for this game.

Really? Interesting. Suppose I'm not quite sure how you mean. Too dramatic? Not dramatic enough? I'd love to get more opinions on the music, as music has certainly been a hot topic as of late.

Keep up the fantastic work :D

Thanks! Saw your new game-play video by the way, your game is coming along quite nicely it seems! Can't wait to see/play more!

Also- I realize I forgot to post our halloween screen/mockup here, so here is our screenshot/mockup of a Barnacle Infestation! (I'm calling it a mix of the two since it is a real screenshot, but modified to test out how certain new assets will look in-game as a sort of proof-of-concept, such as the new water streams, wall barnacles, etc.)



Also, I've been working quite a bit on redoing our rock tiling system (yet again) in an attempt to both make our jobs designing levels easier, as well as trying to achieve an even better look for our game's environments. Here's a few samples!

Barnacle Waters -



Atlantic Waters -



Arctic Waters -



Stormy Waters -

[Erik Schröder]

The music is a bit too dramatic for a comic-looking game. Also, fully orchestral music along with pixelated graphics always make me uneasy. Not saying you must have chiptunes, but some synthetic elements would go along nicely.

For this game I believe the orchestral instruments should be the smaller part of the score. But it's your game and your call, of course.

[Nicholas Lives]

The Engine Overhaul

Hey folks, so some people may have noticed that we have somewhat recently changed our release date from Winter 2014 to a sort of vague estimation somewhere around Mid 2015. Well, we've been meaning to explain some of the reasons behind this decision, but honestly have been in such a heads-down development state that we haven't yet gotten the chance to. So here's a post explaining a bit about what's been going on with Deeper development.

In a nutshell, we ran into some size limitations with our previous engine Gamemaker Studio, that proved to cause a lot of trouble with the build, making it unstable. After working our butts off trying to optimize the game as much as we could without sacrificing what we considered essential elements, we decided it would be best if we switched to a new engine. We've run into several similar problems with the engine along the way, but these last problems (networking issues and data leaks among them) proved themselves to be insurmountable if we wanted to deliver the game as we envisioned it.

So we made the difficult decision to switch to Unity, which has a pretty steep learning curve. Basically, anything that was easy to do in Gamemaker winds up being pretty difficult in Unity, but the things that Gamemaker made difficult for us (like dynamic animation, which had to be coded by hand) Unity has nifty features like Mechanim to help streamline. Allowing us to significantly shrink the size of our game's memory, and thus allows room for a higher number of animations for our game world within our budget constraints. Additionally, because this requires a bit of an overhaul with the way some of our base systems work, we've been able to approach this new build with features that would otherwise take too much time to implement before in mind. Features like controller support and split screen game modes are now back on the table as we consider ways to implement them right from the start as we work on rebuilding the game's features and structures.

Needless to say, as with any engine switch, this switch will cost us some extra time initially, but we hope it will help us bring an even better product to everyone. As you can see from some of the above posts, this switch also certainly hasn't stopped us from overhauling assets and polishing the things we had before now that we've had experience testing out many of our game's features. So design work and other tasks are still in a very forward-moving direction as we work to rebuild what was there before but newer and shinier. Bottom line: we need more time, please don't hurt us.

[Nicholas Lives]

(April Fools 2015)

Here at Deli Interactive, we are always looking for ways in which we can make our games better. But with a world where bills have to be paid, and with only so much time to give ourselves to make good games, we sometimes have to seek alternative methods of funding. That’s why today, we’re proud to announce our newfound partnership with software publishing house NjoySoft!



NjoySoft, for those who aren’t already familiar, are responsible for helping publish iOS titles such as Five Night’s at Teddy’s – a popular iOS horror title in which you play as a security guard for a haunted Build-A-Bear-Workshop, MemeMatch, the match-3 RPG with a wacky sense of humor, and dozens more. We’re happy to be part of the NjoySoft family, and are even happier to announce some of the new exciting changes being made to We Need to Go Deeper at the request of our new publisher.

For starters, we have been working hard on a whole new look for our game! To make things a lot cleaner, smoother, and iOS friendly, we have completely revamped our game’s art to be better suited for a mobile platform, and so far we’re pretty proud of it! Check out these rad new screens:





We’ve also been making some changes to the game design itself; we realized that the perma-death mechanics and randomized level layouts, while cool, didn’t really suit a long-form multiplayer experience as we originally intended for. Instead, our new publisher suggested to us the idea of turning those very same mechanics to a much shorter, albeit still replayable experience, in the form of a single-player endless runner! This allows us to better focus our gameplay on really nailing the submarine driving mechanics, without having to worry about fiddling with things like power distribution, fixing leaks, etc. We’ve really narrowed the game down to its core experience, and we’ll wind up with a much stronger game for it.



Lastly, we’re also excited to announce that We Need to Go Deeper is now going to be absolutely FREE! That’s right, no need for laying down money upfront, you can get We Need to Go Deeper the day it comes out completely pro-bono. Instead of charging money for the base game, we decided it would be better to instead simply offer optional in-game rewards for some petty cash. In addition to being able to purchase new skins, hats, and sound effects for your submarine, you’ll also be able to boost your best runs to the max with BOOST FUEL™ packs, which have a variety of pricing options to suit you no matter what your financial situation.

We’re very excited to announce all of this, and we hope you are too! Watch this space for updates, and keep on rocking everybody!

[Nicholas Lives]

It's been a while since our last non-jokey update, so here's a good time to catch y'all up on what we've been up to as of late!
 
First of all, since I realized I failed to mention it earlier here, although a "test" run of it has been going on for some time now - but I've recently been live streaming development of We Need to Go Deeper on Twitch twice a week, on Mondays and Wednesdays at 12 pm MST with some special all-team streams occasionally going up on weekends around 7 pm MST! This is something we talked about doing for some time, so now's a good a time as any to let y'all know that you can join us on it live now! Here's the link: http://www.twitch.tv/purebredgentleman
 

 
It's all good fun, so I hope to see more of you folks there! Oh and I should also mention that the stream is a great place to share your work if you're an indie dev or hobbyist yourself (as most of you are, obviously). A lot of streams these days have rules against that sort of thing, but I wanted to make it a safe place for networking, sharing and feedback, so feel free to pop in and show off your stuff!
 

 
In other news, we recently entered into The Public Domain Jam 2 - a game jam centered around basing your game off of public domain works. And in our case, we crafted a game based around H.G. Well's The Time Machine! It's called Lair of the Morlocks and can be played and downloaded pro-bono; So give it a spin and be sure to leave some feedback. The game is more closely tied with We Need to Go Deeper's development than you might think, and all the feedback we get from it will absolutely be useful for us going into further Deeper development. In fact, I covered pretty much all of the reasons for why that is and how we justified the time spent doing the jam in this recent Gamasutra article, so check that out if you're curious.
 
Well this certainly has been quite the meaty update - we'll try to get back into the habit of posting more smaller updates more regularly so as always stay tuned and be sure to post feedback/comments/stuff! 

[Impmaster]

I followed your stream.

[Nicholas Lives]

I followed your stream.

Well hey thanks for that! I very much appreciate it. Hope to see ya around. I take it you're either flamelake or DrHemDem? EDIT: Ope! Scratch that just refreshed the followers page. Indeed I assume you must be Impmaster because you're Impmaster here. Sorry for the confusion. Thanks again though by the way!

[Nicholas Lives]

Caves, Caves, Caves!

Well, so much for more frequent smaller updates. Oh well- So for the last few weeks, probably the last month actually, my focus has been on totally rejiggering and reworking our expedition caves. For our Gamemaker build, caves were probably the most overlooked aspect of our game. For one, unlike the outside areas for sub exploration, caves weren't procedurally generated at all. Instead we would just select from a variety of pre-built caves, and spawn enemies on the fly. We wanted to eventually do something more than that, but never found the time. Now that we're rebuilding everything from scratch anyway in Unity, we figured one of the features we ought to try tackling is true procedural generation for our cave systems, at least one that would be comparable to the system we had for our outside areas. Not to mention make caves more fun to explore, make ground-based enemies more fun to fight, and enemy and treasure placement more randomized and sensible.

Well, having been working on nothing but caves for the past while, I can definitely say with confidence that caves have been vastly improved on!


Screenshot of our current caves, this one being a Barnacle infested cave.

For starters, we tried making the flow of a cave expedition feel more organic and cave-like by adding new angled tiles so that hills and valleys could be created without looking too blocky or require a lot of jumping to navigate. We also opted for adding climbable areas around caves, as despite our 2D perspective, platforming and jumping was never really planned to be a huge part of our game. We're not trying to be Spelunky here, and since players navigate through the submarine mostly through ladders, we figured adding them to caves would make caves fit in better with the rest of the game.

To add variety we also added in a few new destructable cave pieces, such as destructable thinned rock pillars and stalagtites; along with moveable physics objects such as boulders. These additional physics objects helped to break up the flow of caves and make exploring them more rewarding. Using the jam game to code and implement these ideas also gave us a nice testing environment to see what kinds of designs for caves would be most engaging.


This is the mockup I made early on to pitch the new cave ideas, although after testing in Morlocks we discovered that making the ceiling rocks intractable wasn't such a hot idea, so we instead created non interactable cave decorations to create visual variety.


During all this, we've also been working on making cave enemies more varied, more interesting, and more fair to fight. Back in the Gamemaker build the only cave enemy we created was the crab, who back then would spawn in a random size at a random time, and rush the players. These create some fun and hectic moments for players, but because the way they damaged the players was by merely touching them, it sometimes felt unfair because there was no way to escape the attack, especially for some of the faster ones.

We decided to try and rebalance the way combat worked with crabs and other player-sized enemies by giving them proper animation states via mecanim. Now instead of hurting the players merely by touching them, crabs will scuttle towards players and once in range, stop for a moment to try and bite them. The attack doesn't register unless the player is caught within biting range by the time the bite happens, so this gives the players some time to escape and ensures that those who are paying attention will rarely if ever take damage from them. Attacking in large numbers still gives the crabs some advantage of course, but this small change made combat feel so much more believable and fair.



Cave enemy AI as a whole also got a much needed boost, as now instead of just bum-rushing players full-hog from the get-go, enemies now only start to chase when they catch sight of a player, and can chase them for a period of time after losing them which we can control via Inspector values.

Now, on to what should probably be the real meat of this post, the actual cave generation. Taking a tip from Spelunky, we crafted a system made from a grid of potential pre-built cave "chunks" which are hand made in categories. Categories of "MiddleChunk," which are always guaranteed a left and right exit "Right Edge Chunk," which is guaranteed a left exit, "Left Edge Chunk" which is guaranteed a right exit, "Up Chunk" which is guaranteed a left, right and top exit, and "Down Chunk" which is guaranteed a left, right, and bottom exit. When a cave is created, all tiles select from an array of appropriate chunks. Middle regions all pick from middle chunks, right edges from right chunks, and so on. After a general cave is created, it is decided whether or not there will be a second floor to the cave. If so, a random middle chunk section is decided to be replaced with a random Down Chunk and the tile immediately below it becomes an Up Chunk, to create a path to the second floor. A simple system, but one that can create a wide variety of cave types with the addition of certain settings. Over the time I've been creating this system, many inspector values have been added that can alter the caves in meaningful ways. "Claustraphobic" and "Open" settings, choose from a subset of random chunks that are designated as claustraphobic style cave chunks, or open style, and if these options are chosen, different types of caves can be generated appropriately. We also recently introduced different grid sizes to control the width of caves, and the option for having one to two floor caves. Here's a gif showing off generation with all these settings:

 


And instead of populating these caves on the fly, we have instead opted for populating them at the start, so that enemies and treasures are guaranteed to appear at pre-designated spawn points for each cave chunk. Population then works by creating a number of enemies and treasures based on a percentage of available spawn points, to ensure that the enemy and treasure ratio is always the same, but always scales to cave size. This percentage multiplier can also be changed on the fly, to allow our AI DM to decide whether it wants the cave to be more or less populated. This way, caves still feel lived-in but we can still change them based on player performance.

And that's about it for caves! There's plenty more to discuss when it comes to our new enemies, random treasure loot, and modular enemy code, buuuut I've probably stretched this post out longer than necessary already. I should also mention that this is mostly just been what I've personally been doing. Soon enough I hope we'll be able to start posting about our new water physics, new exterior areas, and new submarine design, but it'll all happen in due time I suppose. I was really hoping to start writing more short-form updates on a more regular basis, but time really got away from me with this cave stuff. If you have any questions, suggestions or comments as always feel free to leave em! Trying to be more vocal these days.

[grandslam]

By populating your caves early instead of on the fly does that ever create too easy of areas?

[Nicholas Lives]

By populating your caves early instead of on the fly does that ever create too easy of areas?

Good question! It does indeed mean that we can't (or perhaps shouldn't to be consistent) just toss more enemies at the players when things are looking too easy but instead we make up for it by ensuring the next cave they visit will be more challenging. This is more or less the way the Ratchet and Clank games managed their difficulty, and it seemed like it could be a good fit for our game to make caves enemy encounters feel more organic and natural yet still be able to alter difficulty for players. Difficulty in this case is mostly something we can alter with the population multiplier, by increasing the number of enemies that spawns in relation to how many spawn zones are in the map. Although in the interest of transparency, all of this has been tested so far with only one player while networking is being worked on, so time will tell how difficult or easy caves will be with a full team of four players but it's something we plan on testing soon.

[SunWuKong]

Love your dev log. I check back on it to see the progress and it's always very inspirational. Great work here!

-Tim