Project Categories

Project Setting Personal
Team Size 1
Role(s) Creator / Developer
Languages C#
Software/Tools Used Unity (engine), Visual Studio (code), GIMP (texturing), Blender (modeling), LMMS (music/sound), Git/GitHub Desktop (source control)
Status Early Alpha, active development


Unknown Entity 2 takes place aboard a Resurvatarian space station in orbit around the Shanem's second moon. Contact with the lunar bases on the moon have gone dark. In the scramble to re-establish contact, the station soon went dark. A bio-mechanical race has taken over the station.
You are a security officer working aboard the station. You got separated from your team while sealing off a safety zone for numerous Resurvatarians. You make way to your shuttle to grab what you can in order to restore the station and find out why these "entities" are here.

Description from the official game page

Unknown Entity 2 is the sci-fi first-person-shooter sequal to Unknown Entity. It is in early alpha, with a focus on improving AI from the previous game, implementing world-based interactable UI, and utilizing hierarchical prefabbing to create detailed, sophisticated space-station-themed levels. Work on this project started the summer of 2018. This essentially was a take on Unknown Entity from newfound knowledge I learned about OOP and C# and combining it with my pre-existing experience and skill with Unity. As the game is still very early in its progress, much of what is on this page will be expanded upon soon.

My Work


  • Panel-based interior design that overlays primitive planes created using ProBuilder and fits the theme of the game
  • Numerous decorative objects that are designed to accent interiors
  • Equipment such as computer terminals and large-panel screens that keep in mind the potential for the player to interact with them
  • Clean meshes with optimized import and prefab settings
  • Animations for individual entities for different AI states (stationary, wandering, hostile)

Graphics / Level Design

  • Hierarchical prefabbing that allows for snapping different rooms together easily and quickly
  • Interconnecting rooms that create a cyclical, cohesive layout (as opposed to linear) to fit the theme of the game
  • Clean sci-fi aesthetic paying careful attention to subtle normal mapping and material specular/metallic properties

Code / Testing

  • Utilized grayboxing method for prototyping stage of AI
  • Developers console to be used for prototyping and testing assistance
  • Awareness in AI - none, partial (player nearby, but not close enough, moves to and updates position more slowly), and full (actively firing on player, moving around to various spots)
  • Independent code - improvement from tangled interdependencies in original Unknown Entity, highlighted with organization using assembly definitions
  • Clean player code using overloads for different cases of incoming damage
  • Use of inheritance/polymorphism/interfacing for AI and player to allow for less direct class awareness and cleaner, simplified code (e.g. damage contribution toward ICharacter interface rather than handling each type of AI)
  • Component-oriented code - e.g., Player / AI both can use a WeaponController class, which in turn has Weapons that both can use; allows for modularity and prevents against unecessary amounts of re-implementation of similar code / functions
  • Clean, organized code following a standardized convention with accompanying API documentation
    • Lower camel case fields, constants
    • Upper camel case properties, methods, events
    • Self-commenting code / descriptive naming
    • Avoid {}s for single-line if statements and loops
    • Align access definitions for auto-implemented property in column next to their declarations
    • Aligned side-based // comments to describe a field's intended function/etc. if it cannot be made clear in the name
    • Upper // comment labels to divide subsections of fields
    • Method XML comment headers
    • XML comment headers for any enum property / general property whose purpose cannot be made clear in the name or is meant to be extensively used by multiple classes
    • region blocks to separate large blocks of methods, fields, properties, and events
    • Properties with similar types and purposes begin with Type_ for naming; type is shortened (e.g. TextMeshProUGUI -> Text
    • Avoid manager classes, or at least the 'Manager' name for better description
    • Single-purpose classes
    • Re-usable enumerations
    • Delegates declared outside the class they are used in


These are some screenshots, videos, and code snippets that come from the game. Note that these come from different stages of its development (noted in captions)




Home Page Goldenwere
IndieDB Game Page
Source Code GitHub Repo