Well, Indie Speed Run has come and gone, and I’ve got a portmortem up at Spellcaster Studios’ website!
The result was pretty nice… Next month I’ll release this version of the game for free, but we’re going to see if we can improve the game further and release it commercially… Let’s see how that goes!
Well, us at Spellcaster Studios will start the Indie Speed Run in a few minutes…
You can follow the development over at the Spellcaster Studios website!
Since I like pictures, here’s a picture of what we did last year, before we tapped out!
Hi everyone!
It’s been ages since I wrote here, but I’m not dead… My time during Christmas break is usually terribly busy, and afterwards work hit again like a brick wall (was hoping the mad rhythm from last months was gone, but I was wrong).
Anyway, I’ve been doing some things related to Grey and my Indie Speed Run unfinished entry, but you can read about it on Spellcaster Studios’ website…
Here, I want to talk about the games I’ve been trying out lately… Besides the usual Christmas binge on new Triple-A games (Assassin’s Creed III was pretty good, with some flaws, but still a lot of fun… The naval battles rock), I’ve been working through my Steam collection, looking at games I haven’t really tried. Here’s my impressions on some:
“The Binding of Isaac” is a procedural Zelda-like game… That said, I should have liked it, but to be completely honest… I didn’t… The controls were cumbersome for my taste, and there was too little storyline to keep me entertained; this is the problem with most rogue-likes out there (not only indie, but also Triple-A, like Diablo 3); I‘m not the type of person that walks around doing the same thing over and over again without anything to drive me forward (usually story)… Exception to this is probably “World of Warcraft”, where I raid over and over again, but there we have the social component as well.
Anyway, “The Binding of Isaac” is a well made game, with a very cool aesthetics (both visual and thematic), so if you enjoy roguelikes, give it a whirl!
“Closure” is a puzzle platformer whose main mechanic is easy to understand if you see it, but kind of hard to put into words… Basically only things in range of light have any physical substance (or are visible at all)… That means that if you see a wall in front of you (using a source of light), you’ll collide with it, but if you don’t have a light shinning on it, you’ll just pass through it.
This mechanic works making very nasty puzzles that remind me of “Portal”: puzzles that look very hard, but when you finally overcome them, you think: “Damn, this was so obvious!”… So, the game gives you a pretty good sense of accomplishment and I had tons of fun playing this one… the music gets on the nerves eventually, specially when you’re swimming around (music plays at a slower rate, which means it becomes just very very vey annoying, albeit atmospheric).
I didn’t spend much time on this one, to be honest, too little story going around… But the execution is top notch, has a good tutorial (which does a good job of converting an immense amount of instruction into something more manageable) and the overall feel is fun enough, if you’re into this sort of thing…
I’d like someone to make a Tower Defense game where you’d feel more “story" on it, but I’m guessing it’s kind of hard.
One of my complains about most of the strategy indie games is that how heavy they are from the start. Although this one has a good tutorial, after 2 or 3 levels I’d already have too much to do… so, I didn’t have enough time to absorb the previous concepts and I would be already buried in new ones…
On that front, Blizzard games are the best… They introduce everything slowly enough in their games so that me, as a player, never feel overwhelmed by new concepts and ideas. Of course, what I’m complaining about here is the inverse that most people complain (“tutorial was dragging on for ages”), but I think there’s a balance in between.
For me, when choosing a new game to play, I don’t want to spend much time mastering some ground rules… I just want to get into the action/story as fast as possible and spend one hour in the game without feeling overwhelmed, trying to figure out if I actually think I’m going to have fun in the game if I commit enough time to it…
Ok, this post is big enough already, more to follow!
This is one of those posts that have a bit of everything, so no decent title for it… 
Anyway, as you might have seen in the Spellcaster Studios blog, me and Rincewind gave up on the Indie Speed Run, mainly because of scope issues… We went a little wild with it, Rincewind because of lack of 48-hour compo experience, and me because I thought that without needing to do graphics I could do much more…
Anyway, it was a good exercise, and I’m definitely finishing this one, not because it is brilliant, but it’s great to figure out bugs on SurgeEd and SurgePlayer, which I used for the game. Already figured out some nasty bugs which would have taken a lot of time to fix on the “Grey” scripts, specially one that only seems to manifest in specific conditions…
If you’ve been following this blog, you know I’m using Lua to drive the game logic, and specifically LuaJIT, and I found an odd behavior…
The offending piece of code was something that tested a condition and acted on that:
function do_something(param)
if (ffi.C.test(param)) then
change_object() end end
test is a function declared on the FFI, that returned a bool:
ffi = require("ffi")
ffi.cdef[[bool test(const char* str);
]]
Which had a C counterpart like:
extern "C"
{ bool __declspec(dllexport) test(const char* str) {
bool b=do_some_test();
return b;
}
}
Simple enough…
Problem is, “change_object” was never reached… First I thought it was the “do_some_test” function that was failing, and I added some tracing to it (writing to the logger) with the output, and it turned true eventually…
Then I added some tracing in the “do_something” function, and mysteriously, it started working properly… After a lot of tests, I found that if I used any function that called normally bound functions before the “ffi.C.test” call, the system worked properly… But if I added FFI based functions, it wouldn’t work!
This was driving me crazy… then I had a silly idea… “bool” is a C++ type, not C type, so I changed the declaration of the C function (not the FFI declaration) to “int __declspec(dllexport) test(const char* str)”, returning 1 if “do_some_test” was true, and 0 otherwise… And now the system worked properly!
So, I arrived to the conclusion that you can’t output “bool” directly from the C code (although you can declare it that way on the FFI declaration, to get a proper bool and not an int). I imagine the problem was the size of a bool and the stack manipulation of LuaJIT, which caused the system to access corrupted memory (that was probably zeroed before being used, and that’s why the function apparentely always returned “false”, although the C output was “true”).
Anyway, 2 hours of my life getting to the bottom of this… Had to change all the functions that return a bool to return an int instead…
Anyway, on other news, take a look at this Hamnasya game… It’s a cross-media kind of game, where you’re reading a book, but you can affect the outcome and fight battles à lá RPG… Very cool stuff indeed, and has an excellent trailer:
I haven’t picked it up (I had too many pending games at the moment), but it looks pretty good…
If I don’t write anything in the meantime (highly likely), Merry Christmas and a Happy New Year!