Discover Top Posts Tagged with #tuggame

TUG!!! #pupsofinstagram #beddywhippet #puppy #rope #tuggame

#pupsofinstagram #beddywhippet #puppy #rope #tuggame

Offline GPS-enabled maps with Unity

Using GPS with Unity isn’t rocket science (unlike GPS itself) if you use the Input class. Combining GPS coordinates with a map can be quite challenging however. Not having the budget for any pre-baked solutions from the Unity Asset Store I had to slap together something of my own.

As mentioned in an earlier post I have tried this before. This worked with map-tiles being downloaded on demand via way of the digital super highway. This worked fine assuming the player has a reliable internet connection. I planned to implement this system for my final prototype, but I never tested it properly for real world situations. When I did it showed that downloading new tiles for when the player moves over the current tile edge cripples any mobile data connection until they start begging for mercy.

I left it for a while to work on other components of TugGame. When I came back I realised that it doesn’t have to be as complicated as past me thought it should. Why not pre-load the game with one big map of the entire area the game takes place? Not only does this conserve bandwidth, it also gives players a clear boundary of the playing area.

Google Maps is really no help if you want to generate a big high resolution map of a given area. First you have to register as a Maps developer, then you have to activate the correct licence, set up an development environment the correct way, find or write a script to convert Google’s format in a file format that is more usable, to then finally find or write a script to export that data as a PNG… Or I could just take a screenshot. But that is even worse.

Instead I went to the helpful people of OpenStreetMaps. It was really easy: specify the boundaries of the area you want to export… After that you only have to choose one of their exotic file formats, go to OSM-Wiki hoping to find an easy solution. Not being familiar with any of the OSM/Cartography jargon, you try to download all the odd file-formats to trow them at TileMill hoping for something to work.

While considering arguments why not having a map would somehow improve the player-experience, I find a solution that actually works. With BigMap 2 you select a OSM style (Mapnik worked for me) and a place. Hit submit to fine-tune the exact boundaries of the map you want to export. Note that this will always be a square area. Once you’re done click the links that say Py and OZI. This first link should get you a Python script that downloads all the map-tiles from your specified area and stitches them together into a single PNG image. The other link gets you a .map file which will come in handy later on in this text that just suddenly became a tutorial.

To align the position of the players with the correct location on the map we need to know the coordinates at the corners of the map. You can find these coordinates in the .map file. Define a new Rect.MinMaxRect variable with the coordinates of the top left and botton right corners.

private var mapRect : Rect = new Rect.MinMaxRect(5.278931, 51.692990, 5.29541, 51.682774);

Assuming you already written code that initialises GPS you have to make a function that scales the current player geolocation within the boundaries of the Rect onto the map texture. Since the size of the mapsprite doesn’t change during runtime I recommend you save its size in a integer somewhere in the awake or start function of your script.

// Get current GPS position and position player corresponding point on the map

#TugGame #game design

Delving into multiplayer scripting

Making online multiplayer games is difficult. Especially when you think it is a good idea to ignore the existing Unity multiplayer solutions and try to build something from scratch. Because that is what I did.

But before I go into that I want to mention that TugGame now has its own art assets. Well… art. Not really. At least it own identity now. And everything is better then using standard assets stolen from a Japanse tutorial (see spaceship sprites in previous posts).

But what's really important is that I developed my very own system for online multiplayer. It might not work as well as some of the established systems but it’s mine, okay?

More importantly, I learned a lot of new things from coding my own system. At first I tried doing it with NodeJS. With the exception of a bare-bones proof of concept project I couldn’t find anything that wasn’t about the question of the combination of Unity and NodeJS is even possible. I tinkered around with the aforementioned example project, trying to funnel all the data of the game-state into one single string, since I didn’t had access to a database. It was quite a challenge to get my head around asynchronous programming.

In the end it worked. Sort of. But the code was a Frankensteinian mess and I barly took advantage of NodeJS. I started from scratch making an application using Heroku. After some experimentation I build an application using Node that exposed the contents of a PostgreSQL database on a webpage as a JSON string. Doing this made it accessible for Unity with a WWW-object to read, but not to write.

This limitation made me Heroku and NodeJS entirely to replace it with a custom REST-API for PostgreSQL based on PostgREST. Thanks to Jon Harrington for his great tutorial on PostgREST. This application exposes the views of a PostgreSQL database as a REST-API. Meaning that you can acces a specific part of a table in the database with a HTTP-method and a URL. The URL http://localhost:3000/pos?id=eq.2 with the method GET access the position-view (a table with the position data for each player) from the database hosted at localhost, for the entry with the player-id equal to 2. If I want to change this entry I use the PUT or PATCH method together with the new values:

PATCH '{"pos": "-2.02, 4.73, 0.00"}' "http://localhost:3000/pos?id=eq.2”

After some testing using cURL I started implementing this back into my Unity project. Implementing the GET-method was easy since Unity supports this out of the box with its WWW-object. PUT, PATCH and DELETE however, aren’t supported by this. And let me tell you, it took me a lot to figure this out. A library called UnityHTTP eventually saved the day.

#TugGame #game design

Chariots & Harpoons

Chariot is a simple cooperative platformer-type game with only one complex element: a two-wheel cart that player characters can attach to with a rope at the touch of a button. This mechanic is interesting because players can just go and have fun with it straight away. Since it uses properties from our physical world it requires no real learning. Moving the chariot, the most basic procedure in the game, is already lots of fun on its own. Chariot is one of these games where players don’t need to have a sense of achievement in order to have fun.

The other thing I learned from this analysis by Quintin Smith (oh… I forgot to mention, you should probably watch the video first before reading any further) is a new way to approach cooperation in digital games. In most cooperative videogames players assume direct control of the player characters just like they would in a single player game. In the coop mode of Portal 2 for example, players control the two robots ATLAS and P-Body. They are odd looking robots with distinct visual differences both from each other and Chell, the human player character from the single player part of the game. But functionally all 3 characters play exactly the same. The challenges players face in the coop game require some communication, but the gameplay loops and mechanics are no differed from the time GLaDOS was using human test subjects.

In Chariot multiple players control one character: the chariot itself. The chariot is the only thing that can fall in bottomless pits and lava. It’s where the enemies go after and it is also the only thing that can pick up items. Everyone else is never in any real danger themselves and instantly respawns on dead without consequences. In a way it’s a incredibly complex control system for just one character that requires no explanation, unlike games like Octodead or some wacky asymmetric simulation games.

Harpoon prototype A basic procedure that is in itself fun and making one object the center of the spectacle with more agency than the players are things that fit in nicely with TugGame. From the very inception of the basic premise of TugGame I was thinking about players shooting harpoons to attach themselves to a virtual object to pull it along. Back then I quickly dismissed the idea because I assumed it to be too technically complicated.

From developing the slingshot prototype I now know of Unity’s build-in Spring Joint 2D component, which is basically a virtual elastic band… or virtual spring if you will. This is a great alternative for having real rope-physics, which can be extremely complicated, especially when I have to implement the multiplayer component. The rope doesn’t need to bend or collide with the world like in Chariot. Yet you can still have much of the same joy of tugging the object, building up momentum and releasing it to fling it off into the distance. Early playtests confirm that it is indeed really fun to do this, even without a clear goal.

My current goal is to develop prototypes that can be played on a single screen by multiple people using traditional controllers. After each playtest I proces the feedback to refine the basic procedure. Optionally I will add some objectives players can occupy themselves with to yield more usable test results. I will continue doing this until I’ve gathered enough feedback and are confident with the state of the prototype. After that I’m going to continue playtests, only now on mobile devices. I may also need to work on making my own sprites and distinct graphical style, because those spaceships don’t make any contextual sense at the moment.

#TugGame #game design

Prototyping Basic Procedures

Eventually I came to the conclusion that getting the GPS to work properly took to much time. After some brainstorming with one of my teachers Eke Rebergen we came to the conclusion that it is more relevant to focus on the methods player use to interact with this virtual object. The ultimate goal in this research is to arrive at a stage in which players really get a sense of the existence of virtual ball, even though it is invisible for everyone not participating. And aside from that it is also important to make this interaction a fun activity on it own in such a way that players can enjoy themselves without the element of competition.

Prototype 1A: Shockwave In this prototype the player can push the virtual objects away by either walking into them or by setting of a explosion that produces a shockwave to blow them away all at once. When the player taps on the player character sprite, a blue spaceship momentarily changes into a explosive ball of fire while the phone vibrates. The 2D circlecollider quickly expands its radius for a few frames to push them away. (In hindsight it was probably better to use a 2D point effector instead of this expanding method).

I have tested this prototype with a group of people that where already familiar with the general premise of TugGame.

After a few cycles of playtests and iterative changes this was the general consensus from the group:

Very little control over the heading and speed of the red objects (analog for the virtual object).

The shockwave ability ends up to be very useless since you can’t aim it.

Prototype 1B: Slingshot In parallel I developed a prototype in which the player pushes the virtual object by flinging themselves into it with a virtual slingshot. The position of the player is locked to the center of the screen. In order to aim the player have to physically rotate to get the slingshot in line with the target. This is accomplished by matching the player character and main camera rotation to the magnetic compass sensor that is present on most smartphones. To fire the player has to drag the player character as far down as possible using the touchscreen, then releasing it to fire. A quick explosion sprite animation is played while the phone vibrates if something is hit.

Testers said they think that this method is very unintuitive since the representation of the character on screen is detached from what the player does in the physical world. The player character gets shot out of a slingshot while the player stands still. And aside from that everyone said that is played very finicky, but that was mainly to blame on the quality of the prototype itself.

Prototype 1C: Lash & Prototype 1D: Rolling In 1C players are asked to make a pulling motion with their phone like it is the end of a rope attached to a giant heavy bolder. The accelerometer determines how hard the player is pulling. The phone vibrates on the apex of every pull.

Prototype 1D is a similar idea flipped 90°. Players have to make a constant upwards motion as if they where standing on the backside of a giant ball trying to push it forward.

Both ideas where considered to ridiculous in the context of the full game. Pretty much everybody in the test group said they didn’t want to be seen doing these weird motions in public. Fair enough.

#TugGame #game design

Prototyping Tools

While I’m not that amazingly experienced with it, I know from working with it in the past that Unity is a very powerful tool. It’s infinitely expandable and one could easily deploy a game to multiple (mobile) platforms from a single project without much or any special modifications. At first I considered to use the Phonegap/Cordova framework with some additional JS libraries. But after reading some tutorials on how to make a GPS-enabled app I began to remember why I once decided to stop using this framework. Very little seems to be changed since late 2013, the time it was necessary for a project. Having to develop something that uses the native functions of the device (GPS, camera, motion sensors, vibrator, microphone, …) is still very unreliably and confusing. Same goes for the documentation. During this period of frustration I went to the Global Game Jam NL Demo Day event at Microsoft Netherlands HQ. Here I talked with some experienced game developers and designers, who like me also participated in this year Global Game Jam. When talking about my game concept two people (Steven Honders from Speelbaars & Roy van Bijsterveldt from Gamious) told me that Unity has build-in support for many of the special hardware found on mobile devices. With this new knowledge I started with trying to figure out who the GPS functions in work in Unity. I borrowed a Samsung Galaxy S4 from my university and updated the Android SDK to the latest version. Deploying an Unity Scene to an Android device turns out to be very easy. Unity only needs to know the place where you put the Android SDK. For the rest it simply a matter of connecting the phone via USB and pressing cmd + b. Enabling the GPS and returning coordinates only requires two lines of code, no vendor-prefixes required. Displaying to location on a map turned out to be the most challenging part. Eventually I ended up with something loosely based on this example project that projects an image from OpenStreetMaps behind the player character (a red crosshair). This sort of worked, but it wasn’t very accurate and didn’t update in real time.

#TugGame #game design

Pushing the imaginary giant red ball

I have been toying around with idea for the last few weeks now. I’ve been sketching, abstracting, summarising, reformulating and discussing it with others. This is where the name TugGame originated. The general premise is that players have to navigate the physical world to move a virtual object which position is related to a physical position. Imagine a giant red ball in the middle of the street that people try to push forward, only the ball is invisible and can only be pushed by the people participating in the game.

This virtual ball is the center of a tug-of-war style game (think Rope Pulling or the Payload game mode in Team Fortress 2) where everything revolves around winning terrain over the opposing team (think American Football, Nidhogg or Conquest mode in BattleField) and getting a object towards a particular spot while the other party tries to prevent this and/or do the same. The dynamics in games of this type always is a good source of excitement and drama. Instead of some abstract numbers, progress is indicated in a more understandable and relatable way with the position of a physical thing.

I have discussed this premise with many people and try to dissect the concept into the Formal Elements as stated in Game Design Workshop - A Playcentric Approach to Creating Innovative Games by Tracy Fullerton. For each element I tried to come up with some variations to that I could mix and match them into the best possible game concept. This ended up taking way too much time and I didn’t get that much out of it. Instead I decided to go ahead and try to isolate the core parts of the experience I want players to have and make prototypes out of those.

#TugGame #game design

Locative Hybrid Reality Farming

During the research on the topics I discussed earlier, some ideas for game concepts came into my mind. Most of the early ideas came from my fascination with the p2p economy (also know as sharing economy or collaborative economy), which is basically the bests parts of communism turned upside down, except not really at all. The idea is that in this social-economic system people directly share human and physical resources with each other within the bounds of a (online) community. Communities like this already have been successful on the web, see Wikipedia for a notable example. It would be really interesting to have a game that combines this school of social-economic thought with a construction game in something that plays like SimCity, The Sims, SimTower, Factorio, Minecraft, OpenTTD or Rollercoaster Tycoon (the best game of all time). An important theme in the p2p economy is the strive to become self-sufficient. There are already some communities that are completely independent from the electricity companies. Perhaps I could develop a game that could advance their proces on the road to independence by giving the members of the community their very own virtual farm to produce virtual food for their own virtual stomachs. If you could gamify a farm perhaps you could encourage people to start an actual one, using the game as a management tool instead of just a game. Basically a locative hybrid reality version of Harvest Moon.