What technology or API or example behind Pocket monster go?

1. So first google map api.
How to use this in unity game?

2. Next is Camera usage.
How to turn on camera and make game object onto it?

and other points?

 

Both have been answered several times and can be found with google too, but in short:

1. you will not be able to use google maps the same way as pokemon does with the free api limitations

2. http://docs.unity3d.com/ScriptReference/WebCamTexture.html

 

Knew this would start popping up soon. Really should cash in on it with a video or too.

The game tech is realatively straight forward. Get the user location from the device, it's part of the input class. Download the local map from Google. Place the user on the map. Download locations of interest from your own server, and place them on the map.

The AR is even simpler. Get a texture from the camera. Put it on a quad. Put your model in front of the quad. And you are done.

 

uGUI...

 

So AR part is, when see the game video, the camera always turns on? so turn on camera seems easy, but how to put objects onto camera's realtime video shooting? At that time, camera is doing shooting? How to import that video in unity realtime?

 

How to get camera's realtime shooting reality video onto unity?

 

WebCamTexture.

 

And here I was in the process of writing lengthy text about OpenCV.

@leegod: I think you can get rough idea of camera orientation using sensors, even my 3 years old android tablet works ... OKAY with Google SKY (the tablet doesn't have a gyroscope, so the movement is jerky, because it relies on compass instead. Also this thing can't run Pokemon GO).

IIRC, OpenCV also had API for detecting markers (it also has API for accessing cameras) and reconstructing projection matrix from those, but I never really played with that (although I planned to). As I understand it, without markers there would be no information you could automatically use for building projection matrix for the camera, so you'll need some sort of database for ALL devices and sensors you support.

So, basically, using positional and gps data, figure out device's approximate position in space then overlay 3d object using compatible projection.... without depth information (phones don't exactly come with kinect sensors, as far as I know), it'll clip through webcam enviornment, but in the right circumstances it will be convincing enough. It is not a rocket science, pieces of the information can be found on the web, and you'll definitely need license from google for location and elevation data....

Speaking of which, google earth stores 3d data for some cities, and knows street boundaries. If that's accessible, it can be used to make game more convincing.

 

Actually, WebCamTexture alone will not suffice. You will have to use OpenCV to perform non-marker based motion detection. This will be implemented by a combination of device and camera properties (specifically device orientation and camera FOV) and calculating optical flow and recalculating a world projection matrix each camera frame. Then the 3D objects can be placed and the result will be AR. You could cut out all those steps by simply using Vuforia.

 

Dont do it.

 

If I remember right, I think solo-AAA Billy8675309 posted that he's employed doing quite a bit of actual for-pay robotics work that uses OpenCV, if you decide to go down that rabbit hole. (I did, once, a few years back... one of those things I always meant to get back into some day, when I find an infinte amount of free time...)

 

You can get pretty close with just a straight webcam texture.

Sure, it doesn't account for linear movement of the device. But neither does Pokemon Go. Try it, start up the game, see a Pokemon, turn on AR, then walk around the room. The Pokemon stays in the same place relative to the device, not the world. You can't 'circle round' a Pokemon. A Pokemon that starts off 'ahead and to the left' will always stay 'ahead and to the left', no matter how far you travel.

 

Or do what everyone else does, and drive slowly down the street, making sure not to look up at the windshield. Be sure to focus on your smartphone, or you'll miss it.

 

This is perhaps an even better demonstration of my point. On a straight road, the Pokemon will remain in the same place relative to the drivers seat, no matter how far you drive.

 

And don't wear your seatbelt when you are Pokemon hunting, otherwise you may have trouble getting your phone to just the right angle.

And disable your airbags, because if they go off, they might block your camera.

 

Yes.

No. Haven't you been listening to anything I've been saying? Pokemon Go is an overlay. Its not true AR. You can completely block the lens and still catch Pokemon.



Just in case it wasn't obvious, I'm not advocating playing the game while driving. Don't play the game while driving. If you are playing the game while someone else is driving, turn off the AR so that you don't need to remove your seat belt.

 

I only keep opening this thread because "pocket monster go" makes my inner-10-year-old laugh. Every. Time.

 

Oh I didn't notice. I don't play Pokemon Go myself, but I expected a very robust tracking algorithm especially considering how much success it has seen. Yes, WebCamTexture will suffice.

 

Pokémon is the international name. In Japan it's Pocket Monsters.

 

I wouldn't doubt that it was a gameplay design decision rather than a technological limitation of their engineering team. I could imagine they prototyped it out, and found the experience not as user friendly or entertaining as other implementations.

 

I definitely believe it is a design decision. The way it works now, you don't have to chase them down (once they have appeared), and you don't have stop where you are. It is given enough padding of movement to stay safe, and it also keeps the toss/flick mechanic repeatable and consistent.

I least I hope that is the case, 'cause this happened the other day to me:

Note: the crossing gate is lowering, a train arrived a few seconds after this. (And, yes, for those who may be wondering... I did save the pokethingy by catching it right before it got)

 

You could've caught it!

 

I would call it both. Your average smart phone does not have enough sensors to build in a robust AR positioning system. We are working with a single camera, a gyro, an accelerometer and a dodgy GPS chip. I don't care how clever your engineering team is, that's not enough data.

Plus you are running a game that encourages people to move away from charge points, and drains battery at a horrific rate. Even if the engineering team could build in robust tracking, which I doubt, the processing cost in terms of battery life would be prohibitively expensive.

 

1) There are lots of other alternatives to google maps depending on what you want to do.

We have integrated Mapbox so people can design their own maps using Mapbox Studio and then use that as a tile source in our template. Bing, HERE, OpenStreetMaps, MapQuest, Carto, etc.. have tile sources as well.

If you're trying to geocode or reverse geocode, there are alternate services to google maps.

POI data is harder to get. OpenStreetMaps has some but it's better in certain areas than others. HERE, Google, Apple and the other big players only let you use their POI service if you place the data on their map which must be branded in a certain way. Foursquare has good data but they don't list their prices once you go above a certain number of requests. Yelp has a POI api too.

If you're interested in that kind of game, we make an online authoring tool and have a Unity template which communicates with our authoring tool. We're in beta but releasing soon. If you have a deadline or time-sensitive project, we might be able to help. It's here if you're interested: www.motive.io

If anyone knows of more good POI api data sources, I'd appreciate a link.

 

It can be done, at least on a iPhone 5 and up. (No idea about android, but presumably). It can get a little flaky if your signal/connection is weak or if you really fast, though.

 

Wait a minute.. Is Pokemon Go not even reading the pixels and show you Pokemon according to the image's colors?
(For example, when there are a lot of blue pixels, there will be a higher chance for water type Pokemon?)

 

It's using a massive geolocation database to understand where you are. From comments by @BoredMormon it's only using the camera to achieve an AR illusion.

 

No. It's based on location data. Water Pokemon are more common near lakes, rivers, oceans and the like.

The game doesn't actually turn on the camera until after you find a Pokemon.

 

@Ryiah
@BoredMormon
Ah, okay! Very interesting and probably the better way than to interpret the image, which could be faked.

 

A lot of blue pixels mean a high chance of looking at sky or at a blue car.

Reading pixels and analyzing image data is going to be extremely expensive, and will require advanced image recognition. Trying to make mobile app recognize surroundings from pictures is impractical, and obvious approach is looking at geolocation data.

 

Not too difficult in realtime. Simply convert to HSV and accumulate distribution of certain hues.

 

And some fountains.

 

And natural water is hardly ever blue except in places like the Caribbean which I believe is because the depth an refraction due to salt causes alot of subsurface scattering of the blue sky. . On camera it is usually some version of green with lots of specular and reflections.

 

Sci show did a high level idea for this. Worth adding to the thread

 

It has more to do with water flow and depth -- up here in north Florida the water can be fairly slow and silty but it's very blue not too far down the coast and on the gulf side. And I got plenty of blue photos when we were in St. Thomas a few months back. It's interesting to look at the gradation based on depth though.