News/Devlog

Deli Interactive's development and news blog keeps YOU up to date on all of Deli Interactive's latest developments and news-related things! 

view:  full / summary

Shark Week Update 3 - Sharks, Gore, and the Meaning of Life

Posted by Ryan Farr on August 15, 2014 at 9:45 PM Comments comments (0)



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.

Shark Week Update 2 - Enemy Behavior

Posted by JordanFarr on August 13, 2014 at 7:40 PM Comments comments (0)


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.

 


Shark Week Update 1 - Enemy Classes

Posted by [email protected] on August 11, 2014 at 1:35 PM Comments comments (0)

 

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.


News Flash! You're Dead, Mate!

Posted by [email protected] on July 26, 2014 at 5:50 PM Comments comments (1)


 

Hey ya'll, haven't posted in a while I know; we've all been in pretty heads-down style crunch for a while now in preparation for a public demo, but I was working on this particular feature this past week and thought it should be interesting enough to show off and talk about a little bit.

 

Rightio - so this week I've been working on our game's new stats screen. For comparison, when the crew would die in our game, our stats screen up until now looked like this:


 


This worked fine for early testing when all we needed was for players to understand that their stats were being tracked- but as our game evolved, this simplistic and rather boring stats screen never evolved with it. So this week we decided we needed a stats screen that was more fun, more useful, and would actually play a part in the context of our in-game universe. So now when you die in We Need to Go Deeper, you are first presented with a splash screen that looks like this:



Introducing the Voyager's Gazette! Everytime the players die, they are presented a peak at the in-world adventurer-based newspaper, informing them of not only their own demise in the game world, but of other events going on as well. Like everything else in our game, the stories in the paper are randomized, so only through several deaths and playthroughs will players be able to get a glimpse at all of the worldly adventuring news.

Some stories are more humorous fluff, but others will hint at some of the mysteries surrounding The Living Infinite, letting players piece together small bits of information as a sort of post-mortem reward. The phrase "Submarine" in the headline there will also be replaced in-game by whatever the crew decided to name their ship, and with every paper the date moves forward, showing players that the in-game world is always in a progressive state.

After getting a glimpse at the headlines, clicking once on this screen will bring up scraps from other parts of the newspaper, showcasing to the players relevant information regarding their travels as well as each player's personal obituary, which contains their individual accomplishments throughout the trip.



The colored names you see there are the titles players are awarded based on their performance in the game. So if you were say, the kind of player who hoards treasure, doesn't contribute much in combat, and are generally being a complete nuisance, you are awarded the title of "Biggest Scoundrel" post mortem. The stats and titles on this particular screenshot are all mock-up placeholder variables for now, as well as the character portraits themselves, but soon they will be individualized proper.



Clicking again will bring up this screen - notifications of any items that were unlocked during your playthrough, and letting you know that they are now available for purchase (via in-game gold that carries over between playthroughs) in the in-game catalog. (I should note that this screenshot is a mock-up since we don't yet have the in-game catalog set up proper yet and so there's no current need to display these types of messages to players just yet.)



And finally, once you've clicked through any/all item unlock messages, you will be taken to this final screen where you can choose to either dive again into The Living Infinite with the same connections (meaning you won't have to reconnect to your friends again when you want to go another round) or quit to the main menu. Putting together these menus has been surprisingly fun and we can't wait to see what ya'll think of the format!

We Need to Go Deeper has been Greenlit!

Posted by [email protected] on June 11, 2014 at 9:50 PM Comments comments (0)

So a little messaged popped up in our inbox today, looking like this: 


And that was that! Looks like we did it, everybody! And in just 35 days no less! Perhaps sometime in the future we will put up some sort of Greenlight post-mortem for those who are interested in doing the same, but until then, back to game development! Thanks again for all those who supported us, and especially for those websites that chose to cover us and respond to our emails. Thanks to the retweeters, the sharers, the followers, and those who simply told their friends. Every vote counted, and you guys are awesome for getting us to where we are today.

Now it's time for us to give back come winter when we can finally release the game to you! Make sure to follow us on our Twitter: https://twitter.com/DeliInteractive and Facebook: https://www.facebook.com/weneedtogodeepergame ;so you'll know when that day comes, and keep an eye out for when we release new trailers, screenshots, and info! There's still much more game to show off, and we're excited for what lies ahead. 


Rss_feed