CryptRL 0.6340 first ASCII release
Crypt
You can choose between three differents versions without having to download
anything else:
- normal version (with sounds and tiles but without the bonus sounds) = 15.4mg
- or NoSound version = 3.5mg
- or NoSound_NoTile version = 1 mg (the one which could interessed peoples
here)
OPTIONS (None of the following files are required) :
If you download bonusSounds.zip, unpack it in the \sons\ambiance\ folder.
If you download the NoSound version you can download sounds.zip and unpack it in
\cryptrl\
If you download the NoSound and NoTile version you can download sounds.zip and
images.zip and unpack them in \cryptrl\
This the first ASCII release of CryptRL. The ascii symbols selection is not
final, i will probably make color and symbols modifications.
Any feedback appreciated.
Crypt
Three issues i will correct in future releases =
- in Ascii mode the potions of hallucination have no effects (except music and
items names in equipment)
- Ascii mode tends to be slower than Tiles mode (i know why)
- NoTile version : equiped weapons and armors are not displayed in the inventory
panel (because it uses tiles)
Note:
Clicking (using mouse) on a item or creature on the map panel is very useful in
ASCII mode because it display the (known) name of what you click on.
Crypt
Issue :
In ASCII mode the "out of bounds" random dungeon generator bug is even more
confusing than in Tiles mode.
This old issue will be fix in futures releases.
Crypt
In the majority of roguelike the ground discovered by @ is kept displayed even
if it's out of LOS range.
In the current version of CryptRL, what is displayed is only what @ can see.
(but visited places are kept displayed in the minimap)
What do you prefer ?
Radomir 'The Sheep' Dopieralski
Crypt wrote:
> Any feedback appreciated.
Yay! A free epilepsy test! :D
Those thin letters in mad-fruit-salad colors on an animated
background with the screen flashing once in a while. Beautiful.
Can't say much about tha game, I only endured it for several
seconds. :(
--
Radomir `The Sheep' Dopieralski
"Computer Science is no more about computers than
astronomy is about telescopes." [Edsger Wybe Dijkstra]
Crypt
wrote:
The flash is storm.
You can remove the rain by using the menu (rain on / off.)
One more second and you'd found that...
Note: the storm flash will be removed by using the rain on/off menu item in next
release.
Crypt
wrote:
> At Sun, 13 Aug 2006 21:33:29 +0000 (UTC),
A "for your eyes" less epilectic version (with some other modifications) is
uploaded (0.6343)
Hope it will help you test it more than a few seconds.... ;)
Radomir 'The Sheep' Dopieralski
Crypt wrote:
> On 2006-08-14 15:07:13, Radomir 'The Sheep' Dopieralski <ne...@sheep.art.pl>
> wrote:
>> At Sun, 13 Aug 2006 21:33:29 +0000 (UTC),
>> Crypt wrote:
>> > Any feedback appreciated.
>> Yay! A free epilepsy test! :D
>> Those thin letters in mad-fruit-salad colors on an animated
>> background with the screen flashing once in a while. Beautiful.
>>
>> Can't say much about tha game, I only endured it for several
>> seconds. :(
> A "for your eyes" less epilectic version (with some other modifications) is
> uploaded (0.6343)
>
> Hope it will help you test it more than a few seconds.... ;)
That's much better, thank you.
Tried it several times, but never got too far, as any creature I met
killed me in several turns. I managed to kill the wolf once, using the
scroll, and got 3k xp and an instant level up.
The game is confusing -- part of it may be the (non-roguelike) characters
used and the lack of any kind of look command.
I spent some time trying to attack a boulder, for example, and swearing
because it just moved away. Then I spent several minutes looking for an
'attack' command.
The messages are not very informative either. They say that 'it is hit'
or that there is so much damage, but don't say what "it" is and what is
damaged, for example.
Minimap seems disfunctional in the ascii mode?
The characters change their color to red randomly. This is confusing.
Generally, I must say it's generally very confusing. I didn't find
any game to play in it -- is it really a game or just an engine test?
Crypt
> That's much better, thank you.
>
> Tried it several times, but never got too far, as any creature I met
> killed me in several turns. I managed to kill the wolf once, using the
> scroll, and got 3k xp and an instant level up.
the xps number to level up is still to be balanced
>
> The game is confusing -- part of it may be the (non-roguelike) characters
> used and the lack of any kind of look command.
As i said previously you can "look" by using your MOUSE and clicking on what you
want to look at.
If you check the shortcuts you will see : "mouse click on map : farlook."
I will add a pure keyboard farlook command if needed.
>
> I spent some time trying to attack a boulder, for example, and swearing
> because it just moved away. Then I spent several minutes looking for an
> 'attack' command.
As in the majority of roguelikes there is no need for an attack command because
"moving is attacking." But this is only true for attacking beings.
But i agree with the fact that the ascii symbol of boulders should not be 'o' if
we consider that alphabetical letters are only for creatures. (the same is true
for levers, activable teleporters, etc)
As boulders (and walls, and statues, etc) are not living things you cannot
attack them by moving on them. If you move on a boulder or statue you will push
it (depending on its weight and your strength.)
You can KICK (k) them, APPLY (a) a pick on them, THROW (f) something (eg. a
mine, a spell, or anything etc) on them.
>
> The messages are not very informative either. They say that 'it is hit'
> or that there is so much damage, but don't say what "it" is and what is
> damaged, for example.
>
when ?
I don't understand you. In melee attack both the attacker and defender are named
in the messages.
eg ."A wolf hits A sheep (dmg:5)"
About the big damage numbers = Please forgot D&D combats.
All the die rolls are open-ended.
Both the PC and the Creatures can do positive open-ended rolls. (as i'm a
Rolemaster gamemaster there is no chance i will change that. But i can change
the probability of getting a open ended roll quite easily if need.)
> Minimap seems disfunctional in the ascii mode?
>
what do you mean ? The minimap gives a representation of all the current map,
not only the shown part in the center panel. (please note that the minimap
would be desactivated if you turn off the LOS.)
> The characters change their color to red randomly. This is confusing.
Not randomly.
They become red because there is blood here. (will be fixed)
Heavily damaged creatures leave a blood trail.
Killed creatures splash blood on nearby obstacles (walls, statues, etc)
All blood disapears with time.
>
> Generally, I must say it's generally very confusing. I didn't find
> any game to play in it -- is it really a game or just an engine test?
>
As i already said this is an Alpha =>
-no quest yet
-only a few spells, scrolls effects, creatures, etc
-no city yet
-the creatures IA is still limited to
---checking surroundings /
---recognizing ennemies /
---moving /
---melee attack/
---flee / (not all races flee)
---follow /
---open doors /
Obviously, because the game was first in Tiles mode since november 2005 there
are still improvements to do in order to get a not confusing Ascii mode.
Only the far future 1.0 version could be called "a game." (in months ,
years.....)
Crypt
> because it just moved away. Then I spent several minutes looking for an
> 'attack' command.
After playing ZDay (more than a few seconds ;) ) i understand why CrypRL
commands are confusing you.
CryptRL commands are closer to NetHack commands than to ZDay's ones.
(nothing negative here, ZDay is a nice game, but the ergonomy is very
different)
Radomir 'The Sheep' Dopieralski
Crypt wrote:
About using a mouse for look -- I don't have mouse on this box :)
>> The messages are not very informative either. They say that 'it is hit'
>> or that there is so much damage, but don't say what "it" is and what is
>> damaged, for example.
> when ?
> I don't understand you. In melee attack both the attacker and defender are named
> in the messages.
> eg ."A wolf hits A sheep (dmg:5)"
I think it was when I used the scroll to attack a boulder.
I only said something about 'structural damage', whatever it is.
Nothing about any boulders -- that's why I went on attacking it in melee.
And the messages when I pushed it also didn't reaveal its nature.
> About the big damage numbers = Please forgot D&D combats.
> All the die rolls are open-ended.
I didn't say anything about big damage numbers. I don't mind them.
>> Minimap seems disfunctional in the ascii mode?
> what do you mean ? The minimap gives a representation of all the current map,
> not only the shown part in the center panel. (please note that the minimap
> would be desactivated if you turn off the LOS.)
It just shows all blue, and becomes black when I move around, but nothing
on it.
> As i already said this is an Alpha =>
Ah, for an alpha it's very good :).
One advice I could give is to try to actually write a small but playable
(winnable) game, so that you can test the new features also in terms of
gameplay.
> Obviously, because the game was first in Tiles mode since november 2005 there
> are still improvements to do in order to get a not confusing Ascii mode.
Yes, it shows. Maybe I should download the graphical version? And find
a mouse...
> Only the far future 1.0 version could be called "a game." (in months ,
> years.....)
:(
Radomir 'The Sheep' Dopieralski
Crypt wrote:
It was an experiment, and it turned out pretty neat, I think.
I woudn't use this in a large roguelike, however.
btw, the key bindings are not what confused me. I just thought that if
the default action on bumping is pushing, then obviously there must be
a command to attack (I planned to have a separate command for a melee
attack myself). I took me a while to even think about the 'o' not being
a monster. :)
Crypt
wrote:
> At Mon, 14 Aug 2006 16:52:06 +0000 (UTC),
> Crypt wrote:
>
>
> About using a mouse for look -- I don't have mouse on this box :)
ok, ok, understood, i will add a keyboard farlook command.
>
> >> The messages are not very informative either. They say that 'it is hit'
> >> or that there is so much damage, but don't say what "it" is and what is
> >> damaged, for example.
> > when ?
> > I don't understand you. In melee attack both the attacker and defender are named
> > in the messages.
> > eg ."A wolf hits A sheep (dmg:5)"
>
> I think it was when I used the scroll to attack a boulder.
> I only said something about 'structural damage', whatever it is.
> Nothing about any boulders -- that's why I went on attacking it in melee.
> And the messages when I pushed it also didn't reaveal its nature.
>
ok, i see, i add that on my ToDo list.
> > About the big damage numbers = Please forgot D&D combats.
> > All the die rolls are open-ended.
>
> I didn't say anything about big damage numbers. I don't mind them.
> >> Minimap seems disfunctional in the ascii mode?
> > what do you mean ? The minimap gives a representation of all the current map,
> > not only the shown part in the center panel. (please note that the minimap
> > would be desactivated if you turn off the LOS.)
>
> It just shows all blue, and becomes black when I move around, but nothing
> on it.
the minimap only shows obstacles (red), the character (white) and stairs
(green.)
blue is for unknown areas.
Just move a few steps north and you will (should) see a red structure appears on
the minimap.
>
> > As i already said this is an Alpha =>
>
> Ah, for an alpha it's very good :).
> One advice I could give is to try to actually write a small but playable
> (winnable) game, so that you can test the new features also in terms of
> gameplay.
Yes i think you're right. But i must add some features before doing that, IMO.
>
> > Obviously, because the game was first in Tiles mode since november 2005 there
> > are still improvements to do in order to get a not confusing Ascii mode.
>
> Yes, it shows. Maybe I should download the graphical version? And find
> a mouse...
I will improve the ascii/no mouse features.
...but maybe you could give a try to the Tiles+Sound version ;) That's my
favorite one.
>
> > Only the far future 1.0 version could be called "a game." (in months ,
> > years.....)
>
> :(
>
In fact i see that i 've never explained my goal for this project =>
- open-ended / never ending play.
- infinite world.
- strong interactions with surroundings (like in NH/Slash'Em) because my main
goal is the tactic features.
- easy to made addons. I've planned to make special levels. One of them would be
a zombie hunting area with tactical features like in Zombie Nightmare (
http://www.codedread.com/games.php) or some sort of a Romero JaggedAlliance mix
but with RL gameplay.
Other special levels would be ghostbusters/haunting house levels, etc...
That why i didn't put CryptRL in the pure fantasy theme in RogueBasin.
I will put everything i like in this game.
So yes, we can consider CrypRL is still in on "Engine Development Status."
It will takes years to obtain a real game, probably.
Crypt
Done in the new uploaded version.
Brendan Guild
> http://cryptmaster.free.fr/
>
> You can choose between three differents versions without having to
> download anything else:
>
> - normal version (with sounds and tiles but without the bonus
> sounds) = 15.4mg
>
> - or NoSound version = 3.5mg
>
> - or NoSound_NoTile version = 1 mg (the one which could
> interessed peoples here)
[snip]
> Any feedback appreciated.
The version that I would most like to see would be one that is purely
source.
My roguelike development experience is on the software engineering
end. I have a dream of discovering the ideal internal design for a
roguelike game, something simple and yet flexible which allows a
simple game to be written quickly and a complicated game to be
written simply, or at least without rewrites.
That doesn't mean that I don't have ideas for the external design of
a roguelike as well (I have more than enough to fantasize over the
game that I will eventually create), but I won't feel proud of my
game unless it is so polished on the inside that it is a thing of
beauty. Unlike almost everything else in the world, my eventual
roguelike will be as nice on the inside as it is on the outside.
If you really mean that 'any' feedback is appreciated, then I would
be pleased to give you feedback on the insides of your game. Though I
am sure that is not what you had in mind and I would not be at all
surprised if that kind of feedback would be taken more personally
than general game comments.
As an alternative to releasing the source, I'm sure people would
appreciate a design document about the internal structure of the
game, even something highly abstract. Writing such a thing might even
improve the future design, just by focussing your mind on the issues
of how all the little pieces fit together.
Crypt
Sources files can be downloaded here =
http://cryptmaster.free.fr/cryptrl/CRYPT_RL/SAVES/
These are my saves = > "Normal" (tiles+sound so they weight a lot) version +
java files.
I will upload a nosound/notile version with the source files for the next
releases.
You will see that i don't use packages. I know this is evil but i started
without packages and it's a bit too late to add some now. It's not a problem
for me but i'm sure it will be very ambarassing for anyone else trying to look
inside my code. Sorry about that.
I've start learning programming in May 2005 and start CryptRL in november 2005.
I'm sure some parts of the code will appear a bit "newbie" to you while recent
ones are more sophisticated. I'm constantly hunting the old clumsy parts.
Slash
Crypt wrote:
> On 2006-08-15 07:18:10, Brendan Guild <do...@spam.me> wrote:
>
> > Crypt wrote in news:ebo5r9$gi0$1...@news.vol.cz:
> > > http://cryptmaster.free.fr/
> > >
SNIP
>
>
> You will see that i don't use packages. I know this is evil but i started
> without packages and it's a bit too late to add some now. It's not a problem
> for me but i'm sure it will be very ambarassing for anyone else trying to look
> inside my code. Sorry about that.
It is a very bad coding style, however if you use modern IDEs such as
Eclipse or NetBeans, you will find their refactoring tools very useful
for this, and eventually you will get your game packaged on a day or
less. It is really worth the effort, trust me! ;)
> I've start learning programming in May 2005 and start CryptRL in november 2005.
> I'm sure some parts of the code will appear a bit "newbie" to you while recent
> ones are more sophisticated.
> I'm constantly hunting the old clumsy parts.
We all are
--
Slash
[http://www.santiagoz.com]
Crypt
> Eclipse or NetBeans, you will find their refactoring tools very useful
> for this, and eventually you will get your game packaged on a day or
> less. It is really worth the effort, trust me! ;)
>
i will have a look to that
Crypt
I've uploaded a nosound notile source zip of the new version in
http://cryptmaster.free.fr/cryptrl/CRYPT_RL/
Ray Dillinger
> As an alternative to releasing the source, I'm sure people would
> appreciate a design document about the internal structure of the
> game, even something highly abstract. Writing such a thing might even
> improve the future design, just by focussing your mind on the issues
> of how all the little pieces fit together.
Hmmm....
A lot of it, I think, depends on the language you're using. For
example, a lot of the infrastructure I wrote would be superflous
in one of the higher-level languages that has, eg, garbage collection
and serialization support. But I'm doing the roguelike in plain C
just because I like the sheer low-level hardcore-ness of it, and in
a low-level language, you have to plan ahead for even things as
"simple" as memory management and serialization.
So as I've learned to write C (as opposed to Lisp or Scheme,
which I use at work) I've learned some disciplines for not getting
into memory-management trouble. The most important is: Never
have more than one persistent copy (that is, one that crosses
routine boundaries, whether as an argument or a function return,
or one that gets stored in a dynamically allocated structure)
of a pointer at a dynamically allocated object. If you think
you need another pointer at something, or if you think you need
to pass a pointer at something more than once, then what you
need to do is wrap that type of thing in a managing structure
keyed by integer and then store or pass around the integers
that you can provide as keys to the managing structure. C has
lots of syntax for using pointers directly, and lots of
infrastructure for, say, string handling, that assumes you're
not doing this. Use it with restraint if at all. Duplicate
what you need, ignore what you don't, and don't pass pointers
around if you can help it.
This solves most of the memory management problem: it prevents
things from being leaked, gives you a chance to do things like
bounds checking and null checking away from the "pointer" use
site, and if you can tell when something in the structure is
stale or useless, it allows you to periodically traverse the
structure reaping them (and of course, implementing such
structures reminds me OFTEN of Greenspun's Tenth Law).
It also solves most of the serialization problems: You can
serialize your manager structures in a straightforward way
giving just keys and data, and then use the key integers
anywhere else in serialization where you need to refer to
dynamically allocated objects. No naked pointers means no need
to figure out how to store them at save-game time or reconstruct
them at read-saved-game time.
Realizing the importance of this one technique is enough to
prompt a rewrite - or at least it was for me. The reason I
didn't know enough to do it in the first place is I was used
to writing in Lispy languages and I had to beat my head
against these "simple" problems for a while before I figured
out the shape of them and how to handle them.
Bear
Ray Dillinger
> As an alternative to releasing the source, I'm sure people would
> appreciate a design document about the internal structure of the
> game, even something highly abstract. Writing such a thing might even
> improve the future design, just by focussing your mind on the issues
> of how all the little pieces fit together.
Roguelikes are turn based, or so they say. But Time in roguelikes
is as complicated as you want to make it.
Let's start by defining some vocabulary.
"Wall" time or "Player" time - this is time as seen from the player's
POV, and determines, for example, whether your game is a lunch break
game (half-hour) or a weekend game (20 hours) or an obsession-level
quest (80 hours and up). Wall time is important in balancing the game,
in that if you realize the players are spending half their time dealing
with something that's supposed to be one-tenth of the game you need to
rebalance a little.
"Game" time - this is absolute time as seen from the character's
perspective. Seconds, minutes, and hours pass in the dungeon and
game time keeps their count. Lots of people call these "turns" but
I'm going to try not to because that confuses them with Beat time.
"Character" time or "Beat" time is time as measured in your
character's opportunities to act. Fast characters may get ten
beats in a minute of game time while slow ones get six. Lots of
people call these "turns," but I'm going to try not to because that
confuses them with game time.
If your game's time flow is uncompromising, the game clock, the
character speeds, the amounts of "beats" different actions take,
etc, are not integers. They are the outcome of equations that may
have near-arbitrary real results, and counted-move strategies are
nearly useless and would probably require guru meditations on the
source code to develop and execute. Characters can be sped up or
slowed down arbitrarily, and their actions will be rescheduled
according to their new speed from the moment they were sped or
slowed, not from their next turn or their last.
What I have is an "uncompromising" time flow. Here's how it's
implemented.
Anything that changes anything in the modeled world is an 'event':
a serializable structure that can be executed. (Yes, function
pointers are involved. One of the fields of an event is an index
into a big array of function pointers). Events can be "chained,"
and some events modify the ones chained behind them. For example,
a "fireball" spell is implemented as, spell-cast event, linked
to ball-effect event, linked to fire damage on a square event.
The spellcast event takes time and mana and does not execute the
chained following effect if it fails. The "ball effect" applies
the chained following effect to a wide area. The "fire damage on
a square" event applies fire damage to all actors in a square.
There's a classic-computer-science structure called a Priority Queue
(search on "Priority Queue" if you want the implementation details).
It's for keeping things ordered (or partially-ordered) by their
priority, while minimizing the CPU required to add something, get
the first thing, reschedule something, or delete something.
My Game time is implemented as 'events' kept in a priority queue,
and the "priorities" of the events are the game times at which
the events are supposed to happen. I take the first event off
the priority queue, execute it, and delete it. Usually executing
it results in putting another event a lot like it back on the
queue, simulating "recurring" or "duration" effects, and in that
case I reuse the space to store the new event. Some of these
events are effects with duration or delay that are attached to
Game Time, (like the time for smoke to clear or wooden doors to
burn or water to drain) and others represent actors. These "actor
effects" are indexed by the game time of the current first event
in the actors' own 'beat time' priority queues.
Each actor also has a priority queue of 'events' (in fact the code
is reused). But these events are stored according to 'beat time'
rather than 'game time.' This includes the 'event' which is the
character's opportunity to take an action, as well as events with
duration or delay measured in the beat time of the actor, such as
taking poison damage, healing, recovering mana, skill timeouts,
etc. When an actor's event comes up in the gametime queue, I
use the interval between his current and next actions in beat time,
plus the actor's speed, to calculate the game time of the next
actor event for that actor. So the gametime queue never contains
more than one actor event per actor, but the actor keeps getting
new actor events scheduled as long as his 'beat time' queue isn't
empty (it gets empty when he dies, basically).
Executing an actor event means, go to the actor, get the first
event off his beat-time queue, execute that action remembering
its beat-time, put its recurrence if any back into the beat-time
queue, then subtract the just-executed beat-time from the new
'next' beat-time. Divide by the actor's speed, add the current
game-time (ie, the game time of the current actor-event) to
find the game-time of the next actor event for this actor, take
the current actor event off the gametime queue, and put a new
actor event back into the gametime queue.
Because the Gametime priority queue contains events that have
reference to the actors, and the actors know their own events'
locations in the Gametime priority queue, I can slow or speed
a particular actor at any moment. I change his speed. His
"beat time" priority queue remains unaffected. The game time
for his 'actor' event is adjusted so that the interval between
the current moment (the event which is slowing or speeding him)
and the moment of his next movement is halved or doubled. And
then I use the actor's knowledge of its own event's location in
the gametime queue to "fix" the gametime queue after rescheduling
the event.
This means there's a multitude of crap that I don't have to
worry about slowing down or speeding up when an actor slows
down or speeds up; it happens automatically. When his speed
changes, the rate at which his beat time passes relative to
game time changes. This means nothing measured in that beat
time has to be adjusted at all; it slows down or speeds up
with him.
Oh... there's also some special code to handle petrifaction
without dividing by zero. But that's in the column of minor
details.
Bear
Radomir 'The Sheep' Dopieralski
Ray Dillinger wrote:
> This means there's a multitude of crap that I don't have to
> worry about slowing down or speeding up when an actor slows
> down or speeds up; it happens automatically. When his speed
> changes, the rate at which his beat time passes relative to
> game time changes. This means nothing measured in that beat
> time has to be adjusted at all; it slows down or speeds up
> with him.
I'm curious on how do you handle 'failed' and 'interrupted'
actions (like wearing an armor interrupted by a monster attack).
Crypt
> Crypt wrote:
i've spend some time using the refractoring tool of NetBeans. I think everything
will be ok tomorrow.
I still have to modify all my getClass().getName() methods because now it
returns the package name+the class name.....the result is really weird, lol.
Stu George
wrote:
>Realizing the importance of this one technique is enough to
>prompt a rewrite - or at least it was for me. The reason I
>didn't know enough to do it in the first place is I was used
>to writing in Lispy languages and I had to beat my head
>against these "simple" problems for a while before I figured
>out the shape of them and how to handle them.
>
mm. I added a handle based memory manager I wrote to my game.
sounds the same. old palmos/mac concept of memory allocation
via handle (i think win3.x did it as well).
I can flush my memory manager to disk and back and have full state...
its very nice. the hardest part is making EVERYTHING play with it.
ie: linked list code libraries etc...
makes life so much easier. 180 odd lines of code. niiice.
--/\-[ Stu :: http://mega-tokyo.com ] -/\--
Ray Dillinger
>
> I'm curious on how do you handle 'failed' and 'interrupted'
> actions (like wearing an armor interrupted by a monster attack).
>
Currently, I don't - but there's a reasonable strategy for doing
it. It requires the character record to store the index in the
beat-time queue of any current 'interruptible' action. As a first
cut, I'd call any voluntary action that takes more than, say, 3
beats to finish (that is, takes longer than firing a bow) an
interruptible action. I have move-one-square-orthogonally
equals 1 beat, move-one-square-diagonally equals sqrt(2) beats,
hand to hand attack equals two beats, bow attack equals 3 beats.
This would mean most spellcasts are interruptible.
You can record this whenever the actor chooses such an action,
and clear it whenever an interruptible action is executed or
aborted.
It also requires two new event types: An 'interrupt' event, and
an 'abort?' event.
If you have that, you can just chain 'interrupt' events to
events like attacks that interrupt interruptible actions. And
an 'interrupt' event, when executed off the game queue, would
look at the actor record being interrupted, see if there's an
interruptible action going on for that actor, and if there is,
drop an 'abort?' event into the actor's beat-time queue with
the actor's current beat time. (which you'll probably have
to calculate from gametime since it's someone else's action).
This immediate event will cause the 'actor' event to be
rescheduled, moving it to the head of the gametime queue.
When you execute the 'abort' action, you give the actor the
opportunity to abort the current interruptible action and start
some different action instead. If the actor chooses to abort,
you delete the interruptible action from the beat-time queue
(this is what requires the actor record to know the index of
of the interruptible action) and put whatever action the actor
chooses into his beat-time queue.
If I do this, I'll probably create a 'hard-interrupt' action
too - this would be similar except that instead of an 'abort?'
event it would drop a 'your-action-has-been-aborted' (or
'action-failed') event into the beat-time record of the
affected actor.
Bear
R. Alan Monroe
>Any feedback appreciated.
Lightsource management... ugh.
I like the sounds, although when you miss a melee attack it still
sounds like a clank, like you hit something. It would be nice if the
sounds could fade in and out when the rain starts and stops. Even
cooler would be a lowpass filter on the rainsound when you're indoors
but still in hearing distance of the rain :)
The font used for the stats is too small for my tastes. Also the menu
options that represent boolean choices should have a checkmark when
enabled. Right now you can't tell if they're toggled on or off.
Alan
Slash
Crypt wrote:
> On 2006-08-15 15:34:40, "Slash" <java....@gmail.com> wrote:
>
> > Crypt wrote:
> > > On 2006-08-15 07:18:10, Brendan Guild wrote:
> > >
> > > > Crypt wrote in news:ebo5r9$gi0$1...@news.vol.cz:
> > > > > http://cryptmaster.free.fr/
> > > > >
> >
> > SNIP
> > >
SNIP
>
>
> i've spend some time using the refractoring tool of NetBeans. I think everything
> will be ok tomorrow.
thats cool!
> I still have to modify all my getClass().getName() methods because now it
> returns the package name+the class name.....the result is really weird, lol.
What are you using getClass().getName() for?
--
Slash
Björn Bergström
> Crypt wrote:
> > On 2006-08-15 15:34:40, "Slash" <java....@gmail.com> wrote:
> >
> > > Crypt wrote:
> > > > On 2006-08-15 07:18:10, Brendan Guild wrote:
> > > >
> > > > > Crypt wrote in news:ebo5r9$gi0$1...@news.vol.cz:
> > > > > > http://cryptmaster.free.fr/
> > > > > >
> > >
> > > SNIP
> > > >
>
> SNIP
> >
> >
> > i've spend some time using the refractoring tool of NetBeans. I think everything
> > will be ok tomorrow.
>
> thats cool!
>
> > I still have to modify all my getClass().getName() methods because now it
> > returns the package name+the class name.....the result is really weird, lol.
>
> What are you using getClass().getName() for?
Yes, why? If you're ever going to use code obfuscation and you expect
certain class names for some god awful reason then you're screwed.
> --
> Slash
/Björn
Björn Bergström
> Crypt wrote:
> > On 2006-08-15 07:18:10, Brendan Guild <do...@spam.me> wrote:
> >
> > > Crypt wrote in news:ebo5r9$gi0$1...@news.vol.cz:
> > > > http://cryptmaster.free.fr/
> > > >
>
> SNIP
> >
> >
> > You will see that i don't use packages. I know this is evil but i started
> > without packages and it's a bit too late to add some now. It's not a problem
> > for me but i'm sure it will be very ambarassing for anyone else trying to look
> > inside my code. Sorry about that.
>
> It is a very bad coding style, however if you use modern IDEs such as
> Eclipse or NetBeans, you will find their refactoring tools very useful
> for this, and eventually you will get your game packaged on a day or
> less. It is really worth the effort, trust me! ;)
Yes, Eclipse (and probably Netbeans as well) have beatiful tools for
refactoring. They beat everything I've ever encountered before. Long
gone are the tedious manual refactorings and class/method renamings!
Use it! :-)
> > I've start learning programming in May 2005 and start CryptRL in november 2005.
> > I'm sure some parts of the code will appear a bit "newbie" to you while recent
> > ones are more sophisticated.
>
> > I'm constantly hunting the old clumsy parts.
>
> We all are
>
> --
> Slash
> [http://www.santiagoz.com]
/Björn
Crypt
> In article , Crypt wrote:
> >Any feedback appreciated.
>
> Lightsource management... ugh.
>
you don't like it ?
> I like the sounds, although when you miss a melee attack it still
> sounds like a clank, like you hit something. It would be nice if the
> sounds could fade in and out when the rain starts and stops. Even
> cooler would be a lowpass filter on the rainsound when you're indoors
> but still in hearing distance of the rain :)
>
> The font used for the stats is too small for my tastes. Also the menu
> options that represent boolean choices should have a checkmark when
> enabled. Right now you can't tell if they're toggled on or off.
>
> Alan
>
>
thanks for you feedback, i take note of all of this. I will (very probably) fix
all this points.
Brendan Guild
[snip]
>> If you really mean that 'any' feedback is appreciated, then I
>> would be pleased to give you feedback on the insides of your
>> game. Though I am sure that is not what you had in mind and I
>> would not be at all surprised if that kind of feedback would be
>> taken more personally than general game comments.
>
> started without packages and it's a bit too late to add some now.
> It's not a problem for me but i'm sure it will be very ambarassing
> for anyone else trying to look inside my code. Sorry about that.
Packages can be helpful in keeping a very large project organized,
but when you have around 100 classes, I don't think it is at the
point of being a serious concern. This is especially true when you
are the only person working on the game.
If I were you, I would be more concerned by the size of the Entite
(or 'Entity') class, which has over 300 public members. I am certain
that this design can be simplified and I will try to come up with a
few suggestions.
I believe that one of the keys to having a clean, readable game is
that each class represent an easily definable set of objects,
something that can be understood at a glance. Part of being easily
definable is having a small interface of a few well understood
functions.
When each class has a small set of carefully defined functions,
people will be easily able to understand your classes, then you can
work on helping them understand your entire game by making the
relationships between classes clear. Inheritance and containment
relationships are two of the most easily recognizable and so they
should be used often. After that, breaking the classes up into
packages where classes have more relationships to other classes
within the same package than to classes of other packages will make
things even easier to follow.
This does not mean that one must never have a large interface; I am
well aware that sometimes it is impossible to avoid, but it is at
least something to strive for. When you add new features to your
game, you should be creating new classes, not new functions within a
class. If your design forces you to always add new functions to your
classes with each new feature, then you should be concerned.
One powerful trick that I have encountered is to represent stats and
attributes of a character or creature by objects instead of by
members. For example:
int getForce()
int getDexterite()
int getConstitution()
int getIntelligence()
int getForce_Mod()
int getDexterite_Mod()
int getConstitution_Mod()
int getIntelligence_Mod()
void setForce_Mod(int m)
void setDexterite_Mod(int m)
void setConstitution_Mod(int m)
void setIntelligence_Mod(int m)
These 12 members can be replaced with just a few:
int get(Attribute a)
void set(Attribute a, int value)
Using this style, force, dexterity, constitution, intelligence, and
their modifiers become objects instead of members, allowing you to
simplify both the interface and the implementation of the class. In
the case of CryptRL, doing this could hugely simplify things.
There are interesting choices to be made with a design like this. You
could have a pair of additional functions:
int getMod(Attribute a)
void setMod(Attribute a)
This reduces the number of objects that you will need and firmly
indicates the connection between an attribute and its modifier. In
CryptRL, it seems that most things have modifiers, so this might be
appropriate.
Another choice is in deciding what the class of attributes should be.
Attributes usually have names, which is perfect for using them as
keys to access the various numbers in each entity, but attribute
objects could also contain formulas that allow one attribute to be
calculated from others. The maximum and minimum values of an
attribute could be in the attribute object, or the attribute could
contain other attributes. If there is an attribute called 'maxHP',
then the 'hp' attribute could hold the 'maxHP' in such a way that the
maximum value for 'hp' will be drawn from 'maxHP'.
On the other hand, do not be afraid of small classes. Small classes
are easy to understand and that is a very good thing. In this sense,
the ideal class has no members at all. So there is no need to make
the attribute class complicated.
CryptRL uses an interesting technique for copying its entity objects.
Every subclass of Entite has a matching member function of Entite
with the word 'clone' prefixing the name of the class. For example,
Creature is a subclass of Entite, so Entite has a member function
called 'cloneCreature'.
This means that Entite must be modified if a new class of entities is
ever introduced and the number of functions in Entite must increase
even further. Both of these things feel highly undesirable to me, but
fortunately they are easily fixed. One merely needs to combine all of
these functions into one:
Entite clone()
And then cast the cloned entity into whichever subclass is
appropriate. If the function name 'clone' is already in use, then
'copy' (or perhaps 'copie') could be used.
In the current design, one cannot clone without knowing the specific
subclass of the entity because all but one of the functions return
null, but with a unified copy function, one can copy an abstract
entity safely.
Once the number of functions in your classes starts plummeting, you
will probably notice functions that have a bit of an awkward fit. In
CryptRL, there are the sign functions, five overloaded functions with
the name 'sign' that apply to various number types and return -1 or 1
depending on the sign of the given number. These are good an useful
functions, but they are declared to be public and static within
classes that have nothing to do with finding signs. It seems odd to
find them as public static members of the Creature class, for
example. Also: Monde (aka 'world'), Personnage (aka 'character'),
Piege (aka 'trap'), and TerrainPanel
I do not mean that the sign functions are not needed by the
implementation of Creature, but there is no need to make them public
so that the users of the Creature class are forced to learn them. Go
crazy with private helper functions, give them strange names, make
dozens of them just because you can, because no one will care, but in
public you surely want your class to be clean and shiny, with an
extremely well thought-out and meaningful set of functions.
Finally, I recommend that you should not be afraid of introducing
more classes if it means reducing the number of public members in
each class. If you have a collection of getters and setters in a
class that can be meaningfully grouped together somehow, then they
can be replaced by a single getter and a single setter which operate
on a new class of objects that contain all of the needed values.
For example:
void setColAscii(Color asc)
Color getColAscii()
void setCharAscii(String asc)
String getCharAscii()
Could be replaced by:
void setSymbol(AsciiSymbol asc)
AsciiSymbol getSymbol()
where AsciiSymbol is a new class of objects that hold both ascii
information and color information. In this case it is a small thing,
but when the number of members is already very large, every little
bit helps.
Hopefully, this can all be viewed as constructive criticism and is
not going to scare people away from publishing their source. I firmly
believe that we can help each other to make the job of creating
roguelikes easier for everyone.
Crypt
wow, thanks very much for this feedback !
I take note of all of this.
I thought of this kind of think in probably using a future Brain class for every
creature with would hold all of their ia .
ps: i'm not a very organized developper ;)
Crypt
> Crypt wrote:
> > On 2006-08-15 15:34:40, "Slash" wrote:
> >
> > > Crypt wrote:
> > > > On 2006-08-15 07:18:10, Brendan Guild wrote:
> > > >
> > > > > Crypt wrote in news:ebo5r9$gi0$1...@news.vol.cz:
> > > > > > http://cryptmaster.free.fr/
> > > > > >
> > >
> > > SNIP
> > > >
>
> SNIP
> >
> >
> > i've spend some time using the refractoring tool of NetBeans. I think everything
> > will be ok tomorrow.
>
> thats cool!
>
> > I still have to modify all my getClass().getName() methods because now it
> > returns the package name+the class name.....the result is really weird, lol.
>
> What are you using getClass().getName() for?
>
> --
> Slash
>
>
>
I use getClass().getName() (or getClass().getSuperclass().getName()) each time i
need to know what is the exact class of an Entite (every object on the grid is
an Entite. Some are Entite.Creature, others are Entite.Obstacle.Wall, etc,
etc.....)
Here "each time" means very often (objects interactions, creatures turns,
rendering hierarchy, editor...)
lol....i feel you will tell me "don't do that".......;)
hmm....what are you using instead ?
Crypt
>
> Yes, why? If you're ever going to use code obfuscation and you expect
> certain class names for some god awful reason then you're screwed.
>
>
>
>
Could you explain ?
Crypt
> Crypt wrote:
> > On 2006-08-15 15:34:40, "Slash" wrote:
> >
> > > Crypt wrote:
> > > > On 2006-08-15 07:18:10, Brendan Guild wrote:
> > > >
> > > > > Crypt wrote in news:ebo5r9$gi0$1...@news.vol.cz:
> > > > > > http://cryptmaster.free.fr/
> > > > > >
> > >
> > > SNIP
> > > >
>
> SNIP
> >
> >
> > i've spend some time using the refractoring tool of NetBeans. I think everything
> > will be ok tomorrow.
>
> thats cool!
>
> > I still have to modify all my getClass().getName() methods because now it
> > returns the package name+the class name.....the result is really weird, lol.
>
> What are you using getClass().getName() for?
>
> --
> Slash
>
>
>
should i better use an int classId ? (ok, ok, i will)
gf
You can check with instanceof, for example:
if (i instanceof Creature) {
...
}
it is quite light (I also use it for this exact
purpose).
--
Giorgos
gf
>>ok, ok, understood, i will add a keyboard farlook command.
>
>
> Done in the new uploaded version.
Nice farlook command! The game is a bit difficult, I always get killed by some 'G's :-)
How can you pick the lock of a door/window? Kicking it down doesn't help...
When you die and start a new game, the old minimap stays on for the first turn.
Cheers
--
Giorgos
Crypt
> Crypt wrote in news:ebr85p$2gk$1...@news.vol.cz:
do forget you can parry (+ / - ) (this means putting part of your offensive
capability in your defense)
To pick a lock =
- apply a picking tool on it (you can find two picking tools in the beginning
house (there are also one armor and weapons) or in the random underground
levels)
-OR kick it (depends on your strength. It can take a few time and hurts you if
-you're not strong enough. Everything can be kicked, even walls, but everything
has a resistance value and a structural value (hits). Walls can only be kicked
by very strong characters.)
-OR break it with a pick, (more effective than kicking, you can break a wall
with a pick
-OR throw a missile spell on it,
-OR throw an item on it (need big strength to be effective)
Remember that automatic success is rare (opening an unlocked door and digging
with a shovel are the only actions which are automatically successfull) so a
failure at first time doesn't mean it's impossible.
Crypt
you can also:
-untrap a mine (or be lucky moving on it to pick it up) (alt u)
-activate it in your inventory (alt u)
-throw it on the door. (f)
Note that the mine line in the "Explosion test area" contains several very weak
mines (not even strong enough to break a door) and a very powerfull mine
between the two chests (this one can even destroy walls)
(bug found:
untrap fumbles should trigger the trap.)
Slash
If you use a code obfuscator tool all of your class names will be
replaced by meaningless crap in order to protect your game logic from
being reverse engineered, thus your game wont work.
If you need to do type check (which you mustnt really want to use
extensively, as it may denote a poor design) you must use the
'instanceof' operator
--
Slash
Slash
You must use subclassing with care, for example when specific kind of
'entite' has an asociated unique behavior, ... in this case it may be
better to put an 'isWall' attribute on the Entite.Obstacle class (or a
getObstacleType() method ) instead of creating a new
Entite.Obstacle.Wall class; then each time you have to check what kind
of obstacle it is you make a method call instead of a type check, which
makes the program more structured and may as well enhance performance.
Classes should be used to refine functionality, not to categorize
content.
--
Slash
gf
news:1155737404....@75g2000cwc.googlegroups.com:
....
>
> You must use subclassing with care, for example when specific kind of
> 'entite' has an asociated unique behavior, ... in this case it may be
> better to put an 'isWall' attribute on the Entite.Obstacle class (or a
> getObstacleType() method ) instead of creating a new
> Entite.Obstacle.Wall class; then each time you have to check what kind
> of obstacle it is you make a method call instead of a type check,
> which makes the program more structured and may as well enhance
> performance.
>
> Classes should be used to refine functionality, not to categorize
> content.
>
> --
> Slash
>
>
With one exception: using the object system of Java to represent the objects of the game :-)
For example:
class Being { ... }
interface Undead { }
class Orc extends Being { ... }
class Zombie extends Being implements Undead { ... }
...
Being b = methodThatReturnsABeing();
if (b instanceof Undead)
...
This way, you implement a flag ('Undead') that takes space in the Zombie class but not in the Orc
class.
The instanceof operator is for those rare classes that have a particular property that is used only once.
Instead of having 100 beings (boolean isUndead=false) and 5 undead ones (boolean isUndead=true),
you just assign to the selected ones an abstract behaviour with an interface, checking against it at
runtime.
--
Giorgos
Christophe
> With one exception: using the object system of Java to represent the objects of the game :-)
>
> For example:
> class Being { ... }
> interface Undead { }
> class Orc extends Being { ... }
> class Zombie extends Being implements Undead { ... }
>
> ...
>
> Being b = methodThatReturnsABeing();
> if (b instanceof Undead)
> ...
> This way, you implement a flag ('Undead') that takes space in the Zombie class but not in the Orc
> class.
>
> The instanceof operator is for those rare classes that have a particular property that is used only once.
> Instead of having 100 beings (boolean isUndead=false) and 5 undead ones (boolean isUndead=true),
> you just assign to the selected ones an abstract behaviour with an interface, checking against it at
> runtime.
But is that dynamic enouth for your needs ? There are quite a few RPG
where the player can acquire the Undead stats in a way or another. And
what about necromancy resurecting some orc body as a zombie ?
gf
news:44e32b74$0$11928$636a...@news.free.fr:
...
>
> But is that dynamic enouth for your needs ? There are quite a few RPG
> where the player can acquire the Undead stats in a way or another. And
> what about necromancy resurecting some orc body as a zombie ?
>
You are right, I was proposing interface usage for properties that are not to be changed. Maybe we need
an OO-language with evolving classes? :-)
--
Giorgos
Slash
gf wrote:
> "Slash" <java....@gmail.com> wrote in
> news:1155737404....@75g2000cwc.googlegroups.com:
>
> ....
>
> >
> > You must use subclassing with care, for example when specific kind of
> > 'entite' has an asociated unique behavior, ... in this case it may be
> > better to put an 'isWall' attribute on the Entite.Obstacle class (or a
> > getObstacleType() method ) instead of creating a new
> > Entite.Obstacle.Wall class; then each time you have to check what kind
> > of obstacle it is you make a method call instead of a type check,
> > which makes the program more structured and may as well enhance
> > performance.
> >
> > Classes should be used to refine functionality, not to categorize
> > content.
> >
> > --
> > Slash
> >
> >
>
> With one exception: using the object system of Java to represent the objects of the game :-)
Hehehe, that may sound nifty, but it is not really advisable... it is
one of the reason why so many of the nonOOP developers hate OOP so
deeply ;)
A data driven approach is much more flexible in this case; interface
implementation must not be used to flag objects as certain type but to
allow interoperatibility between different layers on your application
>
> For example:
> class Being { ... }
> interface Undead { }
> class Orc extends Being { ... }
> class Zombie extends Being implements Undead { ... }
XD
>
> ...
>
> Being b = methodThatReturnsABeing();
> if (b instanceof Undead)
> ...
> This way, you implement a flag ('Undead') that takes space in the Zombie class but not in the Orc
> class.
'takes space' as in memory space? if so, a boolean flag used to
implement an 'isUndead()' method takes little space for the level of
flexibility it would allow, both at runtime (you can change your
entities to undead status dynamically) and at data entry level (you
just set the flag on when reading your entity definition data, instead
of creating a specific class of object)
> The instanceof operator is for those rare classes that have a particular property that is used only once.
> Instead of having 100 beings (boolean isUndead=false) and 5 undead ones (boolean isUndead=true),
> you just assign to the selected ones an abstract behaviour with an interface, checking against it at
> runtime.
>
> --
> Giorgos
--
Slash
Björn Bergström
I agree 100% with Sheep's reply but as I also come from a limited
device background (handhelds, mobile phones etc) I see other problems
as well. Each call to getName() creates a String object (slow and
costly on limited devices). Also, if you do any kind of string
manipulation or comparisons with that object you will have something
that is much slower than comparing to ints. But hey, CryptRL runs on a
PC so I guess you don't have to worry too much :-)
BR,
Björn
Crypt
> gf wrote:
> > "Slash" wrote in
I will simply use a int classId to replace getClass().getName(), mainly because
i'm quite sure compareTo(" ") apply to a String is more performance consuming
than a simple int == int.
Superclass identification (eg. Entite.Creature.x, as opposed to class
identification which is Entite.Creature.UndeadCategory) is already covered
without using getClass() (except in one line of the editor... ) This uses
String comparison, maybe i will convert this to int comparison, i don't know
yet.
Crypt
> http://cryptmaster.free.fr/
>
> You can choose between three differents versions without having to download
> anything else:
>
> - normal version (with sounds and tiles but without the bonus sounds) = 15.4mg
>
> - or NoSound version = 3.5mg
>
> - or NoSound_NoTile version = 1 mg (the one which could interessed peoples
> here)
>
>
> OPTIONS (None of the following files are required) :
> If you download bonusSounds.zip, unpack it in the \sons\ambiance\ folder.
>
> If you download the NoSound version you can download sounds.zip and unpack it in
> \cryptrl\
>
> If you download the NoSound and NoTile version you can download sounds.zip and
> images.zip and unpack them in \cryptrl\
>
>
> This the first ASCII release of CryptRL. The ascii symbols selection is not
> final, i will probably make color and symbols modifications.
>
>
> Any feedback appreciated.
>
>
Several improvements & cleaning to do.
Expect a nicer version very soon ;)
Radomir 'The Sheep' Dopieralski
gf wrote:
> Christophe <chris.c...@free.fr> wrote in
> news:44e32b74$0$11928$636a...@news.free.fr:
>> But is that dynamic enouth for your needs ? There are quite a few RPG
>> where the player can acquire the Undead stats in a way or another. And
>> what about necromancy resurecting some orc body as a zombie ?
> You are right, I was proposing interface usage for properties that are not to be changed. Maybe we need
> an OO-language with evolving classes? :-)
Python? Ruby?
--
Radomir `The Sheep' Dopieralski
"Computer Science is no more about computers than
astronomy is about telescopes." [Edsger Wybe Dijkstra]
Crypt
I've removed all getClass() in the new version (0.6367) and replaced them by an
int id identification.
The performance improvement is really nice, expecially for the rendering
hierarchy :)
I will wait a while before using packages, i'm not 100% confident with netbeans
refactorising my "yet to be clean" code. (i've test it and obtained some minor
weird effects. Minor but i don't like that.)