Code enhancements and project revamping?

[aki-cat]

I heard there was some interest in revamping this project so it could be a library of sorts for making Love2D games? I have many many ideas on how we could do this, but I'd like to know what sort of things everyone wants to see happening here.

Some major things have in mind are:

1. Making STEAMING not a template, but a library.
2. Define (and follow!) a code standard
3. Adapt hump's code to our needs and throw away what isn't needed (it creates globals! like, wtf)
4. Use transform matrices for drawables and have them be trees
5. Add more drawable types
6. Use meshes for drawables
7. TESTS (unit and integration tests)

And some minor things I thought are:

6. Change some class names ("Clr" is not a good name for Color, even if there already is a module named Color)
7. Have gamestates not be global (don't give me that look, I know it's convenient ok, but it's very unstable and hard to test)
8. Rename some functions (findId is a terrible name for what it does)

Do y'all have other ideas? Are these ideas anywhere near what y'all think is useful? Any other visions on this project?

[aki-cat]

Bump. I would like y'all to comment and say your thoughts. This is just a discussion issue. Let's discuss so we can create actual tasks to be done.

[Kazuo256]

I mostly agree with the proposed changes, so I'll just point out the things I'm not sure about.

My main worry is how we prioritize things, and how we approach them. Since STEAMING is used by at least three projects (Psychoball, Marcellous Inc., and Backdoor that I know of), we need to take some devops logistics into account. For instance, the README says that this is currently STEAMING version 4.0.0, but there's only one tag for version 2.0.0. What versions do each project officially depend on? Is going unstable something to be wary of? What does each project need the most?

Now, regarding the actual proposals:

Adapt hump's code to our needs and throw away what isn't needed (it creates globals! like, wtf)

What are you thinking about concretely? And what do globals have to do with unused features?

Use transform matrices for drawables and have them be trees

Is there a specific reason for using transform matrices?
(I don't mind it, just want to understand the motivation)

Have gamestates not be global (don't give me that look, I know it's convenient ok, but it's very unstable and hard to test)

I didn't understand the extra comment.

[rilifon]

I approve improving STEAMING, but as pointed out by Kazuo, my main issue is the current support for other projects. Some inoffensive issues like refactoring the code to a fix standard and tagging versions properly could be a start, and we could discuss and implement concrete issues after that.

I find it useful most of your suggestions, nonetheless.