Taylorcade

The Taylorcade is an arcade cabinet and machine that showcases video games made by Taylor University students.

The Taylorcade was built by Dr. Jon Denning during Fall 2023. The original design was Arcade Cabinet MKII (plans) by I Like to Make Stuff, but Dr. Denning corrected a few bugs and made a few modifications to make the cabinet work better in public spaces. Controller and coin door components were purchased from X-Arcade. The original game switcher was LaunchBox, set up by Jared Sennese, but now the game switcher is BetterBox, a custom Godot+Python system written by Linus Denning.

arcade games  #

The games on the Taylorcade are written by students. As of 2024.09.20, the following games are ready to play on the arcade.

Rate each of the games using this Taylorcade Game Ratings GForm.

arcade features  #

The cabinet features:

Note: I still have some finish / polish work to do, such as a adding a third coat of paint, designing and applying vinyl decals, sealing up light leak from marquee, trimming it out with t-molding, etc. I plan to finish this over J-term 2024.

arcade game guidelines  #

Games need to adhere to the following guidelines before they will be considered for adding to the Taylorcade.

Launcher  #

We are using a custom game switcher called BetterBox to display, launch, and manage the games. This system takes care of killing games and dropping back to main menu (when p1 and p2 buttons are pressed at the same time, or when the game quits / crashes), so you don't need to do anything about that. BetterBox also displays some teaser details about the game to potential players.

Please send me the following details to tease and attract players:

Controller  #

When the arcade is in a public space, there will not be a keyboard, mouse, or active external USB ports for plugging such devices in, so your game must work completely using only the arcade controller inputs. There is a trackball along with buttons for LMB, MMB, and RMB, but it would be best not to rely on these if possible. For example, if you have a menu, make the menu options selectable using the joystick and buttons, and not clickable. If you do need to use a mouse pointer, maybe consider creating custom cursors that will show up noticeably on a large, high-res monitor!

The only "labeling" on the controller is the p1 and p2 buttons, and it's just simple little people graphics. So, the best way to communicate to the player about which buttons to use is graphically. For example, you can use something similar to the image below as a figure along with a key (ex: 1 attack, 2 block, 3 jump). Please refer to the buttons by their number (1,2,3...) or direction (up, down, ...), and not as "top-left button" or "Z key" or whatever.

As for coding your game to use the controller, here is the mapping for each button as a keyboard press. (the controller registers itself to the computer as a keyboard)

Note: d# keys are the numbers across the top of keyboard, not the numpad numbers.

See Tankstick Manual for more details. Use the Gamepad Tester to test the controller setup.

The rightmost trackball button is a "hold" button, which isn't really a button. When the player holds this button down, the trackball ignores any horizontal movement (ignores motion along x-axis). This is useful for golf games, where you don't want any side-to-side motion, only up-and-down.

Tip: Player 1 Start (p1) and Player 2 Start (p2) keys could be used to start your game from the main menu...

Generally speaking, do not require any other key to be used to play your game except for what is given above.

System

UI

In general, you should try to make the game feel as complete as possible. Title screen with brief instructions, proper end screens that take you back to title screen afterwards, clear beginning, middle, and end of the game, etc. Your game does not need to be big with lots of levels, complex mechanics, several mini-bosses, etc. Just make it a complete demo.

Please set your game to start full screen (not maximized window), and to scale your game to fit the entire screen. You may use black bars to keep your aspect ratio.

Framerate

Do NOT depend on the game running at a particular framerate or processor / graphics speed! The machine inside the arcade is different than your machine, and someday we will upgrade the arcade machine. You should take into account the delta time for each frame, and simply multiply it into your motion calculations. In other words, your game should play basically the same whether it runs at 20fps or 120fps. Watch this excellent video or come talk with me if you have questions.

Binary/URL

The game can be developed using any game engine (ex: Godot, PICO-8, Scratch, GameMaker, Unity) as long as the the game can be played outside the engine's development environment. In other words, the game should be able to run on any machine by running an executable binary or browsing to a URL.

I'm still investigating nice ways to handle web-based games (ex: wrapping them in a thin browser, such as Electron, see alternatives), but Chrome has a decent enough "kiosk" mode that should suffice for now. If you do have a web-based game, please make sure that it is hosted somewhere that will stick around for a long time. There are several past GameJam games that no longer work now, because the jammers lost their hosting or deleted the files. (or consider sending the web files to me, and I'll host them somewhere permanent)

If you make a Scratch game, you can use TurboWarp to create a standalone executable for your game. (wraps your Scratch game in an Electron app)

If you build your game in Python (ex: using pygame), use a tool like PyInstaller to create a executable and distributable version of your game.

Assets

If you used any assets (images, sounds, music, etc.) that you did not create yourself, please send me references! (note: you don't need to reference assets that are built into the game engine, like the Godot logo). In general, cite any content used that you didn't create!

photos

Here are some in-progress photos from the build.