Image 1: End of the alpha demo

Introduction

Trapped in Time (stylized as Trapped in Time RL, or TiTRL for short) is a rogue-like dungeon crawler written in Python and tcod. It is a game designed and programmed by the members of Crywalker Farms. The final release for the course marks TiTRL’s transition from pre-alpha to alpha status. The game can be downloaded from the GitHub page.

Since the last article, there have been minimal conceptual changes to the game, with only minor technical changes in the implementation of the major game features. The team members have continued to learn new skills, despite some issues with GitHub. A final list of unmet goals was also drawn up for analysis and use in any future programming, comprised of goals that were either dropped from core requirements, or designed as optional “bonus” goals.

Zip Link: https://osf.io/4tcn2/

Synopsis

Image 2a (top): closed gate; Image 2b (bottom): open gate and portal

You wake up in a dimly lit room. You can’t remember who you are or how you got here. Strapped to your wrist is a strange watch-like device that allows you to travel through alternate timelines. Your goal is to escape and try find clues to explain your mysterious past. You hear strange noises, the sounds of dangerous enemies lurking. It’s best to find a weapon soon. Your watch may be able to help you – or just land you into even more trouble. You’re going to need all of your wits about you if you want to succeed. Good luck.

 

Design and Development

The original idea was to create a game that valued interesting game mechanics and fun over flashy graphics through the use of ASCII graphics, allowing the team to focus limited development resources on a game that was playable and enjoyable. Having the player begin without weapons was a choice to allow players to choose their playstyle based on their item pick-ups. The team did not want to force players to combat every enemy they encountered, but instead wanted the play to rely on other tactics (such as clever maneuvering and the time-travel mechanic) to bypass obstacles. Choosing to go with a dungeon crawler/maze type game allows for the addition of future levels with increasing difficulty, drawing in gamers who appreciate a challenge.

The team formalized the list of the project goals in a spreadsheet, as seen in Image 3. There were two tabs: bugs and features. When someone had an idea for the game, the feature was named and assigned an ID in relation to any met tasks, prerequisite tasks, or related tasks. It was then assigned identifiers and completion priority as according to its impact on completing a “perfect game”, where the ability to complete a game if played perfectly was measured by the impact of the feature’s presence/non-presence. The feature was then assigned to one or more team members to complete, though some were left unassigned due to the uncertainty of whose “area of influence” the feature fell under. Upon completion of the feature, a description of the feature was added to the spreadsheet and the feature closed. Bug-tracking worked similarly, listing bug summaries instead of feature names.

Image 3 (dates/names omitted for visibility): Fourth feature (with subtasks not listed here); UI; important feature but a perfect play is technically possible without it, so of lesser importance than implementing a win state; results of implementation

Since the mid-term update, the game experienced a very minor conceptual shift and a few changes in the technical implementation. During discussions with the item designer, Bryan, a joke in the naming of the ranged weapon morphed into a full-on idea surrounding the parody of many famous science fiction tropes. With the team quickly jumping on the bandwagon, the remaining items and enemies were re-named to match in short order. Given the timeline-jumping aspect of the game, a future extension to the project posited was that the player would travel through different parodies of fictional settings, giving TiTRL an ironic touch, where levity pairs with survival horror.

Due to ability and time limitations, a few core goals (listed as “features” in the spreadsheet) had to be dropped based on prioritization of essentials to core gameplay. The item menu was turned into an optional goal, with items instead consumed on pickup. In contrast, level-up customization had to be dropped; instead, the demo uses a fun placeholder for upgrading the character. HP and Shield were merged into one life resource, rather than two different resources. Aside from those changes, all main goals were met, creating a playable demo (Images 1 and 4).

Image 4: TiTRL with debug mode enabled: the player can see everything, but so can the enemies

Skills Learned

Bryan

• Python Programming: Most of my programming experience is with Matlab, but I also had an introductory course in Java which is a similar object oriented programming language. Although I was somewhat familiar with class structures, this really expanded my knowledge of how versatile they can be especially in a game setting like this.
• Set up Eclipse with Python: This is the first time I had to set up a compiler separate from the programming language I was using. Eclipse defaults to working with Java, so there was a little extra set up involved. It took some getting used to, but by the end I found the value in using a compiler like this.
• Set up Github: This also took some getting used to, with very little help for beginners within Github itself, but I was able to find various online tutorials to help me learn to do what I needed. Again, after some use, I found it to be a very good tool for collaborative programming. It is very helpful at merging different branches of code to a main branch. By the end, we were trying to merge just small components from what had become very different code, so at that point I thought it might be easier to just do some copy and paste work outside of Github.

DJ

• Level Design in REXPaint: Creating a fun map that is challenging yet playable, as well as appropriate for the contexts of a demo was no simple task. REXPaint is a program that can be used to create ASCII maps for roguelike games, but it does not come without its limitations.
• Learning to work on a collaborative programming project: Working with multiple people on code that needs to interface together is not easy, especially when working in a completely new language and programming environment. I was thankful for group members who were patient and helpful.
• Learning Python: I previously had minimal programming experience, and working on this game was an excellent opportunity to understand the basics of Python and tcod.
• Video Game Design: The principles of designing a fun and balanced video game that attracts a wide audience is complex. Design decisions must be carefully considered so as to not alienate potential players. Personally, I had not contemplated the choice of color selection for the map and player design until Jaime raised concerns about playability for colorblind players. Creating a game that was accessible to a wide variety of people forced our team to think from a consumer mindset and design accordingly.

Jaime

• Set up Eclipse+Python (and tcod): Eclipse is different than NetBeans. Python 3 is a bit less annoying than Python 2. tcod is both better than the last version of the library and worse, due to being in active development.
• Set up GitHub page and link to Eclipse: Useful, but likely due to everyone being completely new to game development, a complete mess to work with. Alright when solo, at least.
• Project management with non-IST majors: The approach that one needs to take differs from an IST major working alongside other IST majors. While obvious, one has to account for the differences when defining and assigning tasks.
• Game design/development for Python: Game development really forces one to focus on implementation over cleanliness/efficiency of code. It also teaches one how to handle tricky bugs, though that might be more a side-effect of using a scripting language than anything else.
• How to choose a license (pros/cons vs. needs): This turned out to be surprisingly difficult between the many similar (yet significantly different) licenses, using this as a test of sorts for future (possibly paid) games, and fighting against the natural tendency to be possessive/protective of one’s code. Realistically, none of the team members will touch the code after the semester; an open license means that someone else might find use for it, at least.

Hurdles to Progress

GitHub was used as the shared repository for the team’s code, but due to constant merge conflicts, it ultimately proved to be useless. As the more technically-skilled team members were preoccupied with their capstone projects, the attempts to fix the conflicts through the unfamiliar Eclipse IDE ended in failure. By the end of the semester, the team instead shared code through email and Google Drive.

Balancing project deadlines with other life goals was a constant challenge and required team work to overcome. Sticking to the project goals allowed the team to prevent the scope of the project from changing and allowed the team members to focus on building a playable demo. Prioritizing the importance of features was a necessary compromise to ensure that core elements of the game were playable and bug-free.

Unmet Goals

• More variety:
  • Dungeon levels/appearance
  • Enemy types
  • Weapon types
• Actual customization on level-up
• Item menu
• Look command
• Game menu/game over -> new game without exiting/reopening game
• Colored messages
• Sprites instead of ASCII
• Full HP/Shield implementation

 

Demo Video