Jump to content
  • Advertisement
  • entries
    11
  • comments
    4
  • views
    2174

Unity Entry #01 - What is Gon'Interactive and who am I ?

Gon'Interactive

730 views

This promise to be a colorful heaven filled with kindness, so stick around !

The main goal of this blog is to not only present our ideas regarding the game, but mainly to share an adventure of building this game with it's up and down, take your suggestions and comment, discuss various subject around game design and share the more we can about how we do it. This is impossible to achieve without a solid community and I hope we will get a warm welcome from GameDev community. I heard good stuff about it :)

Ironically, this first entry is the needed boring one to tell you who we are and who am I. Ok, I did promise you a "rich in color" experience, but you know... word can be colorful too ! I'll try to make this quick so you all know what this is all about. Just read what may interest you and drop be a welcome word or just a hello !

This blog commitment

My intention is to have this blog updated as much as possible to share each step of the creation of the game. By that I mean at least once per month, but i'll try to do it twice a mount. I prefer to do short but frequent blog entry. Once per week would be cool, but we will see. I'll cover all kind of stuff, including what we fail at too. We want to be transparent to ourself and too people. We learn a lot from that. I want to share concept art, talk about game feature, talk about our philosophy and thinking of what a good game is for us, i want to ask you what is best for the game.

The current game process

We are not on day 1, but we ain't achieve alpha build yet. For me, an alpha build is when you have at least 1 complete level with some finish and unfinished asset with a general set of the basic feature. We don't have all that yet. We do have completed many important feature of the game. Thousands of line of code is already there and we are working inside a dev level to test code but we have very few asset ready. You will be able too all that come to life here ! Another blog post will cover what the  game will be and on what ground we started from.

Who is Gon'Interactive ?

Gon'Interactive was funded in 2009 by a group of 4 college in Montreal (QC, Canada). The main interest was, at the time, to provide multimedia services of a professional level with a budget friendly price to accommodate smaller business and independent people that couldn't afford the big studio.  The company was producing website, flash game, 3D illustration and photography. As it evolve, the company became more and more focused on 3D Animation and illustration as it was driving it's main design interest. The company focused on creating marketing illustration and animation for a varied kind of client sets. A clear line grew over the year to establish Gon'Interactive as being an artistic studio capable of producing cool video and animation production from A to Z (Asset production, video montage, sound edit, post prodZ (see from A to Z) ) to accomplish. The Interactive part of the studio was to mix modern traditional medium such as video and enhance them with new multimedia medium. We became strong at building complex AS (action script 2.0) games and website. Unfortunately, as you may know, AS2.0 became AS3.0 and flash was already dying on it's own and replaced by html5, webgl and other medium. The interactive part of the company naturally evolve into Unity C# coding where we felt for the first time completely free to achieve whatever we wanted, and that feeling was awesome ! We started a new learning curve around Unity a couple of years ago to mix our arts with modern tools such as unity. After being involve in projects for other client, we felt it was finally time for us to do our own game. The one we always dreamed of and finally feel comfortable enough to do. Gon'Interactive have always been about putting all the work require to achieve the best image possible and this apply to the game. To keep a focus on this project, we cut down the amount of job we will take during the time of development because we are really committed to it.

Who am I ?

Well, that's a philosophical question I won't be able to answer in this life probably, but on a more scientific approach to the question, I'm Stéphane L'Abbé, president and owner of Gon'Interactive. For as long as I remember, I was addicted to drawing cartoon and superheroes. It was my first contact with art. I started learning photography in high school and also started programming. It was TurboPascal and I was doing boring animation and game with  terrible fabulous graphic. Photography became one of my favorite hobby that eventually evolve to a ProAm level. Photography is a complementary skill to any 3D work as it involve a lot of understanding in light, material and composition. I like how lights and composition could affect perception and emotion. In college I started to learn and use 3D application to complement my work on a daily basis. I went to university to study architecture. During those years I learn a lot about, how to design, how to communicate emotion out of space, how space can affect people, how our mind read stuff, philosophical approach of what space is and how 3D software work and I got my master and became an architect. This was my professional answer to merge multiple interest into 1 job. Design, mathematics and arts. The real life of an architect is mostly project management and team management. You reach a point where you get very good at dealing with tough project, impossible schedule, budget, team management and those skill apply to every type of project management. The need for more artistic freedom is always inside me and building a game like Third Encounter Of A Kind is a dream come true ! I'll manage the community (if we ever succeed to create one) and i'm responsible of design and do a lot of coding too.  My native language is french, so please, be nice to me regarding my English. I also understand a bit of Spanish. I try to do my best at each language, while not being perfect with any of them !

 

My favorite game was Space Defender.

On the personal side, i'm a gamer. My gamer life started with Colleco vision, I still like the game !

cosmicAvengerScreen.jpg.216d4772e2879c7d90343dc512a2e9f9.jpg 

I was lucky enough to have a mother working for a Commodore Store and we were owning soon after an Amiga 500 computer which was way ahead of his time in terms of graphic and processing power (3mhz ?) I then skip to SNES. Big lover of Mario of that time. The first console a bought myself was a Sega Sturn, my brother went on the Sony side at that time. We join back on Xbox, xbox 360 and xbox one. I'm not a fan of console brand, i'm a fan of good game.



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 RoKabium Games
      The puzzles in SAMA varies in difficulty from easier ones on Metis to the most complex ones on Aura. But no matter the difficulty increase all puzzles are still based on the same fundamental principle of placing coloured blocks along edges with corresponding colour by pushing and pulling them into position.
    • By Danzabarr
      My question is about OOP, and best practice writing in C# for Unity.
      Say I'm writing components for an item system.
       
      Consumables have quantity.
      Weapons have durability, damage, block and stats.
      Armour has durability, armour and stats.
      Shield has durability, block, armour and stats.
       
      In this situation, should I...
      write a Consumable component, Weapon component, Shield component and Armour component that each extend an Item class? write a Quantity component, Durability component, Damage component, Block component, Armour component and Stats component, then add as required? write an Item component with all the possible fields plus an enum that decides which ones go unused? I like 1) because it defines the items by what they do, but there's repetition of fields horizontally in the inheritance tree.
      I like 2) because there's no repetition, but it allows for the creation of items that don't make sense. There's no strict definition going on, just the existence or non-existence of components, and some might need to be mutually exclusive.
      I like 3) because it's the solution to the problem with 1), and the enum is kind of a solution to the problem with 2), but it seems wasteful to deal with a larger data structure than required for every item.
      Any thoughts?
    • By kandarp_pandya
      Please check out my new game which is level based infinite target shooter.

      For Android
      https://play.google.com/store/apps/details?id=com.KPGames.KillSwitch

      For iOS
      https://apps.apple.com/in/app/kill-switch-2d/id1483464098

      Please let me know what you think about this. Also any suggestion feedback are most welcome.
    • 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:

  • 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!