Messages

1

Design / Re: Retinue - game design pitch

« on: February 14, 2014, 02:24:24 PM »

Sounds like something that would really need some prototyping and iteration to see what works well in practice. It sounds like a cool starting point though.

One thing that does spring to mind is that the light radius idea could give a large amount of options for movement. OK for the player but for the AI it'd be hard to code, hard for the player to predict and difficult to display clearly when there is also a light radius to render.

I'd suggest instead of giving them a miasma zone they can all move on their turn, but only a short distance perhaps in a limited number of directions (i.e. usually they go 1 square in the 4 cardinal directions but a horseman could go 2 squares and a rogue can go in any of the 8 directions).

2

Programming / Re: Roguelike Gameflow - Alternatives

« on: September 30, 2013, 09:10:21 AM »

wrt story, I've always thought story to be bad in perma-death games, but maybe you could have a perma-consequence game without death at all: you can't die but each level has a pass/fail objective and it gets incorporated into the story (scripted or procedurally).

Or you'd have to go full on procedural story, which I don't think anyone has done well so far (but that's no reason not to try).

3

Design / Re: Super Hero RL - Design Fail?

« on: September 20, 2013, 08:31:21 AM »

There is a tabletop RPG called 'HERO System' that contains ridiculously involved rules for power creation.

As an RL I assume you want pretty quick character generation. Something I thought of for a game I may write is you take the name, hash it, and use that as a seed to procedurally generate a super hero (complete with powers that have generated effects and flavour text).

The same game idea had the following for advancement - when you 'die' (or trigger it manually) you get a second wind: a permanent power buff, full heal and a little extra back story explained/generated; but you only have 2-3 of these. You're then seeing how much fame/popularity you can get before dying 3 times.

4

Programming / Re: Keeping gamepads (and other odd peripherals) in mind

« on: September 05, 2013, 04:14:37 PM »

Your typical modern controller has...

2 analogue sticks (left and right).
A d-pad (the cross shaped thing which makes up 4 buttons).
Start and select/back buttons in the middle.
4 normal buttons on the right.
2 shoulder buttons.
2 shoulder triggers (you can get an analogue for how far they are depressed).

I've never tried a rogue-like on a controller but from having played/written other games on one I would imagine you'd go with...

Left analogue stick for movement (4 way or 8 way, just make sure you set up a decent dead zone so movement doesn't get misinterpreted).
Right analogue can scroll round the map and/or inspect.
d-pad for bringing up in game menus and start for the main menu. I think using this for movement would actually be a mistake.
Common actions go on the 4 buttons on the right. Use the shoulder buttons as modifiers for these (like shift and control) which gives you 12 possible actions.
I can't imagine sensible uses for the other buttons.

I'd imagine the only way to tell for sure is to buy one and try it out yourself, but I can't see why it shouldn't work.

X-Padder is pretty easy to set up and has plenty of options to configure it. You could even make your own config file and distribute it with your game if you didn't want to support it in your own code.


P.S. Macs can be set to allow a right click, but I believe it's off by default.

5

Programming / Re: Path Finding Problem

« on: August 30, 2013, 10:17:56 AM »

Assuming you're using C++ and the standard libraries, maybe something like this...

Code: [Select]

struct node {
    node() : x(0), y(0), g(0), h(0), f(0), state(UNDISCOVERED), previous_step(NULL), tile(NULL) { }

void ResetForDestination( node* destination )
{
// initialises node for new path
h = std::abs(x - destination->y) + std::abs(y - destination->y);
g = f = INT_MAX;
state = UNDISCOVERED;
previous_step = NULL;
}
void Open( node* previous, std::multiset<node*>& open_set )
{
// adds node to the open list, records where it came from and how long the path is
previous_step = previous;
g = previous_step ? previous_step->g + 1 : 0;
f = g + h;
state = OPEN;
open_set.insert( this );
}

    int x,y;
int g,h,f;
    enum { UNDISCOVERED, OPEN, CLOSED } state;
node* previous_step;
node* neighbours[4];
tile* tile;
};

struct nodeCompare {
    bool operator()(const node* lhs, const node* rhs)
{
if(!lhs) return true;
if(!rhs) return false;
        return lhs->f < rhs->f;
    }
};

bool initialised = false;
std::vector< std::vector<node> > nodes;

void Initialise( int max_X, int max_Y )
{
nodes.resize(max_X);
for (int x = 0; x < max_X; ++x)
{
nodes[x].resize(max_Y);
for (int y = 0; y < max_Y; ++y)
{
nodes[x][y].x = x;
nodes[x][y].y = y;
nodes[x][y].tile = &tiles[x][y];
nodes[x][y].neighbours[0] = x > 0 ? &nodes[x-1][y] : NULL;
nodes[x][y].neighbours[1] = x < max_X-1 ? &nodes[x+1][y] : NULL;
nodes[x][y].neighbours[2] = y > 0 ? &nodes[x][y-1] : NULL;
nodes[x][y].neighbours[3] = y < max_Y-1 ? &nodes[x][y+1] : NULL;
}
}
initialised = true;
}

bool FindPathFrom_To( int start_X, int start_Y, int dest_X, int dest_Y, std::list<tile*>& path )
{
if( !initialised )
{
Initialise( MAPX, MAPY );
}
// reinitialise node map
node* start_node = &nodes[start_X][start_Y];
node* destination_node = &nodes[dest_X][dest_Y];
for (int x = 0; x < max_X; ++x)
for (int y = 0; y < max_Y; ++y)
nodes[x][y].ResetForDestination(destination_node);

// open list, automatically sorts by f
std::multiset<node*, nodeCompare> open;
start_node->Open( NULL, open );

// search
while( !open.empty() )
{
// find the current cheapest node (which will be at the start of the set)
node* current_node = *open.begin();
if( current_node == destination_node )
{
break;
}
// open all adjacent nodes
for( int i = 0; i < 4; i++ )
{
if( current_node->neighbours[i] && current_node->neighbours[i]->state == node::UNDISCOVERED )
{
current_node->neighbours[i]->Open( current_node, open );
}
}
// remove current node from the open list
current_node->state = node::CLOSED;
open_set.erase( open.begin() );
}

// calculate the final path
path.clear();
node* current_step = destination_node;
while( current_step )
{
path.push_front( current_step->tile );
if( current_step == start_node )
{
return true;
}
current_step = current_step->previous_step;
}
return false;
}

I haven't compiled it, let alone tested it but all the basics are there (even if it's rather messy).

You call 'Initialise' to create your pathfinding map and then 'FindPathFrom_To' to get a list of tiles you need to traverse. It returns false if no path was found.

6

Programming / Re: Path Finding Problem

« on: August 30, 2013, 09:22:13 AM »

StepsFrom_To looks like it's broken to me. Do you not just want the Manhattan distance from start to dest? ?Iterating over all the steps doesn't seem to make sense and it won't work if dest_y < start_y or dest_x < start_x.

Code: [Select]

int StepsFrom_To(int start_y, int start_x, int dest_y, int dest_x) {
        return abs(start_y - dest_y) + abs(start_x - dest_x);
    }

Looking through the rest of the code you may actually be right that it is all wrong but hopefully we can fix that for you. Unless you really know what you're doing with pathfinding (and usually even if you do) this is the algorithm to use: http://en.wikipedia.org/wiki/A*_search_algorithm

EDIT: Endorya's link looks like a better way to learn how it works.

7

Programming / Re: A major decison that I need to make regarging game-play.

« on: July 16, 2013, 03:06:05 PM »

Sounds like a single player MUD (https://en.wikipedia.org/wiki/MUD). I say MUD rather than text adventure because as I understand it they tend to be closer to rogue-likes in complexity. Interesting text is hard to generate though, harder than interesting maps (and we all know that isn't trivial).

To overcome your original problem of boring exploration, without resorting to all text or auto explore, how about a hybrid approach by having 3 layers to your map...
Overland: Move around and explore etc. like you'd expect.
Region map: Zoom into one region and as you explore more points of interest are revealed, you don't move between them like a roguelike, you just select them from a menu. More like a text adventure.
Dungeon map: Click on a point of interest and select 'delve'. These regions have strict boundaries and you can leave them to return to the sub-region map.

John,

8

Programming / Re: Making a one dimensional roguelike interesting.

« on: July 15, 2013, 09:05:53 AM »

Simple combat is well on its way, but I am a bit stumped on how to show multiple enemies in one tile (currently 16x16) given that there will be more than a couple different kinds of enemy. (having n "subtiles" in a tile breaks if  there are n+1 enemy types)

You should have loads of screen space when working in 1D, so could they not just stack up the screen like this...

Code: [Select]

      h
   g  h
@  Gggh
======================
Maybe the ordering of the stack could be important too, so you can only attack the top/bottom monster in a stack (and special attacks/spells could alter this), or similar.

9

Programming / Re: Making a one dimensional roguelike interesting.

« on: July 02, 2013, 03:17:29 PM »

One thing that could spice it up is giving the player several turns at once (maybe an action point system so you can make support abilities cheap) and giving them plenty of powers like pulls, pushs, teleports, area attacks and traps. The game becomes about controlling your enemies so they are concentrated in your damaging areas while you remain out of their reach.

10

Programming / Re: L-Systems

« on: March 31, 2013, 12:02:30 PM »

It's a little unclear, are you trying to make a tree like structure then? How are you determining where the red line starts?

Whatever the goals, putting in a square of fake roads around the edge of your map usually helps with things like this.

This has an air of delaunay triangulation about it, which could split space up and then connect regions with roads in a similar manner.

11

Programming / Re: L-Systems

« on: March 28, 2013, 09:39:11 AM »

@John: Not sure I can follow. Wouldn't interesting splits suffer from the same problem that they overlap in a manner that's hard to control and work with?

There cannot be any overlap because each rule can only assign out the space it has itself been given (its current 'scope'). Really what I described is just a BSP powered by an L-system (although if you represented space as polygons instead of just rectangles you'd get more variety in how you could split them).

http://johnwhigham.blogspot.co.uk/2012/12/procedural-castle.html and http://procworld.blogspot.co.uk/search/label/L-System have a good exploration of the concept (and are both based on the same paper). They make 3D buildings but 2D should be easier.

12

Programming / Re: L-Systems

« on: March 27, 2013, 03:41:02 PM »

If you want to work on a 2D grid without overlaps you can use the L-System to partition space, rather than picking anywhere to place things. You can do straight binary split or more interesting splits (like get it to generate a grid and/or using only some of the available space).

You then nest the space partitions and eventually convert them into actual things, like rooms(which could be further split for placing items/furniture/monsters). You may need to resort to something else for corridors, or expand the scope of your grammar a bit.

13

Other Announcements / Re: 7DRLC2013 (Lack of) Ideas Thread

« on: March 01, 2013, 09:30:57 AM »

Getting more 'finish' seems to be the main point of 7DRLs.

14

Programming / Re: who has implemented a hex grid?

« on: March 01, 2013, 09:26:20 AM »

I have found some success using libhex - http://blog.firetree.net/2008/01/26/libhex-v010/ it's a c++ library. It didn't compile for me right away but didn't take much time to fix up. The code's not too hard to understand if you want to customise it (I added a hex creation functor to mine so I can use custom hex classes).

15

Challenges / Re: Early 7DRL Declaration

« on: February 28, 2013, 11:53:22 AM »

Going to throw my hat into the ring this year.

Currently the idea is for a space themed roguelike with a focus on tactical positioning. So we're talking limited movement directions, swarms of missiles to evade, maybe gravity effects, a scanning system I invented for a wargame I never finished writing (...as you scan someone, or they scan you, to better resolution they get free movement to represent your previous inaccurately) and anything else I can incorporate in the time.

I had thought about hexes, but maybe I should remove the grid altogether, ending up playing like SteamBirds (but with procedural levels and permadeath). Not sure how roguelike that will end up feeling, but maybe I shouldn't care too much.

No idea about the quest/setting, I'm not really bothered as long as you get to fly around and shoot/evade enemy ships, so something lightweight.