# Unity Weekly Updates #27 - Ｓｔａｒｉｎｇ　ｉｎｔｏ　ｔｈｅ　深淵

783 views

Why hello there, and welcome to this 27th weekly update! I've been cooking up something literally game-changing (sorry for the pun).

Hang on tight and be careful not to fall, and let's get right to it!

# Steppin'

In my previous post, I've ended on a bit of a teaser. I've talked about an algorithm that helps to create varied types of floors.

In essence, the idea is to be able to "paint" different floor type onto a 2D array  (or an "image" if this is abstract enough for you). Once that image is painted, we simply render it and generate special floor types all around the level.

## The Array

Because I've previously used this Unity tutorial as a basis for building my level generate, reusing it was really ideal. I've simply added another 2D array that describes floor types at a given position.

Because I've also previously worked on another 2D array algorithm for prop placement, I've also taken the liberty to reuse those drawing algorithm too.

By mixing both codes I was able to create a reliable 2D array that was easy to modify and access, which is arguably really nice to have.

## The Rendering

Now that the array is set, we now need to somehow render that array to the level, which wasn't as straight forward as it seems...

Because I've followed that tutorial, the algorithm I use is the mighty Marching Square algorithm, which does work nicely on binary maps...

However, my floor map isn't binary. This creates a pretty glaring issue: corners. While I can treat each floor type as their own binary map (and consequently as their own mesh altogether), their corners won't match up and will create holes where there should be none.

Notice the small bright pink triangles on this map

So we need to tweak the algorithm to fix that: we don't want the ground to be swiss cheese...

### Patching-up holes

After thinking about it thoroughly I could list up the "problematic" cases.

First, we could narrow down the problem by simply stating that because a square only has 4 sizes then there could only be as much as 4-floor types per square. this limits the amount of case to search.

Then it was only a matter of visually scanning every problematic case possible.

Here's what I've found:

As we can see, there's a pattern forming. We can state that problems only occur when the following conditions are:

• The floor type we are currently rendering only has one active node for a problematic floor square.
• There are more than one floor type for that square
• The biggest sum of the total number of active nodes between two types of floors is less than 4.

Aside from that, there's also the idea that only non-corner floors can be problematic.

One thing to note is that there are two configurations that are exempt for it:

As you can see, when there are exactly 3 types of floors with these configurations then there are no holes at all...

#### The algorithm

In order to fix those problematic cases, a new algorithm was in order. After snooping around and searching different marching squares tutorial and/or general discussions, I've decided that the best course of action was to use dual squares at these junctions.

For those who don't know, dual squares are the more conformal cousin of marching squares.

From left to right: marching, dual

In essence, with marching squares, we want to create a "triangular" meshes with "rounded" corners (Think of it as a "smoothing" function for pixels), while with dual square we take their dual point.

Like marching squares, dual squares also works by building indexes for particular squares. It's just that when it comes to rendering, duals are far more square that their marching counterparts.

To illustrate this, here are the possible configurations for marching squares:

And here's the same thing for dual squares:

One particularly alluring thing about dual squares is that I can simply reuse the code for building marching cubes meshes but just create another vertices-creating function which creates those squares meshes.

This is far easier to plug into the previous code.

#### Walkable floors types

Another important thing to note is that even though we now have a hole-free ground we also need to do another step in the rendering.

The way the enum is organized is that there are certain floor types that are marked as "non-walkable" (i.e, they aren't your typical floors). Every non-walkable floor type has a chance to be completely invisible.

This means that the player could see holes where those type of floors would be. Not really aesthetic if you ask me...

So, in order to fix these, I've decided to create walls that would surround every walkable floor. Thus, if a non-walkable floor is completely invisible, there would be a wall and possibly a dark "bottomless" pit too.

Because the tutorial also shows how to create walls you would think that just reusing that code would be great, and you'll be partially right.

Although that walkable floor map would be binary, we also need to take into consideration the aforementioned junctions, and more specifically their configuration.

If we have one of these dual junction squares then the extended walls need to only encase walkable floor. Otherwise, you'll get holes in the floor again.

Notice the black triangle on the upper-left.

To fix this we'll simply store an additional square for each junction that actually describes not whenever or not there's a floor there but whenever or not that node relies on a walkable floor.

This way, while building those extended walls, we could simply check these "junction" square instead of the real ones.

Paired with a nice fading shader this makes for a believable bottomless pit.

## Foor patterns

Much like the props placement algorithm, this one also comes with room-specific floor patterns.

It works much like the prop placement ones, but it renders directly onto the floor type map.

Right now, aside from a generic random one, there's only one other arrangement: the Island pattern.

Basically, the pattern consists of a central island surrounded by non-walkable floors. There are also ridges along the rooms' entry and exit wall side.

Everything is connected by semi-procedurally generated bridges.

There will be a lot more different floor patterns... There will also be huge structures here and there too, like lakes or chasms.

Of course, some room patterns will override these, but not all of them.

## Floor types

Now that the technical stuff is done then let's talk about the floor types.

### Normal Floors

This is your typical floor. Nothing special here

### Grass Floors

A typical grass-filled ground. It is very noisy and will get instantly noticed by enemies while walking on these.

I'm not sure how to make this type of floor more interesting...  (A Geometry shader perhaps, or maybe an actual separate mesh of simple billboarding triangles...)

#### Grass Wetness

One particular thing to notice is that this type of floor will have different coloration depending on the wetness level of a room.

To achieve this I've decided to have another 2D array of the float that describes the wetness of a particular square. Like the floor types 2D array, there are many utility functions to draw on that array.

I've also wanted to have some blur going on so I've decided to look into the gaussian blur algorithm, which is quite useful here.

With it, I can control the amount of blur applied between different zones.

After that, I store the wetness of a particular floor square in an unused UV map.

In the shader, I just sample the U coordinate of vertices to get their wetness and that's it.

Take a look:

### Sand Floor (WiP)

This is a sandy floor. Jumping from it yields a really low jump.

### Mud

Ew, mud! Careful not to get yourself dirty!

You can't go really fast while walking in mud.

### Chasm

This is a chasm. Falling into them results in death, so be careful.

### Lava (WiP)

This is your old friend lava. It is a heart-warming friend that is always there for you.

But seriously, don't get in there or you'll catch on fire.

### Ice

A nice clear floor, yet it's quite solid. It is quite slippery, so be careful.

### Water

Ah, nothing feels quite like a nice swim, especially when you're on fire.

### Poisonous Water

This isn't like your normal water. Bathing in it will poison you, so be careful not to slip!

### Liquid Nitrogen (WiP)

This is quite a scene: a sea of liquid nitrogen.

It's impossible in real life, but this is a video game.

But like real life, touching this will freeze you, so be careful!

### Spikes (WiP)

I didn't finish their design yet, but it's your old friend the spikes.

You get the gist: stepping on them will hurt you so be careful!

### Love Potion (WiP)

A bit of a stretch, but it's there!

Stepping in this will make you frenzied, so be careful!

## Liquid Floors

Another thing to mention is that I've also cooked up a wavy vertex shader that makes models wavy, which is quite useful to simulate big bodies of liquids.

Here's a good look of the shader in action:

• I've finally decided to fix most melee weapons hitboxes. Previously I've used the actual weapon's hitbox to basically see if the attack hit something. This was unreliable at best, mainly due to by both animation and code being wanky. I've changed it so that hitboxes are now more reliable and will always hit where the player aims their crosshair. This makes weapons like sword relevant again!
• This applies to both players and AIs

# Next week

Last week was insane! That floor algorithm really took a lot of my time and I think it can really pay. With things like chasms, jumping now gets the importance it should have.

Lately, I'm trying to somehow fit AI in this. I want to give the player the ability to "push" enemies in chasms. Right now AIs are restricted to their navmeshes, which is neat but it makes them immune to chasms, so there's a lot of thinking ahead.

There's also some polishing to do with, especially with floor formations and stuff. I also need to change the visual of some floors, like for example the spikes or the grass.

Afterwards, I really want to diversify enemies. This would be an important step towards having a public demo of some sort.

Nicely done sir.  This just keeps looking better and better.  I'm super curious to give it a whirl.

## Create an account

Register a new account

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• ### Similar Content

• Hi, I'm seeking people interested in help making "Galaxy Forces VR" a great game.
I'm currently alone and like someone that can create simple 3D-models, and a programmer to join the team.
The project is being developed using Unity/C#. It's a 2D game, but viewed in 3D.
The game is based on my project "Galaxy Forces V2", but this will be single player only, and support the game modes race and mission. There will be global hi-scores on the website with replays of the record scores and ranking of top players, as it adds a lot to the game. And also keeps players interested for longer time.
Everything is not written in stone, there are possibilities for someone creative to add their own ideas. In fact I encourage any team member to test and think about different options of how to make the game better.
A change to the original is that this will be easier to play for beginners to make it more attractive but not easier to master fully.
This is the original complete version: http://www.galaxy-forces.com/
I'm new to Unity, and only have a little knowledge of how to create 3D models. I know C++ fully, but C# is mostly the same. I might get the coding done myself, but it would feel better to have one more person coding and testing their ideas.
I share a picture from the development, and a demo version in current state, so you can decide if you want to join. The plan is to release it on the Oculus Store in half a year. I have a todo list, and I promise to do what I can and spend much time on this to get it done to completion. I like to share the profits with those who want to join and have actually done something that pushes the project forward. The demo runs on Windows without VR, but Oculus Rift is recommended to be able to choose level in the menu (otherwise press Return to play the default level)...

Galaxy Forces VR v0.1
The presentation right now may not be the final result, especially the menu needs a new look with more contents.
It is true that it is a hobby project, but I think it has great chances to get accepted by Oculus. There is a large contents of 50 levels for one thing, and the levels don't need much work to reuse for this project. Also since VR is not main stream, and there aren't so many games released, it will not drown in the noise as easily. And I think VR people buy more games than most, at least I do.

This is the full TODO list, that covers most of the needed work from now to release. I think the time plan is realistic...
Map elements
- Landing zone, hangar building - low poly model (only visual)
- Landing zone, antenna - low poly model (only visual)
- Map decorations, trees - low poly model (visual, and collision in map)
- Map decorations, barrels - low poly model (visual, and collision in map)
- Map decorations, red/green house in 3 parts (left, center, right) - low poly model (visual, and collision in map)
- Z-objects for decoration. Objects that can be placed in a map that are larger and sticks out towards the player to make it more visually pleasing to play VR, for example brick walls in different shapes (only visual, placed inside walls not accessible to the ship) The levels
- Now there are 23 race levels and 23 mission levels. There also exist levels for dogfight and mission_coop, take these levels and convert them to race and mission to get 50+ levels
- Need to fix the editor to make it possible to place the new Z-objects in the maps and go through each map and add them Door element
- A low poly model for the end points of the door (only one needs to be created, can be rotated in 4 different angles to make all parts)
- Implement the door element in code Enemies
- Create them in 3D [enemy 0..6]
- Implement them in code Game Status
- Race: show Time, Current checkpoint, Current lap/Total laps, Health bar
- Mission: show Lives, Health bar, Fuel bar, Cargo bar, Score Sound
- More contents (could be Game Name text/logo, animated objects, clouds, anything really)
- Better gfx (different textures for the level select elements)
- Show your score vs the world best on each level, also show your rank (gold, silver or bronze)
- Make part 2 of the menu - after a level is selected in part 1, shows 3 options - play, play your best replay, play the world record replay
- Settings to turn the music on/off (+a minimum of other settings). The VR room around the player
- More contents (could be clouds and a skybox, or a room, or blackness in space, anything really) Replay
- Implement replays in code
- Online hiscores - that is, be able to send/load the replays to the website (either HTTP or HTTPS if possible, maybe easy to do HTTPS with C# ?)
- The hiscore implementation on the website. (mostly done already) Website
- www.galaxy-forces-vr.com exists.
- Better/more contents + the hi-scores Release
- Images in different sizes for release on the Oculus Store
- Game play promotion video
- Test/fix it working on minimum req hardware The demo + the todo list should help get a picture of what this game will be and help you decide if you want to join and if you have the skills needed.
Hope to hear from you.

• By MATov
It's a story on how to write a plugin for Unity Asset Store, take a crack at solving the well-known isometric problems in games, and make a little coffee money from that, and also to understand how expandable Unity editor is. Pictures, code, graphs and thoughts inside.
Prologue
So, it was one night when I found out I had pretty much nothing to do. The coming year wasn't really promising in my professional life (unlike personal one, though, but that's a whole nother story). Anyway, I got this idea to write something fun for old times sake, that would be quite personal, something on my own, but still having a little commercial advantage (I just like that warm feeling when your project is interesting for somebody else, except for your employer). And all this went hand in hand with the fact that I have long awaited to check out the possibilities of Unity editor extension and to see if there's any good in its platform for selling the engine's own extensions.
I devoted one day to studying the Asset Store: models, scripts, integrations with various services. And first, it seemed like everything has already been written and integrated, having even a number of options of different quality and detail levels, just as much as prices and support. So right away I've narrowed it down to:
code only (after all, I'm a programmer) 2D only (since I just love 2D and they've just made a decent out-of-the-box support for that in Unity) And then I remembered just how many cactuses I've ate and how many mice've died when we were making an isometric game before. You won't believe how much time we've killed on searching viable solutions and how many copies we've broken in attempts to sort out this isometry and draw it. So, struggling to keep my hands still, I searched by different key and not-so-much-key words and couldn't find anything except a huge pile of isometric art, until I finally decided to make an isometric plugin from scratch.
Setting the goals
The first I need was to describe in short what problems this plugin was supposed to solve and what use the isometric games developer would make of it. So, the isometry problems are as follows:
sorting objects by remoteness in order to draw them properly extension for creation, positioning and displacement of isometric objects in the editor Thus, with the main objectives for the first version formulated, I set myself  2-3 days deadline for the first draft version. Thus couldn't being deferred, you see, since enthusiasm is a fragile thing and if you don't have something ready in the first days, there's a great chance you ruin it. And New Year holidays are not so long as the might seem, even in Russia, and I wanted to release the first version within, like, ten days.
Sorting
To put it short, isometry is an attempt made by 2D sprites to look like 3D models. That, of course, results in dozens of problems. The main one is that the sprites have to be sorted in the order in which they were to be drawn to avoid troubles with mutual overlapping.

On the screenshot you can see how it's the green sprite that is drawn first (2,1), and then the blue one goes (1,1)

The screenshot shows the incorrect sorting when the blue sprite's drawn first
In this simple case sorting won't be such a problem, and there are going to be  options, for example:
- sorting by position of Y on the screen, which is (isoX + isoY) * 0.5 + isoZ
- drawing from the remotest isometric grid cell from left to right, from top to down [(3,3),(2,3),(3,2),(1,3),(2,2),(3,1),...]
- and a whole bunch of other interesting and not really interesting ways
They all are pretty good, fast and working, but only in case of such single-celled objects or columns extended in isoZ direction After all, I was interested in more common solution that would work for the objects extended in one coordinate's direction, or even the "fences" which have absolutely no width, but are extended in the same direction as the necessary height.

The screenshot shows the right way of sorting extended objects 3x1 and 1x3 with "fences" measuring 3x0 and 0x3
And that's where our troubles begin and put us in place where we have to decide on the way forward:
split "multi-celled" objects into "single-celled" ones, i.e. to cut it vertically and then sort the stripes emerged think about the new sorting method, more complicated and interesting I chose the second option, having no particular desire to get into tricky processing of every object, into cutting (even automatic), and special approach to logic. For the record, they used the first way in few famous games like Fallout 1 and Fallout 2. You can actually see those strips if you get into the games' data.
So, the second option doesn't imply any sorting criteria. It means that there is no pre-calculated value by which you could sort objects. If you don't believe me (and I guess many people who never worked with isometry don't), take a piece of paper and draw small objects measuring like 2x8 and, for example, 2x2. If you somehow manage to figure out a value for calculation its depth and sorting - just add a 8x2 object and try to sort them in different positions relative to one another.
So, there's no such value, but we still can use dependencies between them (roughly speaking, which one's overlapping which) for topological sorting. We can calculate the objects' dependencies by using projections of isometric coordinates on isometric axis.

Screenshot shows the blue cube having dependency on the red one

Screenshot shows the green cube having dependency on the blue one
A pseudocode for dependency determination for two axis (same works with Z-axis):
bool IsIsoObjectsDepends(IsoObject obj_a, IsoObject obj_b) { var obj_a_max_size = obj_a.position + obj_a.size; return obj_b.position.x < obj_a_max_size.x && obj_b.position.y < obj_a_max_size.y; } With such an approach we build dependencies between all the objects, passing among them recursively and marking the display Z coordinate. The method is quite universal, and, most importantly, it works. You can read detailed description of this algorithm, for example, here or here. Also they use this kind of approach in popular flash isometric library (as3isolib).
And everything was just great except that time complexity of this approach is O(N^2) since we've got to compare every object to every other one in order to create the dependencies. I've left optimization for later versions, having added only lazy re-sorting so that nothing would be sorted until something moves. So we're going to talk about optimization little bit later.
Editor extension
From now on, I had the following goals:
sorting of objects had to work in the editor (not only in a game) there had to be another kind of Gizmos-Arrow (arrows for moving objects) optionally, there would be an alignment with tiles when object's moved sizes of tiles would be applied and set in the isometric world inspector automatically AABB objects are drawn according to their isometric sizes output of isometric coordinates in the object inspector, by changing which we would change the object's position in the game world And all of these goals have been achieved. Unity really does allow to expand its editor considerably. You can add new tabs, windows, buttons, new fields in object inspector. If you want, you can even create a customized inspector for a component of the exact type you need.  You can also output additional information in the editor's window (in my case, on AABB objects), and replace standard move gizmos of objects, too. The problem of sorting inside the editor was solved via this magic ExecuteInEditMode tag, which allows to run components of the object in editor mode, that is to do it the same way as in a game.
All of these were done, of course, not without difficulties and tricks of all kinds, but there was no single problem that I'd spent more than a couple of hours on (Google, forums and communities sure helped me to resolve all the issues arisen which were not mentioned in documentation).

Screenshot shows my gizmos for movement objects within isometric world
Release
So, I got the first version ready, took the screenshot. I even drew an icon and wrote a description. It's time. So, I set a nominal price of \$5, upload the plugin in the store and wait for it to be approved by Unity. I didn't think over the price much, since I didn't really want to earn big money yet. My purpose was to find out if there is a general demand and if it was, I would like to estimate it. Also I wanted to help developers of isometric games who somehow ended up absolutely deprived of opportunities and additions.
In 5 rather painful days (I spent about the same time writing the first version, but I knew what I was doing, without further wondering and overthinking, that gave me the higher speed in comparison with people who'd just started working with isometry) I got a response from Unity saying that the plugin was approved and I could already see it in the store, just as well as its zero (so far) sales. It checked in on the local forum, built Google Analytics into the plugin's page in the store and prepared myself to wait the grass to grow.
It didn't take very long before first sales, just as feedbacks on the forum and the store came up. For the remaining days of January 12 copies of my plugin have been sold, which I considered as a sign of the public's interest and decided to continue.
Optimization
So, I was unhappy with two things:
Time complexity of sorting - O(N^2) Troubles with garbage collection and general performance Algorithm
Having 100 objects and O(N^2) I had 10,000 iterations to make just to find dependencies, and also I'd have to pass all of them and mark the display Z for sorting. There should've been some solution for that. So, I tried a huge number of options, could not sleep thinking about this problem. Anyway, I'm not going to tell you about all the methods I've tried, but I'll describe the one that I've found the best so far.
First thing first, of course, we sort only visible objects. What it means is that we constantly need to be know what's in our shot. If there is any new object, we got to add it in the sorting process, and if one of the old one's gone - ignore it. Now, Unity doesn't allow to determine the object's Bounding Box together with its  children in the scene tree. Pass over the children (every time, by the way, since they can be added and removed) wouldn't work - too slow. We also can't use OnBecameVisible and other events because these work only for parent objects. But we can get all Renderer components from the necessary object and its children. Of course, it doesn't sound like our best option, but I couldn't find another way, same universal and acceptable by performance.
List<Renderer> _tmpRenderers = new List<Renderer>(); bool IsIsoObjectVisible(IsoObject iso_object) { iso_object.GetComponentsInChildren<Renderer>(_tmpRenderers); for ( var i = 0; i < _tmpRenderers.Count; ++i ) { if ( _tmpRenderers[i].isVisible ) { return true; } } return false; } There is a little trick of using GetComponentsInChildren function that allows to get components without allocations in the necessary buffer, unlike another one that returns new array of components
Secondly, I still had to do something about O(N^2). I've tried a number of space splitting techniques before I stopped at a simple two-dimensional grid in the display space where I project my isometric objects. Every such sector contains a list of isometric objects that are crossing it. So, the idea is simple: if projections of the objects are not crossed, then there's no point in building dependencies between the objects at all. Then we pass over all visible objects and build dependencies only in the sectors where it's necessary, thereby lowering time complexity of the algorithm and increasing performance. We calculate the size of each sector as an average between the sizes of all objects. I found the result more than satisfying.
General performance
Of course, I could write a separate article on this... Okay, let's try to make this short. First, we're cashing the components (we use GetComponent to find them, which is not fast). I recommend everyone to be watch yourselves when working with anything that has to do with Update. You always have to bear in mind that it happens for every frame, so you've got to be really careful Also, remember about all interesting features like custom == operator. There are a lot to things to keep in mind, but in the end you get to know about every one of them in the built-in profiler. It makes it much easier to memorize and use them
Also you get to really understand the pain of garbage collector. Need higher performance? Then forget about anything that can allocate memory, which in C# (especially in old Mono compiler) can be done by anything, ranging from foreach(!) to emerging lambdas, let alone LINQ which is now prohibited for you even in the simplest cases. In the end instead of C# with its syntactic sugar you get a semblance of C with ridiculous capacities.
Here I'm gonna give some links on the topic you might find helpful: Part1, Part2, Part3.
Results
I've never known anybody using this optimization technique before, so I was particularly glad to see the results. And if in the first versions it took literally 50 moving objects for the game to turn it into a slideshow, now it works pretty well even when there're 800 objects in a frame: everything's spinning at top speed and re-sorting for just for 3-6 ms which is very good for this number of objects in isometry. Moreover, after initialization it almost haven't allocate memory for a frame
Further opportunities
After I read feedbacks and suggestions, there were a few features which I added in the past versions.
2D/3D Mixture
Mixing 2D and 3D in isometric games is an interesting opportunity allowing to minimize drawing of different movement and rotations options (for instance, 3D models of animated characters). It's not really hard thing to do, but requires integration within the sorting system. All you need is to get a Bounding Box of the model with all its children, and then to move the model along the display Z by the box's width.
Bounds IsoObject3DBounds(IsoObject iso_object) { var bounds = new Bounds(); iso_object.GetComponentsInChildren<Renderer>(_tmpRenderers); if ( _tmpRenderers.Count > 0 ) { bounds = _tmpRenderers[0].bounds; for ( var i = 1; i < _tmpRenderers.Count; ++i ) { bounds.Encapsulate(_tmpRenderers[i].bounds); } } return bounds; } that's an example of how you can get **Bounding Box** of the model with all its children

and that's what it looks like when it's done
Custom isometric settings
That is relatively simple. I was asked to make it possible to set the isometric angle, aspect ratio, tile height. After suffering some pain involved in maths, you get something like this:

Physics
And here it gets more interesting. Since isometry simulates 3D world, physics is supposed to be three-dimensional, too, with height and everything. I came up with this fascinating trick. I replicate all the components of physics, such as Rigidbody, Collider and so on, for isometric world. According to these descriptions and setups I make the copy of invisible physical three-dimensional world using the engine itself and built-in PhysX. After that I take the simulation data calculated and get those bacl in duplicating components for isometric world. Then I do the same to simulate bumping and trigger events.

The toolset physical demo GIF
Epilogue and conclusions
After I implemented all the suggestions from the forum, I decided to raise the price up to 40 dollars, so it wouldn't look like just another cheap plugin with five lines of code I will be very much delighted to answer questions and listen to your advices. I welcome all kinds of criticism, thank you!
Unity Asset Store page link: Isometric 2.5D Toolset
• By Dilmer
Hi All !
For those of you who don’t know that I am now providing information about development of games, launching a game studio, and details of what I go through each day as an indie game developer in YouTube. I am also a a full stack software engineer who has a lot of experience in many areas of development.
I want to invite you to subscribe to my YouTube channel where I am providing videos everyday about the topics mentioned.
Check out the channel at:
Also I founded dilmergames.com which is a indie game company where I have done all the development and art by myself for every single game.
Thanks guys

Got an amount of inspiration and made this game. It's humoristic and satiric, so don't take it too seriously)
Here you play as a priest and your main task is catching the kids. Steam store page:
https://store.steampowered.com/app/915730/Catch_The_Kids_Priest_Simulator_Game/?beta=0
Gameplay trailer: