Date Started: August 2015
Date Completed: September 2019
Escape is a graphical text-based adventure game, where the player solves spatial and logic-based* puzzles in order to make their escape from the building.
This Java-based game will run in its own executable and it is set to the theme of a monochrome terminal color scheme.
*As logical as an adventure game can get.
OVERVIEW
-
Graphical Text-Based Adventure Game
-
Written in Java
-
Nearly 2,000 unique responses
-
Monochrome Color Scheme
SCREENSHOTS
PROCESS
(contains spoilers)
Out of the ideas I have for games, this game stands out because it wasn't actually an original idea. Back in high school, I had to make a final project for my AP Computer Science class. After a semester of effort I came up with what would become the prototype of ESCAPE in a ASCII art style. Dubbed "DUNGEON CRAWLER," this game was originally planned to have puzzles and combat, but was eventually rolled back to puzzles to fit into the time allotted. Even though 9 rooms were planned, only three were fleshed out and implemented. When I moved into the senior year of high school, I didn't have any time to work on a project along with school work, but I knew I wasn't satisfied with that final result.
When I had free time on weekends, I started drafting what I would want the second game to look like. At the time, I wasn't even sure I would make another point-and-click adventure game, because I had a plethora of other ideas I wanted to puruse. The only problem was that I didn't have much programming experience, but a lot of ambition. At the time, I was advised by peers to start small, so I thought this project would be a perfect fit to start with. I unfortunately only got about 15% of the game drafted, before I decided to tackle the project.
Sticking to my original ASCII art style, I started taking my original plans and drawing what rooms would look like in-game. I eventually found the task too challenging. In order to make each image readable, the size the of the ASCII art was noticeably different from each other. This and the desire to draw using pixels rather than characters led me to instead learn Java's Swing and use my own drawn graphics. Thankfully this idea to switch art styles happened very early.
Describing the Ladder Puzzle.
Describing the big secret with the soda machine.
Concept as to tackle the problem with the drain pipe.
Original visual ideas for the arcade machine.
At this point in development, I mainly came up with the rest of the rooms off the top of my head. I found writing down the rooms was out-paced by my ability to come up with ideas so I eventually reserved writing down ideas to complicated concepts or puzzles.
In late development, I found that a lot of my ideas were fading in my mind as I took long periods of time off, due to school. I wanted to write down what room ideas I had, but it would be to much to write down every interaction with every concept. To compromise I started making small index cards with little blurbs on them. Though I would have to go back and fill in the details, I would have a general idea of where I was going with each room.
Finally, the reason why the game is not currently finished is because of this paper above. It features just one of the many lists of bugs that I found in a single play-through of what I currently have. This paper is just one of the possibly hundreds of lists I have made over the years. It stands as a reminder to unit test code early to avoid the problem of testing multiple features at once.
Due to the nature of when this project started and its development length, this project taught me the benefits of planning a game before jumping into it's execution. I find this piece to be an advocate for that lesson. Planning is a very valuable skill that every developer should learn early.