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.
- 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.
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
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.