LÖVE

• You'd better use the MiddleClass and MindState files that come with PÄSSION instead of the ones that reside on the separated repository. I update the ones in PÄSSION more often.
• I just found (and fixed!) a bug today on MindState. It was quite difficult to find, probably no one would have noticed. It had to do with destroying actors that are not on the "nil" state. The updated version is on github.
• I'm also thinking about factoring out some common functionality used on timers, Actors and Cameras to a mixin. It will probably happen this week. I'll post here when done.

osuf oboys wrote:The functionality of camera is so common that I'd really like to see your reworked version standing on its own without the need of the complete framework. Though I missed some common functionality - centering the screen and scaling to display a certain number of units - and have attached an extension in case you are interested.

osuf oboys wrote:Mostly because, as with this project, the lack of transparency and documentation makes for a steep learning curve (it's pretty much the only reason I can think of why the majority of projects is not using PÄSSION ). What are your thoughts on this?

• First, there's this "if you build it, they will come" idea. I have hope that if I create a system that is awesome enough, people will use it. I realize that this is not a proper plan. I guess I'm still young and hopeful in some way.
• Then there is my direct attack in the form of a tutorial site. Have you seen it? It's still under development, but it is starting to look cool. I've stopped working on it for a while since I'm doing (again) some re-engineering on the core classes.
• I've got this "do the common bits easy" part. I try hard to make the usual steps as straightforward as possible. This is usually my #1 reason to make a change on a interface
• Then there's the "make things diggable". One should be able to "dig" through the system. Start doing the simple/common things, and then go down at some point. The Actor's getCamera method is an example of that. You go there and you see that there's also a "getCameras"... and that's how you discover that the system supports multicamera stuff (i.e. for split screens or minimaps).
• And then I try to follow the usual DRY, KISS, YAGNI principles that I've learnt from rails. The idea behind this is to make code that is not only "useful" but also "beautiful". I realize that in some cases I've had more luck than in others on this. My Camera code, for example, needs some serious beautification.

osuf oboys wrote:1. to remove a state not necessarily at the top of a stack

myInstance:popState('MyStateName')

osuf oboys wrote:2. to move a state in the stack to the top

function MindState:moveStateToTop(statename)
  self:popState(statename) -- this does nothing if the state isn't on the stack, so it is safe
  self:pushState(statename)
end

osuf oboys wrote:3. for a function to access the version it is overwriting, and its associated state.

function MyState:foo() -- foo is redefined on MyState
  return self.class.foo(self) -- non-stateful version of foo (assuming that it exists)
end

osuf oboys wrote:How would you with states have a puppy limp when it is low on health but return to normal once it has filled up - while the state stack is used for a number of other purposes as well?

osuf oboys wrote:How would you have the regular looks (which may be a product of states) be drawn together with a skull to indicate that an actor is poisoned?

osuf oboys wrote:If the walking behaviour may be the product of a number of status states but we only wish to draw one of them - how would you let the state with the "highest priority" take control instead of the one added last?

function Player:draw()
  if(self:hasSkull()) then
     ...
  else
     ...
  end

kikito wrote:It is funny that you mention it, since the Camera system is one of the things I'm less satisfied about. I'll sure give it a look. Thanks for sharing it.

First, there's this "if you build it, they will come" idea. I have hope that if I create a system that is awesome enough, people will use it.

Then there is my direct attack in the form of a tutorial site. Have you seen it? It's still under development, but it is starting to look cool.

popState can do that. Invoked with no params, it will pop the top state, but if invoked with a state name, it will remove that state from the stack:

kikito wrote:

osuf oboys wrote:3. for a function to access the version it is overwriting, and its associated state.

There is already one variable that gives you access to the "stateless" version of all methods: self.class . You can use it similarly to how you would use "super":

Code: Select all

function MyState:foo() -- foo is redefined on MyState
  return self.class.foo(self) -- non-stateful version of foo (assuming that it exists)
end

osuf oboys wrote: What is it with it that you are dissatisfied about more specifically?

Robin wrote:Oh, Kikito: the parrot image on http://kikito.github.com/passion/tutori ... -and-draw/ has a NPO2 height. You might want to change that. Also, how does it pass the parrot image to the Parrot class?

osuf oboys wrote:Even with being able to call whatever you are overloading, you are highly restricted. Whatever I think about seems to go to states with priorities but I think that would be too complex for the framework in nature. I'll have to come back about this if I can think of anything decent.