top of page

The Tentacle Of Monkey Island

About

The Tentacle of Monkey Island is a small point and click adventure game created using art assets from The Secret of Monkey Island and Day of the Tentacle. I wanted to implement the major features of a point and click game while developing a UI system for my engine that I could use in future projects. Some major features I added were the UI system with buttons that could fire events, an item interaction system, and a dialogue system. The project was also a good opportunity to practice planning and executing a project on my own and I learned a lot about my own time estimation and velocity.

Engine and Tools

Emerald, C++

Development Time

2 months

Platform

PC

Key Features
UI System

The UI system is designed as a tree of UI elements, which can be panels, buttons, images, or labels. The UISystem object owns a root panel that the game uses to attach new UI elements.

​

Panels

​

UI panels render themselves and then all their children unless the panel is set to invisible. The same idea is used to update a panel and all children as long as the panel is active. The tree structure allows for an easy way to hide an entire subset of HUD elements at once. When walking around the environment, the player's inventory and verb list is shown, but upon entering a dialogue the inventory and verbs are hidden and the dialogue HUD is shown. By deactivating and hiding the panel not in use, I could quickly and easily switch between HUD modes and avoid errant click events on buttons that were hidden.

​

Button Events

​

Each UI button allows events to be registered and fired for click, hover start, hover stay, and hover end. When an event is fired, the id of the button along with a set of NamedProperties ( essentially a generic map of strings to data ) containing any data the particular event handler needs is sent along to the listener, allowing for behavior to be given to each button as well as provide feedback when the player hovers over a button.

​

HUD With Debug Draw Outlines for UI Elements
Excerpt from UIElement.hpp
Item Interaction System
ItemInteraction.png

In order to manage each of the 5 verb actions available in the HUD with relation to each entity in the game, I designed a system to send messages back and forth between the map and entity. Each entity knows which verbs are defined for itself and any other information specific to how the entity acts. The map knows how to update the game world based on which verb was used. The main benefit to this approach is that by encapsulating behavior the map doesn't need to know about specific entities and the entities don't need to know about how the game world is updated based on verb actions, allowing for new verbs or entities to be added very easily without needing to refactor existing code.

​

Each item and NPC in the game is assigned ActionEvents in an XML file that defines which verb actions that entity will respond to. Whenever the mouse is clicked the following set of steps is performed:

  1. The map identifies which entity was clicked
  2. The map calls that entity's HandleEvent function with the requested verb
  3. The entity checks if the requested verb was defined in the entity's XML entry
       a. If not, a generic "That's not going to work" message is displayed over the player
       b. If the verb is defined, the entity sends an event via the event system
  4. The map updates the game based on the verb action

Action Events in ItemDefs.xml
Dialogue System

Dialogue is handled as an entirely separate game state. When starting a conversation, the normal HUD is hidden and a dialogue interface is shown that allows the player to choose a response. The speaker's line appears over their head.

​

Each conversation is defined in XML as a state machine, with each choice leading to another section of the conversation. By defining the conversations in data they could easily be updated and extended while writing the puzzles.

Wally Conversation XML

Post Mortem

 

What Went Well

  • I did a good job balancing the workload of each milestone so that I could maintain a steady pace throughout the project.
     

  • I had success identifying when an approach was going to take too long, like adding interactions between entities in XML, and falling back to a simpler method that would allow me to finish the task on time.

​

  • My approach started with a core game loop and iterated on that in order to always maintain a working build, I never went too far off the deep end designing new systems without being able to test them.

​

  • The framework I made was fun to use to add puzzles and with some cleanup would be a good tool to use for future point and click projects.

​

  • I got better at being able to estimate new tasks over the course of the project.

What Went Wrong

  • Art ended up taking way more time than I anticipated. I was able to find sprite sheets for everything in my game, but every single one needed to be edited in some way in order to work in my engine. I wasn’t able to get to all my stretch goals, including an expanded puzzle sequence due to how long it took to put together all the art content.
     

  • While my planning skills for individual tasks improved, my milestone hour estimates drifted further away from reality for each milestone. The main reason for this is that I planned everything out right from the beginning of the project, when I had less knowledge of how later milestones would go. I wanted to experiment and see how close my time estimates were, but in the future I think I’ll readjust my estimates at the end of each milestone.

​

  • Although my UI system was easy to use for the player HUD, the interface was a challenge to use for menus because I designed it with some assumptions that made it hard to place buttons in arbitrary positions on the screen.

What I Learned

  • One takeaway that I had heard before but had never really clicked until this project was that it’s much easier to design engine systems when you have a specific game in mind. When making my UI system, instead of trying to image all the features I might ever need in UI, I could focus on implementing the features I needed for a point and click game which helped to clarify my path forward.
     

  • Interface design takes a long time to get right. Building the underlying code system for the UI went faster than anticipated, but coming up with methods that would be easy to use took awhile and I still didn’t completely nail it.

​

  • Another huge revelation was how much time and energy needs to be devoted to art. I wasn’t even making new sprites, just combining some from the internet and it still took a lot of time and effort. On the positive side, I did learn how to use photoshop and how to do some simple art tasks. I even ended up having fun near the end of the project when I needed to tweak some art to finish polishing the game.

​

  • Polish can do wonders to make a game feel more complete and detailed.

​

  • It’s important to identify when an approach is overengineering and can be simplified in order to make sure there is time to actually finish the game.

​

  • On the process side, I learned that I overestimate most of my tasks, so I end up spending less time than expected working on my features. These estimations can really be affected by how far out I was trying to estimate, as well as the task order of a sprint. Certain tasks become trivial as others are finished, so knowing how to order the tasks in a milestone can really save time.

bottom of page