The Aftermath

Not quite sure if I should call it a ‘post-mortem‘. There are hundreds of these already there. It’s not about what I think went right or wrong. It just … did. Generally I’m glad the way it turned out. However, since I want to keep working on this game I’ve decided to make a list of changes I want to apply to it. That’s why I called the post ‘The Aftermath‘.

The main purpose is to expand it and make the framework more flexible. Then I will extract it and use in future compos.

So, here it goes:

Level entities’ management. Every object in a level is derived from a CEntity class. The examples are mainly … blobs. The pointers to the entities’ instances are stored in a globally-accessible array, which can be accessed at any time. When an entity is no longer needed – it gets deleted and the array is rearranged, getting rid of an unnecessary pointer ( it’s a C++ vector container ).

What if we want to store the reference to the entity and use it on later occasion? For instance, a blob chasing another blob could save a reference to its target and update its position every tick based on that. Storing a raw pointer to the data in memory is risky – we are not able to check whether the entity has been already deleted and the memory’s been freed. Trying to use such a pointer would result in very pesky and hard to track down bugs.

That’s why I came out with the idea of … IDs. An entity’s ID is an index at which it can be accessed in the main entity array ( the STL vector mentioned earlier ). When an entity is about to get deleted, the memory is freed, but the pointer in the array is set to NULL. That way it never gets overwritten and we can check if the object is available, or not. An ID would be an unsigned integer, so it could range from 0 to over 4 000 000 000! The free IDs will never get depleted and the entities themselves will be getting deleted from memory at a constant rate.

The array itself could be though great in size after a while. Every frame each entity needs to receive a tick. Iterating the entire array will be getting more and more time-consuming with the number of the array members growing in size. So … what about a second array? It would contain the IDs of non-deleted entities – that way only the valid members will receive a tick every frame without iterating through the NULL-ed entries.

Although it looks complicated compared to the previous system, it seems that it’s worth a try. Did anybody run into similar, or other worthy conclusions on that matter?

The level editor. Because of a lack of time, I had a really tough time designing the levels. A level editor and an external level file format could really get in handy in this case. Running a game, writing down coordinates and typing them in manually in a source code doesn’t sound appealing, especially when you’ve got dozens of objects which need to be somehow adjusted. I have really no idea how I’ve managed to put all of these blobs in place manually in 48 hours.

The scenes. The hardest thing to think through than the levels themselves. I’m talking here about an intro and ending scenes. Naturally, when you have an idea, you write it down as following: “It fades in within the first 2 seconds. Then it plays the sound X, waits another 2 seconds, shows a few lines of text slowly and gradually fading in …” etc. Not a tough job. It gets complicated, when you only have a level tick method called every frame to put these things in.

Let’s say you want an entity to play an animation after 2 seconds after the beginning of a scene. In the level you’d have to write an if statement which will be called each frame. It’d have to check, whether the time from the beginning of the scene was greater than 2 seconds and if it hadn’t been already greater that 2 seconds the frame before ( starting playing a sound every frame wouldn’t sound pretty – it must be called once and left alone for it to play along ). If there’s many of such ‘timed events’, we need a lot of variables. And now, if not the static variables available in C++, I’d find myself in the dead end. Although the scenes work pretty well, the code itself is a massacre and I was really confused which if statement was responsible for what event.

The threading system could be excellent here. Unfortunately I did attempt this concept few months ago and failed tremendously. Maybe because I used very unfriendly Windows API, who knows? But what other alternatives do I have?

And that’s when I thought of … Lua. I never had the opportunity to work with Lua and so I don’t know its specifications. Hopefully it allows for such maneuvers. I’ll have to dig into it. Is it possible to use threading in Lua?

That’d be it I suppose. There’s a lot of other points in my list but these are regarding either entities’ classes in particular or their implementations. Anyways, after polishing out the game itself, I will add more enemies and more levels, scenes. Hopefully it will come with a great ease. Greater than previously, that’s for sure. Eventually I will publish it.

If you have any suggestions, I’d appreciate if you shared them! I don’t want to implement a total bummer and base the upcoming code on that

Cheers! Thomas

So, just had a shower and came  up with an idea. You play as a person working for the tiny world corporation, a company that purchases tiny bodies in the universe (asteroids etc) and attempts to turn a profit by building accomodation, shops and factories. It will be similar in style to city building games, however there will be an emphasis on trying to maximise the profit making potential of the small area you have on each world.

My inspirations are the tiny levels in the roller coaster tycoon games, and some of the levels of theme hospital where you have to accomplish with not much space.

I will be using löve with lua for the game, gimp and inkscape for graphics, Bfxr for sound, and some kind of music generation tool for music.

I’ve been toying around with LuaJIT lately. If you’re not familiar with LuaJIT, it’s a just-in-time compiler that not only makes your Lua code run super fast, but it also makes it possible to call native code from Lua without any native glue code at all. Pretty cool tech.

OpenGL requires some special handling though, so I made an OpenGL loader for it that handles all the dynamic loading, version differences and extensions and such for you (based on the official spec files), and added some extra code to make shaders easier to work with. I didn’t really plan on using this for LD, but hey, might as well post it now so that I have the option: ld23base.zip (zlib license)

That zip includes some example code using SDL + OpenGL to draw a spinning rectangle in pure Lua =).  I doubt anyone else will use this, but you’re of course welcome to if you want =). Please let me know if you do! It’s a bit WIP-y still, but fully usable and should be pretty straightforward if you’re familiar with SDL and OpenGL. It probably requires LuaJIT 2.0 (beta) to run, and it’s only been tested on 64-bit Linux, but it should hopefully run on anything supported by LuaJIT as long as SDL and OpenGL libs are available.

Hello. I wan’t to put together a team of Lua programmers for the Ludum Dare 23 Jam. We will be using the LÖVE framework/engine for the game. If anyone is interested, please leave a comment.

Current team members:

mad1231999(me)

koblaja321

Volcanox was a lot of fun for me. Although a programmer, game development is not something I normally do. Additionally, it was also a test of the programming language MoonScript. I wanted to see if I could write a game in my own programming language.

The results, I thought, were pretty good. By the end of the competition I had something playable. I even had time to write music and insert sound effects.

If you haven’t played the game yet, you can do so here!

The Process

For this project I started with plain LÖVE. I figured I could get a foundation together. Even before the theme was announced I was pretty certain of making a platformer. It’s something I’ve never done before but I implementation ideas in my head. The first night was all writing collision detection code and movement. This was the one thing I was certain about writing, so I plowed through it. I even had time to write a map loader

I implemented an algorithm called Uniform Hash Grid, which let me subdivide my collidable objects to reduce the number of checks per frame. This worked very well, I was able to create a huge map with no impact to runtime performance. (It had a little load time though, which I think I could improve if I had more time.)

My map loader just loaded a bitmap where pixels represented collidable tiles. I did this to avoid having to use any real map editor tool. In my code I assigned colors from the map image to be actual tile sprites. This was my first map:

From there I just added gravity, and assigned a jump button and I had a working platformer.

I spent some time fooling around with ideas. I wrote a basic particle system which I later used for all the shooting effects.

The next day, after waking up I decided to tackle something I thought would be very hard, drawing sprites. I put together a simple (and awful) animated player sprite:

After that though I kind of lost sight of what I wanted to create. I had a working system, but I didn’t know what kind of game to create. I  got lazy and went out to a coffee shop with friends. I think this was unavoidable because I needed time to think. After that I decided I would have shooting and enemies so I started coding bullets. I added minor things and created a tile set. Things were looking okay but I still didn’t have a game mechanic.

On the last day the name Volcanox finally came to me. I coded up until 1 hour before the deadline adding simple game features like title screen, and winning and losing conditions. I added one enemy and wrote the AI. I had no experience writing something like that so it came out very unnatural. I decided that because the game was so simple, I would make the enemy spawning very aggressive. This actually made the game (annoyingly) hard. I expanded the map to make it huge and have lots of enemy spawners.

Here’s the final map: (yes that’s a volcano)

The last hour I rebooted into OSX and recorded some music on my keyboard, and quickly got some sound effects out of bfxr. I submitted my game at exactly 6pm.

The final submission’s source code is on GitHub.

Review of MoonScript

Part of this project for me was testing how well MoonScript would work for game development. MoonScript is a language that compiles into Lua. It’s a slimmed down syntax that adds a lot of sugar. Things like classes, list comprehensions, and a lot of other useful stuff. It works great with LOVE.

I wrote 1534 lines of MoonScript, and it compiled into 2880 lines of Lua. Pretty cool!

I heavily used the class system, and the inheritance it provides. It allowed me to quickly scaffold objects in my game. I think if I were writing Lua, a lot of time would be spent designing my object interaction. In that regard, MoonScript was an excellent tool to use.

I strongly recommend it for game development.

What went right

• Using MoonScript
• Using a bitmap and gimp as my map editor
• My tools all worked well together

What went wrong

• Didn’t test on windows, got report of people having issues after submission
• Didn’t know what I wanted to make in the middle of the comp
• Didn’t have any foundation code, had to focus more on getting code to do basic stuff instead of adding game features and polish.

Once again, If you haven’t played the game yet  you can do so here!

Hi, this is my first Ludum Dare. I’ve messed around in game development before but never really completed anything. I hope the stress of the competition acts as a great motivator.

I just released my own programming language called MoonScript which compiles into Lua. I’ll be using that to make my game. This will be a great test to see how it works. One of the original use cases of the language was game development because there are so many engines that use Lua.

If you happen to be using Lua, then I suggest you check it out because it’s pretty awesome, works on all platforms, and I’ve written a ton of documentation.

Anyway, about my game. So far I plan to create a platformer, but depending on the theme I might switch things up. I’ll be developing on linux but using LÖVE so my result should run everywhere. I hope to do a time lapse screen capture of the entire weekend but I haven’t found software yet. I’m worried about creating graphics and music because I’m not very good at those things. Must not let them consume too much time.

Here’s the final list:

Language: MoonScript (compiles to Lua)
Editor: VIM
Framework: LÖVE
Graphics: GIMP
Music: MilkyTracker
Sounds: Audacity

Follow me on twitter for updates, and here’s a pic of me being serious:

Hello everyone! I’m ready to join in! This is my first post to the site!

I’ll be doing a Jam entry with a friend. I’d be doing the code work and he’s likely to help with graphics and sound.

So here’s what I’ll probably be using:

• Language: Lua (Using LÖVE as a framework)
• Source Editing: Vim
• Version Control: Git
• Graphics: mtPaint (pixel art), MyPaint (Sketches, concept doodles), Gimp (Anything else)
• Sounds: sfxr (Bleeps and blips), Audacity (Filtering and other stuff)

Hopefully that should all be enough to pull me through. Good luck everyone, see you soon!

…since “I’m in” seems too normal…

This is my 8th or 9th LD, and still is as exciting as ever!

Anyway, I’m using the same framework as last time, done by me, just added a 3d tilemap system (doesn’t have any type of querying yet, just rendering at the moment, I’ll add the rest during the competition, according to needs).

You can download the framework here, if you want to use it (it has two sample applications that show most if not all the features):

• D3D9 initialization and some helpers
• FMOD interface for sound
• 2d Sprites (with sprite caching, etc)
• 2d Particle System
• Text
• 3ds file loading (only tested with 3ds generated by 3d Studio Max). Loads lights, meshes and cameras.
• Small simple math library (vectors and quaternions)
• Simple 3d camera handling system (just with a “look at” operation)
• XML loading/saving (might come in handy for configuration files, load/saves, etc. The XML loader was created by Frank Berghen, not me… the writer is all me, although the loader also has save functions, but I’m too lazy to figure out how they work)
• 3d particle system (based on the 2d one, so very rudimentary)
• 3d sprite system (quads that always face the camera)
• LUA library support (it’s actually ripped from my engine, so it’s a good support system for LUA)… Last time I used cutscenes and scripting, and loads of the game code was much simpler because of that…
• DDS image loading for an offscreen buffer (just supports R8G8B8A8 images). Might be useful for some level design stuff, although I’ll probably go back to my old days of text files
• 3d Tilemap (Kind of a blocky heightmap with an automatic texture atlas generation and partition of the map in chunks for possible culling (not implemented))

On the tools side:

• Visual Studio 2005 (hope I can get used to it again, been using 2010 at work)
• Photoshop CS5 (for 2d graphics and textures if I decide to adventure into 3d, and for map creation, etc)
• 3d Studio Max (for modelling if I go 3d, or for title screens and such otherwise)
• sfxr (or Bfxr) (for audio effects)
• Wolfram Tones (for the music creation – fun tool, saves loads of time) and MIDI Converter Free (to convert the MIDI generated by Wolfram Tones to OGG)
• Live Writer for blogging

About the themes, I have a gut feeling that “Dreams” is going to win, although I don’t have any ideas for that… or any of the others, to be honest, since the times in the past when I tried to think of an idea for all the themes it didn’t work that well…

Anyway, very excited about this all!

Good luck everyone!

Hullo, I’m Scio. Nice to meet you :bows:.

This is actually my third Ludum Dare, but so far I have been totally asocial and never even introduced myself, let alone post the games, of which there was only one that was even remotely playable. Don’t ask.

But motivated by the trivial coincidence of this being LD #21 and being 21 years old myself, I have finally braved an intro. I am quite proud of that.

Let’s see if I can make a game too; shouldn’t be too hard. No pressure…

I will be working with the following tools, depending on how far I manage to go of course:

• The ever lovely LÖVE, if making a desktop game. This’ll mean lua.
• The ever…scripty…Processing.js, if making a web game. This’ll make it sort of javascript, sort of Processing.
• Inkscape, GIMP, and Mypaint for graphics.
• Blender for CGI: I won’t be making a 3D game.
• Sfxr (yay) for sound effects, and possibly Neil if daring to make music.
• My snazzy, Compiz-y desktop running Ubuntu Lucid Lynx.
• Certain other non-computational implements.

I will, almost certainly, not be able to make the competition deadlines, so I’ll focus on Jam instead. And I will try to come up with something fitting the winning theme, but if I can’t…I’ll just choose another one I like and roll with it >.>

As for participation: I will silently stalk the IRC, and try to visit the Hangouts if my connection holds. I don’t have enough bandwidth (or courage) to livestream my work, but I will set up gLapse which was thoughtfully made for this very occasion!

Furthermore, I promise not to get too nervous and go into zen-procrastination-mode like I usually do during rushes.

[Also: Did I go overboard with the tags?]

I’ll probably end up doing something in C and SDL and maybe Lua if I feel like the type of game I’m making would be enhanced by it. I’ll probably draw the graphics in Inkscape and Gimp. The audio will be done in either Audacity or Sox.

I hope I don’t get brought down by crazy bugs like I did last compo. :’(

I should start getting my math figured out right away so that doesn’t happen.

EDIT: Why does it keep autocorrecting my C tag to C++?

Here goes my game, my first on in the Ludum Dare.

GREED-O-RAMA SCREENSHOT

It is called GREED-O-RAMA, and was made on Lua, using Löve!
So bad i didn’t had the time to put the music on =(

I tried to make a classical point chase game with a little psychological approach. The in-game instructions explains more.

Link to download the game: http://dl.dropbox.com/u/2850120/GREED-O-RAMA.love
Link to get the engine (necessary for playing): http://love2d.org/

PS:  I’m Editing the post to make it more clear. The first version was terrible! =P

I’ve added shooting and aiming to Mato. I’ve also added gamepad controls, tailored for an Xbox 360 controller. The game currently has just one weapon, similar to the chaingun in Liero, but I’ll be adding more as I go on. The aiming is done with the second analog stick, while you can use the first analog stick to move left and right as well as control the direction of digging, so you can dig straight down, for example. The gun has analog control over the firing rate, with a maximum firing rate of 8 bullets a second. The clip is infinite right now, but that will change for the final version.

One thing I’ve noticed when writing Lua code is that it’s pretty easy to write horribly bad code. I don’t have to define classes, I’ll just use create an ad hoc table with the necessary fields. My code is a horrible mess right now, but I am going to refactor it eventually. It’s kinda nice to just make a mess of it all and write quick hacks.

Hey, this actually is kinda like a game now. I can move around with the red worm and dig holes. Well, I guess I’ve got the destructible terrain covered already, even though I thought that would be a really difficult thing to nail. Frankly, I expected the simple approach of modifying the image on the fly not to work fast enough, especially because Löve is using OpenGL behind the scenes, so I basically need to upload the fullscreen texture to the GPU every time I modify the terrain. I guess the real hard part will be making the different weapons.

My Lua game engine thing: I call it “slug” [update: hit the slug tag for newer versions]

A bit rough around the edges and messy code, but it seems to work for what it does.  (Here’s a readme.)

I believe a better name than post mortem would be lessons learned, so let’s see my lessons learned from the  competition. I would love to read this before the compo, as I can’t make the time go backawards, let try at least to help other newbies.
1. create the menu navigation at the start of the competition
As I was fighting agains some physics problems during the development process most of the menu was left behind. Then I realized 30 minutes to the end that my menu would be an image =) and a play button…

The lesson on this would be, use time in the middle of the nightmares to do these brainless activities, because what can go wrong while build a menu ? =)

2. draw in the paper build and color in the computer
That helped alot, I save my day manipulate the lines with inkscape, but … in order to slice images I have a nightmare with inkscape, go with Gimp works as a breeze

3. dont split images, let the engine split for you
ahhhh I spend some hours cutting images lol !!, could use something like http://love2d.org/docs/love_graphics_draws_1.html to draw a subsprite of the image …

4. make physics work for you
Oh Well after the physics hit me in the head, I learned some details and was able to make it work in a decent way, special note for the boats that hang around over the sea, for that I created a sequence of x,y that is the path to the boats, and I try to follow the path, I believe if I make the water line as an object and change its group to only colide with the boat would be the best to move the boat around.

5. clean the tables in one place only.
Not sure why, buit when I was removing items from my objects list in teh collision handler the LOVE was just crashing … workaroiund that I found : flag to items to be removed and remove in the update() method and one by one from each table, this is call at the end of the update() for each cleanable table :

[code]--- clean the tables
function cleanTable(table2Clean)

for n=1,table.getn(table2Clean),1 do
if table2Clean[n].dirty ~= nill then
table2Clean[n].poly:destroy()
table2Clean[n].body:destroy()
table.remove( table2Clean, n )
break
end
end
end
[/code]

and at the collision handler, I dont remove the pig from the list, just flag it
and I believe that this would be a nice way to animate the pig booom =)
by using a multistate, like alive/almost dead/dying/im outa here
would change the image section, or play an animation … and at the end remove from the list
that would be great …

[code]
function killThePig( id )

love.audio.play( audioCollision, 1 )
pigsKilled = pigsKilled +1

for n=1,table.getn(pigs),1 do
if pigs[n].poly:getData() == id then
pigs[n].dirty = true
break
end
end
end
[/code]

6. reusable files should be in a folder
I’m using for labels the .lua classes that I made called LOVEly-eyes, but I had this problem with the Text object that wasnt transparent … Oh well I went in the code changed the super class, Rectangle to handle this and the Text is transparent by default, cool, but but but … after that I just copied all the files from the LOVEly-eyes folder to my game folder … too bad because I copied a main.lua file together … If I wasnt using subversion would be a nightmare … now LOVELy-eyes are in a separated folder =)

7. use a version control system
I used subversion, saved me when I made an stupid folder copy … revert and just lost some minutes of work… bu remember keep on committing =)

8. put together a zip with everything
Better that just the .love file, create a package with the execs, the best would be create an installer.

9. level up level up !!!
people like rewards, so more than the score I should add level concept, just with faster attack of the pigs, or a different scenario with different speed .. hummmm that would be cool a .lua file for each level

10. collision has 2 sides … A and B
It took me some time to realize that A and B collision data, first they are the DATA from the polygon nothing else, just disconnected data, not a reference, not and pointer … hehehhe string data what makes very nice and unplugged from the code, and you have to test both sides, if wherever A colide on B and the oposite, this was my colision code

[code]function collision(a, b, c)

if string.starts(a, "pig") and string.starts(b, "battery") then
killThePig( a )
removeTheBattery( b )
elseif string.starts(b, "pig") and string.starts(a, "battery") then
killThePig( b )
removeTheBattery( a )
elseif a == DIODONTIDAE and string.starts(b, "food") then
eatFood( b )
elseif b == DIODONTIDAE and string.starts(a, "food") then
eatFood( a )
end

end

function string.starts(String,Start)
return string.sub(String,1,string.len(Start))==Start
end
[/code]

note that I used start() because I add the object id after the type, so I can grabb it from the list, something like “crap_2″, “crap_3″

11. scroll the view is possible Luke… use the force !
Ha ! not the force, at the end I solved the screen scrolling with a simple solution, calculated a shif from the main character and update this shift in the update() method and every single draw has this shift. So the camera is following the character, thats stays in the screen all the time, and to avoid the char to drop outside the world I add invisible walls on left and right side and check if the cameraX is in the possible range,

this in the start of the code

[code]
startCameraX = love.graphics.getWidth( ) / 2
startCameraY = 200

cameraX = -startCameraX
cameraXLimit = {}
cameraXLimit.start  = 0
cameraXLimit.finish = -2905
[/code]

+ cameraX on each draw
[code]
love.graphics.draw(diodontidae.image,
diodontidae.theChar:getX() + cameraX,
diodontidae.theChar:getY())

------ draw the batteries
for n=1,table.getn(batteries),1 do
love.graphics.draw(
imageBattery,
batteries[n].body:getX() + cameraX,
batteries[n].body:getY(),
batteries[n].body:getAngle() )
end
[/code]
this on the update()

[code]    cameraX = startCameraX - diodontidae.theChar:getX()

-- keep the camera in the boundaries
if cameraX > cameraXLimit.start then
cameraX = cameraXLimit.start
elseif cameraX < cameraXLimit.finish then
cameraX = cameraXLimit.finish
end
[/code]

Participated in the GlobalGameJam This year and was pretty nice, let´s see what I can in this challenge. will use Love2d game engine.

Windows exe + source (compo version; if it crashes, get the post- compo zip below)

Windows exe + source (trivial post-compo fix edition, see below)

Timelapse video

Updated with a fix version above. The game would crash if run at a bit depth lower than 24bpp, use the fix version if it does! The fix also removes a comma from brygge-s.lua to fix a copy/paste bug that prevented turning around/right when looking away from the wharf, this isn’t required to beat the game or even much noticeable though.

Tools used: kate (text), gimp (graphics), sfxr (sound)

Libraries used: SDL, SDL_image (png), SDL_mixer (ogg vorbis), Lua