Being an intern at 2Performant
INTRO
It’s been a very fast paced 3 weeks since we started out as a team of 4 interns at 2Performant. Our first task was creating a small game of our choice in ruby. After some research and discussing some ideas we decided to create a text RPG game. We came up with a simple design of the game: a hero that moved around a map consisting of multiple rooms. From there we added details and enriched the game with weapons, monsters and so on. Now, the hero has weapons and equipment to help him fight monsters, he can find potions and hospitals to heal his wounds, vaults filled with treasures and some surprises along the way. The end goal is to reach the Win Room(if you can).
Expectations and requests
This project was a good way for us to get used to programming in ruby, but also to learn how OOP should be done. None of us were very familiar with ruby, but the biggest challenge to overcome was creating a truly modular and easy to maintain application. Most of the issues that we had to avoid weren’t obvious at first, but as we were developing our game new requests and suggestions about how to create good code were added. We received more suggestions as we were adding new features, which was of great importance because we really understood why we had to adopt this design over the other.
Central concepts in our game
Since the very start we knew that we had to come up with a strong design for our game. We tried to envision many future updates and additions to our program and ways so they would be easy to implement. Unfortunately, there were things that we missed, but more on that later. For now, let’s take a look at some concepts that we established:
- Character — could be either our mighty hero or a dreadful monster
- Stats — it would encapsulate health points, attack, defence and could be used in more than one place
- Room — a generic room that could do an action for the hero.
- Item — we split this into different types of items
- Map — a way to arrange rooms in a certain manner
- Position and cursor — used mainly for the hero to be able to move on the map
- Game — a manager that could tie together the components
Some of the more generic concepts were further divided into concrete examples.
Room:
- Hospital — where you could heal
- Lair — where you would encounter a monster
- Shop — you could buy different items
- Vault — a room filled with treasures, but you could only choose one
- Win Room — where you want to be in order to win the game
Item:
- Consumable — potions that would give a permanent change of stats
- Wearable — like a headpiece or boots — they could be changed in the game
- Weapon — similar to wearable, but pointier
Conclusions
I feel even now, after learning so many new things from coding and also from extra research that our design was good. It separated different concepts into easy to maintain pieces that could also evolve at different speeds. At the same time though, we missed some details. All in all, for the first project in Ruby, and also one of the first were we really had to work as a team, we’re very proud of what we achieved.
From the next episode…
Our design came from all the ideas that we had about how we could improve this game over time and if it would be easy or not for us. But we never thought about playing this game on our phones or using a Voice Assistant. You may think now that some sort of separate IO concept is missing and it’s true. We’ll explore more about the technical issues and how we tackled them in the next post: https://tech.2performant.com/the-obstacles-of-our-first-app-as-interns-2223781edc0a
