rookie

Rookie is a single player, side-scrolling point & click adventure / dating sim hybrid where you play as the inexperienced genie, Zoltran.

After screwing up abysmally while fulfilling your last human’s wishes, you are stripped of your powers and banished to a degrading coin-op fortune telling box on the Ocean City Boardwalk. In order to regain your powers, dignity, and freedom, you must first prove to your boss that you can fulfill the wishes of boardwalk visitors and passersby with the absolute bare minimum, else risking an eternity of continued humiliation.

I created this game as an individual project for UF's DIG3713 Game Content Production course.

You can download Rookie on itch.io here.

Rookie is a story-heavy, side-scrolling point and click adventure game where the objective is to fulfill the wishes of boardwalk visitors, despite having lost your genie powers. Because Zoltran is now completely powerless, these wish-fulfillment quests will consist of incredibly mediocre (and sometimes downright laughable) solutions and problem solving approaches.

The premise was inspired by this completely ridiculous, decade old WKUK skit about a powerless genie given unrealistic wishes to grant.

PRIMARY GAME MECHANIC

Rookie has a dating sim-like human satisfaction system where “bad” moves will decrease human satisfaction and enough “good” moves will lead to the wish being fully granted. Too many bad moves will lead to quest failure.

Check out the full game design document here!

DIALOGUE SYSTEM & STALEMATE PREVENTION

Rookie features a branching dialogue system that allows players to fulfill quests in various ways.

In its previous state, Rookie’s branching decision support was problematic. That is, it was possible for players to exhaust all options (or interact with all interactables) in a way that does not result in win or lose conditions. (For example, a player could be stuck at 95% or 5% satisfaction level without any remaining actions to take.)

The stalemate prevention system runs a check to assess current satisfaction level and remaining interaction options; if it determines that all possible options have been exhausted and the player has not met win/lose conditions, it will force-engage dialogue and apply those conditions automatically depending on the final dialogue option selected by the player.

In a “stalemate” state, the system assesses the current satisfaction score, and if it’s found to be above 50%, win conditions are applied automatically. Otherwise, the stalemate will result in lose conditions being applied.

Ideally, if I had more time for this project, I think I would have adjusted the satisfaction weightings for each interactable to be dynamic. That is, the fewer the interactables left in the scene, the higher the weightings for the remaining ones.

POST-MORTEM

Development Successes:

This class provided students with some Unity starter scripts that greatly reduced the need for me to “re-invent the wheel.” It ended up saving me a lot of time implementing basic features (level change scripts, transitions scripts, etc).
Writing out my ideas and goals in the GDD helped simplify the development process immensely. That is, any time I needed to implement a new feature in code, there were already existing guidelines for that feature within the GDD.

Development Challenges:

Because I chose a pretty niche topic/environment for my game, there were not a lot of existing art assets out there for me to utilize. This slowed the process down immensely-- any time I wanted to introduce new characters/assets, I had to draw them myself. Dressing the scene was also difficult since I needed to ensure that each of the environment assets matched with Rookie’s sketchy, colorful art style. It was a pretty wild ride being the only programmer and the only artist on this project.

This course's lecture videos revolved around the creation of a 2D platforming game, not a text-adventure. There is some overlap between the two genres (namely how Unity Canvas systems work, scene transitions, menus, etc.) but overall I was left to figure out a lot of text adventure-specific issues on my own. The development process may have been smoother if I opted to stick with a 2D platformer more aligned with what the class intended. This was way more fun, though!