nevermind

[YingYang]

nevermind

[GVovkiv]

do things like "mathf.add(a,b)" is really necesery?
Like, it's more cpu intensive and like require more symbols to write...
a + b or mathf.add(a, b)
Anyway, good job, keep it up!

[YingYang]

I completely agree, I am just going to throw out I think just about everything is temporary. The more I learn the more I go through and change stuff! Im not going to lie I am pretty new at this myself lol.

[ReFreezed]

There are so many issues here, I don't even know where to begin...

I guess I would recommend that you really should get some experience first before trying to make something you can claim will make development easier for people.

[YingYang]

You know what, I'm going to agree to disagree here with you. I said I am new here, I have months of roblox lua, months of regular lua and years of python, java and other languages. This is also one of the big reason's that it is open source so that everyone can contribute if they so wish. I just wanted to try to make things that where easier Like I have a colors module I plan on massively expanding that does love conversion to RGB so then you don't have to look up RGB's all the time, a button module that does al the love drawing from font to position location and all, plus I have been documenting everything exetremely well. I don't know dude just trying to be nice and fill some free time that's all

[ReFreezed]

GVovkiv already pointed out the pointlessness of e.g. mathf.add, which you agreed with, so here's a list of some more problems:

• The color module can be replaced with a color picker. There's an infinite number of them online, they are simple to use, they support every color in existence, and they don't use arbitrary names for colors (like "deeppink"). If the developer has to look up color names in the documentation (which doesn't even show a preview of the colors) they might as well use a color picker. Also, how much development time does a programmer spend choosing colors? It's probably close to none, so no time saved here.
• All fonts in the repository are loaded immediately, which will add load time and occupy memory for no good reason, and they are all created with a fixed size. Surely having a choice of multiple sizes would be something people would want? All the fonts also have different variants, including some that have no variants. Very inconsistent. (The included fonts are also missing their licenses!)
• The GUI module doesn't handle any GUI stuff except very basic rendering of a couple of things. How about detecting button presses? The function names should also reflect what they do, but instead they are called "create", which is just confusing.
• Most variables in the code are global. This is going to mess things up at some point.
• genf.setName/getName/getHealth/setHealth literally just set/get an arbitrarily named field on a table. The calls could just be replaced with obj.name="whatever" which is much clearer than calling a function that effectively does the same thing.
• Module names in require() calls should use "." instead of "/" as directory separator. Module names are not file paths!
• "Exception::Incorrect Variable::Required: Number" is not a good error message, and there's no concept of "exceptions" in Lua. This is not Java!
• mathf.radius returns the distance between two points, not the radius of anything.
• The documentation in the wiki is not good (despite you claiming it is). For example, the page with the colors lists the supported colors, but not what their code is (e.g. the code for "Deep Pink" is "deeppink"). The section about game states is also just confusing. Why are a bunch of flags bundled with enums? Also, the way the example implements states allow multiple states to be active at the same time (like the main menu state and the play state). The code/wiki also kind of mentions something about object IDs, but there are no explanations for that.

Out of all the many many things that goes into making games, what this library currently provides solve almost no problems, but does introduce several. This might change as the library is being worked on, but right now I don't see how anyone should consider using this. If you truly have experience programming or developing games then it's not showing through very well in this project.

Finally I'll mention that things like library/tool lists exist for people looking to solve various problems of various sizes, and proper learning resources exist for beginners. Also, one of the good things (or bad, depending on how you see it) about LÖVE is that it doesn't force you to do things in any particular way - it's relatively low level, you get a lot of freedom designing systems, and you're expected to do a lot yourself. This project currently doesn't really help with that.

[pgimeno]

One thing that I found inconvenient, apart from everything that ReFreezed has mentioned, is that the colours are not usable directly in love.graphics.setColor, you have to expand them, i.e. love.graphics.setColor(chosenColour.r, chosenColour.g, chosenColour.b) because they are hashes, not arrays, so you can't do love.graphics.setColor(chosenColour).

[YingYang]

:/ ok

[zorg]

One last thing; redacting your opening post is, in my opinion, a childish thing to do; the sooner you realize we're not here to personally "dog-pile" on you, but give you (constructive, as seen above) criticism, the quicker you might be able to get in the right mindset and decide if you want to continue working on this library of yours, or not.

[ReFreezed]

zorg is correct. We're just being critical because we care. You shouldn't get discouraged by this. All the mentioned problems can be fixed - you just have to keep working on it.