PÄSSION: object-oriented LÖVE

[Geti]

I'm sure i'll get the hang of it. Got to write an essay before I start coding though, and I've got a party tonight. not a great weekend to try for a LD, but oh well. At the very least, it saves me from writing up another class system > an hour or so.

[Luiji]

Aw! I was just about to start using it when it turned out the link was dead! EVIL ALIENS!!

Could you please repost this? And could you please repost it at GitHub.Com so that I can use Git's amazing updating abilities? And it could also allow me and others to submit bug patches through a simple [git push] request.

[kikito]

Hi!

I believe everything is on github already.

What do you need, specifically?

[Luiji]

I don't need anything, I just want to help develop PASSION so that it can get past the alpha stage.

Downloading from GitHub and analyzing...

For now I'm still going to use an internally written game engine until it reaches beta, but I'm modelling some of my game engine after PASSION (I'm using MiddleClass and integrating MindState).

[kikito]

OK I've got some comments:

• 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]

Kikito: Just a quick comment. Thanks for the stackable states and all the other new functionality. I wonder though if your project is not starting to deter new users by its size alone. I know ËNVY used to have something of that effect. 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?

I liked the idea that you had of decoupling parts of your project. This should battle the previous point to some extent. 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.

Regarding MindStates, I think three things that would be nice would be 1. to remove a state not necessarily at the top of a stack, 2. to move a state in the stack to the top, and 3. for a function to access the version it is overwriting, and its associated state.
To illustrate the usefulness of this functionality. 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? 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? 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?

There is an issue on Windows in that you cannot have both a file named "timer.lua" and one called "Timer.lua".


Thanks!

[kikito]

Wow! I'm going to have to digest all this on separate chunks.

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.

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.

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?

Thank you for your kind words. I understand exactly your concerns, and I'm fighting this on several fronts. Your question is a bit philosophical, so my answer will be too (sorry)

• 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.

1. to remove a state not necessarily at the top of a stack

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:

Code: Select all

myInstance:popState('MyStateName')

2. to move a state in the stack to the top

I think it is not common enough to be included on Mainstream Middleclass, but you can implement it yourself like this:

Code: Select all

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

Notice that callbacks will be fired - but I'll assume that is desired.

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

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?

If we have a limp that has no full health, I would simply not use a state. Instead, I would do the plain old if(health < 100) then color=red end . It just takes less space than creating a whole state just for that.

Also, states are kind-of-binary things: you are on them or you are not. Health is more like a range-like thing. The "low health" condition is better expressed by a number than by a state.

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?

If I had things like "Poisoned", "Dazzled" etc, I think I would not use States for this neither; they overlap so much that I would not probably be able to add one without having to modify the rest. But this is just a first thought.

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?

The only way I can think of for making "behaviours that are a product of different stacked states" is by having it "condensed" on a single method, with "holes" on it. The holes would be implemented differently depending on the state.

Code: Select all

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

The Poisoned and Dead states will return true on hasSkull, while the rest would return false, and so on.

I hope I answered everything. Will review the Camera.lua file as soon as I can. Good night!

[osuf oboys]

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.

What is it with it that you are dissatisfied about more specifically?

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.

Sounds fair. There's also the idea of simply implementing what you need yourself because then at least someone will have use of it - you - and chances are others will also. Perhaps if it is awesome enough, you will even have others do the preaching for you.

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.

That's pretty neat! Though what is the idea behind deserting the wiki systems of LÖVE and GitHub? (btw, you may want to add the GitHub link to the first post of this thread)

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:

Ah sorry, didn't know that and was assuming too much. Thanks.

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

Not quite what I had in mind. Let us say that we have a class A and a state B; each with a draw function. One common thing you might want to do is to add some detail to the drawing (icons / sweating /outlines, etc) while a state is active. One way to do this with a state is to simply call whatever was doing the drawing before the state was added (either A or B) and then draw a bit more - i.e. the closest thing on the stack (or the class) that has the same function defined.

You sort of trivialized the limping example. Let it be from a trap and a temporary effect then. Defining checks such as "hasWhatever()" is one solution but it is not perfect. Doing it this way seems to fight a lot of the beauty and power that states otherwise provide, leaving you with pseudo-coupling, code duplication, and potentially major code changes for otherwise simple functionality. Although nicely touching on aspect-oriented programming. Actually, I'm not sure what the solution is, or even if there's a decent one. 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.

Sleep well!

[Robin]

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?

[kikito]

What is it with it that you are dissatisfied about more specifically?

It's just ... fugly. I can't point to anything concretely.

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?

Thanks for pointing this. Will mend this evening, hopefully.

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.

I forgot to mention my other "PÄSSION policy": standing on the shoulders of giants. For MindState, I pretty much copied what UnrealScript does. I think. But maybe my sources are outdated or something. It might be worth it to ask on the Unreal forums how would they model that multi-state thingie.