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 :).
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!
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
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
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?
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.
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.
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.