Jump to content
  • Advertisement
  • entries
    22
  • comments
    7
  • views
    1618

Calibrating Avatar

DATT3701Group

171 views

We have successfully added a 'calibrate' action the game. When the player stands in a T-pose and the 'c' key is hit on the computer keyboard, the avatar will properly adjust to the player's height. In addition, we will add a scene after the main menu scene and before the gameplay starts where the player can calibrate the avatar to their size.

 

-Kristen



0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By Ruben Torres
      Last week, I wrote a post to show you how your unity scene hierarchy is reducing the performance of your game. That post arose awareness across many of you developers. And so, many of you asked great questions that I'll answer in today's entry.
      [The original post can be found here]

      Yes... I confess.
      The examples I often show you in my blog posts are not real-life projects. This is one of the points you have been commenting on.
      Ruben, this is an artificial scenario.
      Ruben, this doesn't happen in games.
      You see, I understand. It's easy to doubt the information I provide you when the only cases you see are extreme. I'd even rub some salt in the wound on the Reddit threads if the author wasn't me (see how I got owned).
      But here's the thing: all the information I give you is based on the pain and gains of real-life projects I worked on. I do my research before I write here too.
      Doing research is great. But that takes time. A lot.
      So I won't set up a new game for every weekly post that I publish. What I do instead is to create a small project to make a point...
      ...A very real point that I experienced in production games.
      You're never going to come across the exact dummy project in your games. But you're likely to suffer from the issues these points reveal.
      And that's what matters.
      So I took some of the feedback you provided for today's post. I'll elaborate on some of the problematic hierarchy patterns you'll commonly see in production games. We will address unity scene hierarchy bottlenecks based on the tools I gave you in the last article:
      The FAP Hierarchy Tool The DetachGameObject simple performance boostingg component Quick Navigation (opens in a new tab)
      The golden rules for an efficient scene hierarchy
          The Gamedev Guru's Golden Rules of a Clean Unity Scene Hierarchy
      Flattening a unity scene hierarchy: an artificial case-study
          The hierarchy structure
          Profiling the unoptimized scene
          Flattening our scene hierarchy
      So what?
      The golden rules for an efficient scene hierarchy
      In the previous post we established a guideline for diagnosing and optimizing unity scene hierarchies.
      Let's quickly recap The Gamedev Guru's golden rules for an efficient hierarchy:

      These apply especially to hierarchy trees that have dynamic objects. And by dynamic I mean, game objects whose transforms are altered. It can be a position, a rotation, a scale or any of the attributes you find in a RectTransform.
      If an entire tree is static, i.e. no periodical transform changes, then don't worry about that tree.
      You see, propagating these transform changes takes time. And it takes more time when you have more game objects in the same tree.
      But it's not the total CPU time that concerns me the most. The issue that I see is that it is pretty hard for Unity to do these transform operations in parallel when they happen to be in the same hierarchy tree.
      So changes in complex trees take a higher CPU time for two main reasons:
      The absolute CPU time required to do the math increases These calculations cannot be spread across different threads Flattening a unity scene hierarchy: an artificial case-study
      I'm a pragmatic and practical professional developer. So let's see all this theory in action.
      The hierarchy structure
      What I have here for you is a scene full of props, particle systems and characters. This is how the unity scene hierarchy looks like:

      Unity Scene Hierarchy: Original Structure
      That's it. No magic. 4-5 levels of depth, plus all the bones required for the characters. Nothing too crazy apart from the 300 simple characters, which probably accounts for all the missing pieces that a real game has.
      Have a look at World. It's a single root game object containing way too many children. This fact violates the first golden rule of an efficient unity scene hierarchy.
      Is that bad? I don't know. The way to find out is by measuring its relative cost.
      I'm using free assets I found in the asset store. That means, I can't upload this project to GitHub or I'll risk ending up in jail. Yeah, thanks for that restrictive license, Unity.
      Profiling the unoptimized scene
      And so I start the scene. Not much happening, just a slight amount of movement. I cannot say this is the funniest game I ever played.

      Sample project "gameplay"
      Well, I'm not an artist or designer. I'm excused for the looks but not for the performance. Point which brings me to using the profiler now.
      I captured a 300-frame profile and here's what I got:

      Unity Scene Hierarchy: Pre-Optimization
      Was that useful?
      Nah, don't even bother to look at the image.
      We don't know whether that's good or bad, because we don't have a reference point.
      But we can compare... We can compare against an equivalent, flattened hierarchy.
      Let's try that out.
      Flattening our scene hierarchy
      Analyzing the previous hierarchy, we can notice something of interest.
      Most of the introduced game objects are there for organization purposes in this setup. That means, some added hierarchy levels are useful for developers to structure content around them. We incorporate these objects to make development easier.
      Game objects such as World, City, Props don't serve any other purpose than organizing. Our characters, particles, UI and props do not really depend on those to accomplish their goals.
      I see a potential gain here.
      But on the other side, we don't want to break the only organizational tool we have. I don't want to deal with a flat hierarchy during development. That sucks.
      We want to keep things structured on the editor and yet we want our game to be performant on run-time.
      Ehmm... Is this possible?
      You bet it is. That we can do by making use of the script you downloaded in the first part of the blog series: DetachGameObject. This script will let you maintain the original hierarchy when you develop your game but will unparent the gameobject of your choice to squeeze all its performance juice on run-time.
      So I'll add right now our DetachGameObject component to the Character prefab, to all particle systems and to the dynamic canvas we have in place. I'll ask our component to unparent the game object after a delay of 15 seconds so I can take two profiles: one before detaching and another after it.
      Below you find the DetachGameObject asset applied to an example particle effect.

      DetachGameObject Performance Booster
      Now that I have set up all DetachGameObject components, there's only one thing remaining. That's right, press the play button!
      So I run the game and after 15 seconds...

      Scene Hierarchy: Flatter Optimized Version
      Boom.
      All my characters, particles and UI have been detached. Now the hierarchy is much flatter.
      So I wonder...
      How do both profiles compare? Let's use the neat profile analyzer to get some fresh numbers.
      *drums*

      Profile Comparison: Deeper vs. Boosted Flatter CPU Performance
      I'll translate for you what this chart means...
      This comparison says that there're significant differences between the deeper and flatter hierarchies.
      The flatter hierarchy improves performance significantly over the deeper one.
      Yes, you might not have 300 characters, but you will surely have many over 100 times more complexity in real gameplay elements, scripts, networking and such.
      So what?
      The conclusion is simple: there's a performance penalty you're paying if you don't have a flat hierarchy. Can you afford it? That's a question only you can answer. And you better answer that with data and metrics. My metrics in my previous games always reach the same conclusion: I don't want to pay that expensive bill. I let instead DetachGameObject pay it for me.
      That's my advice to you. Measure your game through the profiler and FAP Hierarchy Tool. Both tools will immensely help you finding scene hierarchy bottlenecks in your Unity game.
      Always remember...
      Flattening your hierarchy will improve your Unity CPU performance.
      What were your scores before and after flattening your hierarchy? Share below.
    • By UnlovedDolphin
      im going to try to get into vr game making and I want the most meltability and not a pain in my ass to code with. would like any insight and help that can be given
    • By Ruben Torres
      You've optimized all of the low-hanging fruits of your game. Except that you didn't. You missed a sneaky, non-so-obvious spot: optimizing your Unity Scene Hierarchy.
      [The original entry with its formatting can be found at Unity Optimization: Your Scene Hierarchy is Robbing you Performance]

      What's the crack with the hierarchy now?
      I want to show you something.
      Launch Unity and open your game project. Then, run your game on your target device and attach the Unity Profiler to it. Record a few frames during gameplay.
      In the Unity Profiler, look for the following unpleasant profiler markers:
      UpdateRendererBoundingVolumes Physics.SyncColliderTransform TransformChanged​Dispatch You didn't find any?
      Keep looking. I'm sure you'll find at least one.
      They'll spawn when you're about to give up. As soon as you mouse over the close button of the Profiler, they'll show up.
      Found them already?
      If so, it's your lucky day.
      I discovered those in my previous project as well and I learned how to land a final blow to them.
      I know the evil behind them...
      Do you want to know the performance secrets of Unity Scene Hierarchies?
      Quick Navigation (opens in a new tab)
      Level 1 Developer: A Typical Unity Scene Hierarchy
      Level 2 Developer: An Optimized Unity Scene Hierarchy
       The Gamedev Guru's Golden Rules of a Clean Unity Scene Hierarchy
      Level 3 Developer: The FAP Hierarchy Tool
       The Gamedev Guru's Hierarchy Score

      Level 1 Developer: A Typical Unity Scene Hierarchy
      I still remember the first Unity project I worked on, just slightly over a decade ago.
      I was not sure what the difference between game objects and components were.
      But that didn't matter. I created games anyway.

      Deep Unity Scene Hierarchy
      Was it uncommon to see a messy unity scene hierarchy like this?
      Actually, yes. Because it used to be worse than that.
      Interestingly enough, you can get away with this kind of hierarchies most of the time.
      But you'll suffer. You'll pay the price later on.
      Luckily, before I started developing games professionally, I learned to appreciate more structured hierarchies.
      A great scene hierarchy structure can be your best friend. Structure makes development and collaboration much easier.
      It doesn't have to be the best, whatever that means. It's enough for it to be good.
      But bear with me here. This is important.
      Having a cluttered unity scene hierarchy is dangerous and will get you into trouble. This is so because it's highly unlikely you'll directly notice its side effects.
      There'll be a creepy ghost chasing you, pulling you back, slowing you down. Sometimes you think you hear something, but when you look back, there's nothing. So you get used to walking slower.
      I learned to diagnose these side effects over the years. And the main problem is that the side effects of a messy unity scene hierarchy are not obvious to spot.
      You'll see the profiler and wonder what some markers mean. Their names are often cryptic... what secrets do they hide?
      The only thing you can be sure of is this:
      Mysterious markers tell you something's worth investigating
      When you and I talk about structuring your scenes better, we usually discuss increasing clarity and reducing maintenance cost.
      But performance? Just like my cat gitignores all the toys she has around my flat, everybody forgets about performance when it comes to the Unity Scene Hierarchy.
      Let's analyze the previously shown unity scene hierarchy. It contains 2,000 rotating spheres nested on top of each other.
      What does the profiler say about it? Look, don't be scared.
      Unity Scene Hierarchy Optimization-Deep-Hierarchy Profiler Overview
      That's pretty bad for a simple prefab and a rotation script applied to a built-in sphere.
      As you can see, Physics.SyncColliderTransform and UpdateRendererBoundingVolumes are taking a huge portion of your frame budget.
      But let's not stop analyzing there, because I'm quite curious about this case.
      Let's dig further. I hope you saved some 4G data this month for this impressive image.

      Unity Scene Hierarchy Optimization-Deep-Hierarchy Profiler Details
      Here lies the key of the article.
      Unoptimized hierarchies causes two BIG problems in Unity.
      Deep hierarchies do not allow the job system to work efficiently in parallel. Nested hierarchies cause bottlenecks in several subsystems within Unity. Remember my words...
      Because this applies to all types of dynamic objects and especially user interfaces.
      In case you're wondering, I own a Threadripper with 16 physical cores and 32 threads. Do you know how many am I using effectively in this project? Just one.
      There're so many ways to say the same: the performance of your game will suffer. And by trying to fix this mess by following your gut feeling based on those mysterious names, you'll start to age blazingly faster.
      What would a Level 2 Developer do with 2,000 objects?

      Level 2 Developer: An Optimized Unity Scene Hierarchy
      A Level 2 Unity Developer knows that parenting transforms comes at a price.
      The Level 2 Developer also knows this price is paid in milliseconds of CPU time. Or, similarly put, it is paid in hours of overtime spent by the developer chasing this up.
      Ask yourself: do you have enough CPU budget to pay for this expensive hierarchy?
      From which area of your game are you subtracting those milliseconds from?
      Will your game bombard the player with less and less flashy particles? Or will you cut the number of city invaders your player will have to defend from?
      Hopefully, you'll do nothing of these two things., but rather...

      The reason complicated parenting steals resources from your game is simple:
      Each transform modification affects its children and potentially its parent and siblings
      Unity recalculates a lot of thingies for you when you change an object's position, rotation or scale.
      This process is transparently done for you, so you can focus on developing your game. That is great, but the price to pay for it becomes astronomical if you're caught off-guard.
      The solution?
      Keep it simple, adhere to...
       The Gamedev Guru's Golden Rules of a Clean Unity Scene Hierarchy
      No more than 50 total child elements per game object No more than 4 levels of depth in any game object Isn't that simple?
      A Level 2 Developer will keep their unity scene hierarchies as flat as possible.
      Look below. Same amount of objects, this time structured under a flat hierarchy.

      Savings are huge, I see.
      But doing this is easier said than done, right? Detaching and destroying relation(ships) between objects is a laborious, error-prone and time-intensive task.
      What would a Level 3 developer do?

      Level 3 Developer: The FAP Hierarchy Tool
      A good Unity developer gets things done.
      A great Unity developer gets things done faster, more accurately.
      But how is that?
      By using tools.
      Because the only cheap hierarchy is the empty one, there's one key answer you need to answer at all points from your game...
      How complex are your hierarchies?
      You can answer this by methodically analyzing your hierarchies and giving it a score.
      The Gamedev Guru's  Hierarchy Score
       Below 35: Smells of Trouble. RUN!
       Around 50: You might be OK (For now)
       Above 70: Profit! (But don't relax)
      So what are the math formulas I need to calculate the score?
      Luckily, none. I've done this for you.
      I prototyped a tool to automatically analyze and detect bottlenecks in your hierarchy based on The Gamedev Guru's Golden Rules of a Clean Hierarchy.
      I call this tool...
      The Fabulous Advanced Profiling Hierarchy Tool
      Run your game. Get to a point of interest. Open the tool and let it do the work for you.

      The Gamedev Guru's FAP Hierarchy Tool
      Let the tool whisper in your ear the magical melody of an integer that we will call... score.
      Once you know what your score is, you know what to do... Or not?
      Because I'm not giving you only that tool, but also a bonus script to boost your hierarchy problem-solving techniques.
      I'm giving you the extraordinary power of the simple DetachGameObject.cs Demigod script.
      You're not likely to encounter many 27-line scripts that will help you improving performance so much in that small time frame.
      What this does is simple: it'll move your heavy and nested game objects to the root of the scene hierarchy in run-time. That way, you'll profit from having structured hierarchies during development and gain an insane performance advantage during run-time.
      Chances are, you can do this for the great part of your hierarchy that is heavily nested for structure's sake.
      Claim your free bonuses before they become a 404 error (opens in a new tab)
      And after that? Comment below and share your score.
    • By Ruben Torres
      [The original post with its formatting can be found at the Unity UI Profiling entry]
      You spend an infinite amount of time optimizing your Unity UI. But, all it takes to really screw up performance is a sneaky modification on a tiny attribute of an almost invisible Canvas UI element. And when that happens, not even Unity UI Profiling will save you from dropping frames. Are you ready for the road ahead?
      This is what happened in my last project...
      I worked hard to optimize the several UI panels of our port to Oculus Quest. This was mostly about reducing the overdraw level to an acceptable amount to make sure the GPU would be all comfy with the real 3D rendering.
      So I worked on Unity UI Optimization for at least a month and made pretty damn good progress.
      At some point, it was so well optimized that the GPU timings were barely moved by the UI. The opaque UI shading techniques I applied compensated most of the overdraw caused by UI Layering (elements drawn on top of other elements).

      There I was, with a super optimized hybrid UI system that effectively occluded the 3D elements drawn behind it.  It became very easy to discard the rendering of these occluded fragments.
      However, I was far away from being done...
      When I hooked the Unity UI Profiler, one thing caught my attention.
      I saw an overwhelmed CPU taking over 1 ms per frame on UI rendering. That's a hell lot of time for a platform that gives you a budget of 13 ms for the whole game execution: physics, logic, 3D rendering, input, VR, networking are all in the same bucket.
      And I've seen cases where UI kills CPU performance even more.

      Unity UI: Expensive Build Batches
      And that is the thing: UI can be optimized to be GPU-friendly, but that doesn't directly translate into being CPU-performing.
      In fact, CPU and GPU have very different tasks to accomplish in Unity UI Rendering. No wonder, I suggest you approach CPU and GPU optimization very differently, as seen in my previous blog post about Unity UI Optimization.
      Doing more of Unity UI Profiling showed me the obvious problem: the UI was constantly being re-created every single frame, i.e. there was a Canvas Rebuild happening every frame.
      A constant hit of 1 ms on the CPU... ouch.
      But why would Unity do this to me?
      I thought Unity cached the UI Canvases...
      Actually yes, that is correct. Unity effectively caches the canvases to make sure they are built just once.
      The problem arises, though, when you change the properties of any of the UI elements of the canvas, such as a color, a position and so on.
      That means, all animations we love, such as button hover effects, are killing your performance and you might not know it.
      When UI property changes happen, Unity does the famous Canvas Rebuild that will crush your game's performance.
       
      A Unity UI Canvas Rebuild makes Unity iterate over all UI elements of that Canvas to generate an optimized list of draw calls (a set of vertices, colors, materials, etc.). And Canvas Rebuilds take longer than a Seat Panda doing a 0-60 mph test.
      That said, once you've acknowledged you suffered from constant UI Canvas Rebuilds, the natural question to make is...
       
      Why am I suffering the Canvas Rebuilds and what can I do about them?
      ​Answering that innocent question led me to spending 5+ hours researching this topic and empowering the Unity UI Profiler.
      Let's see how.
      Quick Navigation (they all redirect to the original blog page)
      1. Unity UI Profiling: All Good, until...
      2. Unity UI Profiling: A wild Canvas Rebuild appears!
      3. Finding the Saboteur: a politically incorrect brute-force approach
      4. Bonus: Augmenting the Unity Profiler for UI Optimization
       

      1. Unity UI Profiling: All Good, until...
      Let's say we have a weirdo of a UI in front of us.
      That UI is barely doing anything but sitting there, being annoying to the player who just want to see something through it.
      As a collection of 350+ images using a Grid Layout Group, it (miserably) looks like this:

      Unity UI Profiling Example
      And that's fine, even if it contains 350+ images. They will normally be rendered in just two draw calls, as there are two unique images that are not atlased in a sprite atlas.
      Effectively, I can see in the profiler there's almost no overhead on the CPU side. Most of the time we're under 0.01ms, which is pretty damn good.

      Unity UI Profiling: Sneaky Spike
      (...Most of the time)
      ​Wait, what was that CPU spike at the end of the graph?
       

      2. Unity UI Profiling: A wild Canvas Rebuild appears!
      What has just happened there at the end of the Unity Profile? The Unity UI CPU cost has more than doubled in just a second, how weird.
      I want to play a game
      Find the two differences in the samples below (you may want to click on them for zooming in).

      Unity UI Profiling: Cheap Canvas

      Unity UI Profiling: Canvas Rebuild
      I'll give you five seconds to find it out.
      5, 4... Ok here's a hint to make it easier:

      Unity UI Profiling: Canvas Rebuild Overhead
      Yikes!
      PostLateUpdate.UpdateRectTransform and UGUI.Rendering.UpdateBatches really wanted to take all the highlight in today's show.
      What do these regions do?
      The first, UpdateRectTransform, implies that a transform of a specific object has changed, and therefore Unity has to run some expensive logic to keep visuals coherent. We don't know whether it was a position, a rotation, a scale or any other of the RectTransform properties.
      Heck, we don't even know if it was just one attribute or all of them. Was it one object, or multiple? In any case, which ones? This is the problem: we do not know.
      The second cost, UpdateBatches, relates to the fact that the whole Canvas geometry has to be rebuilt. This process is famously known as a Canvas Rebuild. A canvas rebuild implies that Unity goes through all the Canvas hierarchy to generate a list of draw calls, so to speak. The vertices, indices, colors, uv's of all elements are computed and then a batching pass is done to we merge as many draw calls as possible to reduce the CPU overhead of issuing them to the graphics driver.
      Now we know what's going on, kind of. We're on the right track. But how do we go about avoiding these canvas rebuilds? What is causing them?
      We just need to find out more specific information...
      Summary

      An attribute change in a UI element will mark the element itself as dirty A UI element can be totally dirty, but can also be partially dirty: vertices-dirty, layout-dirty, material-dirty. Partial dirty states are cheaper to recover from Unity will rebuild canvases entirely, as soon as any of its elements are marked as dirty Canvas rebuilds are expensive on the CPU, avoiding them is the key  

      3. Finding the Saboteur: a politically incorrect brute-force approach
      We are still to give an answer to the following question:
      Who's triggering that sucky Unity UI Canvas Rebuild?
      It turns out, there's no fast way of finding that out, especially if your canvas hierarchy is immense.
      But, to start out, I'll show you the brute force approach for finding the source of UI Canvas Rebuilds.

      1. Keep the Unity UI Profiler recording
      Filter the metrics so you can focus on what is important: Rendering, Scripts, and UI.
      Keep an eye on the baseline to have a visual cue of your current baseline cost, which should include the expensive Canvas Rebuilds.

      2. Deactivate UI Game Objects and compare
      Select a group of game objects and deactivate it.
      Compare the performance baseline.
      If the baseline didn't improve much, continue deactivating game objects till you see a significant improvement.

      3. Find out who is modifying its properties
      Now you managed to isolate which object is triggering your Canvas Rebuilds. But, who's actually causing those?
      Is it a script scaling it? Or maybe an animation changing its position?
      It helps to do a right-click on the RectTransform and press "Find References in Scene"
      Once you know who's causing the UI canvas rebuilds, do something about it, such as disabling animations or transforms.
       
      Ruben, how am I supposed to follow this approach in a huge UI hierarchy? Don't give me crap
      I told you it was going to be neither fast nor fun, but your players asked for it.
      That's the thing. Having a huge hierarchy in place is not ideal in the first place. Exactly those massive, deep hierarchies will make your Canvas Rebuilds incredibly expensive on the CPU.
      But big and nested UI hierarchies can (and will) happen, so expect canvas rebuilds to hit you where it hurts the most: your players' game-play experience.
      While the brute force approach helps finding the source of canvas rebuilds, this does not scale in the long-run.
       
      Becoming more professional about optimizing UI is what got me into creating a tool that would give me all the answers I needed to match my players' expectations...

      Canvas Rebuild Profiling
       
      4. Bonus: Augmenting the Unity Profiler for UI Optimization
      By now, hopefully, I stressed enough how frequent and impactful UI Canvas Rebuilds can be.
      These troll canvas rebuilds that infested my game stole 10% of my entire CPU budget!
      As we saw, there is a slow brute-force approach for finding the source of a canvas rebuild. Then, I hope you'll be able to do something about it, based on the strategies I posted on my Unity UI Optimization post (visit it, it's free, I promise!).
      But such as error-prone approach is a process a real guru would never settle for. You can literally spend days trying to avoid canvas rebuilds, but the moment you expect it the least, they'll come back just to disappear as soon as you attach the Unity UI Profiler.
      This becomes crucial if you're doing VR development. You don't want canvas rebuilds in your world-space UI. Like not at all. If you don't get rid of these, you're very much likely to convert your players into patients.
      I get it, I will get rid of the canvas rebuilds. But the Unity Profiler won't tell me much about those! What advice can you give me?
      I'm glad you asked. It turns out we can convince the Unity Profiler to give us useful information about who's messing with the performance of our UI.
      You and I can augment the functionality of the Unity UI Profiler. We do so by altering the Unity UI source code that is publicly available. Once you have the source code, you'll want to find the code functions where the Canvas Rebuilds take place. Then, all we need is some BeginSample and EndSample Profiler API magic.
      If you're running Unity 2019.1 or earlier, the Unity UI source code is available for free in their Bitbucket repository. You can follow their guide there to download, install and modify it.
      My suggestion? Use a newer Unity version, at least 2019.2.0. New versions of Unity include the UI source code by default, as the UI system is now part of the package manager. That's the hassle-free way of doing this.
      Here's a list of code regions I found during my investigations where you could add the Profiling API calls:
      CanvasUpdateRegistry.cs: function PerformUpdate Graphic.cs: function SetAllDirty Graphic.cs: other functions such as SetVerticesDirty, SetMaterialDirty, etc..
      Unity UI: Profiling Source Code
      Useful? Yes. 
      Artist/Designer-friendly? No.
      That's why I wrote a small open-source Unity Extension to enhance the Unity Profiler for you.

      The free tool will allow you to quickly switch over profiling modes to make sure the performance of your game is on top.
      The best part of the Unity Profiler enhancer? It just works outside of the editor, effectively replacing all the aspirins you've been taking while profiling your UI in Android and other platforms. 
      Here it is, all its power under your control with two simple buttons: 
      Buff my Unity Profiler Nerf my Unity Profiler. Grab it now here:

    • By UnificationIndeed
      Greetings, 
      Its almost 4 AM in here, i am foreigner who lives in south Korea, married and i have also a stable job. i live in Seoul, and i am looking for a serious group that willing to design and develop a game as a hobby. I am kinda dead serious about it. I made a game but its far form being finished, because lack of ideas and code lines.
      I am looking for group of friends who live in south Korea and are willing to sit down, have a coffee, discuss ideas, and start bringing these ideas to life. (Online, Offline, card or mobile) game. I am good with Unity3d, and a good painter and illustrator, furthermore experienced with WACOM tabs. 
       
      Many games started from a garage by a small groups of developers, and now they reached the sky with their dreams and ideas. Please contact me or comment here, if your passion fall in this direction.
      Here is couple of screenshots of the project i am working on. called "chronicles of SORFIA" 



  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!