It's pretty quiet around here..

[gw0rd]

It's pretty quiet around here, I hope the development hasn't ended. I'm setting up MVS2010 to compile the source right now so that I can contribute my thoughts for future developments.

[Quantummy]

true indeed
I think my small patches where among one of the last things modified in the source. but that might be untrue.
the main developer is not involved anymore as far as I can tell. but then again I haven't checked for some time. I considered goblincamp pretty dead a while ago.

however some basic stuff about the sourcecode which i tinkered with myself:
it uses bjam build system. with lots of build script thingies ( note: I'm not experienced with bjam, prefer cmake )
it includes some boost library stuff. don't know if modified. which does not compile with newer gcc versions
it has its own modified version of libtcod which enables it some tileset rendering functionality
which is a bad move I think because the libtcod is still being updated. ( libtcod has a "do you own rendering" function. which is modified to add another buffer or something but why mod the library for that )
there are lots of casts being used which makes the stuff very confusing.

i found it quite challenging to work with the source code, but I'm not an experienced programmer.

future development is in your hands

[Core]

So has the lead Dev abandoned this project and if so can we revive this?

[Walker]

Dudes, there was a release just last month. The way GC is always declared dead two weeks after a release gets a little old.

The dev is rather busy with the day job at the moment, but if there are quality contributions I'm sure he'll look at them, just like he has so far. (Who do you think sorted out the last release, anyway?) I'm not seeing a lot of pull requests waiting on the bitbucket site.

This is an open source project, after all. Everyone can help keep it alive by contributing content and code. If you're hurting for ideas, I've a few bug reports I've been meaning to post here.

[Core]

is there a bug tracker?

[Quantummy]

my apologies suggesting the project was dead

[NightFalcon]

Eh no problemo... I can see why - many other projects are far more active. It's just that this is a small project led by a single guy with a real life life

[PiotrLegnica]

true indeed
however some basic stuff about the sourcecode which i tinkered with myself:
it uses bjam build system. with lots of build script thingies ( note: I'm not experienced with bjam, prefer cmake )
it includes some boost library stuff. don't know if modified. which does not compile with newer gcc versions
it has its own modified version of libtcod which enables it some tileset rendering functionality
which is a bad move I think because the libtcod is still being updated. ( libtcod has a "do you own rendering" function. which is modified to add another buffer or something but why mod the library for that )
there are lots of casts being used which makes the stuff very confusing.

i found it quite challenging to work with the source code, but I'm not an experienced programmer.

I know the codebase somewhat and I find it challenging to do anything. It just accumulated too much technical debt and decayed. It needs massive refactoring, and that needs time.

I feel bad about abandoning my efforts towards this project, because it's cool project, but I just don't have time to commit to that. :(

BJam-powered build system was an experiment, and I'll be the first to admit that it's terrible and needs to die. The overall game architecture needs some redesigning, too (I outlined some of those in one of the threads from a year ago). Python bindings didn't quite work out, either — they need to be either finished in one push or replaced with something with more C++-friendly API (I thought about V8 and JavaScript; additional plus is JIT). Renderer is a mess, and could use a clean start (possibly with OGL 2.0 and DirectX support only — kill libtcod and SDL completely; pure OpenGL might not suffice because of shitty Intel GPUs).

libtcod is included because a) I wanted to keep dependencies in the project to make build self-contained (it was a plan then, at least — turned out to not be very realisable with bjam) b) they made backwards-incompatible changes to parser and the data format at some point, and just keeping old version was easier than updating all data files (remember there were people writing mods, so more breakage surface). It's not a very good library anyway.

Overall, it needs a brainstorm and then possibly a rewrite, or at least very heavy and deep refactoring (NPC.cpp must die). And it's not a one-man job.

[NightFalcon]

Why do you say libtcod is not a very good library? I've been following its development for some time now, though I've never gotten terribly far with it...

[Quantummy]

I actually think libtcod is pretty nice. (uses cmake)
that said, you don't need it. but the path finding and FOV functions are handy
SDL provides some really basic platform independent functionality.
dumping SDL might give you potential headaches getting input on multiple platforms. or setting up a rendering window.

the current 2d graphics should work quite well even on "shitty intel GPUs"( the newer ones are pretty neat Intel-HD, especially because the Intel drivers are actually open source )

for a hypothetical rewrite, I think all you need is:
C or C++
SDL
SDL_image
LUA for scripting. (apparently its better to extend than to embed. I've got virtually no experience with LUA though )
cmake for building

and optionally:
OpenGL dependent upon driver implementation of course
libtcod if you want to use its full color ascii functions or pathfinding and what not
physicsFS never used it, but it seems very useful. its not a physic library