The purpose of this article is to share some lessons learned - including some links - in game development using Augmented Reality.
Why ARCore instead of AR Foundation?
We chose ARCore for two main reasons:
When we started development in augmented reality, AR Foundation was still in preview and didn't have very solid documentation.
We wanted to make the most of technology. AR foundation did not support all features available on ARCore.
This was a requirements-based design decision and I think you should look at both paths before choosing which one is better suited to your game.
Starting from the beginning:
If you are going to use ARCore, save these links to your bookmarks.
ARCore documentation: https://developers.google.com/ar/develop/unity/quickstart-android
ARCore release repository:
https://github.com/google-ar/arcore-unity-sdk/releases
ARCore's package when imported will bring example scenes for all basic usability and it's where you should start.
1) Do not change the package code if you can avoid it!
Create your scripts or make an abstraction layer for your AR code.
It is not meant to be complex nor to overwrite all ARCore codes.
The main goal is to get ARCore updates easily which will only be possible if you decouple your code from ARCore package code..
If your project takes more than a month, you will need to update the ARCore to stabilize and improve features.
2) Optimize for your needs
To optimize ARCore keep an eye on:
Anchors - are heavier and should only be created when needed.
Anchors should be destroyed when not needed anymore; The ARCore code will update the anchors' position, so be careful with them.
You can control when the plane will be rendered and how many planes will be rendered, see the DetectedPlaneGenerator.cs(ARCore example code)
You can disable plane finding to enhance performance (in ARCoreSessionConfig you can control how plane detection will occur)
The AR Session should not be created and recreated multiple times. Enabling and disabling it is enough.
Pay attention to AR Session configurations; if you are not using something, don't enable it.
3) Instant preview helps a lot, but ...
It does not always work the same as the phone for few shaders and post effects.
It's still a bit slow and requires to move around
Because the application behavior in the editor and AR is very consistent for gameplay, we preferred to make a simulator that had movement input and all AR States (plane finding, anchor objects, reload object) to run in unity's editor. This did not take a lot of time and make development faster.
4) AR already has a well documented and accepted guidelines for its uses, check it out before trying to make yours
First, I would like to give you some usable links:
Here it's some fundamental concepts: ttps://developers.google.com/ar/discover/concepts
Case studies: https://developers.google.com/ar/discover/use-cases
And the ARCore Elements app is great! Check it out: https://play.google.com/store/apps/details?id=com.google.ar.unity.ddelements&hl=en
Second, I will list some conclusions we draw for our experience:
Don't try to have very small colliders; It will be difficult for the player to accurately aim them.
Physics raycast is good, but raycast using the screen position is better and it gave us better responses
Make the AR experience worthy. The AR gameplay must be longer than the time that the user will have to map and anchor the object
Make the user input as simple as possible
Try to think in the user environment, features like scale objects are good
AR is still unstable. Don't forget about it and try to incorporate it to the game design
Change the brightness in the background could make the object more visible (see the ARCoreBackgroundRenderer.cs)
If you need to overlap any camera clip to AR Camera to get some effect, try to do it by code setting your own camera projection matrix to AR camera projection matrix (Frame.CameraImage.GetCameraProjectionMatrix)
5) Watch out for alternative flows
We had problems with the alternative permission streams on android.
AR Core handles the permission calls alone(see ARCoreAndroidLifecycleManager.cs). Some errors were not consistently given after enabling/disabling the main scripts.
The ARCore example code normally exits the application when a permission error is encountered. That was not a possibility for us, then we only treated the errors that were handled consistently by the ARCore lib, which was the camera permission flow exception.
Read more about:
BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
