Project Overview
The original Collaboration Station was written in Java using PlayN. We used Bluetooth for local multiplayer, developing our own protocol by reverse-engineering some of the tricks used in SpaceTeam. In particular, we figured out how they had used Bluetooth device name mangling to figure out who else was playing the game in local range. This worked fine for our Android version of Collaboration Station, but we hit a barrier when we tried to build the iOS version, since the particular Bluetooth function we needed to call was blocked by the operating system. (I'm still not sure how SpaceTeam got around that one.) For Enhanced, I decided to go with Unreal Engine 4 and the GameDNA Realtime Database plug-in, which brings Firebase support to UE4. I learned about this integration as a result of some conversations at GDC 2016; given my experience with Firebase and the cross-platform builds facilitated by UE4, this seemed like a great match.Building the core functionality and architecture of Collaboration Station Enhanced took longer than I expected. As I mentioned in my write-up of Fall's Game Programming class, I had hoped to have the basic pieces in place early in the Fall semester so that students could write their projects as ad hoc plug-ins to my system. In fact, I was only able to implement one sample minigame—memory—in the Fall and get roughly half of the multiplayer implementation working. Some of the delays came from the fact I was using a beta version of the Realtime Database plug-in, and I did have to work with the developers on some critical defects. I also ended up having to get the GameDNA Ultimate Mobile Kit plug-in to allow anonymous sign-in to Firebase; this may now be wrapped up in the other plug-in, but it was no great concern at the time since the budget had plenty of room for such expenses.
 |
| Experiment Sorting: Memory Minigame |
Working with the Student Team
I hired three undergraduates through the grant to work with me in the Fall, using the job titles Game Artist, Game Programmer, and Game Educator. I put together a good team, but there's a sense in which I was not really ready for them for several weeks. I had hoped we could work together for sustained times during the week, but our schedules did not mesh well; there was only one one-hour block MWF afternoon that we could all meet together, so we settled on that. I put the Game Programmer on the task of writing the sequence puzzle ("Simon" game), but I didn't really have the underlying systems in place yet to piece everything together. It took him longer than I had estimated to finish this task, though, and so we never really had any painful merges. I gave the artist some odds and ends to work on, but we never had the right workflow. Technical problems in the studio led her to work elsewhere, but I didn't realize how badly this set us up: she was working mostly independently, and she never got into the workflow of being able to add things to the game herself. That is, she was off version control and outside of UE4. It wasn't until the very end of the project that I realized she was unable to run the game herself at all. A result of all this was that she spent a lot of time on assets that we just couldn't integrate, for technical and aesthetic reasons. The game educator was the one student who worked most independently, but in truth, I let him work perhaps too independently. We sought some feedback from education experts on campus, but he mostly developed the revised Web site and teacher resources by himself. Both of these things take careful design skills, and what he made is sufficient, but I think our lack of communication contributed to a lack of polish.Looking back, I probably could have handled some of the communication and planning better, but there's not much I could have done to improve the rate at which I completed my tasks. The students did a reasonable job of keeping up with the tasks I could think of, but often I couldn't remember what I asked them to work on! Given that we didn't have much face-to-face time, tracking tasks in something like Trello or even just a spreadsheet could have helped. The main impediment, though, was that my mind was full enough of the work that I had to do on the project, plus my other professional obligations; it was just too much to try to remember where they were as well.
 |
| Exercise: Sequence Puzzle Minigame |
Game Design
We did accomplish two significant improvements to the game design. The previous sequence puzzle was based on four somewhat arbitrary ISS factoids, chosen mainly because we could develop good images and sounds for them. We revised this into an exercise minigame, where the sequence of actions represented three authentic exercises astronauts must perform in space. The other improvement was to the sliding tile game, which used to be a single image of a humanoid robot developed by NASA for use on the ISS, but it had no contextualization—a player would have no idea what they are looking at. Now, this game is "telescope alignment", and there are four random constellations chosen from the Southern Hemisphere. We hope to inspire the player to look up more information about them by showing constellations that will likely be unfamiliar.One significant change between the original and the enhanced game is that the original divided the minigames into "science" and "maintenance" tasks, and each level had a goal based on how many of each kind of point were needed. In post-mortem discussions, we realized that this was somewhat artificial and didn't add to gameplay. In Collaboration Station Enhanced, the minigames all generate the same kind of points, and we rely on players' curiosity to try them all.
 |
| Task Selection Screen |
Technical Notes
One of my personal goals in working on this project was to get a better understanding of the C++ bindings for UE4 and their relationship to Blueprints. The memory minigame is a bit sloppy in this regard, but as I worked on other minigames, I had better ideas about how to separate concerns. My Game Programmer student didn't approach any C++, but this is a specific area where if we were collocated, I would have pushed him. Managing the logic for generating and matching sequences is straightforward in traditional text-based programming and ridiculously messy by comparison in Blueprints.
Speaking of which, the networking code is inelegant at best. It is split among a handful of Blueprints, and the dependencies are not always clear. At one point I tried to separate the Firebase logic from the rest of the multiplayer logic, but I'm not sure even where that boundary is any more. It works, but I'm not very happy about it. First, there's no unit tests: automated testing in Unreal Engine is not well supported—at least, not as I understand it—and this left me in a very slow write-deploy-test cycle. It made me afraid to refactor because of the time I would inevitably lose, the fear that leads to bad architecture. I suspect that, like the sequence puzzle logic, much of the multiplayer logic would have been much easier to express in C++. However, despite an email discussion claiming that the 1.0 release of the Realtime Database Plugin would have documented C++ support, it's still all Blueprints.
What is good about the networking code—besides the fact that it works of course—is that we can run multiplayer games over the Internet without needing to collect any private information. Anonymous sign-in is used together with a clever game code system that my students and I designed. This should scale up to the number of users we expect. If the app went viral, it would collapse, but it can handle dozens of games at once for sure. Well, as "for sure" as one can be without actually trying it, of course. The downside to the Firebase networking back-end is that you need to be able to connect to it, unlike the Bluetooth approach that doesn't require any other routing. On campus, we discovered that the normal, secure Wi-Fi is fine, but if we connect to the "bsu guest" network, something is filtering out the Firebase communications. This susprised me, since I thought they were all simply tunneled through port 80, but we did not have the time to figure out where exactly the packets were being filtered. We are keeping both the original and the enhanced versions on the store, though, so if someone is stuck in a school network situation where they cannot alter their filters, they can always go back to the Bluetooth-based solution in the original.
It was great to work on a project where all the assets already existed. I could focus on writing the logic and simply drop in the right pieces where they needed to go: backgrounds, sprite images, music, and sound effects, already made and ready to go. The time from programmer art to production art was very low. The only exception here were the screens themselves, where I would generally whip up the simplest possible UMG widget to test the flow, and only really design the screen once it was done. This worked well, so I didn't lose a lot of time fiddling with placements until I knew the screen was needed.
 |
| Telescope Alignment: The Sliding Tile Puzzle Minigame |
Time = Money
I could not have completed this enhancement project without funding from the INSGC. This was a relatively small grant of $15,000. INSGC requires at least 50:50 cost-share from the organization, and I had worked this out with my department and the university prior to submitting the grant; the total cost of the project on the books was roughly $30,000. (Obviously, the 50:50 minimum is interpreted by the university as a maximum as well.) It turns out that for various reasons, we didn't use all the student wage allotment from the grant, and I was able to borrow several tablets from another office at the university, which meant I had a few hundred dollars of supply budget leftover as well. The total amount spent by INSGC ended up being on the order of $11k.
Many times while working on the project, though, I wondered: what did it really cost? I spent some time last summer working on the project, but we can chalk that up to professional development and preparation. So, for this back-of-the-envelope computation, we'll consider only the academic year costs. For those who don't know, faculty member's time is generally divided into quarters; my usual assignment is three units of teaching and one unit of research during any given semester. The college prefers I charge $12,500 for a course release, so let's use that as the cost of one course-worth of my time. I actually had negotiated a lesser rate for this project to allow it to fit within INSGC's financial constraints, but we're not computing the spent cost but the actual cost. In the Fall semester, I used almost all of my research time and a portion of my CS315 teaching time on this project, so let's call that $12,500 as a low-ball estimate. I worked on it several days over the Winter break as well, but I'll also put that in the "freebie" bin, even though the project would probably have failed without it. In the Spring, I spent practically all day (that is, roughly nine hours) on this project on Tuesdays and Thursdays. I also spent at least one to two hours Monday, Wednesday, and Friday afternoons. As an estimate, then, let's say I spent 3/5 of my week on this project, meaning roughly $60k cost. I've also been working on it since the semester ended to wend our way through the iOS process, but again, let's skip that. This means the total cost of my attention on the project, ignoring other project costs, is about $72,500, or more than double what the official budget states the project to cost.
The university would normally charge around 40% indirect costs for research projects, so if I had provided an honest budget for an agency to cover all of the costs, I would have needed a grant of over $100,000. I asked for the maximum amount that INSGC would provide for a project, and that's less than 15% of the actual project cost. I don't know of any agency that would have funded such a modest project for its actual cost. The fact remains, though, that without the small grant, I would not have been able to do this project at all.
I share this to exemplify a point that I've made before: research loses money. The academic research enterprise forces us to grossly underestimate our costs or to misrepresent what we are doing. The one piece of information I do not have is what it would cost for a private enterprise to do this work. I would love to hear from someone knowledgable about multiplayer game development what they would have charged to do the conversion. The general rule of thumb is "industry is more efficient," but I honestly don't know here how my expertise and cost compare to the games development industry. Of course, living in Muncie has its advantages: $100 grand goes a lot further here than on the West Coast.
 |
| Circuit Repair: Tile Rotation Puzzle |
Wrapping Up
Collaboration Station Enhanced was a great project, and I'm glad to have worked on it. That said, I'll be glad to see the back of it—a lot of other things didn't get done while this dominated my mind the last academic year. However, I learned an awful lot about UE4 development, things I'm sure I would not have learned without being hip-deep in a development project. This investment already paid off in the Spring 2018 Game Studio, who also used UE4 but to make a very different kind of game—expect a post about that in the coming days.
It was fun to revisit this project and rebuild it, but at the same time, I felt creatively constrained. After all, I was not really creating something new from my imagination, interest, and passion: I was recreating a collaborative work but without the original collaborators. I am hopeful that my next project might allow me to deploy these skills in a new context. I do have one such proposal in the works, and it does have a more realistic budget.
I will close by expressing my public gratitude to several people and organizations who made this project possible: Ball State University's Entrepreneurial Learning Office and Immersive Learning program, for funding the original release of Collaboration Station; Indiana Space Grant Consortium (INSGC) for funding the enhancement project; the Computer Science Department, for not just approving the project but for providing valuable space, computing resources, and staff support that allowed us to succeed; Byron O'Conner at the Ball State University Digital Corps for helping me understand the Apple development and deployment models; Kyle Parker at Ball State for generously loaning several devices that we used for development and testing; and Perforce and Epic for providing academic-friendly licenses for their Helix Core and Unreal Engine technologies, respectively.
No comments:
Post a Comment