[1kBRL] Another Visit In Hell

133 views
Skip to first unread message

Jakub Wasilewski

unread,
Sep 28, 2009, 3:08:24 PM9/28/09
to
Seeing that interest in 1kB roguelikes has gone up again, I returned
to my original C+curses 1kBRL ("A Journey To Hell") to see if I could
improve upon it further. It turns out that I was incredibly wasteful
with the source code, allowing me to cut 87 bytes without removing any
features.

87 bytes is a lot, so I made a sequel. Just like the first game I was
aiming to make a game that would have as many traditional roguelike
elements as possible. Just like the first game, it has:
- randomly generated, guaranteed traversable levels
- fully functional true line of sight
- coloured graphics
- simple character progression (max HP increasing)
- multiple dungeon levels getting progressively harder
- collectable gold
- pickup-able items
- monsters with somewhat competent AI - will chase you, won't get
stuck on walls (too often, at least)
- winning condition and death

New stuff:
- monster leave weapons that affect the amount of damage you dish out
- character memory - the parts of the dungeon you visited are
remembered

I've thrown out one boring feature that was in AJTH: chests. Hope
nobody misses them much.

This is the most I was able to manage in 1024 bytes, and I don't think
I can go any further. Shortening the current version by 80 bytes
without removing features would be a small miracle, I think :).

The roguelike is here:
http://wasyl.eu/storage/avih-1-0.tar.gz
http://wasyl.eu/storage/avih-1-0.zip

The 1024-byte version compiles cleanly under most Linuxes. There is a
"safe" version included that allows AVIH to be compiled under Windows
(with MinGW+PDCurses) and fussy Linux systems.

Comments appreciated :).

Jakub Wasilewski

unread,
Sep 28, 2009, 8:22:49 PM9/28/09
to
As usual, immediately after releasing a version on the newsgroup, I
got an idea that allowed me to make it better. I managed to cut down
the dungeon memory implementation by 16 bytes, while simultaneously
making it a little better! All item positions are now shown -- the old
implementation only showed walls and staircases.

As it turns out, 16 bytes was just enough to implement one more
feature I wanted to get in: attack preparation. You are now able to
prepare for an attack by standing still for a turn. A prepared attack
deals +1 bonus damage to your foes, in addition to the usual weapon
damage.

So, here is an updated version:

http://wasyl.eu/storage/avih-1-1.tar.gz
http://wasyl.eu/storage/avih-1-1.zip

Have fun!

Numeron

unread,
Sep 28, 2009, 11:59:19 PM9/28/09
to

You're LOS and map generation are very impressive, damned if I can
figure out how you did LOS even looking at your commented code, but
then again my own is almost at the point where I dont understand that
either lol.

-Numeron

Nik Coughlin

unread,
Sep 29, 2009, 6:50:41 PM9/29/09
to
"Jakub Wasilewski" <kraj...@gmail.com> wrote in message
news:bc920e07-c9f6-49f4...@k17g2000yqb.googlegroups.com...

> Seeing that interest in 1kB roguelikes has gone up again, I returned
> to my original C+curses 1kBRL ("A Journey To Hell") to see if I could
> improve upon it further.
>
> Comments appreciated :).

Extremely impressive, all those features and it's fun too!

At first I couldn't figure out how you squeezed it all in, but looking at
the source my long buried memories of using C all came flooding back :)

I think C is ideally suited to terseness; weak typing, define, bitwise
operators etc. etc.

I have a couple of questions that I'd like to ask about some of the weirder
stuff that you're doing if you don't mind. Will post later on when I have
time to look at the source again.

Jotaf

unread,
Sep 29, 2009, 9:32:13 PM9/29/09
to
The LOS blew me away too, but so did all the other features - I still
can't believe it's all there, you must be accessing an OS function
like "launch_roguelike()" or something :P

Jotaf

Nik Coughlin

unread,
Sep 30, 2009, 12:51:58 AM9/30/09
to

"Nik Coughlin" <nrkn...@gmail.com> wrote in message
news:h9u2v4$6i6$1...@news.eternal-september.org...

1). What does this do?

k[]=L"$`*$.@`>$]```"

I'd get it if it were just k[]="$`*$.@`>$]```", which I'd assume would mean
k is an array of int, so populate it with the string (an array of char, and
char with weak typing is an int anyway), so it would end up being:

k[0]=36, k[1]=96, k[2]=42 etc.

But what does it do when you prefix the string with another (uninitialized)
int, in this case L?

Dirk Zimmermann

unread,
Sep 30, 2009, 3:30:10 AM9/30/09
to
On Sep 30, 12:51 am, "Nik Coughlin" <nrkn....@gmail.com> wrote:
> "Nik Coughlin" <nrkn....@gmail.com> wrote in message
>
> news:h9u2v4$6i6$1...@news.eternal-september.org...
>
>
>
> > "Jakub Wasilewski" <krajz...@gmail.com> wrote in message

A L"" is a wide char string literal. When I remember correctly this
should mean 16 bit (Unicode), something like short int on most 32-bit
compilers.

Dirk Zimmermann

unread,
Sep 30, 2009, 3:43:45 AM9/30/09
to

Just checked on my platform (gcc 4.0.1 for i686-apple-darwin9):
Wide chars are presented by wchar_t and they are 4 bytes, so this fits
nicely into the int array.

Jakub Wasilewski

unread,
Sep 30, 2009, 6:23:14 AM9/30/09
to

> 1). What does this do?
>
> k[]=L"$`*$.@`>$]```"
>
> I'd get it if it were just k[]="$`*$.@`>$]```", which I'd assume would mean
> k is an array of int, so populate it with the string (an array of char, and
> char with weak typing is an int anyway), so it would end up being:

Dirk is correct - the L just means it's a wide-char unicode literal.
The values of ASCII chars stay the same in Unicode, but the unicode
array has a big advantage - it can be used to initialize an int array
thanks to compatible sizes (on every 32-bit Linux, at least). If it
wasn't for that trick, I'd have to use a separate declaration, wasting
6 bytes to say "char ...;" - trying to initialize an int array with an
ASCII string results in an error (on my GCC, at least).

> I have a couple of questions that I'd like to ask about some of the weirder
> stuff that you're doing if you don't mind.

No problem, ask away.

> You're LOS and map generation are very impressive, damned if I can
> figure out how you did LOS even looking at your commented code, but
> then again my own is almost at the point where I dont understand that
> either lol.

Well, the comments mostly serve the purpose of allowing me not to get
lost in the source code myself, so they might not be all that helpful
- especially since some of them might be outdated after the 1.1
update.

The actual LOS is just one line:

F(c,u)d[f+(x-f)*c/u][g+(y-g)*c/u]-35||(b=1);

This casts a ray from [f,g] (the players position) to [x,y] (the
position of the tile under scrutiny). The F(c,u) for loop (equivalent
to for(c=0;c<96;c++)) examines consecutive tiles on the ray (some of
them multiple times, usually, especially if the distance is short). If
a wall ('#' or 35) is encountered on the way, the colour the tile to
be drawn in (b) is changed to 1. Color 1 is previously initialized to
black on black, so this should be invisible.

Reply all
Reply to author
Forward
0 new messages