middleclass & extras: middleclass 3.0 is out!

[kikito]

Hi there,

Just wanted to say that last night I implemented both changes (_call should now invoke the class' new method, and includes now admits a random number of parameters)

Honestly, I didn't have the time to test them properly (I was doing some interesting stuff to MiddleClass too... stackable states!) but I'm pretty sure they will work.

Regards!

[giniu]

I was doing some interesting stuff to MiddleClass too... stackable states!

funny, I was doing something similar just with hierarchy In my approach if you don't specify parents to states, you get just that behaviour - of stackable states I still think that grouping states gives HUGE advantage over unrelated states, especially it simplifies shared resource management - but under the hood my current approach also uses stack to keep track of what states we visited, just it doesn't use classes but plain tables

[kikito]

funny, I was doing something similar just with hierarchy In my approach if you don't specify parents to states, you get just that behaviour - of stackable states I still think that grouping states gives HUGE advantage over unrelated states, especially it simplifies shared resource management - but under the hood my current approach also uses stack to keep track of what states we visited, just it doesn't use classes but plain tables

Well, if you came out with that idea by yourself, you have lots of merit... I just copied what UnrealScript does .. sortof.

In other other of things, there's now a section on the wiki for Naming Conventions. I've also completed the mixins example with more information regarding "included".

[giniu]

Well, if you came out with that idea by yourself, you have lots of merit... I just copied what UnrealScript does .. sortof.

Not exactly myself, my prior knowledge about states comes from article http://gamedevgeek.com/tutorials/managi ... ates-in-c/ - later on, I stumbled upon http://guff.tigris.org/ - this was first time I've seen to incorporate hierarchy into states, but there were lots of things I didn't liked there - it was just limiting and wasn't adding anything to usability - that's why I modified the concept a bit. I.e. When doing state transitions in hierarchy, when one normally calls something like "onLeave"/"onEnter" to "pause"/"resume" state we put or get to at stack, I also do same for all parents in hierarchy up to but excluding first common parent.

That way if in "Menu" that is parent of "MainMenu" and "OptionsMenu" you load GUI stuff not tied to any specific GUI, if there is some menu on Stack below current state, it is still loaded - but when you don't have any menu state on stack, it's not loaded. That way if you keep "MainMenu" on stack what you usually do, whatever menu you use you get instant access to menu resources. Yeah, you can do it other way around - that's true. But this approach extends to FMV's for example - if you play few FMVs in a row, common initialization and allocation can be done in parent state - and as long as you don't leave subtree - you don't reinit it - that's all there is behind it - it's possible to do it other way around, but it's easier to modify it that way and easier to understand too I think

[kikito]

When doing state transitions in hierarchy, when one normally calls something like "onLeave"/"onEnter" to "pause"/"resume" state we put or get to at stack.

That sounds similar to how things are (supposed to be) in MindState (testing pending).

There are actually 6 callbacks:

With gotoState:
enterState when the object enters a new state
exitState when the object exits that state

With pushState:
pushedState when a new state is pushed on the state stack
pausedState on the existing state, when a new one is pushed

With popState
poppedState on the state being "poped out"
continuedState on the state that is the new stack head

This allows a lot of flexibility regarding object allocation/deallocation.

I also do same for all parents in hierarchy up to but excluding first common parent.

I didn't get that last part regarding parents and common parents. You mean that when a new state is pushed (for example) the onPause event is fired on all the states of the stack?

[giniu]

I didn't get that last part regarding parents and common parents. You mean that when a new state is pushed (for example) the onPause event is fired on all the states of the stack?

Imagine such situation. Let "" be root for whole hierarchy tree, now you have "Menu", "FMV", "Game" under it. "Menu1", "Menu2" under "Menu", "FMV1", "FMV2" under FMV. Now let's have "Game1" and "Game2" under "Game" and "Game1A" and "Game1B" under "Game1". Let's assume that "Game1B" is on top of stack and you are pushing "Menu1".

Normally you would say that you are leaving but will be back to "Game1B" and tell "Menu1" that's it's on now. In that case, you would also tell "Game1" and "Game" that you are leaving and "Menu" that you are entering - even though they are not on stack - but they represent groups of common stuff. But if you change from "Game1B" to "Game1A", you don't do anything - "Game1" is their common parent, so you just tell "Game1B" that you leave it and "Game1A" that it's on now. Notice that "Game1" is first common parent so we don't send anything to it.

That way, you can easily group common initialization and finalizing code, for example responsible for loading common stuff, in groups

You can check transitions I have in other topic I made about it - In my version I use names pushState, popState and changeState (you named it gotoState but it does same thing), and call one transition function that does all the transitions in tree in common way. Events names I use is: "init" for first time visit like pushing state, "enter" for revisit like popping state, "leave" for temporary leave like pushing another state and "exit" for permanent leave, like popping state. I also route standard events to current state

If you use terms like that:

1) inactive state (state not on stack)
2) active state (like on top of stack)
3) frozen state (like on stack but not on top)

this method ensures, that all parents of active states are also active - but don't receive events. And parents of frozen state are active or frozen.

So no, not on all states on the stack - but for all states in hierarchy, that's separate from Stack itself.

[kikito]

Mm but the parents aren't really "fixed", are they?

Game is the parent of Game1 and Game2. Does this mean that it must allways be before they on the states stack?

This would mean that you would not be able to go from Menu directly to Game1. Your parents and childs would be "on a tree structure" with no cycles.

[giniu]

Mm but the parents aren't really "fixed", are they?

Game is the parent of Game1 and Game2. Does this mean that it must allways be before they on the states stack?

This would mean that you would not be able to go from Menu directly to Game1. Your parents and childs would be "on a tree structure" with no cycles.

yes, states are in tree - but what you put on stack is references to nodes. You can go directly to any state from any state - but additional when you do transitions you travel trough it - those init/exit/enter/leave for parents is only purpose of hierarchy, and it's structure - structure between states is fixed during state registration - instead of

Game:addState(name)

you do

Game:addState(name, parent)

or something like this - and if parent is omitted, you add it to root. Then when you push first state to stack - this state lands on stack - but you call "init" for all it's parent, starting from root - that's the whole point of state grouping. Take a look at http://love2d.org/forum/viewtopic.php?f=5&t=1146 probably, glancing trough code - it's all done there, I know you looked at it and wasn't liking some parts of it, but the transitions are there already, there is stack of states and all that done - I'm modifying it to use classes in free time, will see how it works out and compare later.

[blenderer]

Hi, thanks for the great library as always, I think I may have found an error in your Mixins documentation on the wiki.
http://love2d.org/wiki/MiddleClass

After having some problems with Mixins, I just copied the code from the wiki page and pasted it into a main.lua, of course i changed print() to love.graphics.print() and moved the fly() methods in the love.draw() function.

Code: Select all

require 'MiddleClass.lua'

function love.load()
	HasWings = { -- HasWings is a module, not a class. It can be "included" into classes
	  fly = function ()
	    love.graphics.print('flap flap flap I am a ' .. self.class.name, 400, 400)
	  end
	}
	
	Animal = class('Animal')
	
	Insect = class('Insect', Animal) -- or Animal:subclass('Insect')
	
	Worm = class('Worm', Insect) -- worms don't have wings
	
	Bee = class('Bee', Insect)
	Bee:includes(HasWings) --Bees have wings. This adds fly() to Bee
	
	Mammal = class('Mammal', Animal)
	
	Fox = class('Fox', Mammal) -- foxes don't have wings, but are mammals
	
	Bat = class('Bat', Mammal)
	Bat:includes(HasWings) --Bats have wings, too.
	
	bee = Bee() -- or Bee:new()
	bat = Bat() -- or Bat:new()
end
 
function love.update(dt)
	
end
 
function love.draw()
	bee:fly()
	bat.fly()
end

the error I'm getting is:

Code: Select all

main.lua:6: attempt to index global 'self' (a nil value)

[bartbes]

Code: Select all

require 'MiddleClass.lua'

function love.load()
	HasWings = { -- HasWings is a module, not a class. It can be "included" into classes
	  fly = function (self)
	    love.graphics.print('flap flap flap I am a ' .. self.class.name, 400, 400)
	  end
	}
	
	Animal = class('Animal')
	
	Insect = class('Insect', Animal) -- or Animal:subclass('Insect')
	
	Worm = class('Worm', Insect) -- worms don't have wings
	
	Bee = class('Bee', Insect)
	Bee:includes(HasWings) --Bees have wings. This adds fly() to Bee
	
	Mammal = class('Mammal', Animal)
	
	Fox = class('Fox', Mammal) -- foxes don't have wings, but are mammals
	
	Bat = class('Bat', Mammal)
	Bat:includes(HasWings) --Bats have wings, too.
	
	bee = Bee() -- or Bee:new()
	bat = Bat() -- or Bat:new()
end
 
function love.update(dt)
	
end
 
function love.draw()
	bee:fly()
	bat.fly()
end