Current state of original code as of March 22: map layout loaded from file with custom player placement, mouseover showing the top symbol at that coordinate, and console output includes time-travel safety check

Overview

Game progress has been stalled for a while, resulting in the movement of some deadlines to catch up. However, with multiple group members are now working on different areas of the code, project completion is estimated to still be on schedule.

Progress Images and Video

REXPaint mockup of Timeline 1 of 2, with walls (#), floors (.), enemies (E), gates (║═), items (!), the floor entrance (▲), and portal (►♣◄).

By the time of presentation, the demo based in original, non-tutorial code was effectively nonexistent, due to various issues getting members to work on code. The primary issue was that the member in charge of map implementation (a general prerequisite for the other goals) had another group project that needed urgent attention. Further delays in the form of unexpected difficulty implementing the map also meant that the presentation had to focus on mockups and potential alternate paths of coding the game.

The original game code can be accessed at GitHub. A video of an extended tutorial base was included in the presentation and can be viewed below:

https://drive.google.com/open?id=1-DCDZ6GKOA3XeQtOe3TUdHGDwC8E_Cpd

Changes in Plan Since Initial Pitch

Several changes were made to the initial plan, either design-wise or on the technical side of things. The changes came about as a result of coming up with a better design, concept or gameplay-wise, or realizing that using a different technical design would be better with the time and skills of the team.

Concept Changes

The main changes to the game concept were to the player and game theme. Instead of the player increasing their stats through items and level-ups, the player now only increases their stats through items. Leveling up has also been modified, with experience points no longer being rewarded by killing monsters. Instead, the player levels up upon reaching the end-of-floor portal, discouraging unnecessary combat. The level-up system was repurposed to allow the player to pick from different item perks instead of stats, therefore allowing for the player to customize their character.

The changes were largely inspired by the addition of the horror genre to the game. While the roguelike aspect still predominates, adding horror elements creates a more interesting game while helping the team to work within a limited scope. The player can no longer kill every monster without a scratch once they gain enough power, as in common in many RPGs. Instead, it is hunt or be hunted, depending on the player’s resources. Being an amnesiac in an old, abandoned factory full of monsters, resources are naturally very limited.

Plans for an improved variety of monsters and better monster AI were also added as a bonus goal. In a horror game, monsters are not all of the “charge straight at the player and die quickly” variety. Some are smarter, and others are stronger. However, due to the goal’s complexity, it has been placed at the very end of the project timeline.

Technical Changes

At the time of the presentation, when the demo comprised of original code failed to even have a rudimentary map system in place, it was thought that the team might have to use more code from the roguelike tutorial. The code (which is public domain) would then be modified to fit to ensure that there was new code created in original ways, while allowing the ME majors to complete a major programming project despite their inexperience with Python.

However, the quality of the tutorial code leaves something to be desired even for those unfamiliar to coding conventions, making it a measure of last resort for use. It is under-commented, lacks coding conventions, and over-stuffs function calls, making it difficult to follow for people reading the code, let alone modifying it in an original direction. For example, consider this long function call:

render_all(con, panel, entities, player, game_map, fov_map, fov_recompute, message_log, screen_width, screen_height, bar_width, panel_height, panel_y, mouse, colors, game_state)

However, a recent breakthrough was made with the map code the day of presentation, with a full basic map being implemented that night. As a result, the team might be able to use a significantly larger amount of clean, original code, while still leaving the ability to use code from the tutorial, should the other team members have trouble implementing their parts from scratch. However, developing the code further with the in-development tcod will still require careful thought, so extending the tutorial will still develop the team’s programming skills.

Skills Learned

DJ Ramachandran

Learned how to set-up Eclipse IDE and GitHub to create a coding repository
Learned about coding standards
Began walking through Rogueliketutorials.com tutorial of how to create a roguelike game
Followed basic Python tutorials to gain a basic understanding of the language and programming in general
Began familiarizing myself with libtcodpy – used in Rogueliketutorials.com
Began mapping the console output commands for various scenarios
Began exploring enemy creation as a class with attributes and methods
Used REXPaint to create a mockup of the 1st Dungeon

Jaime Seaman

Set up Eclipse+Python (and tcod)
Set up GitHub page and linked to Eclipse
How to manage project with non-IST majors
Python game-dev

Bryan McSherry

Python programming with tcod
- Programming using Class
Set up Eclipse and Github
Programming strategies learned from roguelike tutorial
- Combat system (giving/taking damage and hp tracking)
- Item use
- Inventory tracking (add/drop)
- Map generation
- Simple enemy AI
- Field of view
- Composition class structure as opposed to inheritance class structure

Girum Mideksa

(not listed)

Hurdles to Progress

The main hurdles to progress were a combination of inexperience with programming and group coordination problems. The team members collectively only have recent experience in Java and Matlab, while lacking recent/any experience with Python. With issues getting the group together to talk, let alone program with an unfamiliar language and library, and it is no surprise that the group has been struggling.

However, progress has been improving as group members have been communicating with each other a bit more and the lone IST major becomes less busy with other projects.

Updated Project Timeline

Project goals were largely unmodified. While a few earlier goals had to be moved, due to delays, the ability to work on simultaneous areas of code should result in the game being completed on schedule. The new bonus goal was also appended onto the end.

(COMPLETE) Get familiar with language/library: player walking around
(COMPLETE) Set up GitHub and coding standards
(WIP: March 18 -> 25) Implement core mechanic and basic two-timeline floor: player time-traveling
(March 25 -> 29) Implement win condition
(WIP: March 25 -> 29) Implement combat: player fighting/killing/dying to monster
(April 1) Implement lose condition
(WIP: April 8) Implement leveling/items/stats
(April 15 or so, depending on state of BONUS goals) Final testing, documentation, and packaging of demo for public release
(BONUS) Implement procedural level generation, multiple levels
(BONUS) Implement 2D sprites
(BONUS) Implement main menu
(BONUS) Implement save/load system
(BONUS) Multiple monsters, better AIs

Peer Reviews

Peer reviews of the group’s midterm update were generally positive, praising the game’s progress and scheduling. A few reviews suggested ways of displaying upgraded weapons, discussed graphics, or asked about story.

In regards to weapons and tracking upgrades, there are already some plans in mind that should be implementable in the current planned scope, due to the system’s simplicity. While using color leverages one of the few distinctive parts of roguelike design, due to the restrictions of the medium, relying on color alone excludes blind and colorblind players, both of which feature significantly in the roguelike community. Design that does not rely on color first is both easier to implement for the time being, and also increases accessibility for gamers.

There are plans to give enemies and items sprites; however, creating a playable game is still the main priority, and as such, adding full graphics is comfortably considered as a bonus goal that can be pushed back to a later phase of development. Furthermore, though the story has started to develop into a more concrete form, the game is not yet mature enough for the team to feel confident in settling on an art style. Creating full graphics is a potential waste of time and resources designing enemies and an art aesthetic, as they may be replaced at any time. However, the development of a full demo would definitely involve the creation of sprites, as they have greater market appeal than ASCII character.

With the story currently as basic as it is, the protagonist’s appearance and name are not too important, as they are an amnesiac in hostile territory. The most important part about them is their time-traveling ability, and whatever enables them to do so (e.g., a special watch). Creating a backstory would be nice, but a potential distraction from further coding at this time.

Trapped in Time: Midterm Update