Jump to content
  • Advertisement
  • entries
    36
  • comments
    7
  • views
    5453

Secret Santa

Sign in to follow this  
RedOtter

654 views

Hi again everyone!

 

Today I’m writing a small devlog just to let you know that FAXIME has entered Reddit Gifts Secret Santa and we’ve already received our present! We asked for something for our office and we got a a mat ahah it’s really cute, I’ll leave a picture down below!

We've thanked on reddit and our Santa reveled herself muahahah.

 

731331_394641fe88df40e6b0b2104f8613944e~

 

 

 

Basically everyone who knocks at our door smiles :).

 

And we’ll also be at Comic Con Portugal this saturday! Swing by IPCA’s stand if you’re over here in Portugal! :)

 
731331_a79bcf6578ef400a8b892e4b2747b716~

 

 

 

On the holiday spirit Happy Hanukkah for the ones who celebrate it! :)

Fun fact: In Portugal we eat more sufganiyan during the summer! :P

 

731331_95f9e30602a1468eaa78ef3a5d5f64a1~

 

 

[Image made by our team member Lidar]

 

See you soon….

 

The FAXIME Team

 

Follow us and keep updated at:

Facebook: https://www.facebook.com/FaximeGames
Instagram: https://www.instagram.com/faximegames
Twitter: https://twitter.com/FaximeGames
Pintrest: https://www.pinterest.pt/faximegames

SoundCloud: https://soundcloud.com/faximegames

Sign in to follow this  


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 CursedPhoenix
      I'm thinking on developing my own breeding game. Should be easy enougth to create the basic game mechanics and mostly the planning phase is done. I'll use "NimbleBit"s "Pocket Frogs" (https://en.wikipedia.org/wiki/Pocket_Frogs and https://play.google.com/store/apps/details?id=com.nimblebit.pocketfrogs&hl=de) as example, because my idea is in some ways quite similar. Android is the first platform I want to target, with optional expanding later to IOS and perhaps Windows.

      First Problem:
      I'm quite not sure about what language or engine I should use. I know this question is mainly based on opinion, but based on what I plan to do, is there an engine to prefer and why, or should I build it from scratch and wich language should I use then? At the moment my best bet would be on unity or python. Any suggestions here?

      Second (and most significant) Problem:
      I want to create a large amount  of - let's call it - monsters, that differs in color, pattern, color of the pattern and partly shape, but I don't get the trick behind it. So the question here is: How to create reusable monsters that differ in the above mentioned characteristics, with the lowest possible number of graphics.
      My thoughts and attempts on that topic: I looked at Pocket Frogs, and except shape they do exact the same with their frogs what I want to do. But I really don't get how they created over 38.000 (!!!) individual frogs, and the game still doesn't use that much space. I first tried to extract the graphics from the games files to puzzle together what they did. But I could not find them. However I think I figured out some parts of this secret just by looking at the frogs ingame: I think they used a basic frog model. 16 to be exact, to create 16 background frogs in all the colors. On top of them they just displayed the different patterns. But - and thats the mystery - the patterns are in different colors too and  I still dont believe they made 16*104=1664 different pattern graphics. So what trick am I missing here? Some kind of mask? Can I use the same technique to create different additional shapes for my monsters? And how did they made the feet moving. If the pattern on the feet are extra graphics, that would be another 1664 graphics.
      Any idea on how I can make this work, or on how did they make this work will be very appreciated! Thx
    • By JeremyAlessi
      In episode 12, Jeremy chats with Nathan Jester and Derek Hampton at Brown Chicken Brown Cow in downtown Hampton.  Nathan and Derek are local indie developers and long-time PixelFest participants. Nathan recently built a shoe-box arcade controller amongst a variety of gaming projects. Meanwhile, Derek talks Bouncy Bear and personal skill development.
       
       


      View full story
    • By JeremyAlessi
      In episode 12, Jeremy chats with Nathan Jester and Derek Hampton at Brown Chicken Brown Cow in downtown Hampton.  Nathan and Derek are local indie developers and long-time PixelFest participants. Nathan recently built a shoe-box arcade controller amongst a variety of gaming projects. Meanwhile, Derek talks Bouncy Bear and personal skill development.
       
       

    • 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 zwolya
      Trade your way around the Bakersville Baking Convention in your quest to claim THE GOLDEN MUFFIN!
       
      CLICK on the different BOOTHS to see the muffins they have available, and what they are willing to TRADE them for. Make your INVENTORY match Chef Jacques’ as quickly as possible to claim THE GOLDEN MUFFIN!
       
      Read more and play for free at https://www.zwolya.com/the-golden-muffin
       
       

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