Elderlore

Source: Goblin Camp

0.1 is out!

It has a working stock manager, basic combat, basic farming and such. Download it and test it out, and come over to the forums and voice your opinions!

If you don’t have the Visual C++ 2010 Runtime installed already grab it from here: VC++ 2010 Runtime It’s a fairly small download (4.8mb) and it doesn’t require a restart to install or anything. Without it Goblin Camp will complain about msvcr100.dll and msvcp100.dll.

A linux version will be up at some point in the future too.
Goblin Camp can be built in linux: forum thread, it does take a bit of work though. No binary releases yet.

Download link: GoblinCamp01.zip

The source code is available over on bitbucket.

Source: Goblin Camp

There’s a lot of speculation about what my aims are exactly with Goblin Camp, so I’ll try and explain things here.

I’ve played roguelikes for a long time, and as a kid I used to draw cities using ASCII back when PC’s still used DOS. In addition to roguelikes, I’ve always been a fan of the Civilization series, Dungeon Keeper and more recently Anno 1404. When Dwarf Fortress came along I was really excited, it seemed to combine the genres that I’ve always liked. I was content with DF for a long time, but then I got to thinking of all the things I’d like to see done with the genre (genre being roguelike citybuilder, I suppose. Who cares what its called). So I had 3 choices:

• Send Toady my suggestions and hope he does things the way I’d like
• Hope someone else makes a game just the way I’d like
• Do it myself

I’m a bit impatient, so the obvious choice was to do it myself, so here I am.

I want to stress that I’m not setting out to make a Dwarf Fortress clone, it wouldn’t make much sense really. I’m making a game that is inspired by Dwarf Fortress, and there will be certain similarities. Using similar indicators for things like stockpiles and creatures and such that are used in DF, Nethack and so forth is a conscious design choice to make getting into the game easy for people already familiar with DF, or roguelikes in general.

Goblin Camp is going to be more about the broader decisions, and less about micromanagement. You’ll steer your economy by setting minimum production values, and organizing your workshops and stockpiles to ensure efficient hauling. What you won’t care about are who the individual workers are, or who’s assigned to what workshop. Orcs will gain skill in their chosen profession, but assigning jobs to the best workers is left to the game. You the player will want to organize your defences and military in such a way as to keep your working class alive, because the longer they work the better they get. Constant bloodbaths at your workshops will mean that you’ll always have unskilled labor.

This leads to an important point, orcs and goblins (especially goblins) are expendable. An ordinary orcs life is short and brutal, only a select few will survive long enough to become notable individuals.

I’ll expand on all that later, I don’t want this post to stretch too long. As a parting point I want to bring up another big factor in the development of Goblin Camp: Feedback. I want to hear all your suggestions, ideas and critique. I’m not making Goblin Camp just for myself, but for everyone else as well, and as such everyone’s comments are important. Also, Goblin Camp will be open sourced after the 0.1 release, and contributions to the code are encouraged.

Source: Kharne

• Obligatory reference to "M$". Check.
  
• Obligatory insistance that only the one true language (probably C?) be used Check.
• Miltonesque mindset of the true believer on display - that "philsophy" comes first before everything else. Check.
• Lazy assumption that windows software can't be ported to other operating systems. Check.
  

Source: Rogue Wombat

My first introduction to Roguelikes was ADoM, and it will always hold a special place in my heart.  I’ve played it for hours, but I’ve rarely progressed beyond one or two quests / dungeons.  It’s epic, but possibly a little too epic for players like me who can’t devote gads of time to develop a playing strategy that will get me anywhere near completion.  The problem is the lighter Roguelikes I’ve played don’t come anywhere near providing the atmosphere that ADoM does, and it’s the atmosphere that makes the game so appealing to me.  I even bore of the original Rogue after a while, with its spartan use of ASCII and super-simple feature set.

However, my estimation of other Roguelikes may have just recently changed with my discovery of Brogue thanks to a link from the Kharne blog.  Simply put, I can’t recommend this game as highly as I ought to to get you to go play it.  Unfortunately, it’s a Mac native game, and I can’t vouch for the Windows / Linux ports that the author links to.  Let me whet your appetite enough so you go through the trouble of figuring out how to play it…

Brogue.  It’s like Rogue in its simplicity, but it adds a level of visual appeal that I literally haven’t seen in any other Roguelike.  It’s like ADoM in the way it shapes the atmosphere and mood of gameplay, but it requires far less attention and time to learn all the game mechanics.  But don’t let the simplicity fool you… there are plenty of cool features to discover each play through!

For example, Brogue has a limited but fun set of monsters inhabiting its dungeons.  There’s the monkeys that steal from your inventory and run away, the toads that cause you to hallucinate (displayed through some fun visual effects), and the acid blobs that corrode any unprotected weapons and armor upon contact.  Even better, monsters will imprison their own kind and torture them.  I literally walked into a room with a kobold tied up that was getting beaten by other kobolds.  I dispatched them, freed the kobold, and gained a faithful friend.  Brogue gets monsters and allies right.

Let’s not forget the brilliant dungeons you get to crawl, too.  The use of various terrain tiles is quite fun, even if most are simply there for flavor.  Still, don’t start a fire in the swamps or you might get an explosive surprise.  Even better, in addition to terrain types, Brogue also adds cavernous pits that you can jump down to the level below and underground lakes inhabited by eels and krakens.  Get into deep water and any unequipped items in your inventory might just float away to be recovered in the shallows.  Then there are the molten lakes of lava that, well, you just don’t go there.  Brogue gets dungeons right.

What about equipment?  Well, the offering is admittedly simple, but that’s part of the appeal.  You have one stat to track, strength.  That will affect what weapons and armor you can equip.  You can also find rings, staffs, wands, scrolls, and potions to dabble in the arcane.  Everything you pick up will be unknown until it’s used or identified, so tread carefully… some potions when opened cause explosions and poisonous clouds of gas to envelop your player.  I used a wand of obstruction on accident and was stuck for dozens of turns until the affect wore off.  The localized area affect nature of these spells is pretty slick, and the visual presentation is very interesting.  Brogue gets magic right.

I could go on, but I’ll stop there.  This game is loads of fun, easy to get into, and a treat for the eyes.  I highly recommend it and would simply say… beware the monkeys.  They’re filthy pickpockets and deserve to be dispatched in their sleep.

Source: Kharne

1. Introduction
2. Required 3rd Party Components
3. Licensing Notes
4. Other Notes
5. Contact Details
   

Source: Kharne

Source: Kharne

Source: Kharne

Source: Kharne

Source: Kharne

I've just spent about five hours in total dealing with bugs I introduced into the TDungeon level generation code while refactoring, which was mainly due to doing the refactoring offline, i.e. not within an environment where the code could compile. It has been a useful exercise, as well as removing any code that I'd be ashamed of releasing (now there's just a lot of code left that I merely dislike), I've reaquainted myself with a lot of code that has been written for quite a while now and which I had forgotten the purpose of. The code also conforms a lot more to coding standards.

The only major source code left to refactor is UnitDisplay.pas which, as the name suggests, is, contains the code that interfaces with the screen and the GUI-handling code. Its about 4000 lines of code. I'm on target to finish the refactor within the week or so.

Its a messy unit, full of code like this:

Procedure TFormDisplay.ListViewMonstersCompare(Sender: TObject; Item1,
  Item2: TListItem; Data: Integer; var Compare: Integer);
begin
  if ListViewMonsters.Items.Count = 0 then Compare := 0
  else
  begin
    if (StrToInt(Item1.SubItems[6])) > (StrToInt(Item1.SubItems[6])) then Compare := 1
    else if (StrToInt(Item1.SubItems[6])) = (StrToInt(Item1.SubItems[6])) then Compare := 0
    else Compare := -1;
  end;
end;

I'm not coding C, so there's no virtue in conciseness. The refactor turns that code into this (note that some of the indenting may not display properly, but the final code is indented properly):

{ Sort Routine to sort entries in the Visible Monsters display - compares two
  TListItems and returns a comparison based upon TMonster.Level }  
Procedure TFormDisplay.ListViewMonstersCompare(Sender: TObject; Item1,
   Item2: TListItem; Data: Integer; var Compare: Integer);
var
  FirstItemLevel: Integer;
SecondItemLevel: Integer;
begin
  { Logging }
  hLog.Add('{now} {lNum} TFormDisplay.ListViewMonstersCompare()');

  { Default result which is that both items are equal}
  Result := 0;

  try
    { Make sure there are items to compare }
    if ListViewMonsters.Items.Count > 0 then
    begin
     { Get the monster levels from the Listview Items }
      FirstItemLevel := StrToIntDef(Item1.SubItems[MONSTER_LEVEL], 0);
   SecondItemLevel := StrToIntDef(Item2.SubItems[MONSTER_LEVEL], 0);

   { Compare the Monster Levels of each items }

   { First > Second }
      if FirstItemLevel  > SecondItemLevel  then
     Compare := 1
      { First <>
      else if FirstItemLevel < style="font-weight: bold; color: rgb(0, 0, 102);">) then  
     Compare := -1;
    end;
except
 { in case of error, log the Exception }
 on E: Exception do hLog.AddException(E);
end;
 end;