Introducing Ruby & Rails Dungeon App
This application is a tribute to old school hack and slash dungeon crawler video games.
Its goal is to provide players with a fun and fast game, but, most of all to challenge myself, and learn Rails the hard way. It’s a Rails adaptation of RPG Command Line Interface games, with a full database, registered users, and several models, each with their unique attributes and specificities.
After having learnt Ruby & JavaScript with Launch School, and Rails on my own, this is my first big, entirely personal project, and I’m proud of it.
Visit the website | See on Github
Tech Stack
I developed this app in Ruby, as I’ve spent the past year learning programming mainly through this language. I always loved Ruby’s object-oriented design, and that’s what I used there, but with a twist. I used Rails as a framework, and chose to work with registered users through the Devise gem, and a database.
This game being mostly a toy app, I disabled devise email verifications and confirmations. So, you can use a fake email for the account creation, as long as it looks like a legit one.
I followed a test driven development approach, and I’ve wrote a comprehensive test suite (with Minitest), to safely refactor and prevent regressions, which came with some more challenges.
Being mostly a back-end developer, I used Bootstrap for the first time, both as a challenge, and to get a better look. I settled for a minimalist design, made primarily to be used on a desktop, as my focus was not on front.
I deployed the application on Heroku, because it’s a free hosting service (its hosted onto an EU server, so US-based users might encounter some latency).
Challenges
I faced many challenges through this project:
- I used Rails and databases, and combined it with back-end OOP vanilla Ruby.
- I had to use fixtures to properly test my application.
- I used several tools for the very first time, like Bootstrap and the devise gem.
Why did I choose to use logins and a database?
Mainly as a challenge, and as a way to teach myself these elements. For short dungeons like this one, that you can complete in less than a minute, a simple session would have worked just fine. But using a database also has its perks.
Thanks to the database, a user can create up to 3 games, play a few moves, leave the app, and start where he left later. Also, no risk of deleting a game with an accidental refresh.
The registration system also adds a security layer. The app creates a new game object for each new game a player starts, and you could easily guess that if the URL of the first you created is https://ruby-and-rails-dungeon.herokuapp.com/games/25, there was a game 24 played by someone else, that you could access with https://ruby-and-rails-dungeon.herokuapp.com/games/24. But you can only do so if you are logged-in as the user who created the game, and you'll be redirected to the home page otherwise.
Then, most of the back-end work is done in the game model, which works with local class for combats and events, computes the hero’s gains and losses, and then update all the objects that have been affected with these choices (the rooms, the hero, and the messages that the view files will show to the user).
This constant back & forth between the game controller, the game model, and the view files that will collect the player decisions made for some tricky design, and taught me a lot about the subtleties of Rails.
How to play
The game start with a title card that explains the rules.
Once you click START, you access the game screen, with several elements.
You’ll play on the board, which is a 4 x 4 table. It is generated from the room objects every time the page is actualized, either through a request (that modifies it) or a classic refresh.
As you move, encounters will take place then their icon will disappear. Every room the hero has visited will be marked as “visited” through an attribute, and will have a red cross icon. Going to an already visited room will have consequences (see message bellow).
Next to the board are the hero’s stats, that will evolve through the games. Once you reach 0 health points, you die.
Below the board and stats tables, are the game messages. They are created through messages objects, that are related to a specific game. Once a message has been output, and the player has chosen his next action (move or choice), it will be automatically deleted.
The user interacts with the game thanks to form buttons, that transmit their choices and moves to the game controller.
Depending on the board position and adjacent walls, the player can choose between 2 to 4 directions.
Choices are a specific kind of encounter. They involve 3 propositions, and some bad dev jokes.
I used a custom class for all elements of the game, giving them access to both the retro gaming Press Start 2P font, and fade-in transition animation.
The game will end if you defeat the boss, or die at any point. Be it a victory or a defeat, you can then choose to play again. It will automatically delete the current game, and either redirect you to the home page if you’ve got other saved games, or create and start a new game for you if you don’t.
