7DRL (Epic) Fail: A1RL

26 views
Skip to first unread message

Jimmy Åberg

unread,
Mar 15, 2011, 3:33:00 PM3/15/11
to
This year, I failed badly: I did not even manage to start the project
(A1RL) ... This was my second "participation" of 7DRL. (My first time
was in 2009, and that time I even failed to report my failure :/ ).

I wouldn't se my "participation" this year as a "total waste of time"
since I, during the running time of 7DRL, managed to start a
discussion about what language should I use to implement my general
ideas regarding RL-development. (see for details:
http://groups.google.com/group/rec.games.roguelike.development/browse_thread/thread/7bb6884beb01938d#
)

I will try to cover these losses by taking a visit at IRDC 2011 in
Visby, (since I also currently live in Stockholm).

Todd Carnes

unread,
Mar 15, 2011, 5:31:59 PM3/15/11
to
On 03/15/2011 03:33 PM, Jimmy Åberg wrote:
> (My first time was in 2009, and that time I even failed to report my
> failure :/ ).

So, you've made some progress. :)

Todd

Gabriel Arthur Petrie (eyenot)

unread,
Mar 15, 2011, 5:37:59 PM3/15/11
to

Nooo you should have to validate saying it's an EPIC fail by telling us,
in awesome detail, the things we're missing out on that *would* have
been in the RL if you *had* made it. :) I love that part! I'll read it all!

Something I've been doing is, instead of going and playing all these
finished RLs, sitting looking at my code -- where I'm trapped at a
certain phase -- and thinking about others' code and sharing code in
general. And one thing that always bothered me was comments about my
code being unreadable because (as others assumed) I didn't adhere to an
indent style (which I have for many years). So I studied various indent
styles to look for a better one and couldn't actually find one. So today
while I'm having coder's block I spent two hours writing my Precision
Indent Style.

http://eyenot.livejournal.com/1075910.html

The problem I'm having is the best way to implement a failure-less
spread-item-drop routine: "if tile occupied by item on drop, drop it
adjacent, else adjacent to that, repeat until dropped". Or, if I
shouldn't switch from 256 unique items to 256 placements per level
containing however many objects, and come up with an array consisting of
all these objects and their properties, and some way of processing that
array, copying it, defragmenting it and so on. I have some systems I
came up with, in front of me, for doing this, but I don't want to make a
move until I can figure out what I really want.

I want to talk about this stuff in the newsgroup but it's still sort of
bragging period for the 7DRL. So I'm trying to keep it on the downlow.

Joshua Day

unread,
Mar 15, 2011, 6:49:15 PM3/15/11
to
Gabriel Arthur Petrie wrote:
> Jimmy Åberg wrote:
>> This year, I failed badly: I did not even manage to start the project
>> (A1RL) ... This was my second "participation" of 7DRL. (My first time
>> was in 2009, and that time I even failed to report my failure :/ ).
>>
>> I wouldn't se my "participation" this year as a "total waste of time"
>> since I, during the running time of 7DRL, managed to start a
>> discussion about what language should I use to implement my general
>> ideas regarding RL-development.
>
> The problem I'm having is the best way to implement a failure-less
> spread-item-drop routine: "if tile occupied by item on drop, drop it
> adjacent, else adjacent to that, repeat until dropped". Or, if I
> shouldn't switch from 256 unique items to 256 placements per level
> containing however many objects, and come up with an array consisting of
> all these objects and their properties, and some way of processing that
> array, copying it, defragmenting it and so on. I have some systems I
> came up with, in front of me, for doing this, but I don't want to make a
> move until I can figure out what I really want.
>
> I want to talk about this stuff in the newsgroup but it's still sort of
> bragging period for the 7DRL. So I'm trying to keep it on the downlow.

I used a spiral in Rook, and it works quite nicely except that the
test for occupied cells was broken. Check the target cell. Then check
the eight surrounding cells; then check the sixteen cells around those;
then check the twenty-four around those. Keep looping through ever
larger shells until you find a permissible cell. It's a little
trickier if you want to start at a random cell in each shell (which
you probably want to do). If you keep a count of the number of cells
in each shell (eight times the shell number) and the number of cells
where you step each direction (two times the shell number: e.g., two
steps right, two steps down, two steps left, two steps up, for the
first shell), then it's pretty easy to pick a random number of steps
to 'ignore' at first, and then run that many extra steps at the end
of the shell.

If you want to guarantee connectedness (which is overkill), run a
Dijkstra scan out from the starting cell, but go ahead and assume
constant costs so you can use two open lists: one for the cells of
the current distance from the start, and one for cells of the next
distance from the start. When you find a cell that's both permissible
and free, drop your item and break.

--
Joshua Day


Jimmy Åberg

unread,
Mar 15, 2011, 6:57:29 PM3/15/11
to
A while ago I did experiment with coding styles in C#, and this was
the style I finally settled for (the beauty of this style, is that it
does a clear distinticion between method signature and method body):

...<CODE>...

int example(arg) { int a=1;
if(a==1){
if(arg!=a){
int b=2;
printf("foo");
a=arg;}
else{
int c=3;
printf("bie");
b=a;
while(b==1){
printf("bar");
d=4;c=b;
b=a;}}
int a=0;}
return a;}}
int example2(arg) { int a=1; return a; }
int example3(arg) { int a=2; return a; }
int example4(arg) { if(a==1){
if(arg!=a){
int b=2;
printf("foo");
a=arg;}}
int a=0;}
return a;}

...</CODE>...

Jimmy Åberg

unread,
Mar 15, 2011, 6:59:35 PM3/15/11
to
Antother cool trick I realized, was a kind of "minimal switch
notation":

...<CODE>...

int get_damage_by_weapon(int w)
{
int d
= w==0 ? 0
: w==1 ? 2
: w==2 ? 3
: w==3 ? 5
: w==4 ? 8
: 9;
return d;
}

...</CODE>...

gabriel arthur petrie

unread,
Mar 15, 2011, 8:40:32 PM3/15/11
to
Joshua Day <josh...@gmail.com> wrote:

> > Gabriel Arthur Petrie wrote:
> > The problem I'm having is the best way to implement a failure-less
> > spread-item-drop routine: "if tile occupied by item on drop, drop it
> > adjacent, else adjacent to that, repeat until dropped". Or, if I
> > shouldn't switch from 256 unique items to 256 placements per level
> > containing however many objects, and come up with an array
> > consisting of
> > all these objects and their properties, and some way of processing
> > that
> > array, copying it, defragmenting it and so on. I have some systems I
> > came up with, in front of me, for doing this, but I don't want to
> > make a
> > move until I can figure out what I really want.
> >.
>
> I used a spiral in Rook, and it works quite nicely except that the
> test for occupied cells was broken.
> --
> Joshua Day
>

Im glad for your examples, they reflect more or less exactly what i have
devised. However, my block isn in technical achievement but in
philosophy and aesthetic.

In reality a pile will have a limit and ultimately will thwrefore need
to spill or spread over. So if i am going to screw the devil i may as
well have kids. Which to me says,i should go spread form to start. The
only problem is, its unrealistic compared to pile.

What is your opinion on that aspect?

--
blaaaahhhhhhhhhhhhhaaaaaaaaaahaaaahaaahah

gabriel arthur petrie

unread,
Mar 15, 2011, 8:45:46 PM3/15/11
to

I should also mention i have a problem with the fact that e ventually
the entire dungeon MAY *possibly* be full and that the spread algorithm
might fail, which is why i mention it being failure-less. That problem
super edes rl into math or theory, but i love those discussions because
they lead to some formality. What do you think about it, joshua day?
--
blaaaahhhhhhhhhhhhhaaaaaaaaaahaaaahaaahah

Joshua Day

unread,
Mar 15, 2011, 10:55:54 PM3/15/11
to
Gabriel Arthur Petrie wrote:
> Gabriel Arthur Petrie wrote:
>> Joshua Day wrote:
>>> I used a spiral in Rook, and it works quite nicely except that the
>>> test for occupied cells was broken.
>>
>> In reality a pile will have a limit and ultimately will thwrefore need
>> to spill or spread over. So if i am going to screw the devil i may as
>> well have kids. Which to me says,i should go spread form to start. The
>> only problem is, its unrealistic compared to pile.
>>
>> What is your opinion on that aspect?
>
> I should also mention i have a problem with the fact that e ventually
> the entire dungeon MAY *possibly* be full and that the spread algorithm
> might fail, which is why i mention it being failure-less. That problem
> super edes rl into math or theory, but i love those discussions because
> they lead to some formality. What do you think about it, joshua day?

Reality? I'm pretty sure you're making a game. Reality only matters
when it interacts poorly with a player's intuitions about your game.
Some games (Brogue, say) limit the board to one item per cell. It
simplified the code a little bit, but it simplifies the player's job
immensely. Never a prompt asking what to pick up, never any tricky
search for items obscured by other items. Enemies in Brogue do not
generally drop items at death; in some games with the same restriction,
they do, and it looks more realistic than you'd expect. The orc,
in his death throes, scattered his inventory all around him!

There are compromises, too. You can limit the board to one item per
cell, but make provisions for containers. The body of an orc in full
armor might be a container for his armor, weapon, and loot; you might
spill an item or two for flavor.

If you want to go full-out and have many items in each cell, it's
easiest to use linked lists, with a single pointer to an item in each
map cell, and a pointer from each item to the next one. You can also
do a hashmap of lists, which can certainly lighten your programming
load.

Don't be afraid of filling the dungeon.

No game rule is ever absolute; they all exist to fulfil your nefarious
purposes for player experience. If the dungeon fills up, you can
make each cell hold more items, certainly, or: you can make terrain
that destroys items; you can make monsters that destroy items; you can
drop fewer items (which means less junk); you can let the player
squelch items; you can limit the player's time with a stricter food
clock; you can make walking through seas of items a problem for the
player that the player will manage; you can stop dropping corpses,
or not count corpses as items. There are lots of options for any
design problem, and most of the time it's safe to fix them after
you implement your best guess.

--
Joshua Day

Ray

unread,
Mar 21, 2011, 12:22:29 PM3/21/11
to
gabriel arthur petrie wrote:

> I should also mention i have a problem with the fact that e ventually
> the entire dungeon MAY *possibly* be full and that the spread algorithm
> might fail, which is why i mention it being failure-less. That problem
> super edes rl into math or theory, but i love those discussions because
> they lead to some formality. What do you think about it, joshua day?

Use dynamic structures and the problem goes away (well, anybody can run
out of memory, I guess).

But seriously, just make each square have a list of items. Let any
square have multiple items in a stack, at least when all its neighbor
squares are stacked almost as deep.

I recommend this simple failure-free algorithm for "item spill." It
creates "piles" where all the squares on the border of the pile have
one item and squares within the pile may have one more item than any
of their neighbors. Treasure may wind up piled fairly deep in corridors
or next to walls.

1. Dump all the "drop" treasure on a single square. Put this square
into a queue.

2. Repeat
2A. take one square X from the queue.
2B. For each neighboring non-wall square Y to that one;

If the amount of stuff in X, minus one, is
greater than the amount of stuff in Y, then
2Bia. move one item from X to Y.
2Bib. if Y isn't already in the queue,
add it to the queue.
Else If the amount of stuff in Y, minus one, is
greater than the amount of stuff in X, then
2Biia. move one item from Y to X.
2Biib. if Y isn't already in the queue,
add it to the queue.
Until the queue is empty.


gabriel arthur petrie

unread,
Mar 22, 2011, 9:19:34 PM3/22/11
to

Well im not using variable size arrays if i can hrlp it but thats a
distinct possibility. Im also trying to avoid memory allocation outside
variable declarations, as per (my syntactic) usual. Everything is fairly
bone dry you might say. Im glad its not work.

I had a similar idea about randomly scattering pile objects towards a
point the way accumulations tend to get. I have a function that given a
point a and b and a quantum returns another point closer to a from b
based on the quantum. If i ever decide to allocate some additional space
tote effort i could propagate theae quanta to other spaces and variegate
the distrivution of the piles. But i could schlock it and make the
number of objects there the needed mass to attract to. Only problem is
te piles will tend to create a brick or pebble in the raster. Grand idea
though scattering the edes of your piles like that. Great minds.

One hangup im having is how ive taken a simple design where a byte
represents one of 255 unique object 'types', a fairly omnipotent design
from narrative point of view, and graduated it so that instead there is
an object space pbviously unique per level with up to 254 different
delimiters representing differences between piles sizes zero to
sizeofarray. Sizeofarray has me hung a bit. Um gotta ut it short

Types of object are freely expandable before te source is compiled as of
now and im workung on how to offer that u p as metadara.

See im actually abandoing the consteaints of my original design and
encompassig all of it in the engine i always wanted instead replete with
expandability. With what the college puts on my plate i could very well
offer it in flash script by te emd of everytbing.

This summershould see m y macro-able engine ready with a demo. But
everything has to be so porta le, so oldschool and so resource
constrained ( ultimate test bench will be an 80286)

Gottta go
--
blaaaahhhhhhhhhhhhhaaaaaaaaaahaaaahaaahah

Reply all
Reply to author
Forward
0 new messages