Underland is a 2D RPG game where players take on the role of a lost soul facing the challenges of navigating through three distinct worlds. Each instance consists of various obstacles where players must defeat a unique boss before advancing to the next level.

The Goal

The primary goal in creating Underland is to deliver an immersive 2D RPG experience that strategically challenges players, drawing inspiration from titles like Dark Souls, Undertale, and For the King. The game aims to captivate players with a challenging gameplay loop, gradual story unraveling, and a customizable character progression system. 


The earlier development process for Underland involved in creating concepts that would closely fit my desired target audience. I first decided on the genre of the game and how I would approach the vision that I had to make sure it was possible within the limited time-frame of the projects deadline. A lot of planning went along with what would be implemented into the final build as well as to what should be taken out of the game based on its impact it would have for the player's experience. My main goal was to make the game mechanics feel responsive and intuitive for the player. I approached this way of thinking by only implementing features that were necessary for the game and to spend a majority of my time polishing the mechanics that I have chosen. 

My Inspiration

Underland was mainly inspired by various designs from video games that would create a unique experience within its genre. The gameplay primarily focuses on providing an experience for individuals who enjoy character progression, customization, and strategic decision-making traits which are found in modern RPGs.

Similar to games such as Dark Souls and Undertale, my gameplay principle was about emphasizing the player's adaptability towards new mechanics that are introduced and found from the various enemies within the levels. The narrative design took inspiration from following storytelling structures such as Undertale and Shovel Knight by displaying a thematic world that would add onto the overall immersion.  


The design elements focus on creating a customizable character progression system, drawing from traditional RPGs. The game offers players the freedom to allocate stats such as Vigor, Dexterity, and Attack, allowing for a tailored playstyle. Controls involve WASD for navigation and core ability mechanics (shooting, shielding, dodging). The heads-up display (HUD) includes health, stamina, and mana bars to provide real-time player feedback.   

Underland incorporates a difficulty scaling system, gradually increasing the complexity of mechanics required to succeed in each world. World 1 serves as the easiest, progressing to more challenging experiences in World 2 and the final world.

Coding Stage

Using a UML diagram allowed me to visually map out the relationships between the different classes needed for my game.

For example, the Player class utilizes other classes such as Missile by having a list of Missile as objects. This composition is shown in the UML with a diamond arrow pointing to the Missile class.

Additionally, mapping things out visually allowed me to plan out what key classes were needed, how they would relate to each other, and what responsibilities each would have. This helped guide my implementation by laying out a structure to follow.

The UML diagram is not exactly the final code structure, but it allowed me to organize my thoughts and have a blueprint for the core pieces needed. As implementation progressed I tweaked and adapted things. But having that high level visual plan was very helpful for me to create a strong foundation.

The Programming

The game was made on Processing—a Java-derived language that provides coding with the fluidity of visual interface. Processing's user-friendly interface offered me the versatility to experiment with graphics and interactivity, enabling me to focus on gameplay mechanics without being encumbered by the complexities of lower-level programming. This choice reflects my commitment to efficiency and innovation, qualities I bring to every project I undertake. 

My design focus for the game revolves around creating a robust and modular model that would serve as the building blocks of the game's code. 

Several scripts were developed to manage various aspects of the game. Here's a brief overview of some of the key scripts I have used throughout the game development cycle:

Player Class: Defines the main player character with properties like health, weapons, animations etc.
Enemy Class: Defines the enemy characters. Handles movement, collisions, animations etc.
Boss Class: Defines the boss enemy with additional mechanics like firing laser beams etc.
Missile Class: Defines the missiles/projectiles fired by the player. Handles movement and collisions.
Background Class: Handles drawing and scrolling the background.
Character Class: A base class for Player and Enemies handling common functionality.
MovingObject Class: A base class providing movement capabilities. 

Final Thoughts

I've learned so many things about the process on creating a game by myself. I learned how to design an engaging gameplay loop centered around boss battles and grinding mechanics. This involved planning out different phases for each boss fight to escalate difficulty. I gained experience with narrative design by slowly revealing a mysterious story through environmental clues and character dialogue as the player progresses. I practiced designing around a core mechanic (customizable stats) and ensuring all other systems reinforced and enhanced that mechanic.

Prototyping key systems early and leaving buffer time for playtesting and refinement is critical. The initial timeline proved too ambitious. Asset creation and narrative writing takes more time than expected. I had to cut down scope in some areas to focus on core mechanics.

Using inheritance to build more complex behavior off base classes (Player > Character > MovingObject) kept code clean and reusable. Managing state machines for different gameplay modes required care to avoid bugs. I learned techniques to reset state properly when replaying. File organization by responsibility and liberal use of helper classes paid off hugely when adding new features.

The overall experience has given me insight about how a hard deadline teaches you on why scope management is crucial - cutting non-essential features in favor of polishing is important, even if it means deviating from the original vision. Playtesting as much as possible can avoid many bugs and issues to prevent problems in the future. Creating a personal deadline for various implementations will keep consistent progress in check to avoid prevent any form of work crunch to occur at the end of the development cycle. Finally, the strong technical foundations and reusable logic I have created sets up to efficiently expand my scope in future projects I may create.