Never Go Home - A Pixel 2d/3d Platforming SciFi Horror Game.

*Fifty years ago, Oyanumi Corporation’s research vessel, the Aeternum disappeared with out a trace, during a test of their new Dispatar Jump Drive.

Fifty years later, a radio signal matching terrestrial origins were detected.

The signal is that of an Oyanumi Distress Beacon.

You, the Captain of the converted hauler-now-frigate Geryon, have been contracted by Oyanumi Corporation to determine the origin of the signal and uncover the truth behind the Aeternum Incident.

Can you discover the truth?

Can you survive the horrors of space?

Will you make it back home?*

Never Go Home, is a re-imaging and sequel to Goodnight Game’s mobile adventure game NGH: Never Go Home.

This will be a hybrid game combining platforming, arcade space flight, and 2.5d mechanics. The player will

*Explore a number of handcrafted and procedurally generated worlds
*Upgrade your ship and crew to survive the horrors that you’ll face
*Accept side missions, ranging from search and rescue to interrogation
*Engage in a semi linear narrative, where the lines are not always clear
*Manage the sanity of your crew and hope theyll survive to fight another day

Just to name a few things. .

This is our, Goodnight Games first big foray into the 3d world, and to PC/Linux/Mac. Unreal Engine has allowed us to develop this project with the awesome power of blueprint, and create something that is actually viable. Considering that we were all new to Unreal Engine, and for half of 16 months we were learning as we developed, I am quite proud of the direction we have gone.

Of course, things have been redone, removed, and reiterated upon, but we will touch upon those things in the coming weeks.

Any feedback, suggestions, musings, or just a general hello are all welcomed!

You can check out some of our earlier blogs here (though we will be cross posting in the future):

You can check out our other projects here:

You can check out our earlier streams here:

And you can keep up with our shenanigans at:

Hello everyone! We’ve updated our indieDB going over some general development things, and touching on art, our current level mechanics, and enemy behaviors.

You can read more here:

If you sign up for our newsletter, you can be kept up to date on all the going ons and general shenanigans at Goodnight.

Also, dont hesitate to give us any feedback, suggestions, recommendations, etc, as we really look forward to hearing back from the Unreal community!

Pixel = trash

Could you elaborate on why you believe that to be the case?

Hello everyone! I’ve a new update detailing how we go about level design. I cover things such as our snap cell system, lifts, and some other things.




If guys have any questions dont hesitate to ask!

Hello everyone, I’ve a new update for all of you!

We’ve been working hard on the level design of the platforming portion of our game.

**As mentioned before, most platforming levels will have a portion of their maps that may be generated. **For those sections to exist, it relies on a number of conditional attributes that are present, including level type, size, space/planet, and player action. The most important one, in this development phase is player action. Some of you may be confused by that statement, so let me explain.

A player may have a number of objectives when they get to the platforming portion, which includes accessing locked doors. These locked doors serve as buffers between the handcrafted and generated sections. Therefore, when the player unlocks one of these doors, it initiates the level generator and creates that section. However, there are some problems with this approach. One of them being, if we tied such a function to the doors directly, we would need increase wait time for the doors to open, and the generator wouldn’t have enough time over all to finish. Thats an immersions breaker through and through.


The solution?

Stagger the generation, and have the first section generate the moment you get to the platforming section. Example: Planet A has the main section, and four locked doors, for sections A1 - A4. The player gets to the planet by rift gate, and in the background, section A1 generates. This is before the player unlocks the A1 door. When the player does get access to A1 and unlocks it, section A2 generates, so on and so forth. This staggered approach means we can afford those extra few seconds to ensure there are no mishaps and it doesn’t fail a majority of the time.

The generator itself was a hurdle. I mean this is the fourth iteration of it! The previous one worked, but with so much progress having been made in other areas, and it’s progress having become stagnant, it ultimately ceased to be operational and was incredibly outdated. We had a decision to make: attempt to salvage what we had or start from scratch.


With no time to waste, we considered a “why not both” approach. One of us, will have until the business week to see if we can salvage anything, while the other will devise a new system that is simpler and modular. In the end we opted to start from scratch. The old one was too far gone to waste any more man-hours in trying to make it work. But, this was not all a lost, because we were able to devise some similar utilizing what we learned from the previous setup. Iterative design. Love it, hate it, it’s useful.

**The new level generator is constructed in a way that breaks down the entire process into a set of custom events and a series of functions, attached to a sequence. The main custom events are: **

*1. Spawning the initial cell *
*2. Spawning level cells *
*3. Spawning the level rooms *
*4. Check overlaps *
5. Branching The functions are rather straight forward, with things like, “get previous cell,” or “check overlap.”

The goal is to keep the process simple, efficient, optimized, and easily readable should the main designer(s) not be available.

So here’s a breakdown of the generator. At the start some variables are set, like max number of rooms and cells, max number of in-between cells (how many generates before finding a new position), etc, and then it’s initiated. Upon event play, an initial cell is spawned where the generator’s origin location is. That cell is saved in a reference variable, and it’s up, down, left, right components are checked with a line trace to see if they are colliding with any other cells or rooms. Should they not, they are added to a component array. Level spawn cells or level level spawn room is called, and and a number of cells between 5 and 15 or rooms between 1 and 5 are spawned, following a sequence of functions that:

*1. Gets the previous cell/room and components *
*2. Check those components to see if they overlap *
*3. Conditional check for overlap, True: destroy the cell and start again False: continue the process *
*4. Check the number of inbetweens, True: call level spawn cells/room and find new random position to branch False: continue process until number is reached *
5. Continue process until total number of cells/rooms are reached.


If there are any questions, critiques, feedback, etc don’t hesitate to drop a line!

Be sure to subscribe to our newsletter and follow on Twitter.

**BONUS: **Here’s some recent art, our artist have been been wiping up in the dungeons!…74550599200768…48678747983873…57368445833216…99681667248130…44180087640064


Hello everyone! We’ve some more sprite art coming your way!


Hey guys, Ive some more art for all of you!

Here we have “idols” for the Sumrak and Jutro. Beings that are worshipped within the NGH galaxy.

Here we have some sprites for the robotic npcs, including the Drone Bot, Service Bot, and the Security Bot.