Keep it simple, stupid!
corremn
back to it. Thankfully I left it in a runnable condition. However
after playing around with it I saw my todo list and nearly died.
I had great expectations when I started the rewrite, now however I
think I have bit off more than I can chew.
Below is the first 5% of my todo list I wont dump the whole thing as
it scares me. Writing a roguelike should never be this complicated.
After all you are just moving around a few ascii characters right?
Hopefully the next 7drl comp might force me to make a simplier and
usable version of my engine.
TODO.txt
0/ Create base object (used for all base world objects( terrain,
monster, item, etc) - DONE
1/ Rewrite Terrain system. - DONE
2/ Rewrite Item system. - DONE
3/ Rewrite Monster system. - Started
4/ Rewrite Inventory system -
5/ Rewrite Dungeon/World system
6/ Monster skill/trait/ability/effects system
7/ Damage model
8/ System Interaction??
9/ Dynamic Help system
10/ Highlighted Menu system
11/ Popup message/interactive screen system
12/ Option Manager
13/ Sound/Music Manager - Started
0.1 All world objects can be handled generically
1.1 Inherit from base object class -DONE
1.2 Create terrain template -DONE
1.2.1 Each terrain object will link to a template -DONE
1.2.2 Terrain templates has different properties that define its
interaction withing the world-DONE
1.2.2.1 Templates properties allow its use to be in a
generallised manner (with out having to refer to its type) -DONE
1.3 Terrain objects will only have properties that change over time -
DONE
1.3.1 I.e integrity, state, effects -DONE
1.4 Create terrain states (i.e open/close) -DONE
1.4.1 Terrain states can have different appearance and
description -DONE
1.5 A terrain effects manager
1.5.1 Terrain can have multiple effects applied - DONE
1.5.2 Effects have different visual effects - DONE
1.5.2.1 Effects can change terrain symbol, colour or
background colour - DONE
1.5.2.2 Effect colours can change slightly (ie for plasma/gas
effects) - DONE
1.5.2.3 Effect can alter LOS - DONE
1.5.2.4 Effect can alter pathfinding - DONE
1.5.3 Effects can be permanent (i.e blood) and temparary (gas) -
DONE
1.5.4 Effects can interact with other existing effects
1.5.4.1 effects co-exist, eliminate , modify , combine (water
& fire = steam)
1.6 Terrain can be damaged
1.6.1 Define terrain damage/resistance model
1.6.2 Destroyed terrain changes to new type. (i.e wall ->
rubble, rubble ->dirt + item::rocks )
1.6.3 Terrain can be damaged by effects as well as physical/
elemental/magical damage
And it goes on and on and on.
Sir_Lewk
down the list. As things get taking off the top of the list I add
detail and resolution to the rest of it. Perhaps I'm decieving
myself, but I find this to be a lot less intimidating than a massive
TODO.
regards,
Gerry Quinn
@z27g2000prd.googlegroups.com>, cor...@gmail.com says...
> After taking a long break from my Demise Engine rewrite I finally got
> back to it. Thankfully I left it in a runnable condition. However
> after playing around with it I saw my todo list and nearly died.
>
> I had great expectations when I started the rewrite, now however I
> think I have bit off more than I can chew.
> Below is the first 5% of my todo list I wont dump the whole thing as
> it scares me. Writing a roguelike should never be this complicated.
> After all you are just moving around a few ascii characters right?
> Hopefully the next 7drl comp might force me to make a simplier and
> usable version of my engine.
>
> TODO.txt
Too much about code, too little about the game.
You are designing a world simulation, not a game. Does it matter
whether terrain can be destroyed? Whether effects can interact with
existing effects? Probably not - there's no reason to suppose your
gameplay will depemd on those.
- Gerry Quinn
copx
> After taking a long break from my Demise Engine rewrite I finally got
> back to it. Thankfully I left it in a runnable condition. However
> after playing around with it I saw my todo list and nearly died.
>
> I had great expectations when I started the rewrite, now however I
> think I have bit off more than I can chew.
> Below is the first 5% of my todo list I wont dump the whole thing as
> it scares me. Writing a roguelike should never be this complicated.
> After all you are just moving around a few ascii characters right?
The problem is that people nowadays tend to overengineer. The limited
resources available in the past helped to limit that common tendency.
Also people tend to compare their games against the "current standard"
and usually strive to be better than that "current standard".
Back then the standard was Rogue, nowadays the standard are monster
games like ADOM, Angband, or Nethack whose source bases
represent countless hours of work. If you try to offer everything
they offer, or even worse try to surpass them - you chances of ever
actually getting anywhere are mighty slim indeed.
Of course, even if the developer himself is reasonable, players
will quickly start demanding that his roguelike provides at least
all those features which they are used to from the current major
roguelikes. I remember people asking for Crawl-like auto explore
features while I was still struggling with basic AI.
I think the roguelike development community was much more productive
in the past because people focused on gameplay instead of luxury
features like:
>9/ Dynamic Help system
>10/ Highlighted Menu system
Oh and nobody worried about such shit back then:
>0.1 All world objects can be handled generically
>1.5.1 Terrain can have multiple effects applied - DONE
>1.5.2.2 Effect colours can change slightly (ie for plasma/gaseffects) - DONE
> 1.5.2.3 Effect can alter LOS - DONE
In those days we got: Hack (which became Nethack),
Moria (which became Angband), Larn, Omega, Crawl, BOSS,
Alphaman, Unreal World, Ragnarok..
I mean the quantity of games released is much higher nowadays,
but most of them never get out of the "in-development" stage and
are quickly forgotten as soon their author stops posting
updates. My own attempt is just another sad example.
I think if you are actually serious about developing a
game (as opposed to "I use diz forr learnin' teh programmingz!")
you should first come up with a justification why anyone
should play your game instead of the established ones.
Chance is that unique feature which really sets your
game apart doesn't require you to write your own full featured
Angband or whatever clone + extra whizbang + your feature.
I think it would be better if people who start new projects
compare them against Rogue (it's supposed to be a "roguelike"
after all) and try to reach that level of features + whatever
is supposed to make their game unique / interesting.
Hell, every second post in this group seems to discuss the
issue of getting your field of view algorithm right.
Rogue didn't have a FOV algorithm! Unless your roguelike is
based on stealth action why the fuck do you even care to
implement it before you have an interesting game with
something worth viewing?!
You can still bloat up later (see the innocent roots of
most of the major games today).
I am still waiting for a post-apocalyptic roguelike,
or a vampire roguelike, or.. You know, not just a tech-demo,
a fully payable game without holes.
KISS is a mighty fine advice indeed. Any Rogue/Larn/Omega
level roguelike with a fresh theme and some unique features
would be more interesting than something like "Lands of
Elderlore" and similar projects - procedural world generation,
natural ocean lines, ten trillions of independently acting
NPCs who pursue their own ambitions, detailed body part system
where you can even break your nails, advanced object
system which allows you to stuff objects into objects
and then ram said objects up your rectal entrance (with realistically
simulated rectal bleeding), and .. no playable game in
sight in this millennium.
corremn
> corremn wrote:
> > After taking a long break from my Demise Engine rewrite I finally got
> > back to it. Thankfully I left it in a runnable condition. However
> > after playing around with it I saw my todo list and nearly died.
>
> > I had great expectations when I started the rewrite, now however I
> > think I have bit off more than I can chew.
> > Below is the first 5% of my todo list I wont dump the whole thing as
> > it scares me. Writing a roguelike should never be this complicated.
> > After all you are just moving around a few ascii characters right?
>
> [snip]
>
> The problem is that people nowadays tend to overengineer. The limited
> resources available in the past helped to limit that common tendency.
> Also people tend to compare their games against the "current standard"
> and usually strive to be better than that "current standard".
> Back then the standard was Rogue, nowadays the standard are monster
> games like ADOM, Angband, or Nethack whose source bases
> represent countless hours of work. If you try to offer everything
> they offer, or even worse try to surpass them - you chances of ever
> actually getting anywhere are mighty slim indeed.
Everyone over engineers on the first major rewrite. I am just
following the trend. Step One: First you write give a decend attempt
at a roguelike. Step 2: You decide all the things you could do better
and completely blow things out of proportion with a rewrite. Step 3.
You do only what is needed.
I am just stuck on Step 2. And yes I am writing the next big
roguelike, no question about it.
> Of course, even if the developer himself is reasonable, players
> will quickly start demanding that his roguelike provides at least
> all those features which they are used to from the current major
> roguelikes. I remember people asking for Crawl-like auto explore
> features while I was still struggling with basic AI.
I'll add it to the list.
> I think the roguelike development community was much more productive
> in the past because people focused on gameplay instead of luxury
> features like:
>
> >9/ Dynamic Help system
> >10/ Highlighted Menu system
>
> Oh and nobody worried about such shit back then:
>
> >0.1 All world objects can be handled generically
> >1.5.1 Terrain can have multiple effects applied - DONE
> >1.5.2.2 Effect colours can change slightly (ie for plasma/gaseffects) - DONE
> > 1.5.2.3 Effect can alter LOS - DONE
Of course and no one will play crap roguelikes anymore. Times have
changed. I used to play moria on a black and white 13" screen with vi
keys. Rock and Roll! Now give me all the luxuries of Crawl SS any
day. And besides those lines above where coded in about 1 hour
anyway. Being a profession software engineer has its bennefits.
> In those days we got: Hack (which became Nethack),
> Moria (which became Angband), Larn, Omega, Crawl, BOSS,
> Alphaman, Unreal World, Ragnarok..
>
> I mean the quantity of games released is much higher nowadays,
> but most of them never get out of the "in-development" stage and
> are quickly forgotten as soon their author stops posting
> updates. My own attempt is just another sad example.\
Yeah 35000+ downloads is nothing, you suck :p
> I think if you are actually serious about developing a
> game (as opposed to "I use diz forr learnin' teh programmingz!")
> you should first come up with a justification why anyone
> should play your game instead of the established ones.
> Chance is that unique feature which really sets your
> game apart doesn't require you to write your own full featured
> Angband or whatever clone + extra whizbang + your feature.
> I think it would be better if people who start new projects
> compare them against Rogue (it's supposed to be a "roguelike"
> after all) and try to reach that level of features + whatever
> is supposed to make their game unique / interesting.
I have written rogue-like roguelikes and they are boring. I need
something to challenge me and hopefully come up with a fun game. I
feel great when I am programming this, this is for my own self
gratification.
> Hell, every second post in this group seems to discuss the
> issue of getting your field of view algorithm right.
> Rogue didn't have a FOV algorithm! Unless your roguelike is
> based on stealth action why the fuck do you even care to
> implement it before you have an interesting game with
> something worth viewing?!
Because it is so damn easy to implement. And cool.
Dude, where did you passion go?
> You can still bloat up later (see the innocent roots of
> most of the major games today).
>
> I am still waiting for a post-apocalyptic roguelike,
> or a vampire roguelike, or.. You know, not just a tech-demo,
> a fully payable game without holes.
Many many people have started post-apoc rls I wonder why no one
finishes them? Me, I still love standard fantasy. Give me a dwarf
with an axe anyday.
> KISS is a mighty fine advice indeed. Any Rogue/Larn/Omega
> level roguelike with a fresh theme and some unique features
> would be more interesting than something like "Lands of
> Elderlore" and similar projects - procedural world generation,
> natural ocean lines, ten trillions of independently acting
> NPCs who pursue their own ambitions, detailed body part system
> where you can even break your nails, advanced object
> system which allows you to stuff objects into objects
> and then ram said objects up your rectal entrance (with realistically
> simulated rectal bleeding), and .. no playable game in
> sight in this millennium.
Ohh sounds like the gauntlet has being thrown down :P
corremn
> In article <3d821bcf-6e95-4f57-8f14-3d133ed45515
>
> > After taking a long break from my Demise Engine rewrite I finally got
> > back to it. Thankfully I left it in a runnable condition. However
> > after playing around with it I saw my todo list and nearly died.
>
> > I had great expectations when I started the rewrite, now however I
> > think I have bit off more than I can chew.
> > Below is the first 5% of my todo list I wont dump the whole thing as
> > it scares me. Writing a roguelike should never be this complicated.
> > After all you are just moving around a few ascii characters right?
> > Hopefully the next 7drl comp might force me to make a simplier and
> > usable version of my engine.
>
> > TODO.txt
>
> Too much about code, too little about the game.
> You are designing a world simulation, not a game. Does it matter
> whether terrain can be destroyed? Whether effects can interact with
> existing effects?
Hell yeah!
> Probably not - there's no reason to suppose your
> gameplay will depemd on those.
If I write it, it will come. I am not stupid enough to write something
I will never use, oh wait there was that whole month I spent on body
parts...
rdc
the things I learned was that each feature of a product must have an
associated benefit. This idea also works for computer programs. Each feature
that comes to mind must have an associated benefit for the player. If you
can't think of a benefit for a feature that fits within the idea of
promoting the play of the game, that is paying off the player in some way,
the feature probably isn't worth adding to the game.
Recently I came across a very interesting article on Gamasutra that most of
you have probably already read called "Behavioral Game Design"
(http://www.gamasutra.com/features/20010427/hopson_01.htm). Basically, the
article states that each game element must provide a payoff to the player.
My first rogue-like, Deep Deadly Dungeons (DDD), while playable, ended up
being rather tedious and I realize now that the reason was that many of the
game elements didn't incorporate a payoff to the player. In my current
project, The Sword of Light (SOL), every game element is judged against the
criteria of a payoff benefit to the player. If it doesn't benefit the player
in some way the feature, no matter how cool it seems to me, won't make it
into the game.
I also realized while working on DDD that the player doesn't know what is
going on inside the program. (This may seem obvious, but we tend to lose
sight of this while coding.) All they see are the result of the algorithms
within the game. You may a great idea of monster AI using genetic algorithms
combined with a dynamic classifier system but if the visible the result is
the same as a simple AI scheme where a monster attacks or flees based on an
aggression factor and damage taken, why add the GA at all?
All the different visibility schemes is a good example of overkill in my
opinion. Obviously you need a fast algorithm that looks good. However, it
seems to me that the simple line of sight aglo combined with post artifact
killing achieves the same result as the more complicated schemes from the
players point of view and has the added benefit of being simple to code. Of
course there may be special circumstances that require a more complicated
scheme, but for SOL I really don't see the need to have some of these more
complicated schemes when the end result is what is important. (And I may
even argue that having a few artifacts on the screen probably doesn't bother
a player all that much if the game play is keeping his attention, except for
possibly the coder-player. :) )
There is also the issue of program complexity. A program is more than the
sum of of its parts. As you add code the interactions within the program
increase at a greater than linear rate. This increases the risk of
unintended consequences within the game, not just the increase risk of bugs.
The whole dynamic of the game can change by adding a single feature to the
game. I wrote some articles on this that you may find interesting on my
wiki: http://virtualink.wikidot.com/start. It is quite interesting that in
this modern era of advanced computing tools, there is still no easy way to
really know the effects of complexity within a program until you actually
break from the coding and try out your creation.
What you really need to be, in my opinion, is a player first and programmer
second. You also have to be ruthless. If you have to ignore the fact that
you just spent 30 hours coding up this cool feature that doesn't add an
ounce of benefit to the player and rip it out of the game. The only thing
that really matters in the end is did you create an enjoyable game, a game
that the player will want to play more than once?
copx
> Of course and no one will play crap roguelikes anymore. Times have
> changed. I used to play moria on a black and white 13" screen with vi
> keys. Rock and Roll! Now give me all the luxuries of Crawl SS any
> day.
By the same logic one could say "I used to play ASCII games on a
286. Now give me photo realistic 3D graphics + voice acting by
hollywood stars or whatever mainstream game developers consider
essential for games nowadays. I don't need any of that "modern"
stuff to enjoy games. In fact, I do not like auto explore,
to me playing on "auto pilot" just doesn't feel right, oh and
I hate FOV with passion. It creates a very "busy" screen where
many screen cells change each turn (even if they just change
their color). I hate that. I cannot stand "center on player"
scrolling for the same reason. Oh, and 360 degree vision is just
silly.
But well, it's all a matter of taste. If you really don't like
playing games like Moria anymore there is obviously little
point in developing them.
> And besides those lines above where coded in about 1 hour
> anyway. Being a profession software engineer has its bennefits.
It's amazing how you manage to ruin that kind of productivity
with over-ambitious planning! :P
> Yeah 35000+ downloads is nothing, you suck :p
I should have implemented a FOV algorithm, I guess. ;)
>> I think if you are actually serious about developing a
>> game (as opposed to "I use diz forr learnin' teh programmingz!")
>> you should first come up with a justification why anyone
>> should play your game instead of the established ones.
>> Chance is that unique feature which really sets your
>> game apart doesn't require you to write your own full featured
>> Angband or whatever clone + extra whizbang + your feature.
>> I think it would be better if people who start new projects
>> compare them against Rogue (it's supposed to be a "roguelike"
>> after all) and try to reach that level of features + whatever
>> is supposed to make their game unique / interesting.
>
> I have written rogue-like roguelikes
Really?! Are they available for download?
> and they are boring. I need something to challenge me and
> hopefully come up with a fun game. I feel great when I am
> programming this, this is for my own self gratification.
Well, if that is the case you seem to be right on track.
>> Hell, every second post in this group seems to discuss the
>> issue of getting your field of view algorithm right.
>> Rogue didn't have a FOV algorithm! Unless your roguelike is
>> based on stealth action why the fuck do you even care to
>> implement it before you have an interesting game with
>> something worth viewing?!
>
> Because it is so damn easy to implement. And cool.
> Dude, where did you passion go?
See above, I still hate that silly 360 degree FOV
nonsense with passion! ;)
>> You can still bloat up later (see the innocent roots of
>> most of the major games today).
>>
>> I am still waiting for a post-apocalyptic roguelike,
>> or a vampire roguelike, or.. You know, not just a tech-demo,
>> a fully payable game without holes.
>
> Many many people have started post-apoc rls I wonder why no one
> finishes them? Me, I still love standard fantasy. Give me a dwarf
> with an axe anyday.
I envy you.
Perdurabo
> On Jan 14, 3:53 pm, copx <c...@gazeta.pl> wrote:
> Everyone over engineers on the first major rewrite. I am just
> following the trend. Step One: First you write give a decend attempt
> at a roguelike. Step 2: You decide all the things you could do better
> and completely blow things out of proportion with a rewrite. Step 3.
> You do only what is needed.
> I am just stuck on Step 2. And yes I am writing the next big
> roguelike, no question about it.
Aren't we all? ;-)
I'm still on Step 2 as well, and have been for the last nine months.
<snip>
>
> I have written rogue-like roguelikes and they are boring. I need
> something to challenge me and hopefully come up with a fun game. I
> feel great when I am programming this, this is for my own self
> gratification.
We're not twins as well? This is exactly how I feel myself.
> > KISS is a mighty fine advice indeed. Any Rogue/Larn/Omega
> > level roguelike with a fresh theme and some unique features
> > would be more interesting than something like "Lands of
> > Elderlore" and similar projects - procedural world generation,
> > natural ocean lines, ten trillions of independently acting
> > NPCs who pursue their own ambitions, detailed body part system
> > where you can even break your nails, advanced object
> > system which allows you to stuff objects into objects
> > and then ram said objects up your rectal entrance (with realistically
> > simulated rectal bleeding), and .. no playable game in
> > sight in this millennium.
>
> Ohh sounds like the gauntlet has being thrown down :P
Yep. Maybe we should form a support group for this sort of thing?
rec.games.roguelike.vapourware?
Best,
P.
pau...@mbnet.fi
> I am not stupid enough to write something I will never use
You don't know until you play the game. But if you first
make a complex engine you'll never know what actually
works in the gameplay. That's why I think game design
should come first and then you need to think how complex
game engine the game requires.
You don't need todo-list until you have programmed a
game you can play and test. Then you can see what is
missing and add that to the list.
Jeff Lait
> On Jan 14, 11:12 am, corremn <corr...@gmail.com> wrote:
>
> > On Jan 14, 3:53 pm, copx <c...@gazeta.pl> wrote:
> > Everyone over engineers on the first major rewrite. I am just
> > following the trend. Step One: First you write give a decend attempt
> > at a roguelike. Step 2: You decide all the things you could do better
> > and completely blow things out of proportion with a rewrite. Step 3.
> > You do only what is needed.
> > I am just stuck on Step 2. And yes I am writing the next big
> > roguelike, no question about it.
>
> Aren't we all? ;-)
I think Slash has recovered. At least talk about Guardian Angel has
disappeared in its place a series of entertaining games has shown up.
> I'm still on Step 2 as well, and have been for the last nine months.
Give it a couple of years and you'll recover :>
For faster progress to Step 3, I suggest participating in the upcoming
7DRL challenge!
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Jeff Lait
> I also realized while working on DDD that the player doesn't know what is
> going on inside the program. (This may seem obvious, but we tend to lose
> sight of this while coding.) All they see are the result of the algorithms
> within the game. You may a great idea of monster AI using genetic algorithms
> combined with a dynamic classifier system but if the visible the result is
> the same as a simple AI scheme where a monster attacks or flees based on an
> aggression factor and damage taken, why add the GA at all?
This is one of my hobby-horses here at RGRD. Thank you for so clearly
explaining it, saving me the effort.
This applies to more than just AI. Combat models must also be
carefully inspected. The result of combat is:
Deterministic + Random
The key to remember is that deterministic components that are small in
comparison to random components will disappear from the model that the
user sees. The 1% bonus you get to damage because you used a sword on
the 9th day of November will not show up against the 1d100 die roll
you did for damage.
> All the different visibility schemes is a good example of overkill in my
> opinion. Obviously you need a fast algorithm that looks good. However, it
> seems to me that the simple line of sight aglo combined with post artifact
> killing achieves the same result as the more complicated schemes from the
> players point of view and has the added benefit of being simple to code. Of
> course there may be special circumstances that require a more complicated
> scheme, but for SOL I really don't see the need to have some of these more
> complicated schemes when the end result is what is important. (And I may
> even argue that having a few artifacts on the screen probably doesn't bother
> a player all that much if the game play is keeping his attention, except for
> possibly the coder-player. :) )
Better yet, just get libtcod and spend your time on the GAME.
http://jice.nospam.googlepages.com/thedoryenlibrary
I just used libtcod for another project, an artificial life project on
a grid, but I wanted to display using coloured letters. It was a joy
to work with.
> There is also the issue of program complexity. A program is more than the
> sum of of its parts. As you add code the interactions within the program
> increase at a greater than linear rate.
Incidentally, this is why your goal as a programmer should always be
to minimize your line count. (Note: source lines, not comment lines,
but, on the other hand, you shouldn't be writing code that *needs*
pages of comments either!) This comes back to the AI point: "How can
I do this with the least code?" Which requires you know what it is
that you want to do. It never is "Genetic algorithm for monster AI"
unless this is your PhD. It is "monsters that adapt to users bottom-
feeding tactics, rendering them useless in time". You can do this
without genetic algorithms - you could, for example, explicitly make
for any easy bottom-feeding strategy. Say to begin with you can
always pillar dance. Then you hardcode an AI fix to pillar dancing
but only have the AI implement it after a certain pillar dance count
hits a key number. The user thus sees the AI appear to react to their
constant pillar dancing.
> What you really need to be, in my opinion, is a player first and programmer
> second.
Play your game. If you don't like it, why would anyone else?
> You also have to be ruthless. If you have to ignore the fact that
> you just spent 30 hours coding up this cool feature that doesn't add an
> ounce of benefit to the player and rip it out of the game. The only thing
> that really matters in the end is did you create an enjoyable game, a game
> that the player will want to play more than once?
Gameplay first, ideology second. You can always patch your ideology
later. More likely, the reason for the conflict was a
misunderstanding of your ideology that the gameplay was making
painfully obvious.
This ties back to my "reduce lines of code". Gameplay usually
requires the opposite. Overly-factored systems are bland. Avoid
factoring out flavour. Each new feature (item, monster, etc) should
require new code, not just fancy data base entries.
Perdurabo
>
> For faster progress to Step 3, I suggest participating in the upcoming
> 7DRL challenge!
> --
You know what, I think I will. I already have an idea in mind for my
entry. When is the 2009 competition?
Best,
P.
Jeff Lait
> On Jan 14, 2:32 pm, Jeff Lait <torespondisfut...@hotmail.com> wrote:
>
> > For faster progress to Step 3, I suggest participating in the upcoming
> > 7DRL challenge!
>
> entry. When is the 2009 competition?
The Call For Dates will occur in one week, the 21st. Three potential
weeks will be proposed then and voting will be open for a week.
Gerry Quinn
> Hell, every second post in this group seems to discuss the
> issue of getting your field of view algorithm right.
> Rogue didn't have a FOV algorithm!
Well, it did, actually - but it was a simple one based on lit or dark
rooms, corridors in four possible directions, plus the eight contiguous
locations. Shadowcasting and its variants are not the only sort of FOV.
I think some sort of FOV is a good idea in general as slowly uncovering
the map is a strong flavour element in typical roguelikes. So I'd not
argue with someone planning for that, though there is no reason why it
should be implemented right from the start.
But I quibble only about FOV, I agree with the rest of what you say.
- Gerry Quinn
--
Lair of the Demon Ape (a coffee-break roguelike)
<http://indigo.ie/~gerryq/lair/lair.htm>
Gerry Quinn
@w1g2000prm.googlegroups.com>, cor...@gmail.com says...
payable game without holes.
>
> Many many people have started post-apoc rls I wonder why no one
> finishes them? Me, I still love standard fantasy. Give me a dwarf
> with an axe anyday.
Same. Though I don't know where a demon ape overlord planning to
dominate the world with an army of apes and monkeys fits in the canon...
probably I shouldn't have started with the first idea that came into my
head ;-)
Perdurabo
> @w1g2000prm.googlegroups.com>, corr...@gmail.com says...
> payable game without holes.
>
>
>
> > Many many people have started post-apoc rls I wonder why no one
> > finishes them? Me, I still love standard fantasy. Give me a dwarf
> > with an axe anyday.
>
> Same. Though I don't know where a demon ape overlord planning to
> dominate the world with an army of apes and monkeys fits in the canon...
> probably I shouldn't have started with the first idea that came into my
> head ;-)
Overlord is clearly a Prestige class and Demon is clearly a Monster
Template. Probably about a CR13 monster.
I'm showing my age, aren't I?
Best,
P.
Gerry Quinn
@gmail.com says...
> I also realized while working on DDD that the player doesn't know what is
> going on inside the program. (This may seem obvious, but we tend to lose
> sight of this while coding.) All they see are the result of the algorithms
> within the game. You may a great idea of monster AI using genetic algorithms
> combined with a dynamic classifier system but if the visible the result is
> the same as a simple AI scheme where a monster attacks or flees based on an
> aggression factor and damage taken, why add the GA at all?
It only seems obvious to those of us who have learned it from
experience!
Even the above can be problematic: do you realise how annoying fleeing
monsters can be? Lots of quite stupid monsters that either move towards
the player to melee him, or in range of him to shoot, and occasionally
do something random... that's really a solid starting point for a
roguelike, and arguably you need nothing more!
> All the different visibility schemes is a good example of overkill in my
> opinion. Obviously you need a fast algorithm that looks good. However, it
> seems to me that the simple line of sight aglo combined with post artifact
> killing achieves the same result as the more complicated schemes from the
> players point of view and has the added benefit of being simple to code. Of
> course there may be special circumstances that require a more complicated
> scheme, but for SOL I really don't see the need to have some of these more
> complicated schemes when the end result is what is important. (And I may
> even argue that having a few artifacts on the screen probably doesn't bother
> a player all that much if the game play is keeping his attention, except for
> possibly the coder-player. :) )
Artefacts are of too kinds - the sort that are noticeable and annoying
to everyone, and the sort that are noticed only by coders. The latter
sort don't matter in the slightest, unless coding perfection rather than
gameplay is what motivates you.
> There is also the issue of program complexity. A program is more than the
> sum of of its parts. As you add code the interactions within the program
> increase at a greater than linear rate. This increases the risk of
> unintended consequences within the game, not just the increase risk of bugs.
Some coders actively seek this out! Personally I think it's unwise, but
chacun a son gout.
> What you really need to be, in my opinion, is a player first and programmer
> second. You also have to be ruthless. If you have to ignore the fact that
> you just spent 30 hours coding up this cool feature that doesn't add an
> ounce of benefit to the player and rip it out of the game. The only thing
> that really matters in the end is did you create an enjoyable game, a game
> that the player will want to play more than once?
Exactly. (Although while it is perhaps less typical of roguelikes than
most games, in general it's fine to have a game that only needs one
play, so long as that is an enjoyable journey!)
One tip I would have for roguelike coders, once they have a functioning
game and they think of some new things that would be fun like time bombs
or something... see if that can be done in the framework you already
have. After all, if you have a playable roguelike you have a framework
that is capable of many things already. Don't start writing code for
bombs, when with a moment's thought you will see that you just have to
summon a creature that lives for ten seconds without moving, damages
every nearby creature, and dies. (A heatseeking missile could lock onto
a nearby enemy and chase it... your AI probably already has that too.)
copx
> In article <gkjul4$967$1...@inews.gazeta.pl>, co...@gazeta.pl says...
>
>> Hell, every second post in this group seems to discuss the
>> issue of getting your field of view algorithm right.
>> Rogue didn't have a FOV algorithm!
>
> Well, it did, actually - but it was a simple one based on lit or dark
> rooms, corridors in four possible directions, plus the eight contiguous
> locations. Shadowcasting and its variants are not the only sort of FOV.
Well, when I wrote FOV I only meant these newfangled methods which are based
on giving the player character 360 degree vision, not the old
"light up when entered" stuff.
> I think some sort of FOV is a good idea in general as slowly uncovering
> the map is a strong flavour element in typical roguelikes.
I did not try to argue against that. I think Warp Rogue is the only
roguelike where you can see the entire map all the time. However, it
is obvious that implementing the visibility algorithms fashionable
right now is a significant challenge for some people, and that they
often seem to try to do it right after they managed to get the @
walking, i.e. seriously messed up priorities.
David Damerell
>On Jan 14, 3:53=A0pm, copx <c...@gazeta.pl> wrote:
>I am just stuck on Step 2. And yes I am writing the next big
>roguelike, no question about it.
Last person I heard that from was Krice.
>Of course and no one will play crap roguelikes anymore. Times have
>changed. I used to play moria on a black and white 13" screen with vi
>keys. Rock and Roll! Now give me all the luxuries of Crawl SS any
>day.
What's the biggest post-Crawl hit, judging by rgrm? POWDER. Not exactly
overburdened with body part systems and suchlike, is it?
--
David Damerell <dame...@chiark.greenend.org.uk> flcl?
Today is Second Aponoia, January.
Darren Grey
> Gerry Quinn wrote:
>
> > I think some sort of FOV is a good idea in general as slowly uncovering
> > the map is a strong flavour element in typical roguelikes.
>
> I did not try to argue against that. I think Warp Rogue is the only
> roguelike where you can see the entire map all the time. However, it
> is obvious that implementing the visibility algorithms fashionable
> right now is a significant challenge for some people, and that they
> often seem to try to do it right after they managed to get the @
> walking, i.e. seriously messed up priorities.
Really? I've not seen much evidence of that. I certainly haven't
felt compelled to do anything more advanced than line-casting, and
that seems to be what most people go for at first. I see the more
advanced algorithms being discussed only by the people that have
actually used them, and not by newbie developers like myself. And if
people want to play around with the more complicated stuff they're
quite welcome to - it can be fun just for its own sake.
--
Darren Grey
antoine....@gmail.com
> corremn wrote:
> detailed body part system
> where you can even break your nails, advanced object
> system which allows you to stuff objects into objects
> and then ram said objects up your rectal entrance
But what if this was a key game mechanic?
A.
corremn
True enough, I was joking about the "not being stupid enough" bit. I
have the game detailed out, and this is my TODO list for the engine of
the game. Besides I know that I went over the top, as my title
suggests.
corremn
>
> Don't start writing code for
> bombs, when with a moment's thought you will see that you just have to
> summon a creature that lives for ten seconds without moving, damages
> every nearby creature, and dies. (A heatseeking missile could lock onto
> a nearby enemy and chase it... your AI probably already has that too.)
>
could fit that into a rougelike...
corremn
>
> > I have written rogue-like roguelikes
>
> Really?! Are they available for download?
I lost my hosting and I didn't keep the code or binaries. However I
was refering to the Warlock of Firetop Mountain game and sequals.
> > Because it is so damn easy to implement. And cool.
> > Dude, where did you passion go?
>
> See above, I still hate that silly 360 degree FOV
> nonsense with passion! ;)
>
Passions still there, Check. Are you going to attempt a new
roguelike?
> > Many many people have started post-apoc rls I wonder why no one
> > finishes them? Me, I still love standard fantasy. Give me a dwarf
> > with an axe anyday.
>
> I envy you.
Yep, I have tried every other genre, and I just keep coming back to
fantasy, not that I wouldn't love a post apoc game if it was good.
Sounds like a good topic for warp rogue 2.
copx
Pray for forgiveness?
copx
[snip]
> Passions still there, Check. Are you going to attempt a new
> roguelike?
Nothing is planned.
Ray Dillinger
> Overlord is clearly a Prestige class and Demon is clearly a Monster
> Template. Probably about a CR13 monster.
I recognize those words (Prestige class, CR) as being related to
some iteration of D&D. But never having played a D&D that had them,
I don't know exactly what they mean. I have thought of them as
being in the lexicon of a relatively current player.
Bear
Gerry Quinn
@f3g2000vbf.googlegroups.com>, darrenj...@gmail.com says...
You may be right. And, in fact, you can go even simpler than Rogue if
you want by (say) revealing the map for 10 squares around the player
character.
- Gerry Quinn
corremn
wrote:
> Quoting corremn <corr...@gmail.com>:
>
> >On Jan 14, 3:53=A0pm, copx <c...@gazeta.pl> wrote:
> >I am just stuck on Step 2. And yes I am writing the next big
> >roguelike, no question about it.
>
> Last person I heard that from was Krice.
Please dont compare me to "I've-finished-a-roguelike" Krice, I was
just pissing into the wind. Of course the next big RL will NOT come
from me, it will either come from Blizzard or Krice .
Perdurabo
Perhaps it already has - DIablo 3?
*ducks and runs*
Best,
P.
Perdurabo
I think part of the problem with that is that anything more than
simple beamcasting has, historically, not been explained that well,
certainly not well enough to a point where a developer new to either
programming or roguelikes could pick one up and just insert it
straight into their code with a minimum of changes.
Certainly when I moved to using one of the recursive shadowcasting
algorithms on roguebasin in my own semi-vapourware project it took me
the best part of an evening actually figuring out how to use the
algorithm since the author hadn't actually provided any details on how
to call it or which parameters to use.
And I'm a professional software engineer with 12 years experience
coding in a wide variety of languages and situations.
Best,
P.
Gerry Quinn
says...
Well, I have not heard of either! Never did the D&D thing :-)
- Gerry Quinn
Gerry Quinn
says...
Actually I'd recommend this - or a circular pattern which will be
geometrically inconsistent but will look better - for anyone deterred by
complex FOV concepts.
I think the Diablo series uses this, in fact.
Just mark squares withing a certain radius of the player as seen after
every move. Sure, you will be able to see behind walls, but I don't
think it will hurt gameplay - you still have to find out how to get to
those enticing areas.
Jeff Lait
> In article <3ed626b5-c17d-48ba-991c-8935dd719b39
The 7drl Numbers, http://iceyboard.no-ip.org/projects/numbers/, does
this to great effect. Since you are exploring a maze it actually
plays *better* with this than it would with a traditional FOV. The
mazes are relatively narrow so you can use the ability to peek through
walls to greatly improve your exploration, avoiding the frustration
the maze would otherwise cause you.
Which goes to show that some times simpler is actually a better game
mechanic.
Darren Grey
> In article <MPG.23d8be3fb310281...@news.indigo.ie>, ger...@indigo.ie
> says...
>
> > You may be right. And, in fact, you can go even simpler than Rogue if
> > you want by (say) revealing the map for 10 squares around the player
> > character.
>
> Actually I'd recommend this - or a circular pattern which will be
> geometrically inconsistent but will look better - for anyone deterred by
> complex FOV concepts.
>
> I think the Diablo series uses this, in fact.
>
> Just mark squares withing a certain radius of the player as seen after
> every move. Sure, you will be able to see behind walls, but I don't
> think it will hurt gameplay - you still have to find out how to get to
> those enticing areas.
The talk here about simplifying FOVs has made me think about using
exactly this actually. My current code is a bit slow, and is so
messily written it'd be hard for me to simplify - better for me to
resort to something simpler and worry about more realistic vision much
later. 360 degree vision that penetrates walls makes enough sense in
the game theme anyway.
--
Darren Grey
corremn
Referring to it I was.
Darren Grey
I changed my mind - this is horrible. A constant visual area ruins
exploration and seeing through walls ruins suspense, whilst also
making the game much easier and less interesting. It's also not
noticeably quicker than the linecasting (my speed issue must lie with
the redraws). I thus conclude that even a basic Line of Sight
algorithm is worth programming in because it does add a lot to
gameplay. I'll have to look into this shadowcasting some time to see
what all the fuss is about...
--
Darren Grey
Gerry Quinn
@g38g2000yqn.googlegroups.com>, darrenj...@gmail.com says...
I think it depends on the game. For some games it might improve
exploration and add motivation (how do I get to that tempting thing I
can see?). Obviously extra information makes the game a bit easier, but
that can be balanced by making some other aspect(s) harder.
How much easier it makes the game will depend a lot on what sort of
layout your game has. Diablo was based on had large open areas, and
this system is almost the same as shadowcasting in such circumstances.
If it's so bad, why do many games include options for monster and item
detection, magic mapping, etc.?
Anyway, my point was not directed towards the speed off the algorithm
but the complexity. The algorithm under discussion is very easy to
implement. I agree that a shadowcasting system is probably ideal for
most roguelikes.
Chris O
> In article <b6667816-7b14-44ec-8124-c70869c75697
> > I changed my mind - this is horrible. A constant visual area ruins
> > exploration and seeing through walls ruins suspense, whilst also
> > making the game much easier and less interesting. It's also not
> > noticeably quicker than the linecasting (my speed issue must lie with
> > the redraws). I thus conclude that even a basic Line of Sight
> > algorithm is worth programming in because it does add a lot to
> > gameplay. I'll have to look into this shadowcasting some time to see
> > what all the fuss is about...
>
> I think it depends on the game. For some games it might improve
> exploration and add motivation (how do I get to that tempting thing I
> can see?). Obviously extra information makes the game a bit easier, but
> that can be balanced by making some other aspect(s) harder.
Atari's Adventure had mazes and no line of sight calculation. If it
was on the screen, you could see it.
corremn
> On Jan 14, 10:48 pm, copx <c...@gazeta.pl> wrotte
>> I think it would be better if people who start new projects
>> compare them against Rogue (it's supposed to be a "roguelike"
>> after all) and try to reach that level of features + whatever
>> is supposed to make their game unique / interesting.
>
> > > I have written rogue-like roguelikes and they are boring.
>
> > Really?! Are they available for download?
>
> I lost my hosting and I didn't keep the code or binaries. However I
> was refering to the Warlock of Firetop Mountain game and sequals.
Ok so this got me searching for lost binaries. I found the WOFM 7drl
and after playing it realised that it was quite fun (to me anyway).
Just wandering down a dungeon and killing orcs with an axe was quite
forfilling. No magic, no skill tree, no fancy help, no gods to call
upon. Just my trusty axe and armour( and my crossbow when I remember
to use it). While this game is not quite rogue ( it is a 7drl after
all), I do agree that simple is still fun. However I really think that
the anti-aliased fonts and 24-bit colour make it more enjoyable. (I
find that curses based games are bad on the eyes now-a-days)
Simon Richard Clarkstone
iLarn does just one square in each direction. There is a temporary
vision upgrade that gives you 3 in each direction, letting you see
adjacent maze passages too. This is suitable for iLarn's
mazes-with-rectangles-cut-out level design. Also, it used CnC-style
FoV: once something was explored, you continued to see it even once you
moved away.
--
Simon Richard Clarkstone:
s.r.cl?rkst?n?@dunelm.org.uk / s?m?n_cl?rkst?n?@yahoo.co.uk
| My half-daughter went to the GMH riots |
| But all I got was this stupid ¥-shirt. |