The very first arcade consoles had only a single game on each machine. Later, as the hardware evolved, software grew alongside the better machines and different games on the same screen became possible. During this development, programmers needed to solve tough challenges like making games compatible for different processors than what they have been designed to run on, or sharing processor time between the running programs. With Linux, the groundwork for these problems is done and we (luckily) do not think about processor instructions very often anymore when creating games, and instead focus more on the games themselves.
With the rise of home gaming consoles, arcade machines quickly began to fade out and the arcade shops slowly got rarer and rarer. Developers made games for the new platforms and the money definitely was in the PC and console market. This still holds true to this day, but there has not been any new development with public arcade machines and the required software to create such a machine. Big projects like EmulationStation aim for a replacement of bulky machines to make arcade gaming more suitable for home use and to combine multiple emulators into a single, good-looking UI. Projects like OUYA want to create a new home console like the PlayStation or XBox systems, but cannot be used to host a real arcade machine in a store in your neighboorhood. This goal needs a project on its own.
The pigaco project (short for Raspberry Pi Gaming Console) wants to create software to make building arcade style games on real arcade machines easier and to streamline setting up machines in public places. The Raspberry Pi in the name is a remnant of the past and no longer applies to the project, it was only chosen becaue a Raspberry Pi was used to develop its networked input system.
The repository can be found on github. A daily generated online version of the documentation can be found here. I advise against using the APIs in their current form for serious development because they may (and most likely will) change in the near future. Any contribution, pointer or comment which brings us closer to this far fetched goal of easier arcade machines is welcome though and I am looking forward to see some of you in my messages.
The project is structured into 3 parts:
To get a better understanding of how the system is built, look at the following image. It illustrates how the parts work together in a better structure than I can express in the text. (taken from the architecture documentation page)
The library handles communication between games/applications and the host program pigaco. This works using shared memory (boost interprocess), the event system of the host computer (keyboard simulation), and the network (over enet; to communicate with external input sources).
The library is built with C++ and should be usable from any C++-compatible engine. If the engine is not compatible with the language, or the developers do not want to modify their product to fit into the pigaco system, the arcade machine maintainer can specify keyboard-mappings (and soon mouse-mappings too) to be mapped to the game inputs sent from the shared library. This can be accomplished with configuration files in the Yaml format in the game's directory, which are looking similar to the one from BomberPi.
The documentation of the library is not yet finished, the most complete one can be found with the BomberPi game. Also, the class which is used to integrate a game directly over shared memory with pigaco is piga::Interface, which is already documented a bit.
Pigaco manages games, shows a game chooser dialog, runs games, receives inputs from its input hosts and processes possible packets coming from the network. To save ressources, it shuts down its own rendering when a game is running and resumes it afterwards. The GUI is selfmade to fit to the multi-user approach of the input system, which requirements are not really met by other UI-frameworks. The program uses SDL2 for the graphics and is not very pretty yet, but it already works well and the moving background is better than nothing.
If you want to see a screenshot of how it looks, you can look at the following picture. If you don't care about the looks and also think that they will get better once the backend is working fine, just ignore the graphical horror contained within it.
Most of the managing stuff is done in piga::Host, but the documentation for this class still has a long way to go before becoming anything useful.
Input hosts are shared libraries with a common interface (a few functions defined in the host header file), which are loaded by pigaco. It then loops through each loaded host and checks for new inputs for every player, which will then be sent to the running game/application.
Networked clients on the other side are controlling the console over the network from a remote location. Maintainers of arcade machines can specify if a console can be accessed by this network protocol and with what password. They can also state that they want to make networked inputs without passwords possible, so that players can play games with more people in one single game using their smartphones as inputs for the console.
The smartphone app and the manager application are not implemented yet (sadly), but networked inputs are working perfectly well already. The networked client is the best example of a working implementation for this.
My motivation to start this project is explained easily: I always wanted to build games and tools which can be enjoyed by other people. I alredy created smaller projects which were liked by my friends and collegues and the next step for me was to create something bigger. The piga library can be used by everyone who has fun in experimenting with new projects and the console which I'm building by myself currently will surely be fun for my friends and me too. With the upcoming port of my old game SFML-Sidescroller, more piga-compatible games will follow too.
In the near future, I like to finish building my own arcade machine and to improve the documentation of piga. Also, the manager application consolemgr should be ready in the next few weeks, so I can control the console from my laptop or phone and develop games on my machine in a better way. Once the whole system works a little bit better, I would like to post a video on YouTube about the console and some footage of people playing games on the machine.
A far fetched goal will be its own networked service with gamer authentication and multiplayer gameplay over the network (this project would then be called Pine - like the tree, but as abbreviation of Pigaco Network), but this sounds way too ambitious to be archieved someday. It's just good to always have something even greater and harder to accomplish, so that I can work towards it and learn new things along the way. Do not count on that feature, this is just a goal way down on the roadmap.
Along the way I want to write some articles about the development of the libraries and about the methods used to write the backend for the console here on gamedev.net. I found some articles here before, but now I feel like I can share my findings here too, instead of just silently pushing my work onto github and do not tell anybody else from the outside world. I hope somebody will find some useful information in these articles or even become interested in the project and want to collaborate or make arcade games!
With the rise of home gaming consoles, arcade machines quickly began to fade out and the arcade shops slowly got rarer and rarer. Developers made games for the new platforms and the money definitely was in the PC and console market. This still holds true to this day, but there has not been any new development with public arcade machines and the required software to create such a machine. Big projects like EmulationStation aim for a replacement of bulky machines to make arcade gaming more suitable for home use and to combine multiple emulators into a single, good-looking UI. Projects like OUYA want to create a new home console like the PlayStation or XBox systems, but cannot be used to host a real arcade machine in a store in your neighboorhood. This goal needs a project on its own.
Enter Pigaco
The pigaco project (short for Raspberry Pi Gaming Console) wants to create software to make building arcade style games on real arcade machines easier and to streamline setting up machines in public places. The Raspberry Pi in the name is a remnant of the past and no longer applies to the project, it was only chosen becaue a Raspberry Pi was used to develop its networked input system.
Libraries and Tools
- libpiga: C++ library to make interfacing with pigaco and its components easy. (C++) (Already working)
- pigaco: Application which lists games and applications on the console and provides shared objects (C++/SDL2) (Already working)
- networked client: Minimal application to send inputs over the network to the console (C++) (Already working)
- pihud: GUI-Library which has been integrated with arcade control options in mind. (C++/SDL2) (Already working, but with only a small widget collection)
- consolemgr: Manager interface to control multiple consoles with a simple, graphical UI. (Qt/QML) (Recently started)
- Smartphone App: Based on consolemgr - used to control consoles and send arcade inputs to a console (more players) (Qt/QML) (not started yet)
- BomberPi: Sample game (bomberman clone), which uses the piga library to get its inputs. (C++/SDL2)(Already playable)
- Hosts (Raspberry Pi GPIO, PC-keyboard, ...): Sources of inputs to process (C++/Anything than can receive inputs) (RPi GPIO and keyboard already working)
Repository and Resources
The repository can be found on github. A daily generated online version of the documentation can be found here. I advise against using the APIs in their current form for serious development because they may (and most likely will) change in the near future. Any contribution, pointer or comment which brings us closer to this far fetched goal of easier arcade machines is welcome though and I am looking forward to see some of you in my messages.
Architecture
The project is structured into 3 parts:
- C++ library to communicate between the programs over shared memory and the network (libpiga)
- Host program to handle inputs, platform-specific code, and start other applications (pigaco)
- Input-hosts which get linked dynamically by pigaco or connect themselves to pigaco over the network to read inputs from buttons and joysticks, and to send commands to pigaco
To get a better understanding of how the system is built, look at the following image. It illustrates how the parts work together in a better structure than I can express in the text. (taken from the architecture documentation page)
Libpiga
The library handles communication between games/applications and the host program pigaco. This works using shared memory (boost interprocess), the event system of the host computer (keyboard simulation), and the network (over enet; to communicate with external input sources).
The library is built with C++ and should be usable from any C++-compatible engine. If the engine is not compatible with the language, or the developers do not want to modify their product to fit into the pigaco system, the arcade machine maintainer can specify keyboard-mappings (and soon mouse-mappings too) to be mapped to the game inputs sent from the shared library. This can be accomplished with configuration files in the Yaml format in the game's directory, which are looking similar to the one from BomberPi.
The documentation of the library is not yet finished, the most complete one can be found with the BomberPi game. Also, the class which is used to integrate a game directly over shared memory with pigaco is piga::Interface, which is already documented a bit.
Pigaco
Pigaco manages games, shows a game chooser dialog, runs games, receives inputs from its input hosts and processes possible packets coming from the network. To save ressources, it shuts down its own rendering when a game is running and resumes it afterwards. The GUI is selfmade to fit to the multi-user approach of the input system, which requirements are not really met by other UI-frameworks. The program uses SDL2 for the graphics and is not very pretty yet, but it already works well and the moving background is better than nothing.
If you want to see a screenshot of how it looks, you can look at the following picture. If you don't care about the looks and also think that they will get better once the backend is working fine, just ignore the graphical horror contained within it.
Most of the managing stuff is done in piga::Host, but the documentation for this class still has a long way to go before becoming anything useful.
Input Hosts and Networked Clients
Input hosts are shared libraries with a common interface (a few functions defined in the host header file), which are loaded by pigaco. It then loops through each loaded host and checks for new inputs for every player, which will then be sent to the running game/application.
Networked clients on the other side are controlling the console over the network from a remote location. Maintainers of arcade machines can specify if a console can be accessed by this network protocol and with what password. They can also state that they want to make networked inputs without passwords possible, so that players can play games with more people in one single game using their smartphones as inputs for the console.
The smartphone app and the manager application are not implemented yet (sadly), but networked inputs are working perfectly well already. The networked client is the best example of a working implementation for this.
Motivation and Future Goals
My motivation to start this project is explained easily: I always wanted to build games and tools which can be enjoyed by other people. I alredy created smaller projects which were liked by my friends and collegues and the next step for me was to create something bigger. The piga library can be used by everyone who has fun in experimenting with new projects and the console which I'm building by myself currently will surely be fun for my friends and me too. With the upcoming port of my old game SFML-Sidescroller, more piga-compatible games will follow too.
In the near future, I like to finish building my own arcade machine and to improve the documentation of piga. Also, the manager application consolemgr should be ready in the next few weeks, so I can control the console from my laptop or phone and develop games on my machine in a better way. Once the whole system works a little bit better, I would like to post a video on YouTube about the console and some footage of people playing games on the machine.
A far fetched goal will be its own networked service with gamer authentication and multiplayer gameplay over the network (this project would then be called Pine - like the tree, but as abbreviation of Pigaco Network), but this sounds way too ambitious to be archieved someday. It's just good to always have something even greater and harder to accomplish, so that I can work towards it and learn new things along the way. Do not count on that feature, this is just a goal way down on the roadmap.
Along the way I want to write some articles about the development of the libraries and about the methods used to write the backend for the console here on gamedev.net. I found some articles here before, but now I feel like I can share my findings here too, instead of just silently pushing my work onto github and do not tell anybody else from the outside world. I hope somebody will find some useful information in these articles or even become interested in the project and want to collaborate or make arcade games!