Rage Chess
Rage Chess began as a project to help me decide if I liked working in the XR field, and has “ended” [Rage Chess will continue to be developed] giving me that answer. I had an amazing team: Valerie Nierenberg, Kyle Whitten, and Peyton Smith. Together we were able to tackle a brand new software, manage networking, and building a functioning VR game. It was challenging, overwhelming, and incredibly fun experience.
Day one was a complete blank slate. We had zero knowledge collectively on where to start. We had experience with playing VR games, but the development side was quite the mystery. We began to research and quickly landed on Unity as our game engine for its ease of use and because of our access to the Pro version through our school. We all began to familiarize ourselves with navigating the software as we began the next stage of research.
The main focus was creating a viable VR experience that matched our MVP. We wanted to create a VR online multiplayer chess game, in which, players could express frustration, through “Rage Elements”. Luckily, there are many resources on creating VR games, and although there were a couple options, we chose the XR Interaction Toolkit within Unity. It was a good balance of being entry level enough for us to get started while also having functionality within several other plugins we would end up using.
We all began to follow some basic tutorial on creating simple VR scenes with intractable objects. At first this could sound boring, but the pure joy of loading into a virtual world, however simple, that you created, and messing around, is incredibly rewarding. It was blast to play around with basic components and begin to see the path forward form. I personally loved toying with the idea of “alternative hands” and at one point had mapped two five gallon bucket models onto my controllers to be my hands in my virtual world. It sounds silly, but it really let me see how customizable VR was going to be.
We began to build our environment for Rage Chess, quickly finding that our best bet was to use free 3D model assets. Rendering our own models would be too time consuming and was as goal for a later date. The “room” came together fairly quickly and as we begin to add functionality to the objects the game started to have some real life to it! It was incredibly exciting to see our idea start to grow. It was also a nice “return home” for me personally. I love C, it is my favorite language, it makes sense and is so beautifully clean, but it has its shortcomings. Unity uses C#, which is a fantastic marriage of some elements of OOP and C. It was not too hard to pick up, and it is one of the items of this project that really began the desire to work more with XR (as much of it is C based languages).
As we began to settle into Unity and the XR portion, we had to refocus on what exactly was the heart of Rage Chess. We had been advised that multiplayer was a difficult thing to implement, without having a deadline looming overhead. We researched what it would take to have a bot play against us in the world, but quickly came back to multiplayer, because we felt that Rage Chess really was built to have two humans duking it out over a board game.
We decided to march forward with finding a viable tool to build our multiplayer world and found Photon Pun. It is a service for creating online multiplayer games. It had functionality that worked with the XR toolkit we were using and married in rather well. While Photon is amazing the documentation can be vague at points, so finding out that you can’t have two devices connected to the same network was a surprise, as well as finding out about Remote Procedure Calls (incredibly important but not very visible to someone new to the plugin).
Photon, from a high level view, is a server that synchronizes data between devices connected to it. In our case it synched positional and rotational data of both our players and any intractable object within our game. Photon really became central to the project quickly. Anything that was interacted with had to be modified so that it would be passed through the Photon network. Each element that had to be synched needed a Photon View, which is a unique ID to keep track of elements, and a Network Grab Intractable, which controlled ownership of the item between the two players.
These two elements caused a snag when it came to how we were generating our scene. We had wanted to spawn our chess pieces on a grid upon entering the room, but found that doing so led to problems with repeating Photon View IDs, and while this can be fixed through the C# scripts, we found that it was easier, and probably better to just have the elements already created and placed, rather than using extra “horsepower” at startup.
Next was taking the chess room and really beginning to add some “game” elements, like save and reset buttons. This is where I really enjoyed myself. Lots of time and frustration went into the simple save and reset functions, and while work remains to be done to clean up their functionality. I am very pleased with how they turned out. What seemed rather daunting, lead to a rather simple solution. Lots of forums talked out the complexity of save function, and for many games they are, but for us the beauty is that we were already accessing and using positional data. So we realized that we could create an array of objects that could be reset, and an array that stored the position of the elements (vector3 data). When needed we would simply “grab” the array and cycle through the objects and force the old position onto it. It worked wonderfully. Now, the issues with it: momentum seems to also be stored within the object, so if reset is hit before the object have stopped moving, that momentum is still there whenever the position is reset, and the pieces will just fly right back off the board. This is something that we can fix with some additional research into how those objects data is stored and accessed, but for initial presentation it was something where reset can be hit a second time right after and the pieces will have settled, and that was and “acceptable” use, so we could move on to other problems, like making sure both players boards reset.
Photon does not handle all the work of our game, it actually handles a surprisingly small scope of what is happening. Most of the content is running locally on the users device. Adding networking to grabble objects was rather straight forward, but when what is being done is function calls, syncing those are a bit trickier. It took some time to find that a really nice feature of Photon is it’s Remote Procedure Calls (RPC). These allow us to take a function, and run it for both users rather than just locally. In the case of our save and reset button, reseting the board is not a “grab” action, so it’s not happening on the network. So one player would see the board reset while chaos remained on the other side. When the RPC is implemented it affects the Photon View object and not just the local object.
The problem with RPCs was not in the use, but in the syntax. We had to search for quite some time to find out how to properly use them. The documentation was not clear and lead us down some rabbit holes. Eventually we found a forum with a code example that let us know our problem was that both the method that was calling the RPC and the actual “remote method” had to have the RPC tag (eg: [PunRPC]) attached to the method.
I had a wonderful team that really did come together to create something incredibly fun. We all started with almost no knowledge and came out the other side having learned way more than we thought we would have. What was first massively intimidating has become motivation and ambition to continue to challenge ourselves and “finish” Rage Chess, as well as create more VR experiences!
We finally had a game. A VR online multi-player game, and it is fun! We have had the joy of it being some peoples first VR experience and it really has been an eye opening experience. Rage Chess really did answer my questions about XR and I found a passion for it. I am so excited to continue development with my team outside of school. I am looking forward to taking steps to get the game to a commercially launch-able state so that more and more people can experience it. I am especially excited to join and support the VR community as it continues to grow and evolve!
I am Ayden Townsley, a software engineer in Tulsa, OK. I am so thankful you took the time to read my article on RAGE CHESS and hope you are as excited as I am about the future of XR development. You can find a link to our GitHub project page (where you can find an apk of our project) as well as my other info below.
Github Repository: https://github.com/aydentownsley/RageChess
Website: https://aydentownsley.github.io/RageChess/
Linkedin: https://www.linkedin.com/in/ayden-townsley-1847a4133/
Team Roles:
It is worth noting that these roles are more about who felt more comfortable discussing the cited area. This team worked together on all aspects of Rage Chess
Valerie Nierenberg: Deployment & Docs
Kyle Whitten: Asset Integration
Peyton Smith: XR Toolkit
Ayden Townsley: Networking