For the fourth and final year of the undergraduate Computer Science Masters course at The University of Warwick, students team up in groups of around five and work on a thing for the year. That thing can be research-oriented, or it can be a software development project; the latter is the more popular option. It has to be of sufficient technical challenge for a team of that size for the whole year. Our team of five is developing a game about creating and sharing levels in a similar mould to Super Mario Maker, but with our own spin on the concept. Due to the heavy focus on collaboration, we’ve called it Patchworks.
The first major feature we’re implementing is the ability for Android devices to join in while someone is playing the game. The core of the game runs on a PC, with one ‘desktop player’ controlling the most important aspects of the game, but 1-4 ‘mobile players’ may join in over LAN (Local Area Network). We wanted to capitalise on the appeal of couch co-op games, and having people use the mobile devices they already own in a novel way seemed like the obvious solution.
Early on in development, we thought about what we would want to display on the mobile device. Do we want it to mirror the visuals of the desktop game? This would cause problems in synchronising the state of the game between devices, as every game event needs communicating over the network which could strain the LAN connection. Not only that, but the interface would be crowded on such a small screen if the rest of the visuals needed to take up space. We decided that it would be best to use the mobile devices purely as controllers instead, and our attention turned to what type of controller would work best.
Mobile games often have a controller ‘overlay’, where virtual buttons are superimposed on the game. None of us are a fan of this style, as the buttons are non-tactile and do not feel good to use, especially compared to a conventional gamepad. Nor is this type of controller suited to this type of game, as we don’t have any ‘action’ to display on the mobile screen, so the controller interface is free to take up the entire screen rather than being tucked into a corner. We thought about what kinds of control do work well on mobile, and came to the conclusion that a ‘scroll area’, similar to a mouse, would feel right at home on mobile. Housing this on one side of the screen leaves the other half free to display a range of buttons for different purposes; the buttons act just like any other button would on a mobile device, and while they still lack the satisfying tactile feel of a physical button press, this is the best we can achieve on mobile. Perhaps in the future we’ll add haptic feedback (vibration) on a button press.
The gameplay experience for desktop players is inherently different to that of mobile players due to the limitations and design choices detailed above. The mobile players won’t be controlling a conventional character like the desktop player will; they’ll be moving around a ‘cursor’, similar to how the character Murphy works in Rayman Legends on Wii U. Elements in each level will be interactive for mobile players only – enemies and obstacles can be manipulated to help or hinder the desktop player. Our initial prototype had a UFO being flown round the stage, shooting bullets downwards. We plan to add a range of enemies, some with unique controls, for the mobile characters to control, plus we want to use the accelerometer and/or gyroscope for some gameplay elements, also similar to Rayman Legends. Similarly, ropes can be cut by the mobile players by using some kind of ‘scissor’ tool and swiping through a rope.
The focus of the project is on collaboration, and it is the Level Editor where this shines. A grid-based editor, similar to that of Mario Maker, allows players to place tiles wherever they want in a level. At this early stage in the project, we have implemented simple ‘painting’ of tiles, as well as undo and redo, clear and erase tools, and in the future you will be able to grab/select objects you’ve already placed and customise their behaviour. For example, you’ll be able to set the endpoints of a moving platform, set the length of a piece of rope (solving once and for all how long a piece of string actually is).
Mobile players can join in with editing levels, with most of the abilities of the desktop player, although only the latter can set the level name, save the level, go into Play Mode or move the camera. We turned to games like Ultimate Chicken Horse for inspiration – in that game, players take it in turns adding elements to the level with the goal of completing the level themselves but preventing their friends from doing so. Our goal is collaboration rather than competition, so we opted for complete realtime parallel creation, where anyone can add or remove elements at any point.
Super Mario Maker worked so well because it encouraged a community of players to upload and share levels with each other. There were YouTube Let’s Plays of levels, there were notoriously difficult levels like the Panga levels, and there were inventive music-oriented levels in which players input nothing and listened to a tune crafted by nothing but enemies falling onto music blocks. All of those levels were only possible to create because of Mario Maker’s tight mechanics and emergent interactions between different level elements. We want to aim for the same sort of thing, with players able to upload their favourite creations once they’ve beaten them.
Using the mobile app, people can browse levels on the go and bookmark levels for later. This is somewhat similar to a system implemented in Mario Maker after it launched that allowed you to bookmark levels from any internet browser. Of course, this is all going to require some kind of unified account system – possibilities include using people’s Google Play accounts, although some players may not have one. Uploaded levels and bookmarks will be tied to a user account, and you’ll likely use the same account on desktop as you will on mobile. We also thought about a notifications system that lets players know when someone liked their level, or when they’ve reached a milestone of plays or likes. This could be baked into the mobile app and use Android notifications, and it can also feature on the desktop game homepage (a prototype for this functionality was already created).
This Start Menu is extremely rough.
So far, the project is on track to complete its objectives by the due date, which is around the end of Term 2 for feature-completeness, and the start of Term 3 for the final presentation. It’ll be interesting to see which features we get time to implement, as there are a number of ‘stretch’ features we might want to include.
Next time I make a post, it’ll be at or after the end of term 2 most likely, so I’ll have some amazing screenshots to show off. Watch this space!