I like component-based designs. Why the two threads though, what's the benefit? It seems to be just a huge hassle to keep everything synchronized.

[finally]

I not sure how well known this is, but I use a similar sort of technique when I need something akin to a finally block in C++.  Sometimes I need cleanup code that's more complex than what auto_ptr can provide, so I use a local object destructor, something like this:

I think Alexandrescu and Marginean have proposed "scope guards" as a library solution for this kind of thing, though theirs also handles the case where you want to execute some code only in the case of failure (if an exception is thrown). Might be overkill for your simple example maybe, but I do like the idea of hiding implementation details (using a destructor to execute the code).

By the way, the D language has scope guards (for success, failure and unconditional ones) built in which makes this kind of thing very pleasant to do. It really changes the way you do error handling.

The style is charming, I like it. From a very cursory play (<5 min), I couldn't figure out whether I was supposed to rescue or kill the Atlanteans and how to go about it. The mouse-over helpers mentioned some score, but I couldn't figure out what to do to gain that score. I did understand the turn-based structure very quickly due to the scrolling thing in the upper right corner, so that's helpful.

 

That's all I'll have to say on the matter for now.

I like the whole idea of Langdell going on a remorse trip, living like a hermit in a cave for a year, meditating over the error of his ways, then re-emerging reborn as a shining savior of indie gaming. He could publish quirky indie titles left and right and prove that games are art on the side.

Keep in mind though that Toady has been slaving away at DF for years and years, so it's not like someone will go and make an exact replica of all the deep simulation features in a few weeks or months. In that sense I think talking about a "direct clone" misses the mark; few people have the resources and the patience to do that, and those who do would probably rather do their own thing. So if this goes anywhere at all, I'd guess that it will be a simpler game.


The whole premise is built on sand though.

Goblins just aren't as hardcore as dwarves are.

 

[it's quite possible that most of the instruments can be "written" with but a single sampled note recorded!]

Looking back, if there's a way to pitch-shift a recorded note, without changing the timing of it (or more precisely, changing it independently), it's quite possible that most of the instruments can be "written" with but a single sampled note recorded!

Changing pitch and timing independently is possible to a degree, but it's quite computationally expensive. What I think mod/xm players do is just take the sample and resample it at a higher/lower frequency to get the pitch shift. This changes the timing of course; they do have an optional looping region in the sample which can be used to compensate for the change in duration.

Or perhaps simply by using one note per scale, at the most, and a limited shifting variable for clarity (+/-3, for instance). Drums are about the only thing that would require multiple files, that way.

That's basically what the SoundFont format does; you can find huge libraries of sampled instruments in SF format online if you care to look. Some of them have quite high quality.

Three things you don't want if you are a lone game maker (you do everything from art to code): Feature creep, low level coding and clean code. Trust me

What's wrong with clean code?

Yeah, this. I've done several compo games under a tight deadline, managed to build up lots of low-level code (font rendering, no less) over the course of those mini-projects, and several people commented favorably on the cleanness of the code. So I think it's entirely possible. My Ludum Dare entry even did quite ok.

Admittedly, I was hoping to completely internalize my music playback system (just not all of the instrument samples, load those as needed), and simply produce the music by referencing a few strings of code/variables in a player's savegame. So "note scale x" combines with "note/timing patterns n1-n4" to make a verse on the fly; without having to produce an entire song file every time a level is played. The only additional "data weight" is a number of variables like that; and even those can mix and match to some extent.

But if XM support is capable of compiling quickly enough, a wiser move may be to use said variables to construct a temp.xm file and then use ordinary playback functions with it. *hmm*

Sorry for the shameless plug, I don't know if you've seen it, but I've been working on a synthesizer library called Cosyne which is very easy to embed in games; see the link in my signature. It doesn't have any pattern support at the moment, but that should be easy enough to build on top of it.

So if you want to avoid mucking around with temporary files and such, that might be an option.

8 doesn't have much context. You want a:

Code:

const int theNumberEight = 8;

Fixed!

I guessed so. It doesn't matter in this context, though.
I know that I will never change this constant.

It's not only about making it changeable, also about giving it a name which explains what it stands for to make the code more readable. theNumberEight was a joke (I hope) since that doesn't help a bit.

Since you use C++ and Lua is in C, I think you have to use extern "C" around the includes like so:

Code:

extern "C" {
#include "lua/lua.h"
}

Most C headers do that already, that probably isn't necessary.

Yeah, I know, but funnily enough Lua doesn't seem to, that was my point; see http://www.lua.org/source/5.1/lua.h.html. Can lead to weird linking errors.

The most daunting thing is trying to set it up. Is there a website that gives a step by step guide to setting up Lua with Codeblocks? I've Googled and failed to find anything definitive.

I wouldn't know about a tutorial specifically for that, but in general it's easy to set up. What I do is build Lua into a static library (lua.lib), tell the project to link with that, and make sure the compiler has the header files on its include path.

If that seems too complicated, here's another way: just plop the lua sources and headers into a lua/ subdirectory of your project and include all the .c files in your build. Then you should have access to the headers as "lua/lua.h" and such.

Since you use C++ and Lua is in C, I think you have to use extern "C" around the includes like so:

Code:

extern "C" {
#include "lua/lua.h"
}

Hm, I think it's more enjoyable when the compression from lots of lines of moderately complex code turns into one line of very complex code rather than turning into one line of easy code. It makes you feel less like an idiot.

Indeed. This still has to be my favourite line of all I've ever written:

Code:

T *tmp = new T[(trueSize / 2 >= -- filledSize && trueSize > 8) ? (trueSize /= 2) : trueSize];

To be honest, I think that's bad code. It's so obfuscated that you won't know what it's doing in a few months' (weeks'?) time, not to mention what another programmer who reads your code will think of it (hint: hard feelings will be had). This single line manages to mix up a conditional, side effects (--, /=), and an allocation; that's just nasty and a maintenance nightmare. Split it out over a few lines, use well-named temporaries, and maybe comment it. Just stuffing as much stuff as you can into one code line doesn't make for good code.

simple to embed, fun to work with, and it breaks the slow edit-recompile-run cycle you're usually stuck with in C++.

I don't know about being simple to embed, at least not for the first time - I remember a year or two ago spending a lot of time tripping around documentation for various versions getting confused.  But it wasn't an enormous pain.  And once that's out of the way, things should be fine.  And there're people here who can help, so.

Hm, I guess you're right that the whole stack concept and so on can take some while to wrap one's head around. It's definitely easier to get started with than, say, Python or Ruby, which aren't too well-suited for embedding anyway. Also there are some tools which are supposed to automate the process, like SWIG or luabind, though I haven't tried those.

Mikademus: That's a nice list. I don't quite agree with some of your points; AngelScript, in particular, seems to me like someone tried to remake as much of C++ as he could in a scripting language, which seems wrong to me on so many levels. But it's good to see a blow-by-blow comparison, in any case. (I also wonder whether you've looked at Io, I'm partial to that language, but I can imagine that it's too minimalistic for your tastes.)

If you just want something to load your data into the game, then Lua is maybe overkill; in that case, I'd recommend some data description language like JSON, YAML, or XML.

On the other hand, if you do intend to do some scripting within the game itself, then I heartily recommend looking into Lua. It's a small and elegant language, easy to learn (at least unless you get into metaprogramming, that can get surprisingly sophisticated), simple to embed, fun to work with, and it breaks the slow edit-recompile-run cycle you're usually stuck with in C++.

Easy way, although I haven't worked out what distribution it will give you -
Choose a target that you want the number to be weighted towards;
Pick 3 (say) random numbers uniformly from 0 to 1000;
Choose the one that is nearest to your target.

Awesome. I'd really like to see the distribution on that. So simple.

Yeah, me too, and I'm procrastinating at work again...

with 3 candidates:



with 10 candidates:



I thought about it a bit and it shouldn't be too hard to derive the distribution function. Basically I think you get another power of your original cumulative density function per candidate, so for 2 it's squared.

Code:

coinPct = max(monsterLevel/100,1.)
coinPct = min(0.,max(1.,coinPct-(randomPct/2)+random()*randomPct))
coins = coinPct*1000

I think your mins and maxes got mixed up? Far as I can tell, every max should be a min and vice versa.

My first idea was a normal (Gaussian) distribution, it seems like the obvious choice. I really like Pishtaco's idea now though. You can play with the number of candidates to get a tighter distribution; 3 seems awfully low, would be pretty common to have a low-level monster drop a huge pile of loot (unless that's what you want of course).

Is there anything in particular wrong with this algorithm which was already linked from Stack Overflow? It seems to do exactly what you want. I found that one too when I was searching for this kind of stuff a while back.

This is very, very charming! I do have to say that the difficulty of some of the levels is somewhat of a contrast to the serene atmosphere of the game, but eh, why not

Some critiques, mostly minor:

• The single-pixel circles on the level select screen clash with the vector art style of the game.
• The level select screen should make it clear which levels you've already beaten.
• The teleporters should have some visual feedback once they become usable. (A blinking light on top or something.)
• It's often not obvious at all which objects are clickable, which leads to the frustrating mouse-over-everything style of gameplay some adventures were notorious for.

Otherwise, loving it so far! Beat all the levels except for the terrifying monster one. I got the chili or whatever it is, but have no idea what to do with it...

Just played this for 10 minutes or so and it seemed utterly impossible to get to the crown if the king is even the least bit attentive. Nobody managed, anyway. Maybe it's my crappy internet connection though, there seemed to be a lot of lag between ceasing to mash and my character actually stopping, which made it very easy for the king to zap me. Also, only three of the four of us attackers were actually playing.

I also thought it might be fun to have some leeway to move to the left/right instead of just straight at the crown, but then again it would hamper the brilliantly primitive control scheme.

Really like the concept, anyway, not sure why it didn't seem to work that well for me as for other people here.