Well, Im in before the deadline, I could have spent a few more hours testing/balancing but I'm done..
I cranked this sucker out so most of the code lies within main.c/dungeon.c there is support code I pulled from cnc like my memory management code, astar. It uses libfov, libtcod (+sdl), etc.
The game was designed to kinda play like the original rogue, but without the food factor.
The name was supposed to be in the spirit of the Amulet of Yendor / Rodney... Wizardry / Trebor + Werdna...
Rawdin.. Darwin.. only the strong survive...
blah. cheesy I know.
What didn't make it into the game in time... Quite a few things actually...
The biggest omission was the lack of better magics, and there is no ranged anything. It is all bump combat.
Scrolls and Potions are limited and mostly gimicky but some really do help (cure poison, poison resistance, etc.)
Some of the buffs didnt get used...
If it were continued the todo list would be;
Finish the attributes that were half done - Fire / Ice / Acid - More items - More monsters - Lessen the AStar affect (astar pathing makes it overwhelming/too precise) - Ranged weapons/magic?
Dragons on level 10 need to be buffed up a bit more too.
Thoughts... I did initial design for fire/ice and other stuff but didnt really get around to using them in game. ASTAR makes life hard, as in all the monsters on the map with astar flag beeline to you and suddently your surrounded by 10 enemies and nowhere to go....
LibTCOD has some odd designs.. To print a single char you need 3 function calls (char, foreground + background colours).. Then there is the whole pile of crap that is the TCOD_BKGND_SET flag stuff, set/none/add/blah, but that is just me. Console emulator doesnt give you proper console colours... where is brown? Cyan, light cyan, light green, etc. but hey, I do get 3 variations of yellow, 4 of red/orange. Oh there is a dark brown but its so close to black its worthless. Silver and Grey are so close there is little difference.. only 1 green?
Should at least give us the proper 16 colour defaults, then the extra's.
At least it has a rich set of functions for defining your own colors (Nice work there!).
To me it feels backwards (col,row), I'm too used to row,col calling, but thats a personal thing...
Redefines true/false (hello! super bad behaviour!!!) without using stdbool which is not what libfov expects... also means you cant include stdbool in your headers (and the header files are not properly extern'd for C usage)
All in all, these are just minor things easily fixed, despite this, jice did an amazing job on libtcod.
Things I should have done but didnt; Use offscreen buffers for message/stat window rather than redraw EVERYTHING every frame...
I came to like TCOD in the end after the intial cringe, so I might consider movinv CNC from my own SDL console emulation to use TCOD instead.
> LibTCOD has some odd designs.. To print a single char you need 3 > function > calls (char, foreground + background colours).. Then there is the > whole pile of > crap that is the TCOD_BKGND_SET flag stuff, set/none/add/blah, but > that is > just me.
To print a character on a console :
console.putChar(x,y,'@');
I can't hardly make it simpler. It will print with the default foreground/background color. (ok, I know, the C version needs another parameter...). But I see your point. Maybe something like putChar(x,y,c, foregroundColor) would be useful to display creatures/items. I'll add it in the next release.
> Should at least give us the proper 16 colour defaults, then the > extra's.
I didn't put the default 16 colors because they're ugly and every game using them make you blind after a few hours ;P
> To me it feels backwards (col,row), I'm too used to row,col calling, > but > thats a personal thing...
You mean y,x ? weird. Where did you get this habit ?
> Redefines true/false (hello! super bad behaviour!!!) without using > stdbool > which is not what libfov expects... also means you cant include > stdbool > in your headers
stdbool is not in Visual Studio, neither in Mingw. Why would you use a non portable header to replace a feature that is already implemented in a portable way in the library ?
> (and the header files are not properly extern'd for C > usage)
What do you mean ? Could you be more precise ?
> All in all, these are just minor things easily fixed, despite this, > jice did > an amazing job on libtcod.
o_O Pfeew, thanks ! At this point of your post, this was rather unexpected :)
On Feb 6, 3:52 pm, jice <jice.nos...@gmail.com> wrote:
> Ouch, I can't let that unpunished...
> > Should at least give us the proper 16 colour defaults, then the > > extra's.
> I didn't put the default 16 colors because they're ugly and every game > using them make you blind after a few hours ;P
I can understand that, but a few more standard greens, cyans etc ;)
> > To me it feels backwards (col,row), I'm too used to row,col calling, > > but > > thats a personal thing...
> You mean y,x ? weird. Where did you get this habit ?
Dunno, but I always think row/column rather than column/row and I awlays iterate row then column etc. I think its just personal habit.
> > Redefines true/false (hello! super bad behaviour!!!) without using > > stdbool > > which is not what libfov expects... also means you cant include > > stdbool > > in your headers
> stdbool is not in Visual Studio, neither in Mingw. Why would you use a > non portable header to replace a feature that is already implemented > in a portable way in the library ?
stdbool is c99 so it should be in any c compiler thats 'modern'. I know gcc has but (mingw is so antiquated and crap tho, but I see they are working on a new version...).
> > (and the header files are not properly extern'd for C > > usage)
you also stick an underscore at the start of your defines which are supposed to designate compiler reserved defines only (i do this a lot anyway), this is just an FYI. so #define _TCOD_PATH_H should really be #define TCOD_PATH_H, etc.
> > All in all, these are just minor things easily fixed, despite this, > > jice did > > an amazing job on libtcod.
> o_O Pfeew, thanks ! At this point of your post, this was rather > unexpected :)
I'm debating converting cnc to use it over my own SDL console emulator. most of my issues are personal/habits rather than technical against it.
On 6 fév, 22:56, stu <yakumo9...@gmail.com> wrote:
> On Feb 6, 3:52 pm, jice <jice.nos...@gmail.com> wrote:
> > I didn't put the default 16 colors because they're ugly and every game > > using them make you blind after a few hours ;P
> I can understand that, but a few more standard greens, cyans etc ;)
Ok, fair enough. I'll try to put more default colors to cover at least most basic colors.
> stdbool is c99 so it should be in any c compiler thats 'modern'. > I know gcc has but (mingw is so antiquated and crap tho, but I see > they are working on a new version...).
I would probably have used it, but since Visual Studio and MINGW, the best free compilers on windows IMHO, don't support it... If every C compiler was C99 compliant, life would be a blessing...
I already have this in libtcod.h, which includes all the other files. In fact, I should even completely remove the ifdefs in the inner files. I keep putting them by habit...
Anyway, I'm glad you finally like the library. If some other features seem particularly tedious to you, let me know.
> On 6 fév, 22:56, stu <yakumo9...@gmail.com> wrote:
> > On Feb 6, 3:52 pm, jice <jice.nos...@gmail.com> wrote:
> > > I didn't put the default 16 colors because they're ugly and every game > > > using them make you blind after a few hours ;P
> > I can understand that, but a few more standard greens, cyans etc ;)
> Ok, fair enough. I'll try to put more default colors to cover at least > most basic colors.
> > stdbool is c99 so it should be in any c compiler thats 'modern'. > > I know gcc has but (mingw is so antiquated and crap tho, but I see > > they are working on a new version...).
> I would probably have used it, but since Visual Studio and MINGW, the > best free compilers on windows IMHO, don't support it... If every C > compiler was C99 compliant, life would be a blessing...
As far as MingW: *WRONG*, did you actually try it? Both MingW 3.4.5 and MingW 4.2.1 ship with stdbool.h , it's just in the fixincludes header section ( .../lib/gcc/...) rather than the usual includes location (.../include/....)
Furthermore, it's a relatively easy header to reimplement. I see nothing wrong with providing a mocked-up stdbool.h for unmaintained or intentionally obsolete compilers to use, that is "out of line" of the normal build process.
> On Feb 6, 5:00 pm, jice <jice.nos...@gmail.com> wrote:
> > On 6 fév, 22:56, stu <yakumo9...@gmail.com> wrote:
> > > On Feb 6, 3:52 pm, jice <jice.nos...@gmail.com> wrote:
> > > > I didn't put the default 16 colors because they're ugly and every game > > > > using them make you blind after a few hours ;P
> > > I can understand that, but a few more standard greens, cyans etc ;)
> > Ok, fair enough. I'll try to put more default colors to cover at least > > most basic colors.
> > > stdbool is c99 so it should be in any c compiler thats 'modern'. > > > I know gcc has but (mingw is so antiquated and crap tho, but I see > > > they are working on a new version...).
> > I would probably have used it, but since Visual Studio and MINGW, the > > best free compilers on windows IMHO, don't support it... If every C > > compiler was C99 compliant, life would be a blessing...
> As far as MingW: *WRONG*, did you actually try it? Both MingW 3.4.5 > and MingW 4.2.1 ship with stdbool.h , it's just in the fixincludes > header section ( .../lib/gcc/...) rather than the usual includes > location (.../include/....)
> Furthermore, it's a relatively easy header to reimplement. I see > nothing wrong with providing a mocked-up stdbool.h for unmaintained or > intentionally obsolete compilers to use, that is "out of line" of the > normal build process.
mmh I'm using mingw 3.1.0 and I've always been afraid of upgrading it... Maybe I should after all... My previous attempts were not really successes. Anyway you must agree that's a lot of talk for a small line of code that compiles on every C compiler on the planet... i'll protect it to make it compatible with stdbool libraries
jice <jice.nos...@gmail.com> wrote: >stu a =E9crit : >> To me it feels backwards (col,row), I'm too used to row,col calling, >> but thats a personal thing...
>You mean y,x ? weird. Where did you get this habit ?
I have the same habit; I picked it up from curses, which uses that ordering for positional coordinates. It happens to also reflect the way linear framebuffers are stored in memory - one line at a time. -- \_\/_/ turbulence is certainty turbulence is friction between you and me \ / every time we try to impose order we create chaos \/ -- Killing Joke, "Mathematics of Chaos"
On Feb 6, 6:23 pm, jice <jice.nos...@gmail.com> wrote:
> mmh I'm using mingw 3.1.0 and I've always been afraid of upgrading > it... Maybe I should after all... My previous attempts were not really > successes.
I see. I don't have a canonical install (the binary installers tend to crash on Win95, so I have to install everything from tarballs to ensure identical system configurations across Win95, Win2000, and Vista), but I generally find that unpacking the new compiler into its own directory and renaming directories around lets me try out new versions safely.
> Anyway you must agree that's a lot of talk for a small line of code > that compiles on every C compiler on the planet... i'll protect it to > make it compatible with stdbool libraries
> On Feb 6, 6:23 pm, jice <jice.nos...@gmail.com> wrote:
> > mmh I'm using mingw 3.1.0 and I've always been afraid of upgrading > > it... Maybe I should after all... My previous attempts were not really > > successes.
> I see. I don't have a canonical install (the binary installers tend > to crash on Win95, so I have to install everything from tarballs to > ensure identical system configurations across Win95, Win2000, and > Vista), but I generally find that unpacking the new compiler into its > own directory and renaming directories around lets me try out new > versions safely.
> > Anyway you must agree that's a lot of talk for a small line of code > > that compiles on every C compiler on the planet... i'll protect it to > > make it compatible with stdbool libraries
I had a look at your sources and here are a few remarks that might ease your dev the next time you use libtcod :
#if defined(WIN32) || defined(__WIN32__) libtcod gives you compiler dependant macros to ease this sort of conditional code : WIN32/LINUX MINGW32/VISUAL_STUDIO
system_startup function : if you want the current desktop resolution, you'd better use : TCOD_sys_get_current_resolution(int *width, int *height) It would have make your auto-font selection feature work on linux too.
ClearKeyBuffer(); key = TCOD_console_wait_for_keypress(true); With true as flush parameter, wait_for_keypress should already clear the key buffer.
Anyway, that's a pretty impressive amount of work. Congratulations. You also forget to mention it was real time.
jice wrote: > Ouch, I can't let that unpunished...
> stu a écrit :
>> LibTCOD has some odd designs.. To print a single char you need 3 >> function >> calls (char, foreground + background colours).. Then there is the >> whole pile of >> crap that is the TCOD_BKGND_SET flag stuff, set/none/add/blah, but >> that is >> just me.
> To print a character on a console :
> console.putChar(x,y,'@');
> I can't hardly make it simpler. It will print with the default > foreground/background color. (ok, I know, the C version needs another > parameter...).
/* during initialization. The tile for this is a white '@' on a black background with no other attributes. */ playermob.ch = Define_Tile( '@', COLOR_WHITE, COLOR_BLACK, ATTR_NONE); ..... /* whenever we want to print it*/ printmob(playermob, x, y);
That way the character, background color, foreground color, and attributes are all part of the tile and as programmer you don't have to worry about them again once you define them.
>> To me it feels backwards (col,row), I'm too used to row,col calling, >> but >> thats a personal thing...
> You mean y,x ? weird. Where did you get this habit ?
Heh. From using ncurses, probably. Or the C system calls for graphics, or virtually anything to do with computer graphics ... where did you get the other habit??
>> Redefines true/false (hello! super bad behaviour!!!) without using >> stdbool >> which is not what libfov expects... also means you cant include >> stdbool >> in your headers
> stdbool is not in Visual Studio, neither in Mingw. Why would you use a > non portable header to replace a feature that is already implemented > in a portable way in the library ?
Uh, practically everybody doing Linux development uses stdbool. I don't know how it is in the Windows universe, but for linux it's considered a flatly basic header, almost at the level of stdio.h. The answer is they were using it before they even considered linking your library. If this is true it really needs to be fixed.
I gave this a play for 45 minutes or so. Congrats to the author for quite a polished game - a lot done in 7 days. I liked the dungeons which were large without being too big. I only got to dungeon level 4 but the selection of items etc. was quite good although I found it difficult to figure out what the effects of each were (apart from the Magic Mapping potion which was ace). Unfortunately once I finally got down to level 4, I was swarmed by 6 A* lizardmen in a tiny room with only one exit which was the end of me.
The realtime nature of the game gives it a fairly fast pace. However, there are two things which I think really detracted from this. Firstly, the resting system where you have to stand still for 20, 30 seconds of real time to heal and which is the only practical way of gaining hitpoints. This was no fun, particularly in a fast-paced game. The first couple of times I played, I didn't know about resting and played without it which I rather preferred (although I died quickly). Secondly, combat with some creatures (orcs, kobolds) takes a long time, of order 50 turns. This also slows the game down and means that one doesn't read the combat messages because there are too many of them.
So, good game, would be great with faster combat and maybe an 'auto- rest' key.
jice <jice.nos...@gmail.com> wrote: >Anyway you must agree that's a lot of talk for a small line of code >that compiles on every C compiler on the planet... i'll protect it to >make it compatible with stdbool libraries
That won't work. The preprocessor doesn't process typedefs. Since stdbool.h is a feature of C99, you can use this instead:
#if (!defined(__STDC_VERSION__) || (__STDC_VERSION__ < 199901L) typedef enum { false, true } bool; #else #include <stdbool.h> #endif -- \_\/_/ turbulence is certainty turbulence is friction between you and me \ / every time we try to impose order we create chaos \/ -- Killing Joke, "Mathematics of Chaos"
/* Time to define bool */ #ifdef __cplusplus /* do nothing - it's a builtin type in C++ */ #elif (!defined(__STDC_VERSION__) || (__STDC_VERSION__ < 199901L)) /* bool isn't in the library or the builtins on C89 */ typedef enum { false, true } bool; #else /* C99 or later - bool is in stdbool.h */ #include <stdbool.h> #endif
and the really robust version is:
#ifdef __cplusplus typedef bool TCODbool; #elif (!defined(__STDC_VERSION__) || (__STDC_VERSION__ < 199901L)) /* bool isn't in the library or the builtins on C89 */ typedef enum { false, true } TCODbool; #else /* C99 or later - bool is in stdbool.h */ #include <stdbool.h> #endif
and use TCODbool everywhere you currently use bool, so that if some *other* library defines bool-for-C89 in *its* headers, nothing explodes. -- \_\/_/ turbulence is certainty turbulence is friction between you and me \ / every time we try to impose order we create chaos \/ -- Killing Joke, "Mathematics of Chaos"
> /* Time to define bool */ > #ifdef __cplusplus > /* do nothing - it's a builtin type in C++ */ > #elif (!defined(__STDC_VERSION__) || (__STDC_VERSION__ < 199901L)) > /* bool isn't in the library or the builtins on C89 */ > typedef enum { false, true } bool; > #else > /* C99 or later - bool is in stdbool.h */ > #include <stdbool.h> > #endif
> and the really robust version is:
> #ifdef __cplusplus > typedef bool TCODbool; > #elif (!defined(__STDC_VERSION__) || (__STDC_VERSION__ < 199901L)) > /* bool isn't in the library or the builtins on C89 */ > typedef enum { false, true } TCODbool; > #else > /* C99 or later - bool is in stdbool.h */ > #include <stdbool.h> > #endif
> and use TCODbool everywhere you currently use bool, so that if some > *other* library defines bool-for-C89 in *its* headers, nothing explodes.
> > I'm an idiot, since that doesn't check for C++.
> > The cheap version is:
> > /* Time to define bool */ > > #ifdef __cplusplus > > /* do nothing - it's a builtin type in C++ */ > > #elif (!defined(__STDC_VERSION__) || (__STDC_VERSION__ < 199901L)) > > /* bool isn't in the library or the builtins on C89 */ > > typedef enum { false, true } bool; > > #else > > /* C99 or later - bool is in stdbool.h */ > > #include <stdbool.h> > > #endif
> > and the really robust version is:
> > #ifdef __cplusplus > > typedef bool TCODbool; > > #elif (!defined(__STDC_VERSION__) || (__STDC_VERSION__ < 199901L)) > > /* bool isn't in the library or the builtins on C89 */ > > typedef enum { false, true } TCODbool; > > #else > > /* C99 or later - bool is in stdbool.h */ > > #include <stdbool.h> > > #endif
> > and use TCODbool everywhere you currently use bool, so that if some > > *other* library defines bool-for-C89 in *its* headers, nothing explodes.
> mmh why so complicated ?
Familiarity obscures the complexity of what you are insisting on: the exact same design error that PDCurses 3.4 has regarding bool. It's bad enough that I just fork PDCurses and fix it, as the X/Open curses spec appears to require this design error.
> And it works (at least it compiles) when including stdbool.h before > libtcod.h.
Sadly, C99 grants an explicit license to #undef and subsequently redefine the true, false, and bool macros defined in stdbool.h without invoking undefined behavior like #undef'ing *any* other identifier defined (either by macro or more normally) in a system header.
So the above is required the work, regardless of its lack of wisdom.
On Feb 7, 4:50 am, flend <flendn...@googlemail.com> wrote:
> I gave this a play for 45 minutes or so. Congrats to the author for > quite a polished game - a lot done in 7 days. I liked the dungeons > which were large without being too big. I only got to dungeon level 4 > but the selection of items etc. was quite good although I found it > difficult to figure out what the effects of each were (apart from the > Magic Mapping potion which was ace). Unfortunately once I finally got > down to level 4, I was swarmed by 6 A* lizardmen in a tiny room with > only one exit which was the end of me.
thanks for playing. The A* is... too precise. I tried to implement things gradually (ie: the first A* monster you encounter is just an orc with no specials, later on some A* get poison inducement attempt 1 every N rounds, etc).
> The realtime nature of the game gives it a fairly fast pace. However, > there are two things which I think really detracted from this. > Firstly, the resting system where you have to stand still for 20, 30 > seconds of real time to heal and which is the only practical way of > gaining hitpoints. This was no fun, particularly in a fast-paced game.
The resting is really only workable on levels 1 or 2. I had hoped by that time the player would have a few scrolls of healing or poitions of healing or would have armour strong enough to withstand most attacks.
> The first couple of times I played, I didn't know about resting and > played without it which I rather preferred (although I died quickly). > Secondly, combat with some creatures (orcs, kobolds) takes a long > time, of order 50 turns. This also slows the game down and means that > one doesn't read the combat messages because there are too many of > them.
yeah, combat can be slow if your weapon is underpowered. eg: kobolds on level 1+2 are mostly resistant to the knife, you really need a short sword or better against kobolds.
It also depends on your skill level. The game uses the common stat+skill+1D20 method.
so strength+melee+1d20 vs dexterity+defense+1d20 for a hit.
(1 stat and 1 skill will be randomly picked to increase each time you level up, plus some poitions/scrolls will do stat increases....)
most item drops are set for level ranges, and should correspond to the defense of the monsters on those levels type deal, which is why you wont see a crytal knife on level 1 for example, or a blood priest on level 1.
> So, good game, would be great with faster combat and maybe an 'auto- > rest' key.
I'll note the auto-rest function, and I think it really needs to be reduced in time, and making it a bit more useful on lower levels.
The game needs to drop more potions of healing and remove poison or poison resistance etc to make it fairer on the player.
At Sun, 8 Feb 2009 06:54:34 -0800 (PST), stu wrote:
> On Feb 7, 4:50 am, flend <flendn...@googlemail.com> wrote: > most item drops are set for level ranges, and should > correspond to the defense of the monsters on those levels > type deal, which is why you wont see a crytal knife on level 1 > for example, or a blood priest on level 1.
Just a random thought, but maybe it would be better to lower the item levels by one? For example, you have a chance of finding a weapon you will need at the next level...
cheers mate. Thanks for the review, I appreciate it. There is a new release in the wings that will address most of the issues raised in your review and some more.
