I previously played around with the LÖVE (henceforth, Love2D) game engine as part of a Music Hack Day project with a friend. Lately I’ve wanted to teach myself more about game development, so that I could try my hand at a few indie game projects to see whether or not it’s something I’m interested in seriously pursuing.
I’m not sure how I came across it, but Martin Jonasson & Petri Purho’s “Juice It Or Lose It” video was pretty eye-opening for me in terms of how small aesthetic design choices can greatly influence how fun a game seems. After watching that, I wanted to see what it would be like to implement some of those “juicy” features into EchoBreakout.
A good deal of coding, and three or four rounds of full refactoring later, I came up with an implementation that I’m moderately happy with. It can be found on github here. I’m about ready to move on to playing with other frameworks, so figured I’d do a bit of a post-mortem here. Post-Mortem Time!
Specific Juicy Features
- Splash Screen that bounces in
- Bricks and Paddle that drop in, with jitter and elastic shape/rotation scaling
- Bricks that flash colors, and rotate/scale-down/get launched off into background in the direction the ball hits them
- Ball that has elastic shape scaling, color-change, and rotation on collisions
- Paddle and Walls that elastically bounce when hit by ball
- Background that flashes colors on certain ball collision events
- Confetti particles that eject from ball upon collisions
- Flashing “You Win” text when all bricks are destroyed
Support code to get us there:
- A backend Entity-Component system for managing entities, along with basic CNF-query class for retrieving entities with particular components
- Basic movement, input, collision, time, state, statistics-tracking, and rendering components / systems
- Behavior system for adding special frame-by-frame logic to entities
- Message system for announcing events and allowing entities to register their own response to events
- Emitter component / system (used stupidly for particles here, but generic for any kind of entity)
- Camera system (doesn’t get much advanced use here)
- Tweening and Scheduling systems
- Lua ports of a few basic Java-like collections classes
- Implementation of a Pool util class
What I used / was influenced by Over the course of development, I refactored the codebase I was working on a few times to continually clean things up. Eventually I settled on creating a basic Entity-Component framework inspired by Artemis and posts by Adam Martin. Just about everything in the game is an Entity; every data attribute is packaged in a Component; and everything that happens to update or react to those Components happens in a System. For a basic overview of the theory behind this, check out this post.
When coming up with my own scheduler / tween systems, I was heavily influenced by code in Matthias Richter’s HUMP libraries. Other specific code I directly used can be found on the github page. What I learned; Thoughts on the code / development process
- I had a lot of fun playing with Lua — it’s a nice little scripting prototype-based language with an interesting table-centric paradigm of doing things. I did a lot of things with functions and what elsewhere would be called function-pointers/delegates that I’ve never done before, and it was super easy/intuitive to do so. Metatables are pretty cool and are a fun way to think about how to control objects. That all said, I don’t know that I would use it for any sort of serious non-embedded / non-game-related development, since the built-in libraries are not very expansive, and you sort of have to force objects onto it / gamble on someone’s implementation of an object class — I’d generally stick to Python for things I might consider doing with Lua. The lack of easy IDE-integration made refactoring and changing things tough — though there are things like ZeroBrane and LuaEclipse, the tools they offer are way behind the sorts of things you can do in Eclipse with Java and Python.
- Implementing and working with the Entity-Component system made me retroactively understand my forays into Unity3D much better.
- Being used to using powerful Java and Python libraries, I ended up implementing Set, List, Pool, Tally, and Multimap classes in lua, which was a good exercise.
- Throughout most of the development the FPS was solidly at 60, but towards the end it started going way down. There are some basic things that this just seems to be slow with — for example, trying to implement a simple history class that took a snapshot of the ball’s position every 5-10 frames for the purpose of drawing a ball-trail ended up reducing my FPS by ~10. I’m not sure how much of this is me doing things inefficiently vs. limitations of Love2d, but in the back of my head it feels like if Starcraft 2 exists, I should be able to track this small amount of data without slowing things down that much. (I also don’t think Chrome should use a GB of RAM to have a reasonable amount of tabs open, so that shows you what I know.)
- I’m not super happy with my Rendering classes. I didn’t want my shapes to themselves have Transforms, so they are rendered with an offset from an entity’s Transform component; the downside to this is the shape code itself and the collision code dealing with them is much less legible than my original stab at it.
- If I was doing a game for real with this, I would invest more time in the tests / test framework.
- While Love2d is great for rapid prototyping and very easily building / seeing the results of your code changes, the current lack of easy built-in web-integration probably means I won’t be spending much more time with it — if I was doing game I wanted to release “for real” I’d likely want to use a more powerful C-based language, and if I was doing a hack day project I’d want to do something that could export to HTML5 so people don’t have to download an executable to try out the game. (This was annoying when we were trying to publish EchoBreakout.)
What’s next After this extended excursion into Love2d, I’m likely going to move into playing around with things that can easily export to web and give me more direct low-level experience with OpenGL. Given my experience and level of comfort with Java, libgdx is looking like the most likely candidate for this, though I need to dig more into it.
Since the last time I looked at it, Unity started offering iOS / Android deployment as part of the free version, which is a big argument towards starting to learn more about that for more medium-term projects.