Mulitmouse is a collection of minigames where players can plug multiple mice into their computer and have each mouse control its own pointer (default behavior is to have all the mice influence one pointer). The game is coded in C++, using the ManyMouse Library for splitting the mouse input, Box2D for physics, OpenGL for primitives, and SFML for windowing, text and images.
Because the manymouse library has to get data from very low level sources I thought it would be unwise to try to retrofit it into an existing game engine, meaning all gameplay code was written by me. As this project was meant to more be exploring the design space of multiple mice in one game, I knew my #1 priority when it came to developing the framework to build my minigames off of would be flexibility. Designing and implementing the base framework has given me more C++ experience for sure, but I think more importantly it gave me experience trying to build a codebase that I would be working off of for more than just a semester. In addition I knew the framework had to give me the freedom to make many types of minigames, while still giving me the building blocks to make implementing a new minigame a quick and simple process. I believe I succeeded in that goal
Over the course of this project I would run into things where in order to keep the project in scope, I would need to make baby versions of some of the systems I've come to know in the engines I've used in the past. For example, I made a func-timer object that would take in a function and call that function repeatedly at certain time intervals, aiming for a simple version of Invoke Repeating or Coroutine system in Unity. The most interesting example of this in my opinion would be my "scripting" system. I often found myself needing to write small functions, often just to set things up on a certain object, that really only pertained to one minigame. I kept thinking that Function pointers didn't have the flexibility that I wanted, and after some digging I ran across this blog post: C++ Delegates. This was exactly what I needed, and combining them with lambda functions I was able to create a very basic scripting system that would mirror being able to write Start and Update functions for Monobehaviors in Unity.
My favorite part of this project has to be just how simple and quick it is to get a new minigame up and running. Each minigame consists of 3 scenes, instructions, main, and gameover. Instructions and gameover are made using a helper function, and you simply supply some text and an image and they are set. Main is where things get interesting. Here all you have to do is add some objects (Their behavior is already all set to go), including some extra behavior through the update delegate if you need it. This will be about 20 lines for a very complex game. After that you add a win condition into the minigames update method, and you are set. You have a complete minigame! At the current point in the project this framework has really taken form, and I am hoping to start pumping out minigames over the course of this next semester.
