Ruins in Time

Ruins in Time is an left to right platformer game where you travel through the mysterious land in which your are thrusted into in order to find out the truth behind the disaster that looms in front of you. Travel across the realm fighting enemies, and collecting artifacts in order to end the ongoing disaster once and for all.

Controls:

W - Jump

A - Move Left

D - Move Right

Left-Click - Dash Attack 

The player for most of the game will only have 2 hits before they fall before their enemies.

The player will go from room to room killing the main enemy/enemies in each in order to progress.  The main attack is a dahs attack that slices through enemies and sometimes can be used as a dodge or a projectile counter. 

Be careful about leaving enemies alive for too long or else they might get a sudden boost in strength.

Each level will end with a boss which they will have to defeat in order to get an artifact that boosts the players current capabilities and move on to the next level. 

Post-Mortem

What Went Right

The overall look and aesthetics of the game went in the right direction, and the code was executed in a way that made the game appear more interactive with the player. In this regard, player engagement is successful and aligned with our objective of the game. Most importantly, the game had at least two playable levels that had all the core mechanics and allowed for the player to see what was more to come. 

What Went Wrong

Problem(s): Being Overly Ambitious (Not knowing our limits), Lack of effective communication and follow up during development.

Summary of said Problem(s): 

During the production of our game, our team of four people (3 artists, 1 coder) (1 artist left towards the end of the semester) initially designed a multi staged game with multiple choices and different mobs for each environment. Due to our time constraints, we realized too late that in order to get out something we had to cut a lot of what we initially brainstormed. Together with the lack of effective communication and follow-up on what everyone was supposed to do (deadlines) our project turned into an overly ambitious project that grew in scale as the semester progressed (schoolwork).

What Changes Were Made & Why

Due to time constraints, we had to cut out the majority of our levels, or area designs. Initially, there were about 6 to 7 areas with a corresponding enemy that players were expected to encounter, though some of those character designs were also scrapped, or implemented in a way for them to compliment one another (ie. the Plague Doctor summoning the Ravens, as opposed to the two of them being separate enemies on their own). Some aesthetic decisions were also compromised, specifically the way time is moving between the game, and the way storytelling is being told. We initially had a narrative revolving around how the main character must travel back and forth in time in order to defeat the final boss, as well as acquiring allies along the way when speaking to certain NPCs. That said, however, we had to discard these ideas and focus more on the game mechanics without a complex story.  

Lessons Learned

As a group we've learned what we could produce and what our limits are individually as a member of said group. Here, knowing what we can do could lead to more realistic expectations for the time frame we have to create a game. With zero experience on creating an actual game we'd say we've learned the difficulties of creating a game and how difficult it is to organize and plan the game efficiently. 

Another lesson we could take away from this is that in order to reach goals that are ambitious, the group needs to not only have enough time but have effective communication to make sure each member is working effectively as possible throughout the production phase.