Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 Feb 2007
Offline Last Active May 15 2015 09:58 AM

Posts I've Made

In Topic: Save/Load High Scores

23 April 2015 - 01:16 PM

You might want to look at implementing different game states to the overall game loop, so that you don't have to fit the logic for every possible state of the game into one monolithic Update() method.  That's not a brief topic though, (and I suggest doing some googling on "managing multiple game states" even here in the forums).  


As a rough explanation, when your game is playing, some variable somewhere should know that the game is in  regular "play mode".  That's a state, and update should only do stuff that's pertinent for "play mode" updates.  Things like decrementing the timer and checking for "is time up yet", for example.


When the timer reaches zero, state should switch to "endgame mode", and then update calls should have a completely separate set of logic that makes more sense for the game during the post-play time period.  Things like "was the high score good enough to put on the board" and "did the player press 'restart' ", for example.



However, in the interest of a quick solution for now, it sounds like "I already have it in a separate function and I call it where the rest of my [end] game logic goes" should result in only calling the score-comparison once.  What does that code look like?

In Topic: Force skinned mesh to use another skeleton

21 April 2015 - 11:12 AM

Here's one solution someone used, seems several people have had success with it according to the comments.

In Topic: Save/Load High Scores

21 April 2015 - 10:50 AM

Why can't it just run once?  It's something you only need to do once at the end of a game session.  Certainly no need for including it in every frame.

I'd lean towards sticking it in a static utility function just for ease of editing later.  Then in whichever method handles "what happens when a game is over" you just call over to the score-checking method and shuffle around high score order if necessary.

There's no "one best way" (arguably) to do it, but there are certainly easier-to-maintain ways.  


First, just make it work.  Then, if you want and have the time/need, make it work better :)

In Topic: Is Unity3d right for someone like me, mostly doing 2d stuff?

20 April 2015 - 12:54 PM

Not really, we probably SHOULD but the game gets pretty constantly playtested and we're establishing some more structured testing rules now (to include a dedicated "build machine" and a better bug tracking db).  One thing I've enjoyed about Unity is the constant prototyping environment.  You can open a new scene just to test a specific component, muck about all you want, then just throw it out when testing is done or never include it in the check-in so you have a handy sandbox ready for other change-testing.

There are certainly unit test frameworks for C# ready to go, but there's so little lag time between writing a module and being able to test it in-game that we haven't really seen the need to get very test-oriented.

In Topic: Is Unity3d right for someone like me, mostly doing 2d stuff?

19 April 2015 - 10:17 PM

Approximately, how many MonoBehaviours go in to, say, a normal mob?

I grabbed a random mob prefab from the current build (since I have it on my home machine right now), here's the component list:


Mesh Renderer

Mesh Filter: [none]
Tk 2d Sprite

Tk 2d Sprite Animator

(those four come bundled together, tk2d is a 3rd party sprite handling library we grabbed since the project started before native 2d support really took off)
Audio Collection - our mobs own their sound collections

World Object - base component inheriting GameObject that we use for most in-game world-contextual objects
Character Module - component for anything that has sentience (self-movement and physics mostly)

Sprite Module - Where we control worldObjects' sprite changes (new animation clips/states)

Combat Module - component for any objects that can deal/take damage

Ability Module - component handling our ability system: any kind of "action" a combatant can perform (things like "meleeAttack, fireball, laser, etc")

AIControl Module - lets a tweakable FSM control this object's actions (player character has a playerInput module here instead)


And that's it.
All of those components have custom editors (the AI FSM even has its own visual scripting tool we wrote custom) and aren't light on the actual backing code.