How can I store cool levels and sweet resources cozily

General discussion about LÖVE, Lua, game development, puns, and unicorns.
Post Reply
Posts: 1
Joined: Mon Jul 09, 2018 7:56 pm

How can I store cool levels and sweet resources cozily

Post by rhapsodos » Mon Jul 09, 2018 8:40 pm

Hello to the LÖVE community!

Two awesome buddies and I are developing our first game, a top-shooter inspired by manic-shooters such as Touhou Project, Ikaruga. But we do like other games, like narrative, role playing games or 3D action RPG.

Anyway, we are a bit discovering Lua and LÖVE2D all at once, and as the dude in charge of organizing the programming, I was wondering about code organisation and resource management.

First, levels serialization. Our levels are composed of fine-drawed background, evil enemies with their patterns, blocking obstacles and the like. All of those are placed on certain coordinates, some are moving... We also have events and levels with differents phases (for instance, you kill a certain number of enemy type "bob", then "superbob" is coming to avenge them and replace them). Those do represent reasonable challenges enough for us, programming-speaking, but I would be happy to have your inputs. How do you store levels as complex entities? Are there standards formats (XML, CSV)? What tools exist to generate and read them? Especially, are there any map generator tools, or level generation?

Second, code organization. We separated our code in four main files:
player.lua, managing movement, drawing and bullets of players
enemy.lua, doing the same but for enemies. We split them from players because they follow patterns, which are special structures that drive how they move and shoot
map.lua storing our maps. For now we hardcoded our first level with its obstacles and spawn zones, but I would like to load them from the outside.
main.lua, doing a bunch of stuff, including animations and collisions.

This is a bit messy and our code is having some sort of existential crisis, not knowing were it belongs. Do you have any inputs on how to organize our code better?

Thank for your answers :awesome:

Posts: 36
Joined: Mon Sep 12, 2016 7:52 am

Re: How can I store cool levels and sweet resources cozily

Post by Nelvin » Tue Jul 10, 2018 7:07 am

For tilebased levels, have a look at - and IMO the best format is Lua itself, data description is actually the origin of the language.

User avatar
Party member
Posts: 1309
Joined: Fri Mar 07, 2008 1:39 pm

Re: How can I store cool levels and sweet resources cozily

Post by ivan » Tue Jul 10, 2018 8:12 am

Do you have any inputs on how to organize our code better?
This is a hard question.
I think it's not a problem for small projects.
For larger projects I like to divide my code into domains: drawing, input, audio, game logic.

There is no "standard" for game level formats.
Lua is a good format for storing levels, just make sure there is a very clear separation between code and (level) data.

User avatar
Party member
Posts: 1178
Joined: Sun Oct 18, 2015 2:58 pm

Re: How can I store cool levels and sweet resources cozily

Post by pgimeno » Tue Jul 10, 2018 4:57 pm

Most Lua data serializers output Lua code. I don't like it for saving stuff, but it's OK for static data like maps. Yes, Tiled is a great map editor, and outputs Lua already (which STI can read).
Thrust II Reloaded - GifLoad for Löve - GSpöt GUI - My repositories
The Microsoft Github repositories I had have been closed after the acquisition announcement and will be removed in the near future.

User avatar
Posts: 19
Joined: Mon Sep 28, 2015 3:56 am
Location: Hyperborea

Re: How can I store cool levels and sweet resources cozily

Post by shru » Fri Jul 20, 2018 7:33 am

I personally think it's well worth the effort of writing an in-engine level editor. Specifically, the editor should operate by letting you place and manipulate entities inside a frozen game instance.

Then, your level editor's format should ideally be the result of looping through each game entity and calling :serialize(). You should be able to take a serialized entity and reconstruct it exactly as it was before being serialized. If you satisfy this condition, then your level format also becomes the ability to losslessly snapshot a game-state, which is useful for making save files, debugging, replays, and many other things.

Obviously, when making an STG (or any game genre) you'll probably run into some things which might not fit exactly into this model. That's fine, tackle things as you see fit. Still, I think the basis of a coherent level format starts with rock-solid serialization.

JSON, XML, etc. Don't matter as they're all pretty interchangeable and have no real implications, but as others have pointed out, serializing straight to Lua is fastest and will have the fewest dependencies. I like Serpent. Just don't use CSV

User avatar
Posts: 16
Joined: Wed Mar 07, 2018 11:21 pm
Location: Denmark

Re: How can I store cool levels and sweet resources cozily

Post by MissDanish » Sat Jul 21, 2018 9:44 pm

This is entirely subjective, but I think the best option is using Tiled ( It entirely depends on what you want to do and how complex your game is, for really complicated projects I'd recommend tiled. But if you are doing a simple platformer making your own might be a better option because it could allow user created levels even

I have been working with Tiled for 5 months now and mostly like it, there are some draw backs though
Smol programmer :neko:

User avatar
Posts: 78
Joined: Mon Dec 04, 2017 1:47 am

Re: How can I store cool levels and sweet resources cozily

Post by modiX » Thu Aug 02, 2018 3:25 pm

Regarding code organisation:

Your game looks like it will have very strict rules and laws in your game world. This makes your game to a good candidate for an ECS bone structure (Entity-Component-System). So far I have experience with tiny-ecs and Concord. I would suggest you to go for Concord, because it has less limits and is faster than tiny-ecs, but there is also Lovetoys, HooECS and nata to consider. You should also implement a structure for gamestates by using hump.gamestate or using your own.

Having only 4 lua files in your whole game will cause some serious trouble as your game grows. Your main.lua should be only the entrance to your first gamestate and the systems of your ECS bone structure should bring the real logic into your game, actually. Entities and their components are only data structures without logic, then.

Once you adapt ECS, you will get rid of all the mess, because your systems are kinda modular and independent of each other, making it easier to find bugs and change code afterwards.

This is a good tutorial to understand ECS even more:
However, this sample is made with tiny-ecs, so you should not look at the code too much and instead understand the sense and logic behind an ECS.
Visual Studio Code TemplateRichLÖVE Mobile (AdMob+UnityAds)


Post Reply

Who is online

Users browsing this forum: veethree and 8 guests