Jump to content

  • Log In with Google      Sign In   
  • Create Account


We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.

Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Member Since 30 Jun 2007
Offline Last Active Jul 07 2014 03:14 PM

Posts I've Made

In Topic: Is hatred for unity justified?

21 March 2014 - 04:47 PM

Parts of Unity are incredibly frustrating. Serialization is poorly documented and is inconsistently implemented, the GUI sucks, and the editor can get out of hand quickly with large projects.


However, It is rather strange that your game dev teacher is talking about unity from the perspective of a player when your teacher is a developer yes?

Also, before GDC with UE4 and CryEngine, consider what options you had before unity? They were far and few between, and Unity sure beats writing your OWN engine.


Now of course this could limit you if your game doesn't fit well with what Unity provides. There is a statement that is made often on these forums "Make games, not engines". products like unity exist so that small teams or possibly 1 person that works their ass off can actually make a decent 3d game.

In Topic: Reconstruct position from depth

17 February 2014 - 02:35 PM

This, this, and this are good for reference. Have you looked at those articles?

In Topic: Calculate Position as 0 to 1 between two planes.

13 February 2014 - 01:47 PM

Thanks for the replay,


A friend helped me understand it last night and we were able to come up with some working Unity code. After reading your post, I am pretty sure we are doing the exact same thing.


I'll be sure to post it here when I get the chance.


We actuallly just used the bounds of the box collider in Unity to derive points for the two planes, and then since we want the colliders to be point to the "front plane", we just take the forward vector of the unity gameobject that has the box collider. Ends up pretty clean.


Although i really appriciate that guy doing that paper, and am grateful for it as a resource, the lack of clarity on some of the parts has made it extremely painful.

Luckily we are almost there!!!!!!!!!! And the results are soooo worth it.

In Topic: Reflecting on implmenting coroutines in a massively state driven game.

07 February 2014 - 05:25 PM

I think you guys are right that our implementation is wrong.

Reviewing the code shows states called within other states which we are doing everywhere and shouldn't be.

The main states should be called in a loop and exit when a state changes. A stack of coroutines is a special case not the norm

In Topic: Reflecting on implmenting coroutines in a massively state driven game.

06 February 2014 - 04:42 PM

Is the stack static? Maybe I'm naive--or confused--but I've always thought of the state-stack as a dynamic (no set order) list of states where only the "top" one is updated. When you're ready to switch states, either pop the top one off (reverting to whatever the previous state was) or adding a new state on top (when you pop that it returns to whatever the current one is) or both.


A default state can be run alongside the stack (this lets you do maintenance routines and whatnot that need to be updated independent of the current state).


It is dynamic.... let me give you an example.


With a non coroutine API you would expect to be able to do


SwitchState(A, data);

SwitchState(B, data);

SwitchState(C, data);

SwitchState(A, data);


For a JRPG:

SwitchState(StartMenus, data);

SwitchState(Exploreing, data);

SwitchState(Battle, data);

SwitchState(Exploring, data);


Or also:

SwitchState(StartMenus, data);

SwitchState(Exploring, data);

SwitchState(Battle, data);

(you die in combat)

SwitchState(StartMenus, data);


with coroutines, since it is a stack, you would have to do the following to get back to start menus.

the following now becomes abstract psudo code:


with coroutines:

SwitchState(StartMenus, data);

SwitchState(Exploring, data);

SwitchState(Battle, data);

(you die in combat)

SwitchState(Exploring, data);

SwitchState(StartMenus, data);


In my original post i addressed this with a Validate method that is called EVERY frame when a state is run. This would allow the code with coroutines to maybe set a desired location and the couroutines would validate and bail out. I'm not really a fan of this though.