I gave PICO-8 a try and ... I found peace.
The strict limitations are strangely liberating. Asset production (one of the most time-consuming parts of game development for me) is a breeze when you are limited to a 8x8 image and a 16-color palette. A similar thing happens with sound and music.
It is the missing link between developing a text-based roguelike and LÖVE.
Then there are a lot of small details like the fact that sin and cos return numbers in the 0..1 range instead of 0..2Pi range. And there is a reason for that (most things in Pico-8 work on the 0..1 range, it saves tokens). And there are "secrets" as well. It might not be something that I would use to create a commercial product, but it is FUN.
And then you realize you are being strangled by artificial, arbitrary limits that don't actually have any reason nor justification for existing.
Thankfully TIC-80 offers almost the exact same experience with more lenient restrictions.
The [0,2pi) interval is rather strange for an output or do you mean the arcus functions?
But recently, I've been really interested in the idea of a framework over an engine. For my non game-dev job, I of course don't use an engine, I use an editor like everyone else, and the idea of having that kind of workflow for game dev seems really appealing to me.
I've been trying to learn Bevy or maybe Raylib, but LOVE always interested me the most for its incredible combination of performance and ease of use, but didn't want to typecast myself to only 2D. Maybe now, that can change.
If someone wants to get into game dev, I'd recommend Godot or Unity, or possibly Unreal if they're the right sort of person, but if Im talking to another game dev, my first recommendation would be to look into a framework.
Do you have any links? If I just go to the normal Love page I don't see any mention of 3D support
Personally for me, the dream is a framework that can do 2D and 3D. The game I'm currently working on will most likely be 2D, but I'm experimenting with 3D and its nice to be able to do all that with the stuff framework. I think Bevy is currently my favourite, but I'm always looking for others as well
I don't use it much at all anymore (though I have heavily in the past), but I would still recommend it to everyone for which it would be a great fit. If you just want to have a game running asap, then yes, maybe Godot is a better fit, but it's not categorically.
In that regard, it's a lot easier than Unity 2D, which doesn't. It also has commercial support, uses pretty standard de facto formats, like Tiled, for its levels, and has been in development for several years.
It's the most starred Lua game engine on GitHub to my knowledge.[3]
Planimeter also publishes lgf[4], which is a LÖVE 11.3 drop-in replacement which provides PBR support, among other things, out of the box for those concerned with advanced workflows.
[1]: https://www.planimeter.org/grid-sdk/
[2]: https://www.planimeter.org/grid-sdk/api/Tick_rate_and_bandwi...
Planimeter looks interesting and all, but I find Lua itself to be limiting for large scale programs. It's great as an embedded scripting language.
This is much the same as love or dgame though. The api is nice, but offers less than godot and doesn't provide any kind of IDE or development tools.
When I click tutorials, I get some installation tutorials some small one or two line code about making entities, whereas with godot or unity or even love, and such by the end you've got a small basic game going.
Actually, to go on a tangent about game tutorials in general...
This:
Making an entity
class "npc_monster" ( "npc" )
function npc_monster:npc_monster() npc.npc( self ) self:setSprite( "images/monster.png" ) end
entities.linkToClassname( npc_monster, "npc_monster" )
Is not an entity as planimeter seems to suggest. It's a sprite drawn on the screen.
There is a huge difference between functional entity and that above code that every single beginner, come learn my engine now and make a game totally misrepresents. Same with player code and every other beginner tutorial. It's not the reality of any game. No entity is a sprite with nothing else.
I appreciate what Godot provides, but we are not interested in building IDEs, because an IDE is not a game engine. We would rather have features that contribute to games than nice editors, which everyone else already builds. Why would we compete with Tiled? Just go use Tiled. We're not competing with 2D animation software either, just go use them, export those files, and see them reload in the engine in real-time.
If Lua is good enough for for major game studios, and nginx, and other software used by the Fortune 500, it's good enough for us.
The point of Planimeter's Grid Engine isn't to provide a game engine for Lua, despite its tagline, it's to provide a game engine that you can build a game with, out of the box, with opt-in multiplayer as simple as setting `maxplayers`.
You cannot do that with Unity 2D. You can't even do it with Unreal. There is no starting up those engines within 5 minutes, launching a server, having a friend connect, and modifying entities in real-time scripting and having them see those changes.
You receive an abstraction over `:spawn()`, `:update(dt)`, and `:draw()`, and can `:getNetworkVar()` and `:setNetworkVar()` for entities, which automatically serializes and sends data and lets the engine perform engine-level, not framework-level decisions on those entities.
They tie into a save restore lifecycle, and have optional physics, that you make a single call to and it's all networked.
Even if you didn't want to do top-down or side-scroller games with this, you have all of the out of the box engine-level mechanics for building card games, strategy games, or anything else in 2D.
To my knowledge, you cannot do that, even with Unreal out-of-the-box.
I think you’re looking at the front-page examples and thinking this is what the engine does, but really it was put up to show a parallel between Grid and LOVE’s front page examples to show how one graduates from sprites, audio, and printing text to networkable entities, emitting networked spacial audio, and creating GUI elements that are composite rasterized.
The fact that they look as simple as they do is the point.
You seem to think this is an afternoon hobby project, but it’s a very old product.
We of course need to update our documentation and marketing to make that all clear, but the parent company has larger priorities and we bring in more revenue than Godot; Grid just isn’t a primary revenue stream.
In the end it comes down to whatever's the easiest, most efficient to use to get a final product. It's the only thing that really matters when it comes to a tool.
If two tools offer the same things, but one tool offers the ability to do it faster, more easily and more efficiently, that's the ideal tool of choice.
No documentation whatsoever besides a sloppy "getting started", despite being at version 9. By contrast LÖVE has a very comprehensive multilanguage wiki.
Isn't your project an abstraction _over_ LÖVE2D? Odd way to choose to market yourself
That repo hasn't been updated in over a year. Have there been any success stories for grid-sdk other than what you've used it for?
We are held up by releasing the next version due to existing contracts we’re working on, and expanding the business.
The next version will have explicit commercial support on the website and a community version.
Such a curious thing, how we all want to love Lua so much, and yet it's so cumbersome sometimes to get work done with it. It's the beauty of it, I guess.
We're a bit tied up with with some consulting projects at the moment, so Grid Engine 10 has been in slower development than the last few years.
We're planning on providing commercial licenses for small studios at something like a one-time $999/license with things like out-of-the-box community server support and at-cost multiplayer infrastructure, which is something like $15/yr for roughly 1,000 concurrent players at 20-tick.
I find it to be a competitive advantage that we provide community server browsers in the engine directly (think Source or further back, Gamespy/Quakespy) and no one else seems to do this? We also use the common Gamespy server browser protocol, which is also a de facto standard.
I would be curious as to why major studios don't also do the same, but the answer is that most of them want to control the servers today and not let you run your own communities anymore.
Unity allows Multiplay to basically own that, which I think is telling that they don't care about that developer experience.
Godot has no answer to any of this. You also have to roll your own multiplayer entirely.
Planimeter doesn't compete with Unity 2D mobile games. We try and stay away from that sort of image. Our software and licensing is intended to compete with desktop 2D games.
The company has been around for 11 years and was previously a Source Engine contractor. So if it seems strange that company has been doing nothing for a decade, it’s because it’s not our primary revenue stream, but up until now has been our largest open source product that I plan on commercializing.
It’s a very slow process, but one that I think we can still outpace Unity’s 2D offering on, considering that they do not deliver solutions our organization has needed for several years. And that’s their primary revenue source.
What is it missing? I'm honestly racking my brains here trying to think of stuff I've tried to do that was unexpectedly hard, and I can't think of anything. Maybe passing large arrays of vertexes to be drawn can be awkward.
This looks pretty awesome and all but I can't see the benefits over something like unity or unreal or the amazing for the cost and features Godot.
I really like Lua. I've always recommended it to beginners or anyone curious about programming for fun over every other language. I've used it myself extensively
But in this day and age, I can't really see recommendating this or even LÖVE2d anymore to anyone interested in getting into game programming.
There's just too many high quality alternatives these days.