Hello everyone.

It’s now been a lot more than 48h, and I see on the compo blog that some of you have made pretty things. I guess we can call it a week-end, and gather all that’s been made.

Could an admin please set up the submission system?

EDIT: Submit Here | View All Entries

In any case, thanks a lot for your enthusiasm and participation, your help for porting the “engine”, and the hopefully wonderful games you made.

As usual, the submission system will be up for a while, so feel free to submit stuff even very late. This is a Mini LD after all. What matters is the result, not the time limit.

See you soon for more adventures (LD #17 coming up!)

Cheers,

Tenoch

Finally. Finished.

Now I know what I can accomplish in a 48 hour game, if I work all 48 hours without stopping That’s about how long I spent on this game.

Just so much artwork and logic, and starting from scratch with a language I had never used before. Still, I love how it came out. I didn’t think I could possibly do something so large-scale with the constraint of not only the framework and resolution and palette but of time as well. I went way over on not just time, but content size as well. Oh well, I’m just happy I finished.

Anyways, I really hope you enjoy it. It is complete and tested and I tried to put as much polish as time would allow. I think it is actually pretty fun and that is the important thing. Let me know how you like it, it was so much work to do all the artwork and animations.

I suggest you play in fullscreen or at least as large a window as possible on your system, and use your gamepad for the true retro experience. You will enjoy it much more. The 640×400 fullscreen batch file works fine on my netbook and it is plenty fast.

So who would win in a battle between a warrior and a wizard? Why don’t you give it a try and find out…

(REVISION 1.1:  Shortens death animation delay and changes vest color so you don’t blend into background)

http://www.bitjets.com/wizard.zip

keyboard control: left arrow and right arrow to move, up arrow to jump and control to attack.

Didn’t get to work on this as much as I intended this weekend, but I like the concept so I”ll probably try to finish it later.  I’m fairly pleased with the progress but I’m embarrassed at how terrible the code got, and shocked at how quickly it got there. First thing when I resume, I think getting the bugs out of the cable code is going to require completely rewriting portions of it to be rational.

:edit: forgot to link the zip earlier. Click pic for download; includes the statically-linked win .exe, but the main.lua file should(?) run with any working retro setup. :edit2: smaller zip, omits RetroEngine.exe

Poached the concept from the #17 suggested themes… hopefully the theme won’t win, or I’ll end up feeling silly next month. Going to be a puzzle game where the player is working their way through a derelict ship trying to get it’s systems back online using only their collection of trusty Omnicables to transfer power, air, and fuel between systems.

There’s a few buggy bits, I somehow got it crashing when you try to do smooth scaling, the code became a beast and I have no idea how well it’ll run on other computers. Many more tweaks that could be made, but it’s done enough to throw it out there. It’s pong with fluid dynamics, kind of like plasmapong in that I used the same paper for the fluid dynamics code, however I tried to actually make the game side more pong-like and fun to play (I always found that plasmapong was beautiful to look at, but the game wasn’t exactly ‘fun’).

I did find out pretty quickly that even at low res, it’s probably not the best idea to do fluid dynamic simulation in a scripting language. Luckily the LuaJIT version of the engine that sfernald posted in this comment (you can download a bare version here, minus the example game) actually did provide a huge speedup and made it playable on my compy.

You can download the actual game code here, just throw the files in the same folder as the LuaJIT executable and run that. More tasty pixel fluid dynamics after the jump.

(EDIT: replaced rar after fixing a small problem, where it told you you lost when you won, and added 2 more palettes. On a side note, sometimes when running it goes very slow for me, in which case if I close and start again it’ll normally be fine)
(more…)

Ok, so I only had about two hours to attempt this, so I tried to keep it as simple as possible.

It looks cool, but unfortunately all you can do is fall, there’s no collision or anything, and the scrolling is messed up.

However, I didn’t read the docs ahead of time and didn’t realize just how constrained the constraints were. My initial plan was to just use a large image with the whole map predrawn, and use getpixel for collision. But retro engine wouldn’t load large images, or allow getpixel, or blit a partial image. So I had to draw all the tiles. I don’t blame the engine — I just should have taken a closer look before i started, and I probably would have gone with something more putpixelly and less blitty.

On the bright side, it was a good excuse to play with TileStudio and I figured out how to get maps of it and into lua. And it was pretty much the first time I’ve played with lua in years.

Anyways, the whole mess is here:

falling.zip

But it’s not worth downloading, unless maybe you want to use the .tsd file for tile studio.

Still, overall, fun idea and i like the contraints. I wish I had the full weekend to work on this. Next month, I’ve got LD17 blocked off on the calendar, looking forward to that.

Had something I wanted to try at this sort of low resolution, and after reading through a paper and a fair bit of fiddling I’ve got the basics working. Not exactly an original idea, but I thought a nice improvement would be to actually try and make it fun. Am I being vague enough here? A screenshot might help a few people catch onto what I’m talking about:

Anyway, will try to add more tomorrow, as it’s far too late already.

I don’t know why, but I seem to do better when there are constraints when making a game. Somehow I think the pixels and the limited palette inspire me to try harder for some reason. Been focusing on the artwork and sounds for my game all day. Not a big fan of Lua, but it makes it really easy to test the art and animations in game.

The game I’ve come up with is based on the question, “Who would win a battle between a wizard and a warrior?” Thus, the name of it is Wizard Vs. Warrior. I’ve decided to make it a kind of adventure. You are a warrior that has to kill the “evil” wizard. I think I got the idea (or at least the inspiration) from Conan the Destroyer actually. Simple concept, but I’m having a ton of fun with it. I’ve got a lot of the graphics done and soon I’ll start putting it all together. This game has been so fun to make so far. Hope I’m able to finish it.

This one has lots of cool pixel art. Here are some screenshots:

Since I finally managed to wake up, I guess it’s time to officially launch the compo.

Theme: Constraints (déjà vu?..)

To participate in the competition, you must use the provided “Retro” framework (links at the bottom of the post):

Retro (the Recursively and Erroneously Titled Retro Object)

It is a simple and very constrained game engine with a Lua API, offering the following characteristics:

- Low resolution (160×100) with 1-4 zoom, plus smooth scaling algorithms
- Palette based (8 colors including one optional transparent)
- Old console like input: arrows, A and B buttons, start button (mapped to keyboard, and partial gamepad support)
- Total source + assets shouldn’t weight more than 1 MB

If you don’t like Lua, there is a C API as well, but you’ll need to compile your game yourself, while the Lua based games should be (hopefuly) portable. If you like neither of them, you can also program your game in any language/platform, provided that you stick to the given constraints (and use no external library other than what is provided by standard Lua/C)

Note: the Retro thingy doesn’t actually check if your game weighs more than a MB or not. Furthermore, there seem to be problems with “light” music formats like XM, so if the size limit is exceeded because of music, it’s ok.

Note 2: remember to read the documentation! It containts important and valuable information. The packages also contain an example game.

Optional themes: Cute but Evil or Legendary Cosmic Monsters

If you have no inspiration whatsoever, you can use this secondary theme list to get you started.

Schedule

It’s a Mini, so don’t worry too much about time limits. Take 48 hours when you can/want or even a bit more if you feel like polishing your game.

Downloads

Thanks to the community, we have several Retro binaries to use. They should be compatible.

Source, GNU/Linux (32bits), Windows (MinGW),  Windows (MSVC + more options), Windows (LuaJIT version), Mac OS X

See previous post + comments for more details

Final words

Oh well, have fun

Good luck!

Since several persons on the compo blog and the IRC channel seemed interested in my original idea, despite the closeness with the previous Mini, I am hereby releasing the aforementionned Retro engine!

Weee!

Source code, Linux binaries, Windows binaries

As you can see, it lacks terribly of Windows binaries. I’m terribly sorry, but couldn’t get my cross compilation thingy to work. It usually goes flowlessly, but here I’ve been battling for an hour, and I gave up.

EDIT: Thanks to Sos, we now have Windows binaries. Yepee! Thanks a lot to Sos. All hail Sos!

If someone with a good heart would like to, it can be built as follows: compile io.c retro_lua.c and lua_api.c into retro.exe. That’s all. But you’ll need dev libs for SDL, SDL_Image, SDL_Mixer and Lua 5.1

First one to publish a windows binary will win my eternal gratitude, and a cake*

Both source and Linux distribution contain full documentation (I hope), and an example game to help you get started.

And, as promised also, there is (a bit more) than a week before the actual Mini LD, which will therefore be held on the week end of the 20-21 of March 2010. No worries though, we’ll have the usual “take 48h when you want” policy, or even more if you like.

Okee. I hope I didn’t forget anything. Of course, don’t hesitate to ask questions on IRC and in the comments. Meanwhile, I’m gonna catch some z’s (I just love this expression, sorry).

Yours truly,

Tenoch

* The cake is a lie.

So I had this great MiniLD idea, but it turned out that HybridMind completely ripped it off, without even knowing it!
Also, since he did it a month before me, it’s not really a ripoff, just bad luck for me. Stupid MiniLD booking a year in advance…

So here’s what we’re gonna do: I’m going to tell you what I had in mind, and if enough/any people are interested (despite the close resemblance with the previous month’s Mini), we’ll go with it anyway.
If not, I’ll find a new idea shortly. Maybe you could even chose between the two themes.

So, here it goes:

Constraints

Dear, dearer and dearest LDers,

in anticipation of this coming event, and giving in to my never-ending love for the golden times when awesome games held into 1 MB cartridges, I prepared for you a tiny game engine, humorously named:

Retro (the Recursively and Erroneously Titled Retro Object)

It is a simple and very constrained game engine with a Lua and C API, offering the following characteristics:

- Low resolution (160×100) with 1-4 zoom, plus smooth scaling algorithms
- Palette based (8 colors including one optional transparent)
- Old console like input: arrows, A and B buttons, start button (mapped to keyboard, and partial gamepad support)
- Total source + assets shouldn’t weight more than 1 MB

It presents as binaries (for GNU/Linux and Windows, MacOS X if a good will makes the port) to which you feed a Lua source file in which you define callbacks such as update(), keypressed(), etc, and use an API that allows you to:

- Load images/palettes
- Blit images to screen
- Write pixels to screen
- Modify palette on the fly
- Load sound files
- Play sound files
- that kind of stuff

For those who do not desire to learn/use Lua, I intend to make a similar C API, so that it could be used from any C-friendly language (but then it requires you to compile the game yourself, thus limiting portability).

In fact, if you don’t like the engine at all, you can even make anything you want, provided that you stick to the constraints and use no library other than simple IO (basically SDL + standard C/Lua). The idea was just to give the same basecode to a bunch of wizard gamedevers and see what happens.

So there it was. Feel free to express yourself in the comments of this post so that we can decide together what is the better option. Also, the engine is almost entirely coded but it still needs a big evening to finish things up,so if no one is interested, I’ll probably play the lazy card, and just announce a one word theme.

Let me know, LDers!