Lua-based Jet Car

I’ve bound part of the Colorado graphics classes to Lua, along with just enough SDL2 and OpenGL to draw the jet car model.

I’ll be entering for Debian GNU/Linux Testing and Windows XP 32-bit, with SDL2, OpenGL 2, Lua 5.2, and the Colorado graphics classes.

http://192.241.216.120/colorado/colorado-1.1.zip

SHA1 sum: 09204481b907f48aecbecfc8e9a3b78a21999233

Be careful, this Zip doesn’t seem to have a main folder.

This is the base code that I used for warmup today. It depends on SDL2, Lua 5.2 (though it has macros to work with 5.1 somewhat), Qt 4.x (4.8 preferred), and can optionally use PhysFS.

It has a rich heritage stretching all the way back to LD26, and of course I will be using it for LD28 next weekend.

It’s under AGPL3, so if you modify this, make a program with it, and distribute that program, you have to make the full source code available under AGPL3.

http://192.241.216.120/ld28/ld28-warmup-2.0.zip.torrent

The zip is 6.2 MB, and has a SHA1 of 9eb073a219d856631ad22e0de0bec3459bdfa9e3

I finally fixed most of the problem with filesize in Qt 5 deployment, and dropped from a 14 MB zip to 6 MB. But I still want to try using torrents to get a faster download than HTTP alone.

Don’t forget to press “Q” to quit.

LD28 will be my third Ludum Dare, but the first under this name.

I’ll be using the Colorado Game Classes and adding to them as I go.

The current version is 2.0 and is available here under AGPL3: http://192.241.216.120/colorado/index.html

Colorado works on top of SDL 2, Qt 5, Lua 5.2, OpenGL 2.1, and of course C++, so I’ll be using all of those, too.

http://192.241.216.120/colorado/

Don’t let the high version number fool you! Colorado is as unstable as ever.

This update adds UiVboNode to the Lua bindings and breaks compatibility by giving many of the class bindings better names.

By this time tomorrow I hope to be on 3.1. If I’m on 4.0 tomorrow, that just means there was bad forwards-compatibility weather today.

http://192.241.216.120/colorado/

http://192.241.216.120/colorado/colorado-4.0.0.zip

SHA1 is 6d289baa095dbea18915bd8642b7378a4fab2cd7

This version adds PhysFS resource loading and renames a few of the library-registering functions in the Lua binding which is now something like 800 lines long.

In the spirit of a certain mining game featuring plastic bricks, I want to create “Byte Raider”.

Byte Raider will be an RTS where you only get one unit, and you control them directly with first-person controls. Therefore, it is also a First-person Adventure Game.

I wanted to make a game like this already, which is why the main script file for my warmup was “byte-raiders.lua”, but that didn’t get very far.

http://i.imgur.com/8aTRnCi.png

But I’m a bit behind schedule. I should have been here 3 or 4 hours ago.

I’m afraid the scope of my game might be too big.

That is a byte crystal, and soon you will be able to experience grabbing it!

Wow!

In my day, that was all the congratulation we got. And we were happy!

My game is now winnable.

Okay so there is a decent chance I will re-use my Colorado base code that I used to make “Byte Raider” for LD28.

Here is the latest version: http://192.241.216.120:90/colorado/colorado-6.0.1.zip

I might also use some of the shaders from “Byte Raider”, which are available in the release package somewhere, maybe under rom.zip:

http://192.241.216.120:90/ld28/ld28-byte-raider/byte-raider-3.0.1.zip

All my code is under AGPLv3, so if you release a game with my base code, make sure it’s also AGPLv3 so I can reuse your code.

Here’s some images, shaders, and Blender meshes from my old LD games and a miniLD!

http://digitaldoge.duckdns.org:90/ld29/content.zip

Consider them under Creative Commons Attribution Share-Alike.

I would put an example picture here, but WP doesn’t like SVGs.

For MiniLD 53, I’m making a Battleship game which can also transfer files.In the future, you can copy a file from one computer to another.

https://digitaldoge.duckdns.org/battleship/screenshots/1.png

I’m using the latest version of Colorado:

https://digitaldoge.duckdns.org/colorado/

which has all the latest features from Jet Racing (originally my LD27 game) and it has the Lua bindings from Byte Raider, my LD28 game.

Colorado depends on OpenGL 2, PhysFS, SDL 1.2, SDL_Mixer, and GLM, so I’m using all those, too.

I might also use a few files from LD28 that I haven’t integrated into Colorado yet:

https://digitaldoge.duckdns.org/ld28/ld28-byte-raider/byte-raider-4.0.0-source.zip

Particularly vbo.lua and shader.lua which wrap some lower-level OpenGL stuff as Lua objects.

everything’s fine on my end

For this LD, I want to use InterPlanetary FileSystem, so I wrote an image editor that lets you draw a picture and upload it.

Unfortunately it doesn’t work, but I’m publishing it anyway.

https://digitaldoge.duckdns.org/merkle/

The part that doesn’t work is connecting to IPFS. I’m trying to run IPFS as a portable application, inside the game directory, but doing this causes the upload to fail.

The drawing widget seems to work fine.

This code is GNU Affero GPLv3.

Here’s a picture I drew for the occasion:

I got it working!

Here is the code:

https://digitaldoge.duckdns.org/merkle/merkles2merkles.git/

Here is an image I drew in the image editor and uploaded:

I couldn’t get IPFS to work so this is my backup game:

Unless I change something, I’ll be using the Colorado version that Super Jet Racing 3.3 used.

The game, and Colorado, are available here: https://digitaldoge.duckdns.org/super-jet-racing/

I’ll probably make incremental updates to TERF, and I want to redo the mesh format but honestly for desktop it’ll be okay.

Code is all AGPLv3.