LÖVE

Hi all,

Update 2017/09/23, r022 : Playable game with full scoring, ships with different features and a revamped interface,
Update 2017/08/27, r013 : fixed slowdown issues upon explosions and asteroids generation by preloading all graphics,
Update 2017/08/25, r011 : at last, asteroids get blown away on impact !
Update 2017/08/23, r010 : asteroids get destroyed when they impact and exit screen properly, works roughly, but still to be perfected,
Update 2017/08/20, r009 : game now starts in windowed mode, then player can toggle full screen from Options dialog,
Update 2017/08/20, r008 : ships loading from data dir instead of being hard-coded,
Update 2017/08/19, r007 : first playable result, still rough and full of ugly code, but with a minimal gameplay !

I discovered LÖVE2d a few weeks ago and immediately felt enthusiast about it. I already had a Lua background as Stars of Call (aka SoC), the game I'm developing on the Hoshikaze 2250 (fr) universe, is a TC built on the open-source NAEV game, which uses Lua as scripting language.

So I set to experiment and develop an asteroids-like using the graphics I already had for SoC. I quickly found frameworks suitable for my needs, as the OOP and MindState, and a few GUI, from which I choose LUIGI. It's going well, I have the main menu screen set up and most of the project structure. So I'll now be able to proceed to coding the main gameplay.

The goal of this example is to learn LÖVE2d and the frameworks it has available, to make it a tutorial for integrating these frameworks and structuring a project (no one-folder projects with all Lua source dropped in), so I can go farther and make bigger projects...

My ultimate goal, once this example is completed, will be to use the full SoC dataset to make a Lua-only SoC, which will feature different things from NAEV, mainly orbital movement and a richer economy system, and will then be easy to convert to 3D by eventually switching to LÖVE3d, without changing the internal structure.

With little time to code (around half an hour on morning and evening commuting), it'll take some weeks or months. But I've tried so many frameworks and engines, LÖVE2d is at last one I feel comfortable in...

Of course, any criticism and suggestion is welcome to enhance the game and help me to progress, the idea is that this game be used as an example for beginners, showing what I discovered when I was gathering XPs to reach LÖVE Coder Level 1 ^-^

Hi all,


I just attached the first result I can show. It's very rough and only has very limited features, but at least it runs and one can play, even if it's very crude and won't make anyone addict ^-^

As of now, I learnt about :

• Basic use of the LÖVE2d engine, because that's the main point ^-^
• Use of MiddleClass OOP and StatefulObject FSM to make a structured application, and LUIGI for an easy to design UI,
• How to break the code into manageable chunks, properly packed in a structured folders tree reflecting the code's structure.

Next steps as I can see them :

• First, refactor the code by breaking some parts into functions and generally speaking, making it more structured and manageable,
• Add basic Asteroids features like player shooting as asteroids, asteroids breaking down when colliding between themselves, a constant supply of asteroids instead of having them reappear on the other side when they exit the screen, a more elaborate scoring method, difficulty options..,
• Add mining with a limited range beam, so the player is drawn to get close to the asteroids, thus risking collisions, and adding level success conditions instead of only failure condition,
• Customize ships according to what their graphics suggests : agility, resilience, weapons and mining capabilities.

The idea behind these evolutions is to make this crude prototype into an enjoyable game, but also to keep on learning. For instance, I need to grok how to read XML to get the ships' data from a set of files, to make a bullets hell, probably with inspiration from InvaderGame ^-^, or to properly use Lua variable scoping inside a large-scale project, issue in which I'm still fumbling...

Looks good, especially considering your (relatively) minimal experience with the engine! My bit of feedback is somewhat nitpicky, but in general people dislike it if your game starts out full screen.

Hi davisdude,


Thanks for your comment and appreciation ! I would never have been able to do it without the frameworks I've used ^-^

The full screen was for sake of simplicity and I like full screen, but I intend to set it in the (not yet implemented) Options panel, start windowed by default and give the player the choice.

I've made progress on loading the ships and now there is no more ugly hard-coded ships list on the globals, instead the game reads the ships data folder and loads what it finds, without crashing on common errors like sprite file not being there... This allowed me to try and learn various XML parsers. I finally settled for SLAXML, but I have yet to test libxml. Now that the structure is working, replacing a parser will not be difficult.

So I've uploaded a new file with version number 008 !

Hi davisdude, hi all,


That's it for the windowed mode start and fullscreeen toggle...

Hi all,


Next release, asteroids are now destroyed when they impact and the collision spawns smaller asteroids, and asteroids also exit the screen properly, instead of being teleported to the other side.

However, code is beginning to become messy and needs a serious refactoring. I'm beginning to see the limits of my approach and some ways I could improve that. Notably, I could make a better use of Lua variables scoping and define everything at the right scope instead of having everything ending up global by laziness... I'm also thinking at having global variables storing all the game objects lists, and trying to define all non-OOP-factory and non-module globals in one place...

Also, I've added a lot of debug prints on console, so as to make sure everything goes as intended, so don't worry if your console is furiously scrolling while you try to concentrate on your ship ^-^

I've also yet to find some appropriate balancing parameters for asteroids spawning on collision, so as the game stays fun but does look realistic enough not to break suspension of disbelief...

Also, my next goal will be to introduce some animations. For asteroids collision, I'll settle for a nice classical explosion, like pure Hollywood asteroids, made of balsa and stuffed with TNT ^-^ Hopefully, this will be enough to hide the weirdness of current new asteroids generation.

Another detail : if you look in src/main/functionDefinitions.lua, you'll notice 2 functions to handle collision, an old and a new one, of which only the new gets used. The difference between the functions is significant : rough debugging draft and somewhat refined code...

Then, once these issues are solved, I'll be able to get to the point : shoot at asteroids and extract minerals !

Hi all,


That's it, my Hollywood asteroids are there, they nicely blow up when they hit one another ! However, since 009 or 010, I don't remember, I've been forced to use a delay, when a new asteroid is impervious to impact, to manage what happens just next. That's quite unnatural, but I don't know how to do it otherwise. One of my goals in 011 was to get rid of this, but I didn’t succeed and the delay is still there...

A few adjustments now and I'll be able to introduce the next step : ship characteristics, displayed on the selection screen and including armour for resisting multiple impacts, a mining beam for getting material from nearby asteroids, a weapon for shooting at them and agility, broken into acceleration and rotation, for dodging them. Of course, most agile ships will also be destroyed by one impact, while slower ones will be able to sustain a lot of beating...

One issues that bothers me, and on which I would want your feedback, is performance, specially when spawning new asteroids. I didn't optimize anything, and specially, I didn't preload anything, I just pass plain file name to the asteroid creation function. That's bad... So, in stock for next steps is getting rid of these loading delay issues by preloading asteroids and effects graphics.

Now that the game's structure is reasonably stable, I would also like to get a feedback on that structure : do you find it sensible or uselessly complex ? Do you feel some choices, like having a folder for all classes or grouping functions definitions in a single file, are unnatural ? More generally, what would you improve on that matter...

Another thing I've been thinking about, is to keep the player's ship at the center of the screen : that means a camera and there are different ways to do it. It would also change many tests in various files. Not for 012 I think, for hopefully for a coming release...

Thanks in advance for any comment and advice ^-^

Hi all,


That's it, the preload for all graphics works and as intended, fixes slowdown issues when an asteroid explodes and many objects are created at the same time.

Not much else to say, as there is absolutely no gameplay change ! The next planned feature is to keep the ship at the center of the screen, thus learning to define and use a camera object. Following the ship's or the environment's orientation is still a decision to be made, but maybe it'll end up as a toggle in the Options panel. Another future improvement will be to have different ships have different stats. And of course, to be able to shoot and mine the asteroids.

Release #12 was skipped as it was just a small refactoring without much impact. Major refactoring is still to come, it'll be inspired by MadByte's airtaxi code structure, in the wake of what I'd already seen in Arne Schwettmann's Space Taxi, hengying's Invader Game and LudvickToba's Town. The idea is to have a main.lua just creating a few globals by objSomeObjet=require 'some.object.module.path' statements, and then declaring a love.load() function that just calls the main game object. It will use the same libraries as I did before, it's just how I manage globals that will change.

Hi all,


Just some news : I had some bad times refactoring the code, but little by little I began to tame this Lua global things and to devise a sensible structure for my game. There'll be enough work to fill several sessions of commuting time, but by the week-end I should have something to roll out... but maybe it won't have progressed feature-wise...

Nice one!
The screen has no borders hehe
Once I leave it I can't die anymore.
It's hard enough, I like it!
I'm sure that it could become a good game with more ideas and features!