Hyperaustral

Project ID Card:

In 2027, Earth was devastated by an unprecedented catastrophe, leaving the surface uninhabitable and forcing the surviving population to seek refuge in airborne arks. This is the premisce of Hyperaustral, a 2D top-down management game where you lead the crew of your own airship through the catastrophe, and have to learn to manage food, fuel, and your crew's needs and morale in order to keep flying further and, hopefully, reach some safe haven somewhere towards the south (hnce the name, Hyper- as beyond, -austral as in southern).

The team was comprised of 3 programmers and 2 artists, the latter group of which i was a part of for the first 2/3rds of the project before focusing on programming polish and technical improvements. As a student project, development lasted for around three months, including the design phase and the showcase/post-mortem phase. While it was a success in terms of grading and personal improvement for each member of the team, this project was considered a "failure" in terms of game designing by the team, which will be detailed further down this article.

Gameplay concept

The concept our group settled on was a very ambitious one, much more than we could manage at our respective current skill levels. And because of added issues during development, many of these following conceptual elements of the game had to be scrapped.

Event-driven storyline

Random events, happening at random intervals, give glimpses into the lore of the game, add life to the characters by making the player become familiar with them, and add challenge to keep the player involved.

Some events only mention flavor text, describing happenings within the ship that may not affect directly the gameplay. Some others will give the player tasks to accomplish, machines to fix, choices to make, and can lead to event chains depending on what the player does. Finally, some much larger events that don't happen at random but at fixed points in the games progression will lead to more dramatic changes in gameplay and visuals. As a general rule, the higher the impact on the gameplay, the lower the occurence chance for any given random event.

Low animation cinematics for the storyline events

Ressource management

To survive and to progress, the player must meet ressource requirements. Fuel, Raw organic matter, Crew energy and food must be produced continuously through defined stations to ensure the ship can keep advancing, and that the crew survives. Without fuel, the ship crashes and the game is lost. Without any crew member left alive, the ship cannot continue operating, and the game is lost.

Lively crew members

For each save-file, the player would be given a random set of crew members, all with individual names, appearences, attributes, and of course resources. Each crew member can be assigned to specific stations manually to create resources, at the cost of energy and morale which can be restored in the dormitory, play area, and kitchen. If their needs are not met, they gradually deteriorate until they take damage, and die. Through random events, characters might become involved in storylines such as mutinies, epidemics, relationships and others.

Crew members

Each crew character is independant in its movement and animation. The only way the player has to control them is by assigning them to specific tasks and rooms: they are autonomous in navigation through Unity's AI Navmesh agents. They have unique names, specialties, characteristics and stats generated when a new game is begun, that remain until the game is won, or the character dies.

Character Design concepts

Character parts animation sheet

Crew member ID card

In order to have all crew members available animated, randomly generated, and consistent each time the same save file was launched, the Random Character Creator (Full article) split their visuals into each different randomizeable parts, assigns the desired color to each, and encodes it as a single integer string which can then be re-read on loading to generate the very same character visual.

Each part of the body is then independently animated according to the character's activity, and moved by the ai agent around the ship's layout.

Dynamic World Elements

In order to make the world of Hyperaustral feel alive and dynamic, the ship and the world around the ship needed dynamic elements that might change during events, cycle between night and day, or evolve during the progress of the game. As the Tech Artist of the group, I was the one in charge of creating and integrating these non-gameplay elements.

Scrolling Background: Under the airship at all times in the games scrolls an endless ocean from the rising waters of the catastrophe, under a couple layers of clouds. The background is animated through scrolling repeating textures endlessly at varying speed to give the illusion of depth. Those speeds can then be varied depending on the ship's movement speed to better sell the effect.

Background textures : clouds (top), sea and waves (bottom)

Dynamic Weather: Throughout the game, the weather and time of day may shift (sometimes according to pre-scripted events). To reflect that, I set up systems that trigger smooth color transitions in the background depending on the set weather. Originally, the ship's hull was also meant to change color, but our tutor's feedback had us keep it constant.

Dynamic weather system (in order: cloudy, sunset, daytime)

Broken Machinery: As part of the random events system driving the game, part of the environment may break down. Machines, doors, appliances, and ship engines. As of the current version of the game, only the reactors were able to break down (visually), a feature only used in case of critical ship damage (none of the corresponding events had been implemented). In the case of the engines, they would darken, shake, and emit dark smoke and fire particles to indicate a dysfunction.

Full Reactor malfunction

Ship Layout

(Full article)

As artist and asset integrator, I was also in charge of designing the ship's layout, as well as creating and placing all the decorations. For that purpose, I designed a wide set of props to spread around the ship, from furniture to tools and rubbish, that would make the ship feel "lived in". Additionally, to reflect both the gameplay based on work stations and how an airship like that might be organised, the ship is split into distinct rooms, each with a different purpose.

Room layout of the ship

In the above picture, each room is marked in a separate color, in an overlay display available in-game by a toggle button in the UI. Using this display, the player can better visualize the secions of the ship which is especially useful during area-specific events.

To add a bit more immersion and character to the ship, each room has its own style, type of decorations, and overall color scheme. This way, the player has an easier time differenciating the room instinctively and the ship feels more natural. By adding in organic untidiness and solid furniture the characters need to navigate around, each room feels like it has substance and actually exists in the world of the game.

Views of different rooms from the ship and their decoration

Post Mortem

As mentionned in the introduction, this project was considered by the team to be a failure for many reasons:

Despite these negative points from a gameplay point of view, there were some definitive sucesses to highlight:

Future of the project

With the great structure already present of Hyperaustral, the project is currently awaiting a revival. By rebuilding it from the ground up and revisiting the concept, I hope to address the issues of the current game and make it into what it could have become.
Current revival project progress: [To Be Determined]

Related Articles

Magna

Sed nisl arcu euismod sit amet nisi lorem etiam dolor veroeros et feugiat.

Magna

Sed nisl arcu euismod sit amet nisi lorem etiam dolor veroeros et feugiat.

Magna

Sed nisl arcu euismod sit amet nisi lorem etiam dolor veroeros et feugiat.