WVU CS 475 Game Development Final Project
Dev Leader: Jordan Hallow
Devs: Zack Muniz, Ryan Kubik, Paul Drummond
Objective
We were tasked with building an arcade cabinet using whatever material and equipment necessary. Then we had to port old games onto the cabinet so everyone could play their games on the cabinet. We had decided to at least have 10 games on the cabinet to give everyone a fair library then add more depending on how efficiently they ported. The first thing the group had to do was figure out what kind of hardware was going to be running in the cabinet.
Hardware
We decided a Raspberry Pi 2 B was a suitable option for the game cabinet given its 4 GB of RAM and 4 quad core processor. This microcomputer is equivalent to a laptop computer less than 5 years ago. Once we had this information we delved into options of accessories to make the job a little easier.
We found the IPAC-2 a bus board that produces keyboard input after wiring up switches or buttons to it. It is the IPAC-2 because 2 players can play on it. There is an IPAC-4 for 4 player options. This micro controller saved us from trying to disassemble a keyboard and individually farm inputs from it.
Once the internals were set and ready to go we had to pick some exterior hardware to produce the image to and interact with it. We used light up buttons that contain a rocker switch at the bottom for the input mechanism. These buttons have option for single or double throw but since we are only using when a button is pressed we use the single throw portion. The joysticks were 8 directional joysticks with 4 rocker switches built in. We then ground those inputs into the IPAC-2 to give it the voltage differential. The lights inside the buttons are wired in series and plug into a power strip with a modified phone charger powering it. These lights are grounded to the IPAC-2 as well.
For video we initially bought a 8 inch HDMI LCD display to work with since the Pi was small. Our leader had an idea for the board to be much smaller than the finished product so he thought a small screen would be sufficient and we agreed. Once we started working with the cabinet the size of the playing area increased to accommodate 2 players. This made the 8 inch screen obsolete so we decided to use a 22” monitor mounted to the back of the cabinet. This monitor was a good size for the cabinet and supplies a much better system for 2 player action.
For audio we purchased a set of Amazon Basics speakers. They are powered over USB and take input through a 3.5mm audio jack. The sound on these are decent quality but cannot go above a certain volume before running into crackling and clipping problems.
Design
Illustration 1: Iterations of the Cabinet
After we had settled on the initial hardware set up we had to figure out where it was all going to be stored. After some rough sketching we came up with a few profile designs as seen above. We then measured the pros and cons of each system and ultimately went with the last design since it gave us more room to fit all of the hardware and was still sleek enough looking to look good aesthetically.
Once the profile was taken into account we measured two people standing next to each other to get an idea of spacing and playable area dimensions.
We decided to make the game pad area 32 inches across but this can be modified to fit the cabinet builder needs. It is not suggested to go much smaller however. This will cause some space issues with your players. Once we had the boards cut we put the cabinet together. This is where our first issue arose. ¾ inch plywood is not aesthetically pleasing to look at. So we got some paneling from donation if Zack helped tear it out of his friends house. The paneling made the exterior look much more flushed and polished but the edges were still rough. We bought a rubber hose and lined the exterior with it to give a buffer between the user and the harsh edges of the game pad.
Illustration 2: Profile Details and Two Player Board Area
After all of the modifications to the design had been done we had to figure out a button configuration. Ultimately we came out with the configuration seen in Illustration 3. This layout went through a few iterations as well but they were all to linear looking and not form fitting to the human hand. When we started considering the curvature of the metacarpals of a human body we decided an arching structure would be more sufficient. We then used a 25mm Spade Bit to cut the holes of the buttons and a 32 mm spay bit to cut the joystick holes. This gave ample room to move the buttons and joysticks around without being able to lose them in the hole.
Once everything was set in where to go into the cabinet and how the exterior should look it was time to start mounting everything in. First, we mounted the buttons and joystick in and used cable connectors to attach all of the wiring to the appropriate ares for use. Once the buttons were mounted and tested the IPAC was mounted in the center of the game board to provide the correct distance between the two control schemes. Once we had the IPAC mounted we needed to make the Pi centralized to the Ipac so we mounted it along the back wall to give maximal access to all peripheral devices and the IPAC-2. Once the Pi was mounted it became a trivial matter of placing speakers and video outputs. The speakers are mounted with a standard method of wooden blocks below and a screw mounted above to hold it in place. The video cables are ran out of the same hole in the back as the surge protector. Once those things were in place it was time to start into the software.
Illustration 3: Button Layout and Binding
Software
The software section of the Pi proved to be a little more confusing than we thought. However, the process went as follows. First, we installed Noobs onto an SD card this is basically a menu for OS installation. Then we installed Raspbian to the SD card at the same time. We then launch Noobs which installed Raspbian. This was our first success on the software side. We then hooked the video up to the Pi. The Pi couldn’t recognize the resolution so we had to manually set it to the 8 inch monitor. Once that resolution was set in the config.txt document we had trouble running more output out of the USB terminals to run the lights and the button configuration. After fixing that problem we had everything running smoothly on both the monitor and the I/O of the Pi. We then upgraded our video so the config.txt was adjusted accordingly. Then the audio was not working with the speakers. We had to install some software to get the drivers working and ran it in rc.local on boot. Once we had all of the essentials in the machine we then started migrating the games form previous years onto the cabinet.
The games were some of the most tedious parts of the project. As meticulous as the building process was the game ports were even more strenuous at times. Aside from mapping button presses to the correct actions in the code we ran into problems with directory accessing and asset expansion in Pygame. However, this is discussed more thoroughly in the problems section. So we ported all configurations and assets to our files systems and got everything operating at about 80% efficiency. We had to add a few calls for certain functionality such as escape calls to exit the games without crashing the whole program. Once added we implemented in a menu system which funtioned just fine but we needed a front end for it. We decided to go with a JSON front end to make everything look a little more user friendly since a text based menu may be hard to navigate with joysticks and buttons. Once we had all of this we were ready to present the final product.
Illustration 4: Outline Of Station and The Underside Picture
Problems Encountered
Software
This would not have been a semester project with some major hiccups along the way. First, it took us a good portion of our first meeting to figure out how to install the OS on the Pi. Since now of us had ever worked on something like this we were inexperienced and had to follow many tutorials on how to do so. Before we could get the OS on the Pi a SD card reader died and we had trouble troubleshooting that problem. We also tried the OS RetroPi but unfortunately while it would have made our lives easier it wouldn’t work very effectively with our Python codes. Once we had the OS on the Pi we noticed our second problem. Porting the screen resolution onto the Pi became a bit of a task when it came to the 8 inch monitor. It took Zack about 2 hours to get that all straightened out mostly due to the fact that he didn’t know about the config.txt document in boot directory. To do this you have to enable overscan and manually stretch the image using overscan_:left, right, up, and down. Once we stretched that image to correct dimensions we noticed that the image was very tiny and not playable between 2 players. We then just started using random monitors till one came in in the mail and the process restarted.
Once we had all of our resolution problems handled we started trying to port the games. This was a slow process since not everyone’s games would exit gracefully. We had to catch multiple bugs in the code before we even started fixing asset sizes. Once we had done the initial troubleshooting we had some issues when we went to full screen. Full screen caused problems with asset sprite not expanding, game fields not expanding, and counters, scoreboard, etc not being in the correct positions. After sorting all of this out we still had some problems with assets not binding correctly to directory locations. We had to redo some of the file structures just to get the assets to work correctly.
Lastly, we were trying to get our menu to come up on the start of the boot process. First we did this through the rc.local file and just ran a python script to execute the menu. This wouldn’t work because the OS details weren’t loaded yet so we would error terminate on boot. So after fixing our boot problem on another computer we then made a shell file that would execute the code directly after booting. This produced our menu correctly but would layer the menu too soon and the OS would boot behind it. This meant that when we loaded up the games it would open in the background behind the menu and would give part control to the executing code and little control to the menu. We would then have to go into the terminal mode of X-light and kill all running Python processes. We decided to scrap the auto-run menu on boot shortly after due to time constraints and hardware research.
Hardware
A suggestion to future cabinet builders. Use a table saw or a band saw to make your cuts. Zack had many problems when cutting the wood. Using a circular saw is fine and it was close enough to hold the cabinet together. However, a good table saw would make a world of difference with the cutting. It was a little difficult to keep the saw level during all of the cuts so a file was used to sand it down to level. This is too much effort to get right and would’ve saved time to just use better equipment. Also, use ½ inch plywood with paneling on top. We had problems once we added the paneling of the buttons not going back on correctly and had to insert cut some holes for them. Also with using smaller plywood would be a weight differential in the right direction. I will recommend that instead of using hose as a boarder find some rubber paneling to use. This will help with cutting time and curing time for the glue.
When it came to the lighting we had issues with connections not being made in the channel lock of the connector. This could be remedied with using solder in the channel or hooking the wire around the metal. That would stop all flickering and button loss that we encountered. We remedied some of the problems with hot glue just to keep the wires in place. I would suggest using bus wires or serial cables in the future to keep everything modularized.
When it came to the Pi we ran into some trouble with the hardware as well. We had problems with the output voltage of the Pi initially. This was due to the fact that we didn’t know you could set a
current value in config.txt to output higher current to the USBs. Once we had that we were able to power both the Ipac and the speakers without losing all power like what was happening prior. I would suggest to ANYONE working on a Pi to get acquainted with the config.txt in the boot directory.
Once we had installed the speakers we realized no sound was coming from them. We dug into the package manager and pulled out the software needed to run the audio. There are multiple so I will
not list what that was here just in case there is a better one when anyone makes their own cabinet.
However, once installed you have to run the command in terminal every boot to get audio to work. This meant that we had to figure out how to set it upon boot to run the command in terminal. Since we were all new to this idea we had to research how to do so. After much research we found that you can run command on boot in rc.local file in the etc directory. So once we put that in there in the correct order we had audio working after every boot sequence.
There were little problems found here and there about the wood and the wiring but these were easily solved with a little work. Nothing worth reporting since it was all solder error or screws coming loose.
Conclusions
Overall the project was a pretty good experience. We had a lot of work with the hardware portion of a computer as well as a software side. Getting these two sides to cooperate with one another
was a challenge occasionally but was very rewarding regardless. This taught us a lot about time management and what it meant to be able to rely on a team to distribute the workload. Our overall
product wasn’t exactly where we wanted it to be in the end but the major elements were there. Given a little more time and research we could probably take the cabinet from a 97% done to 100% in very little time. Aesthetically we would need to clean up some code but that can be remedied fairly easily at this point. We have made it pretty modular on how to port in games so a developer should be able to pick up our menu and figure out how to import their game fairly painlessly.