top of page

Escort of Ethshar

Click To Play!

https://flamingtrash.itch.io/escort-of-ethshar

The Escort of Ethshar is descended from top-down roguelike and RPG games with pixel-art styles. Through a job structure (choosing one of three paths/levels) and the knockback-based combat, protect the cargo like your life depends on it!

The Game's Development 

I. Core Problem & Initial Thinking

The Escort of Ethshar was created by a team of 4 in the span of 15 weeks. The core problem the team and I wanted to solve was: How do you create frantic, physics-based combat where the challenge is positioning and knockback, not dealing damage? We drew inspiration from Nuclear Throne's simple attack animation, Overcooked's sense of franticness, and Team Fortress 2's Mann vs. Machine mode where enemies ignore the player and focus on the objective. The Escort of Ethshar is a game with tons of replayable abilities due to the game loop we created. You play as a mercenary who is tasked with protecting a cart of goods as you travel from kingdom to kingdom. This is no easy task as enemies are trying to attack the cart throughout the levels. I helped design the combat so you fight your way through the town by knocking enemies back to achieve your goal.​

Escort of Ethshar Gameplay

Bug.png

We studied these games to understand what made their combat and tension work. Our knockback-based 'sumo' combat was our unique twist."

II: My Contributions

My specific contributions to Escort of Ethshar:

  • Collision system programming

  • UI/UX system design and implementation in Godot

  • C# scripting for game states (failure screen, success screen, level selection)

  • Tutorial screen implementation

  • Team documentation and postmortem

III: Tools & Technologies

Game Engine: Godot

  • ​We chose Godot and C# despite knowing there would be a learning curve. The GitHub synchronization issues slowed us down but never halted development entirely. We learned to communicate more frequently before pushing code.

Code Editor: Visual Studio 2022

  • ​Since this was the first project, we all knew a lot more about Visual Studio and decided to use it. It was also helpful since Visual Studio id the common tool used in game development.​

Version Control: GitHub

  • With multiple coding confits happening during this project, know who pushed the code was helping for debugging conflicts.

Project Management: Discord

  • One of our members had created a bot that reminded us of due dates in the class. With this new feature, we could use Discord as a source of communication and task management. 

Art Tools: Aseprite & Photoshop

  • ​The artist for our game spent a lot of time in Aseprtie and Photoshop. To ensure we got all the assets we needed, we decided o use their tools due to familiarity from the team.​

Playtesting: Google Forms, in-person sessions

  • Playtesting was a big part of this project and helped us decided the path we wanted to go down for development. We made sure to conduct in person playtest and record all our finding in Google Forms since we can create a sheet with all the information on.

Documentation: Google Doc, Google Slides, Google Drive

  • For documentation that is a "living" asset, created and maintained by a team, Google Doc, Google Slides, Google Drive are perfect for that. We were able to all be on the same document the same folder and see live edits as they were happening in real time.

IV. Mechanics: Code & Systems

Mechanics

I helped program the collision along with the UI/UX for the game. Enemies have a constant force pulling them towards the cart. When they are colliding with it, they will periodically decrease the cart's health value. When the enemies leave the scene with a velocity moving away from the cart, they will die. When that cart's health reaches zero, a failure screen will appear with a button that transitions the UI to a level selection screen. Alternatively, the player can reach the end of a time limit with the cart health still above zero, in which case the success screen will appear with a button which also takes the player back to level selection. I outlined and programmed the UI/UX system within Godot and coded using C#.

​

​

​

​

​

​

​

​

​

​

​

 

 

 

​

​

Control

ToThe player can exert force on the player using the WASD or arrow keys. The player can also create an "attack hitbox" which exerts a large impulse on any overlapping enemies. This hitbox will be created next to the player, in the direction of the mouse cursor, when clicking the left mouse button.​

​​

Escort of Ethshar Gameplay

Control Page

Onboarding

To ensure the player has an understanding of how to play the game we created a tutorial screen. This screen is shown right after the player starts the game. By doing this we were able to make sure the player fully understands our game and the controls before starting gameplay.

Bug.png

We tracked bugs across 6 sprints. The gray screen crash (Sprint 6) was our most serious bug – standing in a certain spot would break the entire game. We documented it and prioritized fixes.

V: Design: Playtesting & Iteration​

The game has a medieval-esque aesthetic in a pixel-art style. With whimsical sound effects and mystical enemies that attack the character, the player can feel submersed in the game setting. The character themselves even fits the aesthetic as you play as a knight.​

Bug (1).png

Our playtest evolution from gray squares to a complete game. Each sprint, we collected feedback via Google Forms and in-person observation. The biggest insight from this: players figured out controls instantly, so we added a tutorial screen anyway to be safe.​

UI Mockup​

I helped design the game's over all UI and the game flow. The tutorial appears before the first play, but players can skip it after they've learned. The level select uses cryptic job posters that make more sense after playing.

​

The Game Flow is: 

  1. Main menu screen
  2. Tutorial screen (WASD/arrow keys, mouse click to attack)
  3. Level select (three jobs on a bulletin board)
  4. Main game state (defend cart from enemies)
  5. Success screen (cart intact, time limit reached) OR Failure screen (cart destroyed)
  6. Return to level select
Protoype
Final Version

VI: What I Learned & Post Mortem

That a new engine (Godot) mid-project comes with challenges. C# and GitHub had desync issues, and we faced multiple merge conflicts. But we anticipated these problems and they never halted development entirely.

  • Team process matters. During our initial sprint, we didn't know who was doing what. After a meeting where we talked out our issues, we established weekly meetings, defined roles, and worked mostly in person. Productivity improved dramatically.

  • To use Google Forms to standardize playtest feedback. We'd put final touches on the build the day before, prepare specific questions, and have one team member oversee tests to capture oral feedback.

Bug (1).png

Our postmortem honest reflection. We achieved our core combat loop but cut the shop mechanic due to scope. Learning Godot caused technical issues, but we never halted development.

Credit Page

bottom of page