Posted by Todd Rivers (Owner of RDI Studio) on September 17, 2017
A couple of weeks ago I decided to take Brain Dead, a slots game that I designed over a year ago, and convert it into a Brain Dead Keno game. ‘Convert’ means that I was to take as much of the art and theme from the original slots game and use it in the new keno game.
In order to complete the game within a couple of weeks, it was imperative that I have several systems and techniques already in place. My whole concept of rapid prototype development is to be in tune with and take ownership of the entire games development process…That means I design and program everything, from the art production to the UI and UX designs.
Fortunately, for many years now, I have a template UI and UX design for each of RDI Studio’s casino game types, including cards, slots, and keno games. The ‘dash’ button set for a keno game has already been laid out and programmed. I simply have to change the look and feel of the overlying artwork…plug-n-play, so to speak.
Of course, each ‘game engine’ is different; and, adjustments need to be made to the art and the programming to accommodate game features. Having a baseline keno game already done, however, makes creating a new game so much easier.
Once I have a game engine in mind, my first step in prototyping the new game is in creating the Help screens. By organizing the new game with a succinct set of words and images, I can make my to do list. While I am inside of the code, it also helps to have the Help screens available, as reference in the development of the game’s ‘controller.’
I tackle the art production next. The Help screens will notify me of the new images and animations that will be required. My art production pipeline is decidedly ‘2D’ in nature. I have a preferred set of tools, including Adobe Animate, Bridge, and Photoshop, that allow me to quickly populate sprite sheets. All images for the game are essentially PNGs and PNG sequences populating these sprite sheets.
If I am lucky, converting a slots game to a keno game will require little to no sound additions or editing. All of my games have win tunes that are based on seven winning tiers; so, the win tunes would not have to be made again. In fact, for Brain Dead Keno, I only had a couple of keno spots HIT sound effects that needed to be added…no big deal. I have a complete library of sounds and sound resources already available.
Similarly, themed games will have identical bitmap fonts; so, those assets would not need to be created again either.
I am meticulous with my art production files too. So, before anything is programmed, I have already created annotated layout files within Adobe Animate. And, by ‘annotated’, I mean everything in the .fla files gets a description. As an Art Director for a couple of casino gaming companies, I taught everyone on the team the importance of art work labels. No production artist wants to search for a missing font, when it can just as easily be gleaned from a label within the art production file.
For the very same reason, I carry my labeling obsession into the programming code. I find it imperative to label variables with very specific names and to leave a trail of ‘bread crumbs’ in the form of comments within the code explaining my reasoning behind a particular piece of the algorithm.
Coding the prototype is, of course, my last step in the game development process. I have the programming files for all of the other RDI Studio casino games; so, I use them as a quick reference.
Because I have detailed art production layouts, I can make quick work of incorporating the new art into the code. Determining x-y coordinates is as simple as referring to the info tool within an Adobe Animate file.
A majority of the time used in converting the former slots game into a keno game is in programming the new game rules. Creating the game’s data simulator alone can take the better part of one day. The remainder of my time is spent incorporating the game rules and adjusting the UX timings. Fortunately, I already have an Events manager in place; so, that is fairly painless too.
for the frequency of bonus features and the appropriate size of multipliers etc. Art changes can be quickly made and incorporated into the code to accommodate any math changes…This is perhaps the best feature of rapid prototype development…Get it up and running to see if your first stab at the math is any good.
The aforementioned series of steps is described as linear in fashion; but, of course, the whole rapid prototype development process is a continual ‘back and forth’ between code, math, and art production files. Make art changes. Create new sprite sheets. Adjust the code. Search for the bugs. Fix the bugs. Run the prototype on your desktop and check that the fixes work. Rinse and repeat.
In a former life, I was a mechanical product design engineer. The digital product rapid prototype cycle I describe above is very similar to the physical one…except it and the rewards are much faster. :)
Please feel free to contact me on the www.rdistudio.com web site if you have any questions concerning this topic or need help with your own art production or game prototyping needs.
Todd Rivers, Owner of RDI Studio