LÖVE

kikito wrote:The latest sourcecode can be downloaded from the new google code page.

kikito wrote:Unfortunately today's demo doesn't look very different from the previous one, since most changes have happened "under the hood".
The most visible difference is that the demo no longer segfaults.

• A Game object that removes Actors when the states change
• The keys on the piano are subclasses of passion.gui.button, and the piano is a Pannel. So everything can be moved around nicely.

osuf oboys wrote:Really useful, especially MindState

osuf oboys wrote:Stacks of states and the ability to "super-call" a lower state would be nice btw.

require('MindState.lua')

Theory = class('Theory', StatefulObject)

function Theory:foo() print('foo') end

local StatefulState = Theory:addState('StatefulState', StatefulObject) -- <-- the magic happens on this line
function StatefulState:foo() print('bar') end

local InternalState = StatefulState:addState('InternalState')
function InternalState:foo() print('baz') end

theory = Theory:new()
theory:foo() -- foo
theory:gotoState('StatefulState')
theory:foo() -- bar
theory.currentState:gotoState('InternalState')
theory:foo() -- baz

osuf oboys wrote:Not sure I like that there is a single world by default - some games will certainly want to use more.

osuf oboys wrote:The example code needs to be updated to 6.0.1

osuf oboys wrote:'updateUnlessFrozen' or something in the Actor class should take and send the dt parameter - or else no actor will get their dt's.

osuf oboys wrote:Something that that is not clear to me is how one gets callbacks in a Game class, without having to rely on actors or GUI elements

• Make Game a subclass of Actor. Then you can do Game:onkeypress() and handle keys there. Problem with this approach is that you have to be careful not to do funky things with the game object- i.e. passion.Actor:applyToAllActors('destroy') would end the game, when you just wanted to destroy all actors instead.
• Use an invisible actor for keyboard handling. You don't even need to define a class for it - just add an onkeypress function to the instance:

keyHandler = passion.Actor:new()
keyHandler.onkeypress = function() ... end

osuf oboys wrote:Perhaps just a general register() function which allows callbacks to be sent to an object; be it a Game, non-Actor class, or otherwise?

osuf oboys wrote:This is a simple solution but I do not like this framework of direct input-model coupling; not even for Actors, as they are now.

osuf oboys wrote:For instance, it is complicated to let the state of the Game influence Actors (is this the "states in states" deal?).

local BeVeryMean = Director:addState('BeVeryMean')
function BeVeryMean:enterState()
  musicPlayer:transitionToCreepyMusic()
  Bee:applyToAllActors('growHorns', 13) -- invoke methods on all actors, with parameters
  Zombie:applyToAllActors('gotoState', 'nightmarish') -- change the states of actors
  Enemy:applyToAllActors('shout') -- all enemies (zombies and bees) will emit a fearsome cry now!
end

osuf oboys wrote:If we bring up the main menu, we do not want callbacks to be sent to the Actors unless Games wants it to be that way.

osuf oboys wrote:Perhaps something more like ËNVY's observer pattern (http://en.wikipedia.org/wiki/Observer_pattern) where Actors are registered as observers to Game and game an observer of love's callbacks?

osuf oboys wrote:Sorry about all the criticism, the framework is really good. Keep it up!

kikito wrote: Thanks! I'm trying hard to make it easy?

kikito wrote: Not sure what you mean by "stacks of states".

kikito wrote:You mean states with states inside? I call those "stateful states" . It is in theory possible. The trick is that addState takes a second parameter that is the superclass of the state you are creating.

However, I couldn't see any way of providing a simple interface for multi-words, while the mono-word interface is quite streamlined.

I'll check that out. However, the "frozen" part is probably going to go. I'll add a Frozen state to actor! (and redefine update() to do nothing there! how cool is that?)

Yes, I know what you mean. You might not like my responses very much but - you rely on actors. You can do two things:

• Make Game a subclass of Actor. Then you can do Game:onkeypress() and handle keys there. Problem with this approach is that you have to be careful not to do funky things with the game object- i.e. passion.Actor:applyToAllActors('destroy') would end the game, when you just wanted to destroy all actors instead.
• Use an invisible actor for keyboard handling. You don't even need to define a class for it - just add an onkeypress function to the instance:

Code: Select all

keyHandler = passion.Actor:new()
keyHandler.onkeypress = function() ... end

This way your Game is "more inmune" to Actor:applyToAllActors stuff.

I've thought about something like this, but for different reasons: efficiency. When the key 'space'(for example) is pressed, onkeypress is invoked on every actor, even if they "do not care" about space, and only "care" about "enter". But that's something I'll address if I run into performance issues, not before.

Maybe we are conceiving two different types of Game object. On my head, the Game object just says "actors, create!", "actors, destroy!" depending on the status he is - only enterState and exitState callbacks are used, most of the time. He's like a lazy dictator; he doesn't even track the input directly, he has a subdit that does it.

keyListener: boss, somebody has pressed esc. We should return to the menu
Game: You are right keyListener. Allright, everyone just DIES now! - except you, keyListener (boum) Now, actors used on the menu, create yourselves. Now, start working! Ok, I'm going back to sleep.

So, the Game just creates and destroys actors, and they do their stuff.

Well, on my example it will not matter because all the that aren't supposed to receive callbacks will be destroyed. Game is supposed to be a bastard ( ok, they could also be just frozen and invisible, and stored in a pool, to save creation time. Actor pools is another thing I'm considering doing)

statefulObject.pushState("game")
statefulObject.pushState("menu")
statefulObject.popState()

What would be a practical application of that over, say, using a single layer of states but multiple such?

-- notation: Class { State { functions or substates } }
Enemy {
  Attacking {
    f1()..
    f2()..
    WithWeapon {
      f2() -- do more damage
    }
  }
  Running {
  }
}

Ninja < Enemy {
  Attacking {
    WithWeapon {
      f2() -- instant kill
    }
  }
}

Nice. Perhaps a bit unrelated but what I find the most intuitive is not for states to have their own set of functions, but rather to overload functions (blanking them to deactivate, e.g.). That way, when the actors are "frozen", they could still be drawn without having to respecify the draw function. Similarly for applying a new state on another (the stacks).

Could be possible but then you should perhaps make it a class for callbacks (Game, GUI, etc) ... (snip) ... MVC design ... I cannot think of an example where this subordination part would be superior to your states+stack.(snip)

Should there have to be this much work to just bring up a menu though when you already have all of the data prepared?

kikito wrote:statefulObject.pushState("game")

Code: Select all

-- notation: Class { State { functions or substates } }
Enemy {
  Attacking {
    f1()..
    f2()..
    WithWeapon {
      f2() -- do more damage
    }
  }
  Running {
  }
}

*BUT* I want something simple and easy to grasp. The thing I like about my current approach is that it is very easy to understand to someone familiar with LÖVE, or learning it. If I'm going to lose that, it must be to something as easy to use as that.

Sorry, which work are you referring to? I didn't get that last part.

osuf oboys wrote: If we bring up the main menu, we do not want callbacks to be sent to the Actors unless Games wants it to be that way.

kikito wrote: Well, on my example it will not matter because all the that aren't supposed to receive callbacks will be destroyed. Game is supposed to be a bastard ( ok, they could also be just frozen and invisible, and stored in a pool, to save creation time. Actor pools is another thing I'm considering doing)