Grace (Alpha 4) - object-oriented framework for LÖVE

[BlackBulletIV]

Well, here's where Grace is at. Even though for most of the development process I didn't think it, I was falling into the trap of making engines, not games. Grace has become so big, I find it hard to work on, and because of this there are also a tonne of bugs lurking all over the place.

So instead, I've started working on a game, without using Grace at all. I've taken the fundamental concepts of Grace (worlds, entities, layers), simplified them a lot, and only implemented what I need; and now I'm actually getting somewhere!

Grace will most likely revive again, but when that does happen, I'll scrap all that I've done, and extract the core code that I'm working on into a reusable library (following the advice of the article linked to before).

Anyway, I've learned my lesson, and that's the status of Grace!

[genericdave]

Edit: Added another bullet point.
Another Edit: Added suggestions for critical components.

I think this is a step in a good direction for you. I've looked at your Grace lib, and while it's impressive, it's huge. This, in itself, is not a bad thing, but the problem is that you were trying to wrap everything up right off the bat. As a result, in order for someone like me to use it to do anything useful, I would have to learn your new system and then pray that I don't run into a hole in the code that I would have to fill by digging into your codebase.

Essentially, what I'm saying is that attempting to write such a massive lib so that you could free yourself up to write game code will most likely only end up bogging you down in details and intricacies. Starting over and thinking small is probably the best thing you can do right now, so good on you for that.

I propose we throw some ideas and code around in order to get a workable idea of what's needed in order to actually simplify game creation. I'm working on some stuff right now. Maybe we can help each other out.

Here are a few of the requirements I'm setting for myself when it comes to writing backend code:

1. Simple. Nothing overly complicated. If it's complicated and finicky and has a bunch of dependencies, then it's probably wrong. Someone who's never seen the code shouldn't be immediately lost upon entering one of the lib's files.

2. Pluggable. If I (or somebody else) wants to use my Camera class, I (or they) shouldn't have to use a world/actor/state/xml parser/metascripter/etc. I should just be able to plug it in and use it on its own.

3. ALWAYS in a useful state. This means that I don't go off on a tangent and leave my Camera class broken because I need to write some other class in order to make my Camera class awesome. Code should be progressing from point to point in a linear fashion without getting broken by feature bloat.

4. Doesn't restrict you by trying to do everything for you. Abstracting away world transformations and rotations into an easy to conceptualize Camera class is a great idea. Restricting the way my game can be written by locking me into a particular kind of scene, world, actor, state, etc paradigm is not. All those things (scenes, worlds, etc) are perfectly fine in and of themselves, but they should be made in a way that allows me to use them in order to help me code. A lib should be a sidekick, not a tyrannical dictator.

5. Easily modifiable. LÖVE will change. Needs will change. Bugs will crop up. Problems will arise. If the code isn't manageable, it isn't able to keep up with change. And if it isn't able to keep up with change, it isn't useable.

6. FOCUSED. Having a Camera class isn't useful if it's only half done. Whatever I'm working on, I need to get it nice and solid before I move on to a thousand other things. Regardless of how sweet having those thousand other things would be, they are all useless if none of them are implemented fully.

I'm curious to know what you think. The experience you gained from making Grace has undoubtedly taught you countless lessons. This is your chance to put that new knowledge to use and make something really awesome. The truth is: we need something like this. LÖVE is fantastic. It's flexible, fast, stable and all around awesome. It allows us to do most anything by not trying to do everything. However, there's a huge, gaping hole that needs to be filled by us on the script side of things. Let's fill that hole. There doesn't have to be any one tool to rule them all. We just need at least one tool that actually works, and works well, without trying to be everything for everyone.

Ideas for core classes:

We need to focus here, so let's come up with the most critical core components of any sort of 2D game lib. Some ideas:

1. Camera. (In case I didn't make that obvious enough) Humans don't think in terms of translating coordinates on a 2D plane. Let's put it into terms we can easily conceptualize. In other words, we want to zoom a view rather than scale a 2D coordinate system.

2. Draw manager. I shouldn't have to think about what order I call things in when I want to draw. Layers and culling should happen without bothering me with details.

3. Timing and interpolation. If I move a sprite 2 pixels to the right every frame, what does it mean to the player? The output will vary greatly depending on framerate. Instead of thinking in terms of frames, we should be thinking in terms of seconds and accelerations and interpolations. (Of course, we should also never restrict the programmer from doing things in terms of frames)

[BlackBulletIV]

Thanks for your long post, some great things you've said there.

I actually didn't try to wrap everything off the bat, alpha 5 (not released, and probably won't be for a while) started that. And this is where I went badly wrong. With the amount of stuff I was doing, I should've just written my own game engine instead. I didn't start by cleanly integrating Grace with LOVE, which just ends up making game development ungraceful. The core code I'm working with now is currently attempting to integrate with LOVE and nicely as possibly, really only providing organisational aids, and some utilities.

One thing I should clarify. Grace is probably not what you would call a library; instead it's more of a framework. Where I want Grace to go is more like Ruby on Rails approach. Rails makes things extremely elegant and simple, by locking you into a certain way of doing things. This means it can aid you with code generation, and awesomely simple ways of doing things. I'm starting to think of the ideal Grace as a kind of "Rails for game development."

As for point 5, this is where I also got into trouble. Because of how big and massive it was, I found it hard to manage.

We just need at least one tool that actually works, and works well, without trying to be everything for everyone.

That's kind of what Rails does. It works well, but doesn't try to please everyone. I think that's a good direction to go.

For you ideas:

2: FlashPunk (off which I've based a lot of Grace's ideas) has a simple numbered layer system. You specify a number, the lower the number the higher something displays on the screen. Is this what you're talking about? Or are you talking about some sort of graphics system like in FlashPunk?

3: Are you talking about a tweening system with options for frames? I think this is very important.

Thanks a lot!

[genericdave]

I actually didn't try to wrap everything off the bat

Yeah, you're right. A better way of putting it would be to say that you seemed to be spreading yourself too thin. You have a lot of code, but nothing really cohesive. In other words, you didn't try to wrap everything off the bat, but that was the direction in which you were heading. Am I right?

As for Rails, I don't have much experience there. It's probably not a bad place to draw inspiration from. That definitely seems to be more of a monolithic system, however. Meaning that each part seems to be pretty dependent on all the others to keep consistency. From a usage perspective, however, it's probably a great model upon which to build. Just try to keep your focus narrow and work on improving modularity. If it isn't modular, it'll probably end up in perpetual development.

Now that I see Flashpunk, I can start to see where you were getting some of your ideas from. Worlds and entities and the like. Good stuff when done right. And you're right, when I was talking about layers, I was talking about a system where lower number = higher in draw order. I've got something started in this area. I've also got the start of a tilemap class and a camera class that's essentially done, but could use some more time to get the kinks out. I'll be putting up some code once it's looking a bit better rounded.

Are you talking about a tweening system with options for frames? I think this is very important.

Yeah, basically. Watch one of the tutorial videos over on Cocos2D to get an idea (some of them are also quite amusing).

Anyway, I shouldn't distract you with high-minded banter about game libraries when it sounds like ignoring that sort of thing would be the best way for you to make some headway. I'd say, get something playable done, then show us what the state of your framework is. By then, it'll be battle worn and field tested and all. I'm sure I'll have something circulating by that time as well, so we'll be able to compare notes.

[vrld]

The wiki contains a lot of useful libraries.

1. Camera. (In case I didn't make that obvious enough) Humans don't think in terms of translating coordinates on a 2D plane.

hump.camera does that. It's also easily pluggable, though it depends on hump.vector.

3. Timing and interpolation. If I move a sprite 2 pixels to the right every frame, what does it mean to the player? The output will vary greatly depending on framerate. Instead of thinking in terms of frames, we should be thinking in terms of seconds and accelerations and interpolations. (Of course, we should also never restrict the programmer from doing things in terms of frames)

That's why you use the dt variable for that stuff.
For interpolation, EmmanuelOga implemented both an excellent easing and tweener library. For timed function calls, you could use hump.timer.
lQuery also provides neat generic animation functions.

2. Draw manager. I shouldn't have to think about what order I call things in when I want to draw. Layers and culling should happen without bothering me with details.

I am not sure about that. It's hard to maintain your requirements "simple", "pluggable", "easily modifiable" and especially "doesn't restrict you by trying to do everything for you" while providing a general interface.
On the other hand, it's really not that hard to implement something specialized that suits the game you're making...

[genericdave]

I'm not sure how I missed your hump library. I will be checking it out. It definitely has promise.

I am not sure about that. It's hard to maintain your requirements "simple", "pluggable", "easily modifiable" and especially "doesn't restrict you by trying to do everything for you" while providing a general interface.

That sounds like a challenge. I have an idea of how the implementation will go. If I get something neat, I'll put it up for inspection. Unfortunately, due to lack of several critical features in love (namely, a portable, fast, modular random number generator and ssl among other things) and the difficulty involved in modifying the love base code in non-trivial ways, I might be migrating over to Slick2D for now. Oh well. I can still use love for prototyping and the like.

[BlackBulletIV]

Now that I see Flashpunk, I can start to see where you were getting some of your ideas from. Worlds and entities and the like. Good stuff when done right.

Well, I'm an organisational freak, and my experience in FlashPunk (first experience in game dev too) was awesome (seriously, it's a very well crafted library).

And you're right, when I was talking about layers, I was talking about a system where lower number = higher in draw order.

That's what I've implemented in my current code. Much simpler than using full-on classes for layers... saves me headaches.

I'd say, get something playable done, then show us what the state of your framework is. By then, it'll be battle worn and field tested and all.

That's the plan.

About all the timer, tweening stuff. This is one place I really want to make a simple and elagent API, that also doesn't have a lot of overhead underneath. I was getting closer in Grace I think, but that was still a little heavy to use. What I would want is an extendable API underneath, with some core actions controlled by simple function calls... if that makes any sense. Kind of like this:

Code: Select all

delay(1, function() print('1 second gone!') end)
delayFrames(5, function() print('5 frames later..') end)
entity:animate(1, {x = 3, y = 4, lameness = 1000}) -- first param is duration - lQuery has this kind of thing

And about the draw manager. I think I tried to something like this will Grace, with Graphics and Entities have graphics and so on. FlashPunk implemented this, and I think I like it. But FlashPunk was only dealing with images really, and a bit of text. In LOVE we can draw circles, polygons, and all kinds of other cool stuff. So I tend to shy away from a draw managing system a bit, instead preferring just a draw function for entities.