Lessons Learned Implementing Game Logic in Rails

Robin Tully
May 23, 2016 · 5 min read

60 percent of Americans play video games, and the overall video game industry reaps in over 20 billion dollars a year. It is an ever increasing cultural medium, and must be explored in ways that are not strictly related to trying to hack any daily product into being able to run Doom. Web developers must appreciate this domain and must learn the trials and tribulations of game development. This blog post serves as a minuscule parsing of lessons of a beginning developer into this domain.

Over the last few days, I have tried to channel one of my passions into code and have been working with a group of four people on implementing a multiplayer real-time game with Ruby on Rails. This project has taught me numerous things about the Rails and underscored the importance of other lessons in ways that were not wholly apparent in simply trying to pass tests written by other developers. It is my present intention to try and elucidate some of these difficulties and lessons to both affirm what I have been learning and potentially inform others who wish to undertake the task of implementing games with Ruby on Rails.

  1. Enrich your data through default values and restrictions on the database

It is all too easy to rely on the notion that the database must be malleable and broad, and any limitations on the database must be abhorred as any selection can be made when drawing from it. Although such observations are not entirely unsubstantiated, one must find a careful balancing point. The aforementioned group project includes a database that stores at times thousands of potential options for player choice, and at even this relatively small scale the need for certain rational limitations has already become readily apparent. If the database is properly limited and has accompanying appropriate default values, it becomes substantially faster and more accessible. The UX of your players becomes drastically improved as well, as the performance of the app is improved with data being properly curated on the initiation of entries in the database.

2. Rails is not the ideal language for Game logic.

Rails shines brightest as a quick and simply way to immediately launch a simply web app or site. Yet, its emphasis on the MVC framework and its backend strengths can often seem antagonistic to implementing a fully featured and integrated game environment. Creating a responsive front end necessities the use of multitudes of Javascript AJAX calls and cable hacks. Thankfully Rails 5 has integrated cable features simplifying the process but throughout the project’s development, I have often wondered how much simpler this might have been had it been implemented with MEAN stack. When trying to create a single page web game, the reliance on strict MVC paradigms begins to be demonstrated. The greatest strength perhaps of Rails in implementing this type of project is that is has allowed for easy to read code that is easily digestible across the entire team; yet alternative paradigms and languages seem like a pertinent and future solution.

3. Be careful with the interaction of Javascript and ERB tags

It appears that ERB tags are only evaluated once when triggered as a result of Javascript buttons. The rational for why this may be the case seems understandable enough. Upon evaluating what HTML content is to be displayed, Rails will interpret the ERB tags first and then pass that information onto the browser. While this may not seem to be much of a problem, it can cause problems when the button’s resulting logic includes randomization that is determined on the view page. The ERB will store the information once, and such information will not be re-evaluated when the Javascript call is raised again. My project encountered this problem when trying to create a button that rendered a new randomized GIF. While the ERB tag was capable of selecting one random GIF, the ERB evaluation wouldn’t change on subsequent presses and thus repeated clicks would only return the same orginally determined GIF. The solution for my project was to treat the GIF storage in the same way that a deck of cards would be treated, Randomly generated but the top card is always drawn. Other work arounds exist as well but encountering this angle on randomization was one of the most curious yet logical hurdles encountered in developing the project on the rails platform.

4. It is easier to read the past then to try and write to a potential future

This lesson is simply a fancing way of the well known idea that computers essentially read script sequentially and chronologically. The hurdle encountered by my group can be expressed in the idea that during the update action of a round (assigning a winner to that round), a Judge for the next round needed to be determined. The initial logic for doing so resembled the following.

Round.find_by_id((round.game_round)+1).judge = round.winner
Round.find_by_id((round.game_round)+1).save

Yet, try as I might I simply could never get this information to properly save. Upon re-evaluating my options, it became apparent that it might be simply easier to just evaluated the data that already existed in the database to determine who would be the judge for the current round. The end code is the following

 @judge = Round.find_by_id((@round.id) -1).winner

This code is seemingly more elegant then the previous option, and relies upon accessing information that has already been saved, rather then trying to update multiple attributes of nested resources in a disparate update action. The lesson can be explained simply, do things simply and work with what you have.

5. When in doubt, Pry

The final lesson is oft repeated yet wholly important. Pry is your friend and should be used frequently. Use it to plan you next steps, evaluate your code, and find bugs and you will be well on your way to enriched code and an enriched end product.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade