A GPS game that tests your physical ability, as well as your mental ability


(Daniel Hollands) #1

Pinging @DaveDev, @gavinkimpson, @omarqureshi, @wprk, @King_Jk, and @TajinderSD - you might be interested in this.


I’ve decided that I want to work on the evolution of GPSpy (or GP-Espionage, or Spylio, or whatever we ended up calling it). Well, it’s more of a side-step than an evolution, and is very similar to our Koding hackathon project, albeit with some slight tweaks.

Long story short, the idea is to build an app-based game which takes multi player game concepts from first-person shooter games such as Unreal Tournament, and brings them into the real world.

It’ll work something like this:

  1. Using their phone, someone hosts a new game. In app they’re presented with a map of their local area, which ideally will be a park or a field, in which they define X number of bases by placing them on the map (one next to the old tree, one next to the play park, one by the entrance, and one right in the middle of the field).

  2. The friends that they’re hosting the game for, also using their phone, find and connect to the game. They’re shown the map with the locations of all the bases, and once everyone signals that they’re ready, are split into two teams.

  3. When the game starts, the objective is to capture each of the defined bases for your team. This happens by first: being in close proximity of the base according to the geolocation positioning on your phone, and second: completing a puzzle or some other type of challenge in the app.

  4. Once you’ve captured a base, you’re free to run to another base to capture it, but of course this leaves the previous base open for capture by the other team. I have some ideas on exactly how this will work, but I don’t want to go into too much detail about it right now.

  5. At the end of a pre-determined length of time, or maybe once one of the teams reaches an upper score limit, the game ends, and the team with the highest score wins.

There is some more to it than this, but hopefully the above is enough to give you an idea.

Anyway - I want to build this, as I think it would be a lot of fun to build, and a lot of fun to play. So if helping build this idea appeals to you, post a comment below.

:deciduous_tree: :video_game: :blossom: :game_die: :evergreen_tree:


Has anyone used AppGyver Steroids/Supersonic?
Web Artisan here
Hello, I'm Iain and I'm here (and there sometimes)
What's the best nosql data structure for multiple people's geolocation data?
Geolocation - getCurrentPosition() every X seconds, or watchPosition()
I'm a bit confused by this angular code
Programming a bot
Hello all! I'm a freelance iOS + Android developer
Looking for a partner/someone that can kick me up the ass
(Stuart Langridge) #2

Interesting idea! I have a bunch of questions, such as: how do the phones communicate? Via a server? Can you interrupt a capture in progress? A bunch of ideas fork off of this around being able to shield yourself from attack or attack but not both, and both run down your store of energy, which can be recharged at bases you own, or… etc. Why is it app-based rather than a website (which makes participation by a group easier because they don’t have to install ahead of time)? Now I want to build something like this, or maybe help with this one if it’s going the way I imagine… :smile:


(Daniel Hollands) #3

I’m glad you think so.

This is undetermined right now, but the current (prototype) idea is to have a permanent connection to a server, which will keep track of the scores, and alerts other players when a base has been taken over, etc… But this is subject to change, as better ideas are introduced.

I was having a chat with @defsdoor about this yesterday, and he has some ideas on how this could work. I also have some ideas, which I’ll come back and expand upon later.

It’s app-based because apps should have better support for geolocation. If there is anything that @DaveDev and I learned at Hackference is that geolocation in browsers isn’t very reliable - by making it app-based, it should have better access to the geolocation api.

I would very much welcome your involvement in this - I honestly think this could be something truly awesome.


(Daniel Hollands) #4

OK, so lets expand on the base-capture idea a little. This is where the mental ability testing (as teased in the subject) comes into play.

To capture a base, while you’re in range of it, you need to complete a little puzzle or other challenge using your phone. Depending on the game/player settings this could be as simple as popping all the red balloons, or as complex as solving a math equation. Whatever it is, it needs to be quickfire stuff that can be completed in 10-30 seconds.

Each time you successfully complete a challenge your team gains a tick on that base, and whichever team has the most number of ticks on any particular base is considered to have taken that base at that point in time.

But ticks don’t last forever, and all of the time you’re not actively topping them up via challenges, they’re counting down - this means while Team A, who’s previously put 10 ticks into Base Alpha, while they’re off capturing Base Beta their ticks are diminishing, meaning Team B can come in and overtake.

If you get what I mean?

But this is just one idea. As I’ve mentioned, @defsdoor has an idea for this, and by the sounds of it, so does @sil - so I’m happy to explore them all.


(Peter Oliver) #5

Here are a couple of blog posts I read recently from Fire Hazard, who have some experience of this kind of stuff:


(Stuart Langridge) #6

Very excellent posts. Nice tip!


(Stuart Langridge) #7

The way the game in my head works is this:

Every player has a capacity for energy; bases have a certain energy content. You can fill up on energy at one of your own bases. At an enemy base you can attack it by spending energy to reduce the base’s total: this takes time (so you have to stand there by the enemy base feeding energy into it to reduce its energy store). So, you capture an enemy base by going to one of your bases, filling up, then going to an enemy base and attacking it until it runs out…and then it’s your base.

However, you can also attack other players, if they’re near you. This costs you energy and drains theirs. They can shield, which costs them energy but protects them from attack. One cannot shield and attack at the same time, so while attacking you are vulnerable to being attacked in turn; thus, a red team person attacked by a blue person can be rescued by a red attacking the blue in turn.

It’s all about the energy. Game ends if one team owns all the bases, or after a given time toral bases are assessed and a winner awarded.


(Daniel Hollands) #8

This sounds like a cool idea (and actually very similar to an idea I’ve got for my GPS-based MMORPG - but that comes much further down the line). To be, it’s much more like the experience in an FPS would be - if an enemy enters the area, you attack them.

I don’t see why this can’t be one of many different game modes offered by the app, with my idea being another, with maybe a CTF style mode as well.

It sounds like you’re interested in taking part in building this, @sil? I’ll admit, I’d very much welcome your participation.


(Daniel Hollands) #9

Thank you for the link, @mavit - the following made me laugh:

If all the phones are out (sunspots? nuclear apocalypse?), we’ve got the Meltdown Sheets. If we have to run this game on paper, we can.


(Stuart Langridge) #10

I’m interested – I’m loath to commit to things because I’m so short on time, though, and don’t want to hold people up. How is this best resolved?


(Daniel Hollands) #11

Honestly, I don’t know.

Right now I’m at the concept stage, starting to think about implementation. The problem I’m having is this is way outside my comfort zone, so I’m not even sure quite how to get started. While the game is active, everything will be happening in real-time, and that’s not something I’ve got any experience with.

If people in the know, such as yourself, were to point me in the right direction (i.e. suggesting what technologies I should be using, etc… then I can go off and start investigating into them.


(Stuart Langridge) #12

OK. I’ll tell you how I’d do it, but I’d do it on the web; if you want to look at native technologies, you’re on your own :smile:

You need (a) a central server (b) some channel for sending updates to that central server © a constant stream of updates from the central server (d) the ability to cope with network dropouts (e) a decision on how to deal with conflicts caused by clashing updates where everything wasn’t real time. Unpacking that a bit:

I suggest you have a model where you store data on the client and sync it to the server, and receive updates from the server which update the local data model. That way you’re impervious to network dropouts or slowness, and your client is fast, because it’s working on local data only. To do this, you need some sort of data storage layer which is capable of synchronisation between two places (client and server); I’d recommend PouchDB for this, but look around for other things. The key point here is that your model on the client is “someone presses a button; update the local database; continue playing”, and a separate process takes care of “something in the database has changed; tell the server about it” and “the server tells me something has changed; update the local database and tell the client that that’s happened”. PouchDB, being based on CouchDB, does that. Other things do too. Do not try to write your own synchronisation routines. It is really hard.

The issue with this approach, of course, is getting out of sync. What’s supposed to happen is this:

Client 1             | Client 2            | Server              |
---------------------+---------------------+---------------------+
destroys artifact (A)|                     |                     |
(A) -> server        |                     |                     |
                     |                     |acknowledge (A)      |
                     |                     |tell c2 about (A)    |
                     |acknowledge (A)      |                     |
                     |count artifacts      |                     |
                     |gets answer "0"      |                     |
                     |do something relevant|                     |

but what might actually happen, because of network lag, is

Client 1             | Client 2            | Server              |
---------------------+---------------------+---------------------+
destroys artifact (A)|                     |                     |
(A) -> server        |                     |                     |
                     |count artifacts      |                     |
                     |gets answer "1"      |                     |
                     |try to do something  |                     |
                     |FAIL!                |                     |
                     |                     |acknowledge (A)      |
                     |                     |tell c2 about (A)    |
                     |acknowledge (A)      |                     |

that is: if client 2’s view of the universe is out of date because they haven’t yet got the updates from the server (because of network lag, or a network dropout, or server slowness) then we have to be able to reconcile “impossible” actions – in this case, client 2 doing something to an artifact which no longer exists because client 1 destroyed it.

(The other alternative, which avoids this problem, is that all computation is done on the server and the clients are fairly dumb terminals; this way things never get out of sync because the server is the Source Of Truth, but if your client can’t talk to the server for some reason (lag, dropout, slowness) then your client basically locks up solid and doesn’t let you do anything. This is massively injurious to the user experience.)

There are things out there designed precisely to facilitate this model. Firebase, for example (which I think has offline sync support, but I’m not sure. Parse does not.) However, they’ll cost you money (and potentially quite a bit of money if the game gets popular). Rolling it yourself, I think I’d have a PouchDB database on client and server, and a websocket (or server-sent event, or similar) which the server sends “there is new data! do a sync!” events on . When the client changes the DB, kick off a push sync; when the server sends the new-data event, kick off a pull sync.

EDIT: PouchDB supports live sync, meaning that you tell it “sync”, and it keeps things in sync forever without prompting. I do not know how good it is at handling connection dropouts, but if it does handle that well then there’s no websocket needed.

And then work out how to deal with conflicting actions, which requires individual thinking about each action (there’s no generic solution here). This basically means a bunch of “what if this happened” whiteboard thinking; imagine the game is my example of attacking people with energy. If I’m currently attacking you, and I stop, I’ll send a “stop attacking” action to the server; if you don’t receive that for a little while, then that’s OK – you might think you’ve been attacked more than you actually have, but when you get the server update, you’ll realise. (There is potential UI trickiness if you die but only because you hadn’t been told yet that the attack was over, but that can be finessed.)

Does that make some sense?


(Daniel Hollands) #13

Thank you @sil, that makes a lot of sense.

I think, in the grand scheme of breaking things down into manageable chunks, my first job is to look at PouchDB and CouchDB and get my head around them. This’ll be the first time I’ve played with a NoSQL database, so that’s quite an exciting (if scary) prospect.


(Stuart Langridge) #14

I’ve been noodling around with PouchDB, and it seems to work and do what I’m imagining, which is encouraging. There’s a sorta-kinda design forming in my head, so this is a random stream-of-consciousness brain dump rather than anything useful, and it’s a design for how my model of the game (attack others, attack bases) works. It’s not supposed to necessarily be very readable for anyone but me, but I wanted to write this stuff down somewhere…

It starts with each participant joining the game, being issued a temporary ID, using it for authentication, and updating its own document with a list of actions. One of the things I’m not sure about is timestamps; obviously we don’t want to rely on the local device clock, but I think that if the server sends its timestamp as part of the signon, the local app can calculate a correction factor of how far it is away from that clock and send corrected timestamps with every action. Clock drift is a problem, but probably not a big deal over the course of a single game, which is likely to only be a few hours. In my model of the game, the actions are “attack someone else”, “refuel at a base”, “attack a base”. Bases have shield levels; attacking a base reduces its shields. Attacking an unshielded base converts it to be your team’s base. I’m not sure how one handles the situation of defending a base; if Eric the Red is attacking a Blue base, and Blue Tony is close enough to attack Eric, then Blue Tony is also close enough to the Blue base to refuel from it, meaning that Blue Tony effectively has unlimited energy with which to attack. This is a problem, because it means that you can costlessly defend a base; ideas I have around this are that you can’t refuel and attack at the same time, perhaps. Attacking a person reduces their energy, and commensurately reduces yours (so in order to attack you have to refuel first, and if you’ve been attacked a lot you have no energy left with which to attack bases or others). Also not sure what happens if Eric and Tony attack one another simultaneously. Performing an action (say, “attack Eric”) means writing that into your list of actions in your local document. That then syncs; the server will update that document and others during the insert process (so Eric gets “being attacked by Tony” written into his document, which is how he knows it’s happening, and the server will ignore attempts by Eric to edit that out of his document). So the server is still the source of truth, but it’s all done by syncs. I think this idea works.


(Daniel Hollands) #15

I think we’ve got the basis for something good here, and even an idea of how to implement it - this is amazing.

In your game, how do you envision making things like attacking happen? What I mean is, I’m assuming the app will show some type of radar, showing how close you are to bases and other players, and once someone comes into range, you’re able to click on them to start the attack?

I’m very much playing catch up on the technical side, but I’ll take a proper look at PouchDB and see what I make of it.


(Stuart Langridge) #16

Ya, that’s precisely what I’m imagining :slight_smile:


(Tajinder Singh) #17

@LimeBlast hello mate, i have been away for a long time it seems. Been finding it hard to get time off, feels like 24 hrs aint enuff at the mo. Can’t guarantee my participation as of now but thanks for keeping me in mind.


(Will Parker) #18

Hi all,

Sorry I’m a little late to the party. I don’t check Brum.io as often as I should and am equally busy. Whether I have time or not to work on this project or not I don’t know. I could probably dedicate an evening to it once a week but not to learning a new language or framework for it.

Will keep an eye on this thread thou, sounds like a fun project to be involved with :smile:


(King Jk) #19

Dear All long time no see ~

Does anyone know React ? Recently , i see a some guy use React build Native Mobile Application

maybe now just IOS but i think it can build on another Platform :grin:

btw . i am busy on my job now but if i have time , i think i can join the project


(Daniel Hollands) #20

I’ve not yet had any time to play with this, but I did find http://nunchuckjs.com/ today, which I figured was worth posting here for reference.