Messages

1

Early Dev / Re: Stone and Steel

« on: July 17, 2010, 06:22:30 PM »

I'll be posting updates and other stuff at the Development Blog.

2

Early Dev / Re: Stone and Steel

« on: July 15, 2010, 09:49:37 PM »

Any error in particular? You might need the MSVC 2008 Runtime or something. I've never distributed across multiple platforms so I'm not real sure yet

3

Traditional Roguelikes (Turn-based) / Re: Goblin Camp

« on: July 14, 2010, 08:09:04 PM »

This looks absolutely awesome.

4

Early Dev / Re: Stone and Steel

« on: July 14, 2010, 07:36:12 PM »

I can now provide Windows builds. I'm using MSVC 2008 on 32-bit Windows 7 for the builds, but I'm not sure that means anything for the end-user. Updating the main post with Revision 21 builds. You can now look with the L key. For a complete list of commands, see the README file or the Google Code project page.

5

Early Dev / Re: Stone and Steel

« on: July 13, 2010, 04:56:00 AM »

Updated the download link with the Revision 20 Debug build. For some reason the Release build was crashing for me, so you're stuck with the slightly larger file

Features have also been updated.
 * You can now combat the Kobolds
 * The Kobolds now have a Field of View and basic awareness
 * The Kobolds now have pathfinding (this is being tweaked) and attacks
 * Tiles with multiple entities will have a copper background

Run it in a terminal to view the combat output. Otherwise you won't see much as I haven't implemented the announcements window yet.

Also, sorry for the inactivity of late. Have some very minor health complications plus work.

6

Programming / FoV and Pathfinding

« on: July 03, 2010, 11:23:10 PM »

Currently, I have 50 entities (51 counting the player) on the dungeon level. Rebuilding the FoVs every turn for every entity is a bit.. slow. Anyone have any input on how to speed things up? Here's what I'm currently doing:

BuildMap():
Builds the FoV Map around the entity based on it's sight. If it has a sight of 5, it loops through position.x-5, position.y-5 to position.x+5, position.y+5

Create Entity
 - Initiate FoV Map, which is the size of the level
 - BuildMap()

Entity Turn
 - BuildMap()
 - ComputeFoV()
 - check if player pos is in FoV
 - Path to player if he is, rebuild path if he has moved

I'm currently rebuilding the FoV every turn even if the entity hasn't moved just in case the player steps into the FoV. This has really slowed down my game though, so it's a bit unacceptable.


Edit: disregard. got some sleep and realized I only needed to build the map once

7

Early Dev / Re: Stone and Steel

« on: July 03, 2010, 04:45:50 PM »

Updated the main post with a Linux build. If someone wants to provide a Windows build, I'll gladly put it up on the project page.

Please see the Current Features and Known Issues in the original post for details. I've also included a small ReadMe file.

8

Early Dev / Re: Stone and Steel

« on: July 02, 2010, 10:25:21 PM »

I'm unfamiliar with Conan/Lankhmar, but pushing a bear off a cliff will hopefully be possible. In the first builds that I release, the setting is an underground Kobold lair. I'm currently tweaking the dungeon generator to allow multiple z-level rooms and stuff like that. After it's stable enough, and I decide on a turn scheduling solution, I'll expand it to above-ground areas.

I'm a huuuge fan of Survival RLs (UnReal World for example), so I'm hoping to have some survival features in it eventually.

But first.. simple (and then not so) kobold killings.


Edit:
Currently if you compile the src, you will be able to walk around  a cave and see 'k's. They're Kobolds and they have no AI

9

Early Dev / Re: Stone and Steel

« on: July 02, 2010, 01:24:50 PM »

Thanks! I'm really at wits end on how to implement a timer/turn system. Most other things I have a plan for, but some things just evade my mind I guess. I'm thinking that I like the energy system.

Pseudo-code:

Code: [Select]


void CPlayer::doEvent()
{
   while(true)
    {
        key = checkforkeypress();
        if (key == left or right or up or down)
        {
            Energy += Move(key); // Move returns the move cost to move into a tile
            break;
        }
    }
}

// for cases such as inventory, we wouldn't break; the loop. Checking ones inventory shouldn't use up their turn

player.gainEnergy();
if (player.getEnergy() <= 0)
    player.doEvent(); // inherited from Entity, checks for keypress instead of doing AI action

for (int i = 0; i < monsters.size(); ++i)
{
    monsters[i].gainEnergy(); // monsters[i].energy -= monsters[i].speed
    if (monsters[i].getEnergy() <= 0)
        monsters[i].doEvent(); // this will be AI, in the players case it will wait for a keypress. mosnters[i].energy += TimeToTake
}

Any disadvantages to this? It seems like a fairly solid idea for implementation, but I'm not sure how multi-turn actions would work (reading a book, Lasik eye surgery, etc). This is something I'd rather like to get right the first time since it seems like any game entities action will revolve around it.

10

Early Dev / Stone and Steel

« on: July 02, 2010, 01:40:24 AM »

Development Blog

Just dropping in to announce my upcoming Roguelike. It's called Stone and Steel. If this name is taken, let me know, but I did a quick check and didn't find anything other than some WH40k stuff. I will be developing on Linux, but it should be cross-platform. I'll do my best to provide builds for Window/Linux. Mac may be a different story (no access/experience).

It's an open-source project under whatever LibTCOD reqires me to use (I'm no good with licensing), and I'm using SVN for version control. Here's the Google Code project page. This is my first C++ project in a long while, but the code still runs regardless of how gross some of it is. A lot of it will be cleaned up eventually.

So far there isn't much to show, but I'm making good progress. The early versions will only contain underground dungeoneering, but later on I'll be implementing an above-ground world. I don't want to get ahead of myself on features, but I'm leaving my mind open to some larger scale stuff.

As far as combat goes, I'm looking forward to implementing a Dwarf Fortress Adventure Mode-like combat/injury system (though perhaps not as complex at first) as well as tending wounds (something like UnReal World maybe?). Before that, I will be implementing a generic placeholder system.

Here's a screenshot!


As you can see, nothing too serious yet. Races are moddable (for what it's worth), but there's not really any substance to it yet. This is more of a pre-alpha announcement. I'll use this thread for discussion/etc, but feel free to follow the revision log on the project page or check out the source.

Stone and Steel Revision 23 Download Links
http://code.google.com/p/stone-and-steel/downloads/list

Revision 23 Features:
  * AI Framework and basic pathfinding (this can be a bit.. off)
  * AI Field of View
  * Config options (only keyboard repeat for now)
  * Combat with the Kobolds
  * Tiles with multiple entities will have a copper background
  * Player now has a look command, usable with 'l' - Somewhat incomplete, will have to update when items are added

Revision 26 (Current) Features:
  * Databanks, easily mod most parts of the game
  * Materials, durability, and quality
  * Picking up items
  * Checking inventory (through console)
  * 15 randomly placed masterwork steel swords in dungeon (this is temporary)

Known Issues:
  * I have not yet implemented a way to connect or fill in off-caves, just restart the game if you get stuck in a tiny area. (all)

Stone and Steel is a Roguelike game where the player will complete quests for factions, and do whatever he or she wants in general.

There will be multiple races to choose from. Rather than classes, the player will advance skills through practice, reading, and being taught.

Monsters in S&S will be of the typical fantasy variety, including kobolds, goblins, orcs, dragons, etc.

The world will be completely procedurally generated, guaranteeing a different play experience every time. This is not expected to be an early feature, but random dungeon generation is.

Death in Stone and Steel is permanent, and saving games will only allow you to resume a game. You will not be able to load a dead character.

The early releases of Stone and Steel will consist of a simple cavernous area, known as The Kobold Burrows where the player will fight Kobolds until he or she reaches the Kobold Shaman, which is the end-boss. Upon killing this boss, the game is over and score is taken.

11

Early Dev / Re: Rogue Survivor Alpha 3.1

« on: June 28, 2010, 02:18:01 PM »

I am sad that I could not run this under Wine on Linux. Looks awesome!

12

Temple of the Roguelike / Re: Added a Python/Curses example

« on: June 25, 2010, 05:42:07 PM »

Thanks getter77 . I had no luck with the Windows module myself, so I'm going to use PDCurses. I'll be sure to post the C/C++ version whenever I get done.

What is normally used for such projects?

13

Temple of the Roguelike / Added a Python/Curses example

« on: June 24, 2010, 09:08:02 PM »

I read that this was the main community for RogueBasin. If it's not, sorry for the misplaced post. I was reading this article on the dungeon building algorithm, and converted the Java example to Python/Curses. you can find a link at the bottom of the article, or here

This is my first post here, and I'm currently working on my own Roguelike project. Hope this is of some use to someone.