http://roguebasin.com/api.php?action=feedcontributions&user=Stu&feedformat=atomRogueBasin - User contributions [en]2024-03-28T09:38:33ZUser contributionsMediaWiki 1.36.0http://roguebasin.com/index.php?title=2010_ARRP&diff=221512010 ARRP2010-09-19T03:21:19Z<p>Stu: fix place in sort order</p>
<hr />
<div>= 2010 Annual Roguelike Release Rarty =<br />
<br />
The deadline for the 2010 [[The annual roguelike release party|Annual Roguelike Release Party]] is September 19th 2010. This is the nearest Sunday to 6 months after the 2010 7DRL competition.<br />
<br />
Those planning to participate are encouraged to declare their planned releases below, so that we don't all feel too lonely. Announcement is not necessary though - simply release your game or update on the above date to participate.<br />
<br />
== Releases ==<br />
* [[Cracks and Crevices]] by [[Stu George]]<br />
* [[Toby the Trapper]] by [[Darren Grey]]<br />
* [[The cave]] by [[jice]]<br />
* [[Umbra]] 10.09 Alpha, by [[User:dominikmarczuk|Mingos]] & [[Jice]]<br />
<br />
<br />
== Announced roguelikes ==<br />
<br />
(named roguelikes, in alphabetical order)<br />
<br />
* <strike>[[AarrrRL]]</strike> by [[User:Fisticuffs|Heroic Fisticuffs]]<br />
* [[Albion]] by [[OrangyTang]]<br />
* [[CrashRun]] by Dana<br />
* [[Dance of Death]] by [[Nolithius]]<br />
* [[Demonhunt]] by [[Fobbah]]<br />
* [[Dungeon Monkey Unlimited]] by [[Joseph Hewitt]]<br />
* [[Dweller]] by Bj&ouml;rn Ritzl<br />
* [[Exploring The Bleak]], Release Candidate by [[User:5v3nd0ttg|Nathaniel Inman]]<br />
* [[Fall From Heaven]] by [[User:Jolly Roger]].<br />
* [[Gruesome]] by Darren Grey<br />
* [[Kharne]] by Dave Moore<br />
* [[LambdaRogue]], the big 1.6 update by [[Mario Donick]]<br />
* [[NLarn]] by [[Joachim de Groot]] and Johanna Ploog<br />
* [[Plains of Sedia]], Alpha Candidate by [[User:5v3nd0ttg|Nathaniel Inman]]<br />
* [[Prospector]] by magellan<br />
* [[Squirm]] by Aging Minotaur<br />
* [[Teratogen]] by Risto Saarelma<br />
* [[The cave]] - <strike>Chapter I (tutorial part)</strike> Walking @ by jice<br />
* [[Traction Edge]], techdemo by [[Mongrol]]<br />
* [[cataclysm]], by [[Whales]]<br />
* [[SewerJacks]], by [[corremn]]<br />
(still unnamed roguelikes)<br />
<br />
* ?? by Paul List<br />
* ?????? by purplearcanist<br />
* ???????? by humasect</div>Stuhttp://roguebasin.com/index.php?title=2010_ARRP&diff=221502010 ARRP2010-09-19T03:20:56Z<p>Stu: Moved CnC from announced to Released</p>
<hr />
<div>= 2010 Annual Roguelike Release Rarty =<br />
<br />
The deadline for the 2010 [[The annual roguelike release party|Annual Roguelike Release Party]] is September 19th 2010. This is the nearest Sunday to 6 months after the 2010 7DRL competition.<br />
<br />
Those planning to participate are encouraged to declare their planned releases below, so that we don't all feel too lonely. Announcement is not necessary though - simply release your game or update on the above date to participate.<br />
<br />
== Releases ==<br />
* [[Toby the Trapper]] by [[Darren Grey]]<br />
* [[The cave]] by [[jice]]<br />
* [[Umbra]] 10.09 Alpha, by [[User:dominikmarczuk|Mingos]] & [[Jice]]<br />
* [[Cracks and Crevices]] by [[Stu George]]<br />
<br />
== Announced roguelikes ==<br />
<br />
(named roguelikes, in alphabetical order)<br />
<br />
* <strike>[[AarrrRL]]</strike> by [[User:Fisticuffs|Heroic Fisticuffs]]<br />
* [[Albion]] by [[OrangyTang]]<br />
* [[CrashRun]] by Dana<br />
* [[Dance of Death]] by [[Nolithius]]<br />
* [[Demonhunt]] by [[Fobbah]]<br />
* [[Dungeon Monkey Unlimited]] by [[Joseph Hewitt]]<br />
* [[Dweller]] by Bj&ouml;rn Ritzl<br />
* [[Exploring The Bleak]], Release Candidate by [[User:5v3nd0ttg|Nathaniel Inman]]<br />
* [[Fall From Heaven]] by [[User:Jolly Roger]].<br />
* [[Gruesome]] by Darren Grey<br />
* [[Kharne]] by Dave Moore<br />
* [[LambdaRogue]], the big 1.6 update by [[Mario Donick]]<br />
* [[NLarn]] by [[Joachim de Groot]] and Johanna Ploog<br />
* [[Plains of Sedia]], Alpha Candidate by [[User:5v3nd0ttg|Nathaniel Inman]]<br />
* [[Prospector]] by magellan<br />
* [[Squirm]] by Aging Minotaur<br />
* [[Teratogen]] by Risto Saarelma<br />
* [[The cave]] - <strike>Chapter I (tutorial part)</strike> Walking @ by jice<br />
* [[Traction Edge]], techdemo by [[Mongrol]]<br />
* [[cataclysm]], by [[Whales]]<br />
* [[SewerJacks]], by [[corremn]]<br />
(still unnamed roguelikes)<br />
<br />
* ?? by Paul List<br />
* ?????? by purplearcanist<br />
* ???????? by humasect</div>Stuhttp://roguebasin.com/index.php?title=News&diff=22149News2010-09-19T03:19:10Z<p>Stu: Added release of Cracks and Crevices for ARRP</p>
<hr />
<div><!-- Add new news to the top --><br />
* 19 Sep 2010 - [[Umbra]] 10.09 Alpha [http://umbrarumregnum.110mb.com/download/umbra released]<br />
* 19 Sep 2010 - [[The cave]] 0.0.1 [https://roguecentral.eptalys.net/projects/the-cave/files released]<br />
* 19 Sep 2010 - [[Cracks and Crevices]] 0.5 [https://redmine.bloodycactus.com/projects/sdlrl released]<br />
* 18 Sep 2010 - [[Fall From Heaven]] 0.0.4c1 [http://www.roguetemple.com/forums/index.php?topic=1286.0 released]<br />
* 11 Sep 2010 - [[Hydra Slayer]] 3.0 [http://www.roguetemple.com/forums/index.php?topic=1270.msg9127#msg9127 released]<br />
* 11 Sep 2010 - [[Neon]] 0.3.2 [http://sourceforge.net/projects/neon/ released]<br />
* 09 Sep 2010 - [[Triangle Wizard]] R 9.03 [http://www.trianglewizard.webs.com/ released]<br />
* 06 Sep 2010 - [[Triangle Wizard]] R 9.02 [http://www.trianglewizard.webs.com/ released]<br />
* 05 Sep 2010 - [[ToME]] 4.0.0 Beta10 [http://blog.te4.org released]<br />
* 04 Sep 2010 - [[UnNetHack]] 3.5.3 [http://unnethack.wordpress.com/2010/09/05/unnethack-3-5-3-released/ released]<br />
* 31 Aug 2010 - [[Rogue Survivor]] Alpha 4.11 [http://roguesurvivor.blogspot.com/ released]<br />
* 31 Aug 2010 - [[Lost Labyrinth]] 4.1.0 [http://www.lostlabyrinth.com/ released]<br />
* 30 Aug 2010 - [[Frozen Depths]] 1.04 [http://koti.mbnet.fi/frozend/ released]<br />
* 30 Aug 2010 - [[SilverQuest]] OPL 081610 [http://arwym.com/silverquest/ released]<br />
<div style="text-align:right"><br />
''See also: [[Old news]]''<br />
</div><br />
<br />
[[Category:Main]]</div>Stuhttp://roguebasin.com/index.php?title=Cracks_and_Crevices&diff=22148Cracks and Crevices2010-09-19T03:16:50Z<p>Stu: Updated to v0.5 for ARRP</p>
<hr />
<div>{{game-alpha| name = Cracks and Crevices<br />
|developer = [[Stu George]]<br />
|theme = Fantasy<br />
|influences = Underdark<br />
|released = 2007 Feb 24<br />
|updated = 2010 Sep 18<br />
|licensing = GPL<br />
|language = [[C]]<br />
|platforms = Windows, Linux<br />
|interface = [[Graphical ascii tiles]], [[Keyboard]]<br />
|length = short<br />
|site = https://redmine.bloodycactus.com/projects/show/sdlrl<br />
}}<br />
<br />
''Cracks and Crevices'' is a graphical ascii roguelike game written by Stu, using [[SDL]]. It takes ideas from my other roguelikes like [[UnderDark]] and [[SRL]].<br />
<br />
The originally idea was to keep things simple in order to create an actual working game instead of a huge mountain of ideas that never get implemented or see the light of day.<br />
<br />
Its designed to not be so hardcore as [[NetHack]] and [[Crawl]] but not be as easy as [[Larn]]. It does provide help for the beginner and cue's when the game starts.<br />
<br />
== Story ==<br />
''Cracks and Crevices'' is about life in the small village of ''Danforths Outcrop'', hewn into the rock at an opening to a large crevice. The game starts with you, a young person of the village on the verge of your adulthood test, which is to survive two days in the labyrinth of the crevice before you will be allowed back into town. Only the strong survive to increase the strength of the village, and if you survive you will be allowed back into town, there you can explore or re-enter the labyrinth or take up some quests offered by the town clerk.<br />
<br />
<br />
== Features ==<br />
* Semi real-time gameplay<br />
* Facing FOV<br />
* Stackable spell / weapon system<br />
* Magic System based on MP that regenerates over time or by wielding/wearing mage type items<br />
* Weapons, Potions, Spell books, mushrooms, rings, armor, shields, etc<br />
* No preset classes or skill systems. Development of @'s class is up to the player.<br />
* Customer key configuration<br />
* Message Logs<br />
* Character dumps<br />
* Save / Load<br />
* Permadeath<br />
* Working towns (shops, inns, banks, etc)<br />
* Special NPC's<br />
<br />
<br />
== Time and Modes ==<br />
''Cracks and Crevices'' uses semi-realtime to set the game play. There is an Easy / Medium / Hard mode of play.<br />
<br />
=== Easy ===<br />
* Easy mode gives you 3 seconds to make a move before you loose your current turn and all the monsters get to move. <br />
* More Money to start the game with<br />
* Circular FOV<br />
<br />
=== Medium ===<br />
* 1.5 seconds per move<br />
* Facing directional cone FOV<br />
<br />
=== Hard ===<br />
* 1/2 second per move<br />
* Facing directional cone FOV<br />
<br />
== Class System ==<br />
There is no preset class system or skill system in the game, but it does implement 'Instant Fuzion' game system underneath, there are stats and skills. It is left up to the player to choose the direction of development, if they want to focus on pure melee fighter type or mage type or something in between. There is no restriction on wielding swords and casting spells at the same time. There are pros and cons to each and heavy armor may not be the best choice for a spellcaster...<br />
<br />
<br />
== Current Status ==<br />
0.5 has many changes over 0.4 (not the least is the implementation of Instant Fuzion), for a more complete changelog see the [https://redmine.bloodycactus.com/projects/sdlrl/repository/revisions/v0.5/entry/docs/Changelog Changelog].<br />
<br />
==External Links==<br />
* [https://redmine.bloodycactus.com/projects/sdlrl/files Downloads]<br />
* [https://redmine.bloodycactus.com/projects/sdlrl/issues Buglist]</div>Stuhttp://roguebasin.com/index.php?title=2010_ARRP&diff=220712010 ARRP2010-09-15T01:40:48Z<p>Stu: added cnc to the list...</p>
<hr />
<div>= 2010 Annual Roguelike Release Rarty =<br />
<br />
The deadline for the 2010 [[The annual roguelike release party|Annual Roguelike Release Party]] is September 19th 2010. This is the nearest Sunday to 6 months after the 2010 7DRL competition.<br />
<br />
Those planning to participate are encouraged to declare their planned releases below, so that we don't all feel too lonely. Announcement is not necessary though - simply release your game or update on the above date to participate.<br />
<br />
== Announced roguelikes ==<br />
<br />
(named roguelikes, in alphabetical order)<br />
<br />
* <strike>[[AarrrRL]]</strike> by [[User:Fisticuffs|Heroic Fisticuffs]]<br />
* [[Albion]] by [[OrangyTang]]<br />
* [[Cracks and Crevices]] by [[Stu George]]<br />
* [[CrashRun]] by Dana<br />
* [[Demonhunt]] by [[Fobbah]]<br />
* [[Dweller]] by Bj&ouml;rn Ritzl<br />
* [[Exploring The Bleak]], Release Candidate by [[User:5v3nd0ttg|Nathaniel Inman]]<br />
* [[Fall From Heaven]] by [[User:Jolly Roger]].<br />
* [[Gruesome]] by Darren Grey<br />
* [[Kharne]] by Dave Moore<br />
* [[LambdaRogue]], the big 1.6 update by [[Mario Donick]]<br />
* [[NLarn]] by [[Joachim de Groot]] and Johanna Ploog<br />
* [[Plains of Sedia]], Alpha Candidate by [[User:5v3nd0ttg|Nathaniel Inman]]<br />
* [[Prospector]] by magellan<br />
* [[Squirm]] by Aging Minotaur<br />
* [[Teratogen]] by Risto Saarelma<br />
* [[The cave - <strike>Chapter I (tutorial part)</strike> Walking @]] by jice<br />
* [[Traction Edge]], techdemo by [[Mongrol]]<br />
* [[cataclysm]], by [[Whales]]<br />
(still unnamed roguelikes)<br />
<br />
* ?? by Paul List<br />
* ?????? by purplearcanist<br />
<br />
== Other releases ==<br />
<br />
* [[Umbra]] 10.09 Alpha, by [[User:dominikmarczuk|Mingos]] & [[Jice]]</div>Stuhttp://roguebasin.com/index.php?title=Talk:NLarn&diff=19498Talk:NLarn2009-11-03T01:35:04Z<p>Stu: Created page with 'Currently its listed as a "rewrite", but its not a rewrite, its inspired by, as it does not use the Larn codebase. (I'm a Larn fan so.. GREAT STUFF) ~~~~'</p>
<hr />
<div>Currently its listed as a "rewrite", but its not a rewrite, its inspired by, as it does not use the Larn codebase. (I'm a Larn fan so.. GREAT STUFF) [[User:Stu|Stu]] 01:35, 3 November 2009 (UTC)</div>Stuhttp://roguebasin.com/index.php?title=Talk:Evolution&diff=18964Talk:Evolution2009-08-27T13:12:07Z<p>Stu: </p>
<hr />
<div>Did this really have a release on 2006 Jul 04 ? No official site I could find. [[User:PaulBlay|PaulBlay]]<br />
<br />
: This is not wikipedia. If you are not able to confirm something it is not good enough reason to delete informaion. There is no offical site currently. <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 23:34, 26 August 2009 (UTC)<br />
: I actually agree with paulblay here, a release is not just any old content, it specifically states that this game was released SOMEWHERE. And if it wasn't, I think the offending "release date" should be removed. There's been a glut of these talkie talkie pages recently. I don't mind them, but it's going too far if they claim to have fake releases. - [[elig]]<br />
<br />
:: I happen to be game author and one who added this content. Effectively that accuses me of providing false information. Unfortunately site where release was announced (World of Roguelike) is down long ago. Now I cannot prove it. Besides, you'd need to understand Polish well to dig through. Wait! Do you consider Actively Developing Roguelikes to be reliable source? If yes, the date July 4th 2006 is written there. <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 08:58, 27 August 2009 (UTC)<br />
<br />
:: Elig, if Michal says that's when there was a release, then we should believe it. What makes you think it would be a fake release date? And if it was a fake release date, whats the big deal in the overall scheme of things... nothing! Lets not go down the crapper like wikipedia and start demanding that if it wasn't in a print magazine or newspaper, it didn't happen. [[User:Stu|Stu]] 13:12, 27 August 2009 (UTC)</div>Stuhttp://roguebasin.com/index.php?title=RogueBasin_talk:Community_Portal&diff=18499RogueBasin talk:Community Portal2009-07-12T16:41:20Z<p>Stu: </p>
<hr />
<div>{{talkpagetool}}<br />
<br />
<table class="infobox" style="float:right;clear:right; width: 11em; border: 1px solid #93BACB; background:#E0E7EF;font-size:95%; margin:1em; line-height:1.4em;"><br />
<tr><br />
<th style="background:#C2D8EF; padding:.4em; margin:1em; font-size:105%/j">Archives</th><br />
</tr><br />
<tr><br />
<td><br />
* [[/Archive 1|1]]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Game Announcements ==<br />
If you have a new game/version/release to announce to the world, Make an edit to the [[News]] page, and please follow the existing format. If you want to generate discussion and receive feedback and comments, make sure to head over to [http://roguetemple.com RogueTemple] and use their forums, as well as [[rgrd]]. [[User:Stu|Stu]] 14:21, 16 May 2008 (CEST)<br />
<br />
<br />
<br />
== Link breaks wiki, News at 11 ==<br />
<br />
The following link (from 'dead-end pages') fails to display anything other than nasty error messages. Possibly due to illegal characters in title?<br />
<br />
http://roguebasin.roguelikedevelopment.org/index.php?title=Hansj%3F%84%E2%80%9A%3F%82%C2%B6rg_Malthener<br />
<br />
Other 'bug'ish news. [[SDL]] exists, but searching for SDL will return zero hits. [[User:PaulBlay|PaulBlay]]<br />
<br />
The error with Hansjoergs page are not because of illegal characters in the URL. They should be valid even though they look like at least twice encoded in Unicode. There seems to something terrible broken recently with non 7-bit characters. Database update maybe? Try searching for any special character like e.g. '????' (U+00C4 "LATIN CAPITAL LETTER A WITH DIAERESIS" if it gets mangled). Even the db search bails with an error. --[[User:Bhaak|Bhaak]] 15:58, 23 March 2009 (CET)<br />
<br />
== Spambots ==<br />
<br />
There was a small spambot attack recently, dunno how they overrid the spam protection (what is the current spam protection)? I had no luck blocking them via the sysop special pages. Is there any way to delete user accounts?<br />
<br />
--[[User:Slash|Slash]] 01:08, 12 Apr 2007 (CEST)<br />
<br />
I think it may be useful to update MediaWiki software to the latest version. The one that's currently installed is so old, the mind boggles. The current version has captchas and other stuff, and it's much easier to revert vandalism. [[User:Grue|Grue]] 10:23, 12 Apr 2007 (CEST)<br />
<br />
IIRC Bj????rn set up the latest version when the server translation was performed? Also, this is plain vandalism, not even spam (deleting '+' and everything after a '&', what use would that have?<br />
--[[User:Slash|Slash]] 17:19, 12 Apr 2007 (CEST)<br />
:It can't be the latest version. For example when you look at the diff between two revisions, there's no link to edit the revision. This feature was in Wikipedia since I joined it, probably, and that was very long time ago. So, to revert vandalism one has to click three times instead of two, pretty annoying. I don't know, maybe it's configured incorrectly, but it definitely looks very outdated. [[User:Grue|Grue]] 10:52, 13 Apr 2007 (CEST)<br />
<br />
:It's definitely an old version, the [[Special:Version]] page shows as using version 1.3.9 ''(The 1.3.x line was last updated in November 2005)''. The newest release is 1.10.0 although most modern versions of MediaWiki require PHP5 though ''(since version 1.7)''. The latest version that still supports PHP4 is 1.6.10 available [http://www.mediawiki.org/wiki/Download here]. 1.6.10 was released on 20th February 2007. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
::THe Wiki is currently running MediaWiki 1.6.10. Hopefully we won't see any more spam attacks. -- Bjorn 09:50 3 Jul 2007<br />
<br />
There was another spammer, although it could be a person doing it, rather than a bot. It was [[User:Yaxiaexx099|this account]] doing it, and [http://roguebasin.roguelikedevelopment.org/index.php?title=Dalhxf&oldid=12449 this] was was what he did.<br />
<br />
Here we go again, looks like the spambots are returning? Three new pages filled with.. something. [[Aldan|Here]], [[Generosity|here]] and [[Nourished|here]], created by three (new?) users in a short succession. Are there any anti-spambot guidelines somewhere, since I'm not sure of what to do, except for reporting? [[User:Solarnus|Solarnus]] 23:48, 8 January 2009 (CET)<br />
<br />
:Wonder if there is any way we can give rights to some users to approve new users so we dont have these spambots sign up, or we need to modify the captcha code to stop this crap. [[User:Stu|Stu]] 14:31, 12 January 2009 (CET)<br />
<br />
::I would suggest try giving a selected few, trusted users the rights to approve new users. The use of CAPTCHAs is kinda useless as of today (well, except for scaring off scriptkiddies), since it's an out of date "security measure" and there's some various techniques to bypass it. It's also a problem for ie, visual impaired people having trouble reading the characters (more info over at wikipedia, for those of you not being convinced it's a crappy technology..). [[User:Solarnus|Solarnus]] 15:50, 23 January 2009 (CET)<br />
<br />
<br />
<br />
<br />
<br />
== All those guides! ==<br />
<br />
Where did all those good guides at http://www.roguelikedevelopment.org/ go? according to the news, the content has been moved to this wiki but I can't find any of those guides! me want's 'em badly!<br />
[[User:Solarnus|Solarnus]] 11:28, 16 January 2008 (CET)<br />
:Sorry, I meant of course that alot of guides are missing, as least most of the map algorithm stuff previously found on the old site is missing here at the wiki. Anyone got copies of those guides, please? [[User:Solarnus|Solarnus]] 14:28, 23 January 2008 (CET)<br />
::And you looked in the map section of [[Articles]]? All the ones I recall are there. Perhaps you can use the wayback machine to calculate which ones seem to be missing? [[User:Duerig|Duerig]] 17:12, 23 January 2008 (CET)<br />
:::lol, the wayback what..? No, realy, I know there's alot missing from the site. Some examples are the guides written by Mike Anderson (Dungeon-Building Algorithm, Fractal Landscapes) and Radomir "The Sheep" Dopieralski (Recursive LvL Generation) [[User:Solarnus|Solarnus]] 17:52, 23 January 2008 (CET)<br />
::::Look at this URL. It is from www.archive.org, the wayback machine for the Internet: http://web.archive.org/web/20060114055601/http://roguelikedevelopment.org/ but before you go adding all of the articles to the wiki, you should know that there was some effort to move them over, but only if the original authors could be found to give permission. So you should check with an admin here about what to do. [[User:Duerig|Duerig]] 08:50, 24 January 2008 (CET)<br />
:::::Oh crap, I thought I could just go and add what I managed to find, since it had already been released on the site o.0' Pardon me, I'm too quick sometimes, doing stuff without thinking first. <br /> But, IMHO, not moving over all that stuff just because the original author couldn't be found kinda buggers me, that's just wast of time and good knowledge, stupidlly forcing to "reinvent the wheel". And it buggers me even more, since obvisiouly (spelling?) it can still be found on the web thanks to that wayback machine you're talking about (thanks for that link btw, would've never thought of that). <br /> Thanks for telling me dude, I'll try slowing down/backing off and poke an admin about it before doing anything else.<br /> <br />Anyway, should the "previously missing" [[Dungeon-Building Algorithm]] article I dug up yesterday be removed, or just leave it for now and hope for the better? [[User:Solarnus|Solarnus]] 13:50, 24 January 2008 (CET)<br />
<br />
<br />
::::::Is there any chance of the articles being reposted on the original site until they can be ported here? They're only text documents, and a number of them were very good references. Most of the original files are not stored on wayback machine, so forn ow they are lost for good. [[User:lapoubelle|lapoubelle]] 30 April 2008<br />
<br />
I have spent most of today searching for and collecting all of the articles that were on the old system but not on roguebasin. I was able to recover all but two. Those two and links to the archives are at [[User:Duerig]]. That way they should be safe until we can decide how to handle them. If the admins have a problem with this, I'll host them on my own domain if I have to. Let me know if you can find information on either of the two remaining articles. [[User:Duerig|Duerig]] 21:53, 1 May 2008 (CEST)<br />
<br />
<br />
<br />
<br />
== Game or project? ==<br />
<br />
Template [[Template:Angband-variant]] asks for status field. Then game entry is added to "status games" category. This works well for stable games and defunct games but fails for alpha, beta and talkie talkie *projects*. Thus any Angband variants which classify themselves as having alpha or beta status do not get included in proper category. Any ideas how to correct that without destroying too much existing work? I would opt for removing status field and adding all variants to categories manually. Other choice is to spilt template into several like it was done with [[Template:Gameinfo]]. What are others opinions on this? <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 16:18, 19 August 2008 (CEST)<br />
<br />
: I think the best bet is to split the template like the Gameinfo did. I presume there was a good reason to do that split rather than use the status field cleverly. I don't like people having to manually add the category tag as that will result in people forgetting to categorize the variant at all. --[[User:JeffLait|JeffLait]] 05:21, 21 August 2008 (CEST)<br />
<br />
:: Foundations are lain. I am going to wait some more time before proceeding to change all Angband variant pages in case better ideas show up or someone has objections. <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 15:03, 25 August 2008 (CEST)<br />
<br />
== 1krl ==<br />
<br />
We should add this to the wiki, but I'm not sure where.<br />
http://1024brl.googlepages.com/<br />
(and a link to the rgrd posts of course.<br />
--[[User:Soyweiser|Soyweiser]] 02:00, 22 August 2008 (CEST)<br />
<br />
== Rule of thumb for new -> old news? ==<br />
<br />
How many months (or how many posts) should be in [[News]] before you should move some to Old News? I would suggest that four months or so is enough as the 'News' section is currently longer than the rest of the Main page. [[User:PaulBlay|PaulBlay]]<br />
<br />
:I think that we should move all news from 2008 to Old News. We actually don't really need the [[News]] page to show news older than a month, as it is intended to show '''new''' releases. I will move all news from 2008 now. [[User:Nate879|Nathan Stoddard]] 22:34, 22 March 2009 (CET)<br />
<br />
== More bug-ish behaviour - support for unicode/multi-byte characters ==<br />
<br />
I've just noticed that Japanese text typed in my user page spontaneously changed into gibberish (technically 'mojibake' ;-). The interesting point is that '''initially''' it displayed properly, only after a day or two did it turn into unintelligible characters. Similar behaviour can be seen at [[POWDER/Russian translation]]. For test purposes I will now write something in Japanese. ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? [[User:PaulBlay|PaulBlay]]<br />
: My bet is someone used a browser that didnt handle jis/utf or whatever encoding properly and saved it back... your test string is nothing but ?????? to my browser... (ff3.5) [[User:Stu|Stu]] 19:59, 10 July 2009 (CEST)<br />
<br />
== talkie = pre-alpha / planning ? ==<br />
<br />
The 'talkie' category appears to be a little off compared to the line-up of "alpha, beta, stable". Should I understand it to include games that are pre-alpha / planning or should "pre-alpha" be a new category? <br />
<br />
A significant number of 'alpha' projects include no download. I was under the impression that 'alpha' meant that you could run it and see something even though it might not be a playable game yet. [[User:PaulBlay|PaulBlay]]<br />
:Yes, I think that games that are in 'alpha' but have no downloads should be moved to 'talkie'. [[User:Nate879|Nathan Stoddard]] 23:23, 12 April 2009 (CEST)<br />
<br />
== Image uploads? ==<br />
<br />
I see that file uploads are disabled. I'd like to be able to upload a few small icons for alpha/beta/stable/defunct (after I find/create them ;-). If I can't do it myself, is there an admin who I could email or something? [[User:PaulBlay|PaulBlay]]<br />
:It's not possible to upload files, but you can use images from other sites. Put the image's URL on the page, without any special formatting (look at [[Downfall]] for an example). If you need a site to upload to, I recommend [http://imgur.com/ Imgur]. [[User:Nate879|Nathan Stoddard]] 23:26, 12 April 2009 (CEST)<br />
<br />
== RGRD Wiki Project ==<br />
<br />
I see this hasn't had any new names added since August 2008. As such perhaps it shouldn't be so prominent in the Contribute section. Maybe ...<br />
<br />
<br />
<nowiki>=Contribute=</nowiki><br />
If you'd like to contribute to RogueBasin, simply create an account and log in. Feel very free to edit! We especially need more information added to the [[:category:roguelike games|games pages]] and the [[list of roguelike games|lists]] - if you're a developer, consider updating your game's page, and making sure that it (and you) are included in the relevant lists.<br />
<br />
If you're an experienced developer, consider writing articles about creating Roguelikes. There are many people new to Roguelike development, and they often need help. It's especially helpful to write articles about problems you have experienced yourself. Also you can add your name to the [[RGRD Wiki Project]] (directly, or by posting a message on [[rgrd]] saying how you want to participate). If someone sees a relevant post by you, they'll upload it to this wiki as an [[articles|article]].<br />
<br />
[[User:PaulBlay|PaulBlay]]<br />
:I think this will be fine. You can go ahead and change it if you want. [[User:Nate879|Nathan Stoddard]] 23:27, 12 April 2009 (CEST)<br />
<br />
== New main page ==<br />
<br />
I like the appearance of the new main page :) --[[User:Slash|Slash]] 05:32, 13 April 2009 (CEST)<br />
<br />
I like it too, nice work! I'd like the contribute part to be blue though, [[User:Colonp/maintest]].. Not perfect right now. [[User:Colonp|Colonp]] 04:17, 17 April 2009 (CEST)<br />
<br />
== STATUS in game templates ==<br />
<br />
A number of games have |status= lines in the info box, but it does not display anything on the screen. The content is generally a duplicate of the type indicated by the template name (e.g. game-beta is status [[Beta]], etc.)<br />
<br />
Are these lines left over from an earlier set of templates? Can the STATUS information safely be called redundant and removed? [[User:PaulBlay|PaulBlay]]<br />
<br />
== 'roguelikes' section of Main page. ==<br />
<br />
I think that ''influential'' would be clearer (and less controversial) than ''popular''. There are arguably many recent roguelike games that are more popular than ToME, but few (if any) that have been more influential. <br />
<br />
I suggest that [[Major roguelikes|Major Roguelikes]], [[Roguelike Reviews]], [[Tree of roguelike evolution]], and [[Recently Updated Roguelikes]] be added to the 'inclusion' page [[list of roguelikes|Lists of Roguelikes]], and the text changed as below:<br />
<br />
<nowiki>= Roguelikes =</nowiki><br />
Many Roguelikes are freely available online. The most <strike>popular</strike> influential are:<br />
<br />
<div style="text-align:center">[[ADOM]] '''·''' [[Angband]] '''·''' [[Crawl]] '''·''' [[NetHack]] '''·''' [[ToME]]</div><br />
<br />
Since the control systems of these Roguelikes are geared towards "expert" players, the novice player may be interested in trying a 'lighter' game like some of the '''[[coffeebreak roguelike]]s''' or just dive in at the deep end and find a '''[[:Category:Roguelike_games|game]]''' to suit you.<strike>. The following may help you find out more: <br />
<br />
*[[:category:roguelike games|Categorized Roguelikes]]<br />
*[[list of roguelikes|Lists of Roguelikes]]<br />
*[[Major roguelikes|Major Roguelikes]]<br />
*[[Roguelike Reviews]] <br />
*[[Tree of roguelike evolution]]<br />
*[[Recently Updated Roguelikes]]</strike><br />
<br />
== Also ... ==<br />
<br />
See [[Talk:List of roguelikes]] for possible replacement for the content of that page. [[User:PaulBlay|PaulBlay]]<br />
<br />
== Featured game section? ==<br />
<br />
How about a 'featured game' section (bottom left of main page). Suggested content: Short description, mini-review, link to RogueBasin page and main review (if present). I'd suggest choosing games that have been updated in the last month and are at least 'beta'. [[User:PaulBlay|PaulBlay]]<br />
<br />
: Well, I've done one. Maybe someone will replace it with a different game in a week or two. [[User:PaulBlay|PaulBlay]]<br />
:: Looks great! I actually have a C64 in a joystick system that has this game on it. [[User:Elig|elig]]<br />
<br />
== Location instead of Nationality? ==<br />
<br />
In the developer info, I think it would be more fun to have a Location option instead of a Nationality option. With location, people can put in however much information on their location they want. They could type things like "Sacramento, CA, USA" or just "Arizona, USA" or even "France". The Nationality field limits this information purely to the country where the person is from, which in many cases might not be as interesting as the state in that country that the person lives in. <br />
<br />
So, the advantage with using the word Location instead is that it provides people the flexibility to put in however much or little information they want, and it can still contain the exact same information that Nationality does. Also, upgrading is easy because we can just replace all instances of Nationality with Location. Although this might be considered a minor issue because people can enter their state and so on into the Nationality field, the Nationality field still encourages new contributions to contain as little information as possible on the location of the developer. Renaming it Location would encourage them to put in as much information as they wanted to. - [[elig]]<br />
<br />
: I'm not hard against it, but it doesn't sound that great a move. I doubt the excitement would keep you awake at nights if I told you that I live in Wiltshire now but Berkshire before I moved. ;-) States are mostly only going to be interesting if you happen to live in the same country. That said, go ahead and do it if you want, it's no big deal either way. [[User:PaulBlay|PaulBlay]]<br />
<br />
: The biggest problem with this is that every developer would have to change their developer info. It would be better to create a new template with the nationality changed to location, but then some developers would have a "location" field and others would have a "nationality" field, which could be confusing. I don't think it's worth it to change it. [[User:Nate879|Nathan Stoddard]] 00:38, 8 May 2009 (CEST)<br />
<br />
== Important links on front page? ==<br />
<br />
What about having some closely related important community links on the front page? There are very few major resources aside from Roguebasin, pretty much just Temple of the Roguelike, the rgrd newsgroup, #rgrd and Temple of the Roguelike's forums. The RGRD links are currently under articles, perhaps for lack of a better place. They're not articles and it seems a little confusing to me to have them under there. Links might be appropriate, but since there are so few other major resources for the roguelike community, why not highlight them directly on the main page? I feel this would really help people who find Roguebasin for the first time to enter the community. At least, I think all these links should be placed in a single location that is easy to access and properly labeled. Thoughts? - [[elig]]<br />
<br />
I have now added this to the front page, to show how I think it might look. Feel free to take it off ofcourse if you absolutely hate it, but I think it could be a valuable addition to the front page. Thoughts? - [[elig]]<br />
<br />
A few [[User:PaulBlay|PaulBlay]]<br />
<br />
# Although I like "Temple of the Roguelike" it doesn't really need two links.<br />
<br />
# r.g.r.d Newsgroup and R.G.R.D IRC Chatroom could have direct links as well as (instead of?) the links to RogueBasin pages.* <br />
<br />
# angband.oook.cz deserves a mention.<br />
<br />
# You've just stolen the space I wanted to use for the "Featured game section" ;-) (But I can't complain too much as I didn't take the time away from [[Angband/65]] development to feature even one game)<br />
<br />
NOTE: r.g.r.d Newsgroup should probably have a Google groups link - many people won't have a browser that supports things like news://msnews.microsoft.com/microsoft.public.pocketpc. If there was a browser equivalent for IRC:// I'd probably say the same about that.<br />
<br />
Also note that there's a "links" link at the top of the page. I'd suggest that page could be made more user-friendly and updated.<br />
<br />
<br />
Featured games is a good idea. We can always put it above or below the community links. But it should definitely have a featured games thing on the front page. The other changes are all good, I'll probably just leave the Temple of the Roguelike forum, since this page already has news physically on it. The r.g.r.d. newsgroup should be a direct google link IMO as well. IRC I think it would be better to have a seperate page for, just because there's no easy way to specify an IRC server's address, to my knowledge. I'll also add angband.oook.cz - [[elig]]<br />
<br />
I've also added a temporary space for the future featured Roguelike section. Feel free to remove/edit it of course. Just figured I'd reserve the space :) Also, feel free to put it above the Roguelike community links if you want. Also, what about having the featured roguelike at the very top of the page? Like, in the space where "What is a Roguelike?" is now, with "What is a Roguelike?" right below it? It might be something neat to entice any new visitors to try a Roguelike. - [[elig]]<br />
<br />
== Specific games.. ==<br />
<br />
''"I don't think we should have links to sites about specific games"''<br />
<br />
http://angband.oook.cz/ is not about a single game, it is about an entire genre of roguelike games. As evidenced by the fact that there are 82 *band variants in the [[List of Angband variants]]. There are at least as many posts on variants as on 'vanilla' Angband and frankly it gets more traffic than http://www.roguetemple.com/ by a long way. [[User:PaulBlay|PaulBlay]]<br />
:Okay. From the description of the site, I assumed it was primarily about Angband. I didn't even look at the site. I will re-add it. :) [[User:Nate879|Nathan Stoddard]] 21:50, 14 May 2009 (CEST)<br />
<br />
== Reorganize site? ==<br />
<br />
Right now, this site serves two main purposes: to describe existing Roguelike games and have articles about creating new Roguelikes. I think that at least for the average user, it might be confusing to have the two "mixed" like they are. For example, I think the news section of the main page should be divided into two sections: games and development tools. What do you think? [[User:Nate879|Nathan Stoddard]] 21:54, 14 May 2009 (CEST)<br />
<br />
: I don't think the development tools should be split out of news, but I do agree that something of a reorganisation is needed. The site is, IMO, more accessible for game information than it is for development help. The great majority of game information is in one of two types - 1) Lists and categories, 2) Individual game information. That is basically all that's needed - ways of finding a suitable game efficiently and information on the game itself. <br />
<br />
: Development articles (and related content) are trickier. For one thing I suspect many of the articles may be old fashioned. There are also quite a few articles that are 'locked' (can't be edited). They are spread around between different languages and I think there are big gaps in difficulty level between them. What I think would be great would be if there was a series of articles all in the same language (preferably one accessible to new learners and usable on many platforms) that cover all major aspects of development. Don't worry about having the most efficient algorithms, worry more about understandability and consistency between articles. Make use of stable libraries if appropriate. Basically with the intent that someone starting at the first article and finishing at the last could go from newbie to having made a basic functional roguelike game. That series could form a stable "trunk" and generous inclusion of links to other relevant articles would provide branches off to the details and options that more experienced developers (and those using other languages) will need. [[User:PaulBlay|PaulBlay]]<br />
<br />
:: I think that's a good idea. It might be best to use [[Python]], because it is easy to learn, fast to develop in, and portable. It's slow (some say it's 100 times slower than C++), but as you said, efficiency isn't very important. I have some experience with Python, so I could help write some of the articles. [[User:Nate879|Nathan Stoddard]] 01:42, 15 May 2009 (CEST)<br />
<br />
::: As I understand it the latest version has improved quite markedly in speed, hasn't it? <br />
<br />
::: I'm pretty much booked up working on [[Angband/65]] as far as my free time goes up till the end of August so I'm afraid I won't be of much use (and I don't know python). [[User:PaulBlay|PaulBlay]]<br />
<br />
:: Definitely, the game info is far more accessable than the development info. What we're desperately lacking is more information on development, a better organization of that information, and a better way to access that information. I'm not entirely sure how to fix these problems, except for maybe creating a generic Roguelike Development page that is linked to from the front page. Aside from that, I'm not sure. :\ I've thought about adding articles from time to time, but I never know what to name them or where to properly add them. - [[elig]]<br />
<br />
== Library template(s) ==<br />
<br />
I've added [[Template:Library]] and applied it to the pages in category:library. While doing so two points came up to be resolved: <br />
<br />
1. Should there be -alpha, -beta, -stable and -defunct divisions for libraries?<br />
<br />
2. Should [[Roguelike Library For Java]] and [[Roguelike Library For Perl]] be changed to use the library template I added? <br />
<br />
P.S. Feel free to change / or comment on the library template I made. [[User:PaulBlay|PaulBlay]]<br />
<br />
: IMO all libraries should follow the same format, and I love the alpha beta stable etc. thing. Sounds good to me! - [[elig]]<br />
:: I also like that curses uses a library like template to specify that curses is a series of libraries. [[elig]]<br />
<br />
== Who's minding the store? ==<br />
<br />
That is to say, who is it that does the admin stuff like delete pages in the delete category, pay for the domain name, update the mediawiki version? I'm just asking because it would be a real shame if I came back here one day and it was all 404'ed or something. [[User:PaulBlay|PaulBlay]]<br />
<br />
Not sure, might be slashie. I was thinking of just such an awful idea myself recently. Maybe we should start some kind of fund to financially support roguebasin. Erowid for instance has a non-profit donation based organization that pays their bills. Of course, we wouldn't be able to do anything nearly so fancy, but a paypal account and the ability to donate might be nice... Thoughts? - [[elig]]<br />
<br />
:: I just now noticed the PayPal donate button on the lower left side of the page. Is that new? I definitely think it should be given a more prominent place on the website if it is! Maybe a nice spot on the front page, and one on the left right under the logo, maybe. Glad to see this place has a donate button now, though! Everybody donate! :D [[elig]]<br />
<br />
::: That's been there forever. Before everybody donates I think someone should email the address shown and see if you get a reply. (I don't think Bjorn has edited anything here all the time I've been here?). [[User:PaulBlay|PaulBlay]]<br />
<br />
:: This is being discussed at http://www.roguetemple.com/forums/index.php?topic=413 , thanks for your interest! --[[User:Slash|Slash]] 07:18, 2 July 2009 (CEST)<br />
<br />
== Wiki backup / duplicate? ==<br />
<br />
With the current situation (not sure who runs RogueBasin, not sure who has the admin account for the wiki, out of date mediawiki version) would it be possible for someone to duplicate / backup the wiki content? Worst case it wouldn't all be lost if it goes south. Best case someone might be willing to set up a new host with better spam-protection and less bugs. [[User:PaulBlay|PaulBlay]]<br />
<br />
::I agree, it would be a great benefit to the entire community if we were able to duplicate/mirror this wiki. If anyone could duplicate it, we could set up some mirrors in case the main site ever goes down. Plus, this has the added advantage of independent members of the community being able to download a backup copy. We definitely need an easy way to mirror/download/backup Roguebasin, IMO. [[elig]]<br />
<br />
::: There's a special page for Exporting pages for import to another '''MediaWiki''' wiki. [[Special:Export]]. Not sure how well it works. Or you can ''just'' manually copy each page source. Possibly to a wiki host like PBWorks ??? [[User:PaulBlay|PaulBlay]]<br />
<br />
:::: I have written/grabbed a few scripts to begin automating the backup process and I've also used them to make a complete backup of the roguebasin wiki. Both the scripts and the initial backup are available in a package at: EDIT: Download scripts at http://www.xmission.com/~tyrecius/roguebasin-backup-scripts.zip and backup at: http://www.xmission.com/~tyrecius/roguebasin/backups/ /EDIT so grab a copy and keep it just in case. If somebody feels ambitious, they can finish automating the process. [[User:Duerig|Duerig]] 07:05, 2 July 2009 (CEST)<br />
:::: This is awesome, Duerig! This is exactly what we needed! :D Thank you. I'm going to download it right away. [[elig]] Edit: After having downloaded it, this really is EXACTLY what we need. This is fantastic. Everyone should download this. [[elig]]<br />
<br />
::::: Ha-ha, maybe not *everyone* (surely there are bandwidth concerns?). But great news and thanks Duerig. I have just downloaded it and will experiment with how easy it is to set-up elsewhere. (It's not a backup until you've tested the restore process! ;-) I'll report in the Temple of the Roguelike thread. [[User:PaulBlay|PaulBlay]]<br />
<br />
:::::: Given your enthusiasm, I decided to bite the bullet and finish automating the process. Download the scripts and run 'backup.sh' and everything will be done for you including downloading the actual xml files and compressing them into a tarball with the current date. I converted a piece of my webspace into backup storage and I've set up a cron job to make monthly backups and stash them there. Fully automated backup scripts at: http://www.xmission.com/~tyrecius/roguebasin-backup-scripts.zip and backup index at: http://www.xmission.com/~tyrecius/roguebasin/backups/ I plan to leave things running and available until/unless my provider complains. [[User:Duerig|Duerig]] 09:32, 2 July 2009 (CEST)<br />
<br />
::::::: Scautura has made the [http://www.roguetemple.com/forums/index.php?topic=413.msg3322#new very generous offer] to supply ad-free wiki hosting. Depending on whether we get any replies from Bjorn (and what those replies are) I think it might be a good idea to move RogueBasin. Obviously it will still be a good idea to make regular backups whatever else happens. Otherwise YourWiki looks like a possibility for temporary / emergency backup location. I'll be waiting a while to see how things proceed before doing more. [[User:PaulBlay|PaulBlay]]<br />
<br />
::::::: Duerig comes through once again! This is absolutely amazing stuff, and exactly what we need. Thank you! Now I can start a torrent based on the backups/ directory. This is awesome! :D [[elig]]<br />
<br />
== Weird error? ==<br />
<br />
Every time I search for Bjorn or Bergstrom the search crashes. I was trying to figure out when the new paypal button was added by searching for Bjorn Bergstrom and then seeing when he added it. Unfortunately, it crashes. Any idea why? [[elig]]<br />
<br />
: I've seen this before. Unfortunately I can't remember the exact reason for the problem (or where I wrote about it) but I think it's got something to do with the content of the pages searched for (possibly related to the way non-ascii characters get messed up). [[User:PaulBlay|PaulBlay]]<br />
<br />
== The Roguebasin torrent! ==<br />
<br />
Here is a torrent for the most recent backup of the Roguebasin. I'll be seeding it at 50kb/s pretty much forever. Remember, seeding this is completely legal and supports the preservation of the Roguebasin, so please seed!<br />
[http://www.mininova.org/tor/2742707 Get the torrent here!]<br />
<br />
::You can also save the copy on [http://www.adrive.com/static/storageplans_basic Adrive] or [http://skydrive.live.com Skydrive] --[[User:Pilotpirx|Pilotpirx]] 11:36, 8 July 2009 (CEST)<br />
<br />
== New spamers ==<br />
Think its time to update the wiki again? or do something with captha or something to lock new users... the spam is coming thick and fast [[User:Stu|Stu]] 17:39, 10 July 2009 (CEST)<br />
<br />
: It might be best to have an administrator activate each account before it can be used. This would prevent the spam, and there aren't very many new accounts, so it wouldn't be too tedious. Another option would be to disallow accounts with "buy" in the name. We would need an administrator to do either of these, and it would be useful to have more administrators. [[User:Nate879|Nathan Stoddard]] 21:23, 10 July 2009 (CEST)<br />
:: Right its time someone locked new users down until something can be organised. its beyond ridiculous now. [[User:Stu|Stu]] 18:41, 12 July 2009 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=RogueBasin_talk:Community_Portal&diff=18477RogueBasin talk:Community Portal2009-07-10T17:59:27Z<p>Stu: /* More bug-ish behaviour - support for unicode/multi-byte characters */</p>
<hr />
<div>{{talkpagetool}}<br />
<br />
<table class="infobox" style="float:right;clear:right; width: 11em; border: 1px solid #93BACB; background:#E0E7EF;font-size:95%; margin:1em; line-height:1.4em;"><br />
<tr><br />
<th style="background:#C2D8EF; padding:.4em; margin:1em; font-size:105%/j">Archives</th><br />
</tr><br />
<tr><br />
<td><br />
* [[/Archive 1|1]]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Game Announcements ==<br />
If you have a new game/version/release to announce to the world, Make an edit to the [[News]] page, and please follow the existing format. If you want to generate discussion and receive feedback and comments, make sure to head over to [http://roguetemple.com RogueTemple] and use their forums, as well as [[rgrd]]. [[User:Stu|Stu]] 14:21, 16 May 2008 (CEST)<br />
<br />
<br />
<br />
== Link breaks wiki, News at 11 ==<br />
<br />
The following link (from 'dead-end pages') fails to display anything other than nasty error messages. Possibly due to illegal characters in title?<br />
<br />
http://roguebasin.roguelikedevelopment.org/index.php?title=Hansj%3F%84%E2%80%9A%3F%82%C2%B6rg_Malthener<br />
<br />
Other 'bug'ish news. [[SDL]] exists, but searching for SDL will return zero hits. [[User:PaulBlay|PaulBlay]]<br />
<br />
The error with Hansjoergs page are not because of illegal characters in the URL. They should be valid even though they look like at least twice encoded in Unicode. There seems to something terrible broken recently with non 7-bit characters. Database update maybe? Try searching for any special character like e.g. '????' (U+00C4 "LATIN CAPITAL LETTER A WITH DIAERESIS" if it gets mangled). Even the db search bails with an error. --[[User:Bhaak|Bhaak]] 15:58, 23 March 2009 (CET)<br />
<br />
== Spambots ==<br />
<br />
There was a small spambot attack recently, dunno how they overrid the spam protection (what is the current spam protection)? I had no luck blocking them via the sysop special pages. Is there any way to delete user accounts?<br />
<br />
--[[User:Slash|Slash]] 01:08, 12 Apr 2007 (CEST)<br />
<br />
I think it may be useful to update MediaWiki software to the latest version. The one that's currently installed is so old, the mind boggles. The current version has captchas and other stuff, and it's much easier to revert vandalism. [[User:Grue|Grue]] 10:23, 12 Apr 2007 (CEST)<br />
<br />
IIRC Bj????rn set up the latest version when the server translation was performed? Also, this is plain vandalism, not even spam (deleting '+' and everything after a '&', what use would that have?<br />
--[[User:Slash|Slash]] 17:19, 12 Apr 2007 (CEST)<br />
:It can't be the latest version. For example when you look at the diff between two revisions, there's no link to edit the revision. This feature was in Wikipedia since I joined it, probably, and that was very long time ago. So, to revert vandalism one has to click three times instead of two, pretty annoying. I don't know, maybe it's configured incorrectly, but it definitely looks very outdated. [[User:Grue|Grue]] 10:52, 13 Apr 2007 (CEST)<br />
<br />
:It's definitely an old version, the [[Special:Version]] page shows as using version 1.3.9 ''(The 1.3.x line was last updated in November 2005)''. The newest release is 1.10.0 although most modern versions of MediaWiki require PHP5 though ''(since version 1.7)''. The latest version that still supports PHP4 is 1.6.10 available [http://www.mediawiki.org/wiki/Download here]. 1.6.10 was released on 20th February 2007. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
::THe Wiki is currently running MediaWiki 1.6.10. Hopefully we won't see any more spam attacks. -- Bjorn 09:50 3 Jul 2007<br />
<br />
There was another spammer, although it could be a person doing it, rather than a bot. It was [[User:Yaxiaexx099|this account]] doing it, and [http://roguebasin.roguelikedevelopment.org/index.php?title=Dalhxf&oldid=12449 this] was was what he did.<br />
<br />
Here we go again, looks like the spambots are returning? Three new pages filled with.. something. [[Aldan|Here]], [[Generosity|here]] and [[Nourished|here]], created by three (new?) users in a short succession. Are there any anti-spambot guidelines somewhere, since I'm not sure of what to do, except for reporting? [[User:Solarnus|Solarnus]] 23:48, 8 January 2009 (CET)<br />
<br />
:Wonder if there is any way we can give rights to some users to approve new users so we dont have these spambots sign up, or we need to modify the captcha code to stop this crap. [[User:Stu|Stu]] 14:31, 12 January 2009 (CET)<br />
<br />
::I would suggest try giving a selected few, trusted users the rights to approve new users. The use of CAPTCHAs is kinda useless as of today (well, except for scaring off scriptkiddies), since it's an out of date "security measure" and there's some various techniques to bypass it. It's also a problem for ie, visual impaired people having trouble reading the characters (more info over at wikipedia, for those of you not being convinced it's a crappy technology..). [[User:Solarnus|Solarnus]] 15:50, 23 January 2009 (CET)<br />
<br />
<br />
<br />
<br />
<br />
== All those guides! ==<br />
<br />
Where did all those good guides at http://www.roguelikedevelopment.org/ go? according to the news, the content has been moved to this wiki but I can't find any of those guides! me want's 'em badly!<br />
[[User:Solarnus|Solarnus]] 11:28, 16 January 2008 (CET)<br />
:Sorry, I meant of course that alot of guides are missing, as least most of the map algorithm stuff previously found on the old site is missing here at the wiki. Anyone got copies of those guides, please? [[User:Solarnus|Solarnus]] 14:28, 23 January 2008 (CET)<br />
::And you looked in the map section of [[Articles]]? All the ones I recall are there. Perhaps you can use the wayback machine to calculate which ones seem to be missing? [[User:Duerig|Duerig]] 17:12, 23 January 2008 (CET)<br />
:::lol, the wayback what..? No, realy, I know there's alot missing from the site. Some examples are the guides written by Mike Anderson (Dungeon-Building Algorithm, Fractal Landscapes) and Radomir "The Sheep" Dopieralski (Recursive LvL Generation) [[User:Solarnus|Solarnus]] 17:52, 23 January 2008 (CET)<br />
::::Look at this URL. It is from www.archive.org, the wayback machine for the Internet: http://web.archive.org/web/20060114055601/http://roguelikedevelopment.org/ but before you go adding all of the articles to the wiki, you should know that there was some effort to move them over, but only if the original authors could be found to give permission. So you should check with an admin here about what to do. [[User:Duerig|Duerig]] 08:50, 24 January 2008 (CET)<br />
:::::Oh crap, I thought I could just go and add what I managed to find, since it had already been released on the site o.0' Pardon me, I'm too quick sometimes, doing stuff without thinking first. <br /> But, IMHO, not moving over all that stuff just because the original author couldn't be found kinda buggers me, that's just wast of time and good knowledge, stupidlly forcing to "reinvent the wheel". And it buggers me even more, since obvisiouly (spelling?) it can still be found on the web thanks to that wayback machine you're talking about (thanks for that link btw, would've never thought of that). <br /> Thanks for telling me dude, I'll try slowing down/backing off and poke an admin about it before doing anything else.<br /> <br />Anyway, should the "previously missing" [[Dungeon-Building Algorithm]] article I dug up yesterday be removed, or just leave it for now and hope for the better? [[User:Solarnus|Solarnus]] 13:50, 24 January 2008 (CET)<br />
<br />
<br />
::::::Is there any chance of the articles being reposted on the original site until they can be ported here? They're only text documents, and a number of them were very good references. Most of the original files are not stored on wayback machine, so forn ow they are lost for good. [[User:lapoubelle|lapoubelle]] 30 April 2008<br />
<br />
I have spent most of today searching for and collecting all of the articles that were on the old system but not on roguebasin. I was able to recover all but two. Those two and links to the archives are at [[User:Duerig]]. That way they should be safe until we can decide how to handle them. If the admins have a problem with this, I'll host them on my own domain if I have to. Let me know if you can find information on either of the two remaining articles. [[User:Duerig|Duerig]] 21:53, 1 May 2008 (CEST)<br />
<br />
<br />
<br />
<br />
== Game or project? ==<br />
<br />
Template [[Template:Angband-variant]] asks for status field. Then game entry is added to "status games" category. This works well for stable games and defunct games but fails for alpha, beta and talkie talkie *projects*. Thus any Angband variants which classify themselves as having alpha or beta status do not get included in proper category. Any ideas how to correct that without destroying too much existing work? I would opt for removing status field and adding all variants to categories manually. Other choice is to spilt template into several like it was done with [[Template:Gameinfo]]. What are others opinions on this? <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 16:18, 19 August 2008 (CEST)<br />
<br />
: I think the best bet is to split the template like the Gameinfo did. I presume there was a good reason to do that split rather than use the status field cleverly. I don't like people having to manually add the category tag as that will result in people forgetting to categorize the variant at all. --[[User:JeffLait|JeffLait]] 05:21, 21 August 2008 (CEST)<br />
<br />
:: Foundations are lain. I am going to wait some more time before proceeding to change all Angband variant pages in case better ideas show up or someone has objections. <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 15:03, 25 August 2008 (CEST)<br />
<br />
== 1krl ==<br />
<br />
We should add this to the wiki, but I'm not sure where.<br />
http://1024brl.googlepages.com/<br />
(and a link to the rgrd posts of course.<br />
--[[User:Soyweiser|Soyweiser]] 02:00, 22 August 2008 (CEST)<br />
<br />
== Rule of thumb for new -> old news? ==<br />
<br />
How many months (or how many posts) should be in [[News]] before you should move some to Old News? I would suggest that four months or so is enough as the 'News' section is currently longer than the rest of the Main page. [[User:PaulBlay|PaulBlay]]<br />
<br />
:I think that we should move all news from 2008 to Old News. We actually don't really need the [[News]] page to show news older than a month, as it is intended to show '''new''' releases. I will move all news from 2008 now. [[User:Nate879|Nathan Stoddard]] 22:34, 22 March 2009 (CET)<br />
<br />
== More bug-ish behaviour - support for unicode/multi-byte characters ==<br />
<br />
I've just noticed that Japanese text typed in my user page spontaneously changed into gibberish (technically 'mojibake' ;-). The interesting point is that '''initially''' it displayed properly, only after a day or two did it turn into unintelligible characters. Similar behaviour can be seen at [[POWDER/Russian translation]]. For test purposes I will now write something in Japanese. ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? [[User:PaulBlay|PaulBlay]]<br />
: My bet is someone used a browser that didnt handle jis/utf or whatever encoding properly and saved it back... your test string is nothing but ?????? to my browser... (ff3.5) [[User:Stu|Stu]] 19:59, 10 July 2009 (CEST)<br />
<br />
== talkie = pre-alpha / planning ? ==<br />
<br />
The 'talkie' category appears to be a little off compared to the line-up of "alpha, beta, stable". Should I understand it to include games that are pre-alpha / planning or should "pre-alpha" be a new category? <br />
<br />
A significant number of 'alpha' projects include no download. I was under the impression that 'alpha' meant that you could run it and see something even though it might not be a playable game yet. [[User:PaulBlay|PaulBlay]]<br />
:Yes, I think that games that are in 'alpha' but have no downloads should be moved to 'talkie'. [[User:Nate879|Nathan Stoddard]] 23:23, 12 April 2009 (CEST)<br />
<br />
== Image uploads? ==<br />
<br />
I see that file uploads are disabled. I'd like to be able to upload a few small icons for alpha/beta/stable/defunct (after I find/create them ;-). If I can't do it myself, is there an admin who I could email or something? [[User:PaulBlay|PaulBlay]]<br />
:It's not possible to upload files, but you can use images from other sites. Put the image's URL on the page, without any special formatting (look at [[Downfall]] for an example). If you need a site to upload to, I recommend [http://imgur.com/ Imgur]. [[User:Nate879|Nathan Stoddard]] 23:26, 12 April 2009 (CEST)<br />
<br />
== RGRD Wiki Project ==<br />
<br />
I see this hasn't had any new names added since August 2008. As such perhaps it shouldn't be so prominent in the Contribute section. Maybe ...<br />
<br />
<br />
<nowiki>=Contribute=</nowiki><br />
If you'd like to contribute to RogueBasin, simply create an account and log in. Feel very free to edit! We especially need more information added to the [[:category:roguelike games|games pages]] and the [[list of roguelike games|lists]] - if you're a developer, consider updating your game's page, and making sure that it (and you) are included in the relevant lists.<br />
<br />
If you're an experienced developer, consider writing articles about creating Roguelikes. There are many people new to Roguelike development, and they often need help. It's especially helpful to write articles about problems you have experienced yourself. Also you can add your name to the [[RGRD Wiki Project]] (directly, or by posting a message on [[rgrd]] saying how you want to participate). If someone sees a relevant post by you, they'll upload it to this wiki as an [[articles|article]].<br />
<br />
[[User:PaulBlay|PaulBlay]]<br />
:I think this will be fine. You can go ahead and change it if you want. [[User:Nate879|Nathan Stoddard]] 23:27, 12 April 2009 (CEST)<br />
<br />
== New main page ==<br />
<br />
I like the appearance of the new main page :) --[[User:Slash|Slash]] 05:32, 13 April 2009 (CEST)<br />
<br />
I like it too, nice work! I'd like the contribute part to be blue though, [[User:Colonp/maintest]].. Not perfect right now. [[User:Colonp|Colonp]] 04:17, 17 April 2009 (CEST)<br />
<br />
== STATUS in game templates ==<br />
<br />
A number of games have |status= lines in the info box, but it does not display anything on the screen. The content is generally a duplicate of the type indicated by the template name (e.g. game-beta is status [[Beta]], etc.)<br />
<br />
Are these lines left over from an earlier set of templates? Can the STATUS information safely be called redundant and removed? [[User:PaulBlay|PaulBlay]]<br />
<br />
== 'roguelikes' section of Main page. ==<br />
<br />
I think that ''influential'' would be clearer (and less controversial) than ''popular''. There are arguably many recent roguelike games that are more popular than ToME, but few (if any) that have been more influential. <br />
<br />
I suggest that [[Major roguelikes|Major Roguelikes]], [[Roguelike Reviews]], [[Tree of roguelike evolution]], and [[Recently Updated Roguelikes]] be added to the 'inclusion' page [[list of roguelikes|Lists of Roguelikes]], and the text changed as below:<br />
<br />
<nowiki>= Roguelikes =</nowiki><br />
Many Roguelikes are freely available online. The most <strike>popular</strike> influential are:<br />
<br />
<div style="text-align:center">[[ADOM]] '''·''' [[Angband]] '''·''' [[Crawl]] '''·''' [[NetHack]] '''·''' [[ToME]]</div><br />
<br />
Since the control systems of these Roguelikes are geared towards "expert" players, the novice player may be interested in trying a 'lighter' game like some of the '''[[coffeebreak roguelike]]s''' or just dive in at the deep end and find a '''[[:Category:Roguelike_games|game]]''' to suit you.<strike>. The following may help you find out more: <br />
<br />
*[[:category:roguelike games|Categorized Roguelikes]]<br />
*[[list of roguelikes|Lists of Roguelikes]]<br />
*[[Major roguelikes|Major Roguelikes]]<br />
*[[Roguelike Reviews]] <br />
*[[Tree of roguelike evolution]]<br />
*[[Recently Updated Roguelikes]]</strike><br />
<br />
== Also ... ==<br />
<br />
See [[Talk:List of roguelikes]] for possible replacement for the content of that page. [[User:PaulBlay|PaulBlay]]<br />
<br />
== Featured game section? ==<br />
<br />
How about a 'featured game' section (bottom left of main page). Suggested content: Short description, mini-review, link to RogueBasin page and main review (if present). I'd suggest choosing games that have been updated in the last month and are at least 'beta'. [[User:PaulBlay|PaulBlay]]<br />
<br />
: Well, I've done one. Maybe someone will replace it with a different game in a week or two. [[User:PaulBlay|PaulBlay]]<br />
:: Looks great! I actually have a C64 in a joystick system that has this game on it. [[User:Elig|elig]]<br />
<br />
== Location instead of Nationality? ==<br />
<br />
In the developer info, I think it would be more fun to have a Location option instead of a Nationality option. With location, people can put in however much information on their location they want. They could type things like "Sacramento, CA, USA" or just "Arizona, USA" or even "France". The Nationality field limits this information purely to the country where the person is from, which in many cases might not be as interesting as the state in that country that the person lives in. <br />
<br />
So, the advantage with using the word Location instead is that it provides people the flexibility to put in however much or little information they want, and it can still contain the exact same information that Nationality does. Also, upgrading is easy because we can just replace all instances of Nationality with Location. Although this might be considered a minor issue because people can enter their state and so on into the Nationality field, the Nationality field still encourages new contributions to contain as little information as possible on the location of the developer. Renaming it Location would encourage them to put in as much information as they wanted to. - [[elig]]<br />
<br />
: I'm not hard against it, but it doesn't sound that great a move. I doubt the excitement would keep you awake at nights if I told you that I live in Wiltshire now but Berkshire before I moved. ;-) States are mostly only going to be interesting if you happen to live in the same country. That said, go ahead and do it if you want, it's no big deal either way. [[User:PaulBlay|PaulBlay]]<br />
<br />
: The biggest problem with this is that every developer would have to change their developer info. It would be better to create a new template with the nationality changed to location, but then some developers would have a "location" field and others would have a "nationality" field, which could be confusing. I don't think it's worth it to change it. [[User:Nate879|Nathan Stoddard]] 00:38, 8 May 2009 (CEST)<br />
<br />
== Important links on front page? ==<br />
<br />
What about having some closely related important community links on the front page? There are very few major resources aside from Roguebasin, pretty much just Temple of the Roguelike, the rgrd newsgroup, #rgrd and Temple of the Roguelike's forums. The RGRD links are currently under articles, perhaps for lack of a better place. They're not articles and it seems a little confusing to me to have them under there. Links might be appropriate, but since there are so few other major resources for the roguelike community, why not highlight them directly on the main page? I feel this would really help people who find Roguebasin for the first time to enter the community. At least, I think all these links should be placed in a single location that is easy to access and properly labeled. Thoughts? - [[elig]]<br />
<br />
I have now added this to the front page, to show how I think it might look. Feel free to take it off ofcourse if you absolutely hate it, but I think it could be a valuable addition to the front page. Thoughts? - [[elig]]<br />
<br />
A few [[User:PaulBlay|PaulBlay]]<br />
<br />
# Although I like "Temple of the Roguelike" it doesn't really need two links.<br />
<br />
# r.g.r.d Newsgroup and R.G.R.D IRC Chatroom could have direct links as well as (instead of?) the links to RogueBasin pages.* <br />
<br />
# angband.oook.cz deserves a mention.<br />
<br />
# You've just stolen the space I wanted to use for the "Featured game section" ;-) (But I can't complain too much as I didn't take the time away from [[Angband/65]] development to feature even one game)<br />
<br />
NOTE: r.g.r.d Newsgroup should probably have a Google groups link - many people won't have a browser that supports things like news://msnews.microsoft.com/microsoft.public.pocketpc. If there was a browser equivalent for IRC:// I'd probably say the same about that.<br />
<br />
Also note that there's a "links" link at the top of the page. I'd suggest that page could be made more user-friendly and updated.<br />
<br />
<br />
Featured games is a good idea. We can always put it above or below the community links. But it should definitely have a featured games thing on the front page. The other changes are all good, I'll probably just leave the Temple of the Roguelike forum, since this page already has news physically on it. The r.g.r.d. newsgroup should be a direct google link IMO as well. IRC I think it would be better to have a seperate page for, just because there's no easy way to specify an IRC server's address, to my knowledge. I'll also add angband.oook.cz - [[elig]]<br />
<br />
I've also added a temporary space for the future featured Roguelike section. Feel free to remove/edit it of course. Just figured I'd reserve the space :) Also, feel free to put it above the Roguelike community links if you want. Also, what about having the featured roguelike at the very top of the page? Like, in the space where "What is a Roguelike?" is now, with "What is a Roguelike?" right below it? It might be something neat to entice any new visitors to try a Roguelike. - [[elig]]<br />
<br />
== Specific games.. ==<br />
<br />
''"I don't think we should have links to sites about specific games"''<br />
<br />
http://angband.oook.cz/ is not about a single game, it is about an entire genre of roguelike games. As evidenced by the fact that there are 82 *band variants in the [[List of Angband variants]]. There are at least as many posts on variants as on 'vanilla' Angband and frankly it gets more traffic than http://www.roguetemple.com/ by a long way. [[User:PaulBlay|PaulBlay]]<br />
:Okay. From the description of the site, I assumed it was primarily about Angband. I didn't even look at the site. I will re-add it. :) [[User:Nate879|Nathan Stoddard]] 21:50, 14 May 2009 (CEST)<br />
<br />
== Reorganize site? ==<br />
<br />
Right now, this site serves two main purposes: to describe existing Roguelike games and have articles about creating new Roguelikes. I think that at least for the average user, it might be confusing to have the two "mixed" like they are. For example, I think the news section of the main page should be divided into two sections: games and development tools. What do you think? [[User:Nate879|Nathan Stoddard]] 21:54, 14 May 2009 (CEST)<br />
<br />
: I don't think the development tools should be split out of news, but I do agree that something of a reorganisation is needed. The site is, IMO, more accessible for game information than it is for development help. The great majority of game information is in one of two types - 1) Lists and categories, 2) Individual game information. That is basically all that's needed - ways of finding a suitable game efficiently and information on the game itself. <br />
<br />
: Development articles (and related content) are trickier. For one thing I suspect many of the articles may be old fashioned. There are also quite a few articles that are 'locked' (can't be edited). They are spread around between different languages and I think there are big gaps in difficulty level between them. What I think would be great would be if there was a series of articles all in the same language (preferably one accessible to new learners and usable on many platforms) that cover all major aspects of development. Don't worry about having the most efficient algorithms, worry more about understandability and consistency between articles. Make use of stable libraries if appropriate. Basically with the intent that someone starting at the first article and finishing at the last could go from newbie to having made a basic functional roguelike game. That series could form a stable "trunk" and generous inclusion of links to other relevant articles would provide branches off to the details and options that more experienced developers (and those using other languages) will need. [[User:PaulBlay|PaulBlay]]<br />
<br />
:: I think that's a good idea. It might be best to use [[Python]], because it is easy to learn, fast to develop in, and portable. It's slow (some say it's 100 times slower than C++), but as you said, efficiency isn't very important. I have some experience with Python, so I could help write some of the articles. [[User:Nate879|Nathan Stoddard]] 01:42, 15 May 2009 (CEST)<br />
<br />
::: As I understand it the latest version has improved quite markedly in speed, hasn't it? <br />
<br />
::: I'm pretty much booked up working on [[Angband/65]] as far as my free time goes up till the end of August so I'm afraid I won't be of much use (and I don't know python). [[User:PaulBlay|PaulBlay]]<br />
<br />
:: Definitely, the game info is far more accessable than the development info. What we're desperately lacking is more information on development, a better organization of that information, and a better way to access that information. I'm not entirely sure how to fix these problems, except for maybe creating a generic Roguelike Development page that is linked to from the front page. Aside from that, I'm not sure. :\ I've thought about adding articles from time to time, but I never know what to name them or where to properly add them. - [[elig]]<br />
<br />
== Library template(s) ==<br />
<br />
I've added [[Template:Library]] and applied it to the pages in category:library. While doing so two points came up to be resolved: <br />
<br />
1. Should there be -alpha, -beta, -stable and -defunct divisions for libraries?<br />
<br />
2. Should [[Roguelike Library For Java]] and [[Roguelike Library For Perl]] be changed to use the library template I added? <br />
<br />
P.S. Feel free to change / or comment on the library template I made. [[User:PaulBlay|PaulBlay]]<br />
<br />
: IMO all libraries should follow the same format, and I love the alpha beta stable etc. thing. Sounds good to me! - [[elig]]<br />
:: I also like that curses uses a library like template to specify that curses is a series of libraries. [[elig]]<br />
<br />
== Who's minding the store? ==<br />
<br />
That is to say, who is it that does the admin stuff like delete pages in the delete category, pay for the domain name, update the mediawiki version? I'm just asking because it would be a real shame if I came back here one day and it was all 404'ed or something. [[User:PaulBlay|PaulBlay]]<br />
<br />
Not sure, might be slashie. I was thinking of just such an awful idea myself recently. Maybe we should start some kind of fund to financially support roguebasin. Erowid for instance has a non-profit donation based organization that pays their bills. Of course, we wouldn't be able to do anything nearly so fancy, but a paypal account and the ability to donate might be nice... Thoughts? - [[elig]]<br />
<br />
:: I just now noticed the PayPal donate button on the lower left side of the page. Is that new? I definitely think it should be given a more prominent place on the website if it is! Maybe a nice spot on the front page, and one on the left right under the logo, maybe. Glad to see this place has a donate button now, though! Everybody donate! :D [[elig]]<br />
<br />
::: That's been there forever. Before everybody donates I think someone should email the address shown and see if you get a reply. (I don't think Bjorn has edited anything here all the time I've been here?). [[User:PaulBlay|PaulBlay]]<br />
<br />
:: This is being discussed at http://www.roguetemple.com/forums/index.php?topic=413 , thanks for your interest! --[[User:Slash|Slash]] 07:18, 2 July 2009 (CEST)<br />
<br />
== Wiki backup / duplicate? ==<br />
<br />
With the current situation (not sure who runs RogueBasin, not sure who has the admin account for the wiki, out of date mediawiki version) would it be possible for someone to duplicate / backup the wiki content? Worst case it wouldn't all be lost if it goes south. Best case someone might be willing to set up a new host with better spam-protection and less bugs. [[User:PaulBlay|PaulBlay]]<br />
<br />
::I agree, it would be a great benefit to the entire community if we were able to duplicate/mirror this wiki. If anyone could duplicate it, we could set up some mirrors in case the main site ever goes down. Plus, this has the added advantage of independent members of the community being able to download a backup copy. We definitely need an easy way to mirror/download/backup Roguebasin, IMO. [[elig]]<br />
<br />
::: There's a special page for Exporting pages for import to another '''MediaWiki''' wiki. [[Special:Export]]. Not sure how well it works. Or you can ''just'' manually copy each page source. Possibly to a wiki host like PBWorks ??? [[User:PaulBlay|PaulBlay]]<br />
<br />
:::: I have written/grabbed a few scripts to begin automating the backup process and I've also used them to make a complete backup of the roguebasin wiki. Both the scripts and the initial backup are available in a package at: EDIT: Download scripts at http://www.xmission.com/~tyrecius/roguebasin-backup-scripts.zip and backup at: http://www.xmission.com/~tyrecius/roguebasin/backups/ /EDIT so grab a copy and keep it just in case. If somebody feels ambitious, they can finish automating the process. [[User:Duerig|Duerig]] 07:05, 2 July 2009 (CEST)<br />
:::: This is awesome, Duerig! This is exactly what we needed! :D Thank you. I'm going to download it right away. [[elig]] Edit: After having downloaded it, this really is EXACTLY what we need. This is fantastic. Everyone should download this. [[elig]]<br />
<br />
::::: Ha-ha, maybe not *everyone* (surely there are bandwidth concerns?). But great news and thanks Duerig. I have just downloaded it and will experiment with how easy it is to set-up elsewhere. (It's not a backup until you've tested the restore process! ;-) I'll report in the Temple of the Roguelike thread. [[User:PaulBlay|PaulBlay]]<br />
<br />
:::::: Given your enthusiasm, I decided to bite the bullet and finish automating the process. Download the scripts and run 'backup.sh' and everything will be done for you including downloading the actual xml files and compressing them into a tarball with the current date. I converted a piece of my webspace into backup storage and I've set up a cron job to make monthly backups and stash them there. Fully automated backup scripts at: http://www.xmission.com/~tyrecius/roguebasin-backup-scripts.zip and backup index at: http://www.xmission.com/~tyrecius/roguebasin/backups/ I plan to leave things running and available until/unless my provider complains. [[User:Duerig|Duerig]] 09:32, 2 July 2009 (CEST)<br />
<br />
::::::: Scautura has made the [http://www.roguetemple.com/forums/index.php?topic=413.msg3322#new very generous offer] to supply ad-free wiki hosting. Depending on whether we get any replies from Bjorn (and what those replies are) I think it might be a good idea to move RogueBasin. Obviously it will still be a good idea to make regular backups whatever else happens. Otherwise YourWiki looks like a possibility for temporary / emergency backup location. I'll be waiting a while to see how things proceed before doing more. [[User:PaulBlay|PaulBlay]]<br />
<br />
::::::: Duerig comes through once again! This is absolutely amazing stuff, and exactly what we need. Thank you! Now I can start a torrent based on the backups/ directory. This is awesome! :D [[elig]]<br />
<br />
== Weird error? ==<br />
<br />
Every time I search for Bjorn or Bergstrom the search crashes. I was trying to figure out when the new paypal button was added by searching for Bjorn Bergstrom and then seeing when he added it. Unfortunately, it crashes. Any idea why? [[elig]]<br />
<br />
: I've seen this before. Unfortunately I can't remember the exact reason for the problem (or where I wrote about it) but I think it's got something to do with the content of the pages searched for (possibly related to the way non-ascii characters get messed up). [[User:PaulBlay|PaulBlay]]<br />
<br />
== The Roguebasin torrent! ==<br />
<br />
Here is a torrent for the most recent backup of the Roguebasin. I'll be seeding it at 50kb/s pretty much forever. Remember, seeding this is completely legal and supports the preservation of the Roguebasin, so please seed!<br />
[http://www.mininova.org/tor/2742707 Get the torrent here!]<br />
<br />
::You can also save the copy on [http://www.adrive.com/static/storageplans_basic Adrive] or [http://skydrive.live.com Skydrive] --[[User:Pilotpirx|Pilotpirx]] 11:36, 8 July 2009 (CEST)<br />
<br />
== New spamers ==<br />
Think its time to update the wiki again? or do something with captha or something to lock new users... the spam is coming thick and fast [[User:Stu|Stu]] 17:39, 10 July 2009 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=RogueBasin_talk:Community_Portal&diff=18476RogueBasin talk:Community Portal2009-07-10T17:59:02Z<p>Stu: </p>
<hr />
<div>{{talkpagetool}}<br />
<br />
<table class="infobox" style="float:right;clear:right; width: 11em; border: 1px solid #93BACB; background:#E0E7EF;font-size:95%; margin:1em; line-height:1.4em;"><br />
<tr><br />
<th style="background:#C2D8EF; padding:.4em; margin:1em; font-size:105%/j">Archives</th><br />
</tr><br />
<tr><br />
<td><br />
* [[/Archive 1|1]]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Game Announcements ==<br />
If you have a new game/version/release to announce to the world, Make an edit to the [[News]] page, and please follow the existing format. If you want to generate discussion and receive feedback and comments, make sure to head over to [http://roguetemple.com RogueTemple] and use their forums, as well as [[rgrd]]. [[User:Stu|Stu]] 14:21, 16 May 2008 (CEST)<br />
<br />
<br />
<br />
== Link breaks wiki, News at 11 ==<br />
<br />
The following link (from 'dead-end pages') fails to display anything other than nasty error messages. Possibly due to illegal characters in title?<br />
<br />
http://roguebasin.roguelikedevelopment.org/index.php?title=Hansj%3F%84%E2%80%9A%3F%82%C2%B6rg_Malthener<br />
<br />
Other 'bug'ish news. [[SDL]] exists, but searching for SDL will return zero hits. [[User:PaulBlay|PaulBlay]]<br />
<br />
The error with Hansjoergs page are not because of illegal characters in the URL. They should be valid even though they look like at least twice encoded in Unicode. There seems to something terrible broken recently with non 7-bit characters. Database update maybe? Try searching for any special character like e.g. '????' (U+00C4 "LATIN CAPITAL LETTER A WITH DIAERESIS" if it gets mangled). Even the db search bails with an error. --[[User:Bhaak|Bhaak]] 15:58, 23 March 2009 (CET)<br />
<br />
== Spambots ==<br />
<br />
There was a small spambot attack recently, dunno how they overrid the spam protection (what is the current spam protection)? I had no luck blocking them via the sysop special pages. Is there any way to delete user accounts?<br />
<br />
--[[User:Slash|Slash]] 01:08, 12 Apr 2007 (CEST)<br />
<br />
I think it may be useful to update MediaWiki software to the latest version. The one that's currently installed is so old, the mind boggles. The current version has captchas and other stuff, and it's much easier to revert vandalism. [[User:Grue|Grue]] 10:23, 12 Apr 2007 (CEST)<br />
<br />
IIRC Bj????rn set up the latest version when the server translation was performed? Also, this is plain vandalism, not even spam (deleting '+' and everything after a '&', what use would that have?<br />
--[[User:Slash|Slash]] 17:19, 12 Apr 2007 (CEST)<br />
:It can't be the latest version. For example when you look at the diff between two revisions, there's no link to edit the revision. This feature was in Wikipedia since I joined it, probably, and that was very long time ago. So, to revert vandalism one has to click three times instead of two, pretty annoying. I don't know, maybe it's configured incorrectly, but it definitely looks very outdated. [[User:Grue|Grue]] 10:52, 13 Apr 2007 (CEST)<br />
<br />
:It's definitely an old version, the [[Special:Version]] page shows as using version 1.3.9 ''(The 1.3.x line was last updated in November 2005)''. The newest release is 1.10.0 although most modern versions of MediaWiki require PHP5 though ''(since version 1.7)''. The latest version that still supports PHP4 is 1.6.10 available [http://www.mediawiki.org/wiki/Download here]. 1.6.10 was released on 20th February 2007. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
::THe Wiki is currently running MediaWiki 1.6.10. Hopefully we won't see any more spam attacks. -- Bjorn 09:50 3 Jul 2007<br />
<br />
There was another spammer, although it could be a person doing it, rather than a bot. It was [[User:Yaxiaexx099|this account]] doing it, and [http://roguebasin.roguelikedevelopment.org/index.php?title=Dalhxf&oldid=12449 this] was was what he did.<br />
<br />
Here we go again, looks like the spambots are returning? Three new pages filled with.. something. [[Aldan|Here]], [[Generosity|here]] and [[Nourished|here]], created by three (new?) users in a short succession. Are there any anti-spambot guidelines somewhere, since I'm not sure of what to do, except for reporting? [[User:Solarnus|Solarnus]] 23:48, 8 January 2009 (CET)<br />
<br />
:Wonder if there is any way we can give rights to some users to approve new users so we dont have these spambots sign up, or we need to modify the captcha code to stop this crap. [[User:Stu|Stu]] 14:31, 12 January 2009 (CET)<br />
<br />
::I would suggest try giving a selected few, trusted users the rights to approve new users. The use of CAPTCHAs is kinda useless as of today (well, except for scaring off scriptkiddies), since it's an out of date "security measure" and there's some various techniques to bypass it. It's also a problem for ie, visual impaired people having trouble reading the characters (more info over at wikipedia, for those of you not being convinced it's a crappy technology..). [[User:Solarnus|Solarnus]] 15:50, 23 January 2009 (CET)<br />
<br />
<br />
<br />
<br />
<br />
== All those guides! ==<br />
<br />
Where did all those good guides at http://www.roguelikedevelopment.org/ go? according to the news, the content has been moved to this wiki but I can't find any of those guides! me want's 'em badly!<br />
[[User:Solarnus|Solarnus]] 11:28, 16 January 2008 (CET)<br />
:Sorry, I meant of course that alot of guides are missing, as least most of the map algorithm stuff previously found on the old site is missing here at the wiki. Anyone got copies of those guides, please? [[User:Solarnus|Solarnus]] 14:28, 23 January 2008 (CET)<br />
::And you looked in the map section of [[Articles]]? All the ones I recall are there. Perhaps you can use the wayback machine to calculate which ones seem to be missing? [[User:Duerig|Duerig]] 17:12, 23 January 2008 (CET)<br />
:::lol, the wayback what..? No, realy, I know there's alot missing from the site. Some examples are the guides written by Mike Anderson (Dungeon-Building Algorithm, Fractal Landscapes) and Radomir "The Sheep" Dopieralski (Recursive LvL Generation) [[User:Solarnus|Solarnus]] 17:52, 23 January 2008 (CET)<br />
::::Look at this URL. It is from www.archive.org, the wayback machine for the Internet: http://web.archive.org/web/20060114055601/http://roguelikedevelopment.org/ but before you go adding all of the articles to the wiki, you should know that there was some effort to move them over, but only if the original authors could be found to give permission. So you should check with an admin here about what to do. [[User:Duerig|Duerig]] 08:50, 24 January 2008 (CET)<br />
:::::Oh crap, I thought I could just go and add what I managed to find, since it had already been released on the site o.0' Pardon me, I'm too quick sometimes, doing stuff without thinking first. <br /> But, IMHO, not moving over all that stuff just because the original author couldn't be found kinda buggers me, that's just wast of time and good knowledge, stupidlly forcing to "reinvent the wheel". And it buggers me even more, since obvisiouly (spelling?) it can still be found on the web thanks to that wayback machine you're talking about (thanks for that link btw, would've never thought of that). <br /> Thanks for telling me dude, I'll try slowing down/backing off and poke an admin about it before doing anything else.<br /> <br />Anyway, should the "previously missing" [[Dungeon-Building Algorithm]] article I dug up yesterday be removed, or just leave it for now and hope for the better? [[User:Solarnus|Solarnus]] 13:50, 24 January 2008 (CET)<br />
<br />
<br />
::::::Is there any chance of the articles being reposted on the original site until they can be ported here? They're only text documents, and a number of them were very good references. Most of the original files are not stored on wayback machine, so forn ow they are lost for good. [[User:lapoubelle|lapoubelle]] 30 April 2008<br />
<br />
I have spent most of today searching for and collecting all of the articles that were on the old system but not on roguebasin. I was able to recover all but two. Those two and links to the archives are at [[User:Duerig]]. That way they should be safe until we can decide how to handle them. If the admins have a problem with this, I'll host them on my own domain if I have to. Let me know if you can find information on either of the two remaining articles. [[User:Duerig|Duerig]] 21:53, 1 May 2008 (CEST)<br />
<br />
<br />
<br />
<br />
== Game or project? ==<br />
<br />
Template [[Template:Angband-variant]] asks for status field. Then game entry is added to "status games" category. This works well for stable games and defunct games but fails for alpha, beta and talkie talkie *projects*. Thus any Angband variants which classify themselves as having alpha or beta status do not get included in proper category. Any ideas how to correct that without destroying too much existing work? I would opt for removing status field and adding all variants to categories manually. Other choice is to spilt template into several like it was done with [[Template:Gameinfo]]. What are others opinions on this? <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 16:18, 19 August 2008 (CEST)<br />
<br />
: I think the best bet is to split the template like the Gameinfo did. I presume there was a good reason to do that split rather than use the status field cleverly. I don't like people having to manually add the category tag as that will result in people forgetting to categorize the variant at all. --[[User:JeffLait|JeffLait]] 05:21, 21 August 2008 (CEST)<br />
<br />
:: Foundations are lain. I am going to wait some more time before proceeding to change all Angband variant pages in case better ideas show up or someone has objections. <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 15:03, 25 August 2008 (CEST)<br />
<br />
== 1krl ==<br />
<br />
We should add this to the wiki, but I'm not sure where.<br />
http://1024brl.googlepages.com/<br />
(and a link to the rgrd posts of course.<br />
--[[User:Soyweiser|Soyweiser]] 02:00, 22 August 2008 (CEST)<br />
<br />
== Rule of thumb for new -> old news? ==<br />
<br />
How many months (or how many posts) should be in [[News]] before you should move some to Old News? I would suggest that four months or so is enough as the 'News' section is currently longer than the rest of the Main page. [[User:PaulBlay|PaulBlay]]<br />
<br />
:I think that we should move all news from 2008 to Old News. We actually don't really need the [[News]] page to show news older than a month, as it is intended to show '''new''' releases. I will move all news from 2008 now. [[User:Nate879|Nathan Stoddard]] 22:34, 22 March 2009 (CET)<br />
<br />
== More bug-ish behaviour - support for unicode/multi-byte characters ==<br />
<br />
I've just noticed that Japanese text typed in my user page spontaneously changed into gibberish (technically 'mojibake' ;-). The interesting point is that '''initially''' it displayed properly, only after a day or two did it turn into unintelligible characters. Similar behaviour can be seen at [[POWDER/Russian translation]]. For test purposes I will now write something in Japanese. ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? [[User:PaulBlay|PaulBlay]]<br />
: My bet is someone used a browser that didnt handle jis/utf or whatever encoding properly and saved it back... your test string is nothing but ?????? to my browser... (ff3.5)<br />
<br />
== talkie = pre-alpha / planning ? ==<br />
<br />
The 'talkie' category appears to be a little off compared to the line-up of "alpha, beta, stable". Should I understand it to include games that are pre-alpha / planning or should "pre-alpha" be a new category? <br />
<br />
A significant number of 'alpha' projects include no download. I was under the impression that 'alpha' meant that you could run it and see something even though it might not be a playable game yet. [[User:PaulBlay|PaulBlay]]<br />
:Yes, I think that games that are in 'alpha' but have no downloads should be moved to 'talkie'. [[User:Nate879|Nathan Stoddard]] 23:23, 12 April 2009 (CEST)<br />
<br />
== Image uploads? ==<br />
<br />
I see that file uploads are disabled. I'd like to be able to upload a few small icons for alpha/beta/stable/defunct (after I find/create them ;-). If I can't do it myself, is there an admin who I could email or something? [[User:PaulBlay|PaulBlay]]<br />
:It's not possible to upload files, but you can use images from other sites. Put the image's URL on the page, without any special formatting (look at [[Downfall]] for an example). If you need a site to upload to, I recommend [http://imgur.com/ Imgur]. [[User:Nate879|Nathan Stoddard]] 23:26, 12 April 2009 (CEST)<br />
<br />
== RGRD Wiki Project ==<br />
<br />
I see this hasn't had any new names added since August 2008. As such perhaps it shouldn't be so prominent in the Contribute section. Maybe ...<br />
<br />
<br />
<nowiki>=Contribute=</nowiki><br />
If you'd like to contribute to RogueBasin, simply create an account and log in. Feel very free to edit! We especially need more information added to the [[:category:roguelike games|games pages]] and the [[list of roguelike games|lists]] - if you're a developer, consider updating your game's page, and making sure that it (and you) are included in the relevant lists.<br />
<br />
If you're an experienced developer, consider writing articles about creating Roguelikes. There are many people new to Roguelike development, and they often need help. It's especially helpful to write articles about problems you have experienced yourself. Also you can add your name to the [[RGRD Wiki Project]] (directly, or by posting a message on [[rgrd]] saying how you want to participate). If someone sees a relevant post by you, they'll upload it to this wiki as an [[articles|article]].<br />
<br />
[[User:PaulBlay|PaulBlay]]<br />
:I think this will be fine. You can go ahead and change it if you want. [[User:Nate879|Nathan Stoddard]] 23:27, 12 April 2009 (CEST)<br />
<br />
== New main page ==<br />
<br />
I like the appearance of the new main page :) --[[User:Slash|Slash]] 05:32, 13 April 2009 (CEST)<br />
<br />
I like it too, nice work! I'd like the contribute part to be blue though, [[User:Colonp/maintest]].. Not perfect right now. [[User:Colonp|Colonp]] 04:17, 17 April 2009 (CEST)<br />
<br />
== STATUS in game templates ==<br />
<br />
A number of games have |status= lines in the info box, but it does not display anything on the screen. The content is generally a duplicate of the type indicated by the template name (e.g. game-beta is status [[Beta]], etc.)<br />
<br />
Are these lines left over from an earlier set of templates? Can the STATUS information safely be called redundant and removed? [[User:PaulBlay|PaulBlay]]<br />
<br />
== 'roguelikes' section of Main page. ==<br />
<br />
I think that ''influential'' would be clearer (and less controversial) than ''popular''. There are arguably many recent roguelike games that are more popular than ToME, but few (if any) that have been more influential. <br />
<br />
I suggest that [[Major roguelikes|Major Roguelikes]], [[Roguelike Reviews]], [[Tree of roguelike evolution]], and [[Recently Updated Roguelikes]] be added to the 'inclusion' page [[list of roguelikes|Lists of Roguelikes]], and the text changed as below:<br />
<br />
<nowiki>= Roguelikes =</nowiki><br />
Many Roguelikes are freely available online. The most <strike>popular</strike> influential are:<br />
<br />
<div style="text-align:center">[[ADOM]] '''·''' [[Angband]] '''·''' [[Crawl]] '''·''' [[NetHack]] '''·''' [[ToME]]</div><br />
<br />
Since the control systems of these Roguelikes are geared towards "expert" players, the novice player may be interested in trying a 'lighter' game like some of the '''[[coffeebreak roguelike]]s''' or just dive in at the deep end and find a '''[[:Category:Roguelike_games|game]]''' to suit you.<strike>. The following may help you find out more: <br />
<br />
*[[:category:roguelike games|Categorized Roguelikes]]<br />
*[[list of roguelikes|Lists of Roguelikes]]<br />
*[[Major roguelikes|Major Roguelikes]]<br />
*[[Roguelike Reviews]] <br />
*[[Tree of roguelike evolution]]<br />
*[[Recently Updated Roguelikes]]</strike><br />
<br />
== Also ... ==<br />
<br />
See [[Talk:List of roguelikes]] for possible replacement for the content of that page. [[User:PaulBlay|PaulBlay]]<br />
<br />
== Featured game section? ==<br />
<br />
How about a 'featured game' section (bottom left of main page). Suggested content: Short description, mini-review, link to RogueBasin page and main review (if present). I'd suggest choosing games that have been updated in the last month and are at least 'beta'. [[User:PaulBlay|PaulBlay]]<br />
<br />
: Well, I've done one. Maybe someone will replace it with a different game in a week or two. [[User:PaulBlay|PaulBlay]]<br />
:: Looks great! I actually have a C64 in a joystick system that has this game on it. [[User:Elig|elig]]<br />
<br />
== Location instead of Nationality? ==<br />
<br />
In the developer info, I think it would be more fun to have a Location option instead of a Nationality option. With location, people can put in however much information on their location they want. They could type things like "Sacramento, CA, USA" or just "Arizona, USA" or even "France". The Nationality field limits this information purely to the country where the person is from, which in many cases might not be as interesting as the state in that country that the person lives in. <br />
<br />
So, the advantage with using the word Location instead is that it provides people the flexibility to put in however much or little information they want, and it can still contain the exact same information that Nationality does. Also, upgrading is easy because we can just replace all instances of Nationality with Location. Although this might be considered a minor issue because people can enter their state and so on into the Nationality field, the Nationality field still encourages new contributions to contain as little information as possible on the location of the developer. Renaming it Location would encourage them to put in as much information as they wanted to. - [[elig]]<br />
<br />
: I'm not hard against it, but it doesn't sound that great a move. I doubt the excitement would keep you awake at nights if I told you that I live in Wiltshire now but Berkshire before I moved. ;-) States are mostly only going to be interesting if you happen to live in the same country. That said, go ahead and do it if you want, it's no big deal either way. [[User:PaulBlay|PaulBlay]]<br />
<br />
: The biggest problem with this is that every developer would have to change their developer info. It would be better to create a new template with the nationality changed to location, but then some developers would have a "location" field and others would have a "nationality" field, which could be confusing. I don't think it's worth it to change it. [[User:Nate879|Nathan Stoddard]] 00:38, 8 May 2009 (CEST)<br />
<br />
== Important links on front page? ==<br />
<br />
What about having some closely related important community links on the front page? There are very few major resources aside from Roguebasin, pretty much just Temple of the Roguelike, the rgrd newsgroup, #rgrd and Temple of the Roguelike's forums. The RGRD links are currently under articles, perhaps for lack of a better place. They're not articles and it seems a little confusing to me to have them under there. Links might be appropriate, but since there are so few other major resources for the roguelike community, why not highlight them directly on the main page? I feel this would really help people who find Roguebasin for the first time to enter the community. At least, I think all these links should be placed in a single location that is easy to access and properly labeled. Thoughts? - [[elig]]<br />
<br />
I have now added this to the front page, to show how I think it might look. Feel free to take it off ofcourse if you absolutely hate it, but I think it could be a valuable addition to the front page. Thoughts? - [[elig]]<br />
<br />
A few [[User:PaulBlay|PaulBlay]]<br />
<br />
# Although I like "Temple of the Roguelike" it doesn't really need two links.<br />
<br />
# r.g.r.d Newsgroup and R.G.R.D IRC Chatroom could have direct links as well as (instead of?) the links to RogueBasin pages.* <br />
<br />
# angband.oook.cz deserves a mention.<br />
<br />
# You've just stolen the space I wanted to use for the "Featured game section" ;-) (But I can't complain too much as I didn't take the time away from [[Angband/65]] development to feature even one game)<br />
<br />
NOTE: r.g.r.d Newsgroup should probably have a Google groups link - many people won't have a browser that supports things like news://msnews.microsoft.com/microsoft.public.pocketpc. If there was a browser equivalent for IRC:// I'd probably say the same about that.<br />
<br />
Also note that there's a "links" link at the top of the page. I'd suggest that page could be made more user-friendly and updated.<br />
<br />
<br />
Featured games is a good idea. We can always put it above or below the community links. But it should definitely have a featured games thing on the front page. The other changes are all good, I'll probably just leave the Temple of the Roguelike forum, since this page already has news physically on it. The r.g.r.d. newsgroup should be a direct google link IMO as well. IRC I think it would be better to have a seperate page for, just because there's no easy way to specify an IRC server's address, to my knowledge. I'll also add angband.oook.cz - [[elig]]<br />
<br />
I've also added a temporary space for the future featured Roguelike section. Feel free to remove/edit it of course. Just figured I'd reserve the space :) Also, feel free to put it above the Roguelike community links if you want. Also, what about having the featured roguelike at the very top of the page? Like, in the space where "What is a Roguelike?" is now, with "What is a Roguelike?" right below it? It might be something neat to entice any new visitors to try a Roguelike. - [[elig]]<br />
<br />
== Specific games.. ==<br />
<br />
''"I don't think we should have links to sites about specific games"''<br />
<br />
http://angband.oook.cz/ is not about a single game, it is about an entire genre of roguelike games. As evidenced by the fact that there are 82 *band variants in the [[List of Angband variants]]. There are at least as many posts on variants as on 'vanilla' Angband and frankly it gets more traffic than http://www.roguetemple.com/ by a long way. [[User:PaulBlay|PaulBlay]]<br />
:Okay. From the description of the site, I assumed it was primarily about Angband. I didn't even look at the site. I will re-add it. :) [[User:Nate879|Nathan Stoddard]] 21:50, 14 May 2009 (CEST)<br />
<br />
== Reorganize site? ==<br />
<br />
Right now, this site serves two main purposes: to describe existing Roguelike games and have articles about creating new Roguelikes. I think that at least for the average user, it might be confusing to have the two "mixed" like they are. For example, I think the news section of the main page should be divided into two sections: games and development tools. What do you think? [[User:Nate879|Nathan Stoddard]] 21:54, 14 May 2009 (CEST)<br />
<br />
: I don't think the development tools should be split out of news, but I do agree that something of a reorganisation is needed. The site is, IMO, more accessible for game information than it is for development help. The great majority of game information is in one of two types - 1) Lists and categories, 2) Individual game information. That is basically all that's needed - ways of finding a suitable game efficiently and information on the game itself. <br />
<br />
: Development articles (and related content) are trickier. For one thing I suspect many of the articles may be old fashioned. There are also quite a few articles that are 'locked' (can't be edited). They are spread around between different languages and I think there are big gaps in difficulty level between them. What I think would be great would be if there was a series of articles all in the same language (preferably one accessible to new learners and usable on many platforms) that cover all major aspects of development. Don't worry about having the most efficient algorithms, worry more about understandability and consistency between articles. Make use of stable libraries if appropriate. Basically with the intent that someone starting at the first article and finishing at the last could go from newbie to having made a basic functional roguelike game. That series could form a stable "trunk" and generous inclusion of links to other relevant articles would provide branches off to the details and options that more experienced developers (and those using other languages) will need. [[User:PaulBlay|PaulBlay]]<br />
<br />
:: I think that's a good idea. It might be best to use [[Python]], because it is easy to learn, fast to develop in, and portable. It's slow (some say it's 100 times slower than C++), but as you said, efficiency isn't very important. I have some experience with Python, so I could help write some of the articles. [[User:Nate879|Nathan Stoddard]] 01:42, 15 May 2009 (CEST)<br />
<br />
::: As I understand it the latest version has improved quite markedly in speed, hasn't it? <br />
<br />
::: I'm pretty much booked up working on [[Angband/65]] as far as my free time goes up till the end of August so I'm afraid I won't be of much use (and I don't know python). [[User:PaulBlay|PaulBlay]]<br />
<br />
:: Definitely, the game info is far more accessable than the development info. What we're desperately lacking is more information on development, a better organization of that information, and a better way to access that information. I'm not entirely sure how to fix these problems, except for maybe creating a generic Roguelike Development page that is linked to from the front page. Aside from that, I'm not sure. :\ I've thought about adding articles from time to time, but I never know what to name them or where to properly add them. - [[elig]]<br />
<br />
== Library template(s) ==<br />
<br />
I've added [[Template:Library]] and applied it to the pages in category:library. While doing so two points came up to be resolved: <br />
<br />
1. Should there be -alpha, -beta, -stable and -defunct divisions for libraries?<br />
<br />
2. Should [[Roguelike Library For Java]] and [[Roguelike Library For Perl]] be changed to use the library template I added? <br />
<br />
P.S. Feel free to change / or comment on the library template I made. [[User:PaulBlay|PaulBlay]]<br />
<br />
: IMO all libraries should follow the same format, and I love the alpha beta stable etc. thing. Sounds good to me! - [[elig]]<br />
:: I also like that curses uses a library like template to specify that curses is a series of libraries. [[elig]]<br />
<br />
== Who's minding the store? ==<br />
<br />
That is to say, who is it that does the admin stuff like delete pages in the delete category, pay for the domain name, update the mediawiki version? I'm just asking because it would be a real shame if I came back here one day and it was all 404'ed or something. [[User:PaulBlay|PaulBlay]]<br />
<br />
Not sure, might be slashie. I was thinking of just such an awful idea myself recently. Maybe we should start some kind of fund to financially support roguebasin. Erowid for instance has a non-profit donation based organization that pays their bills. Of course, we wouldn't be able to do anything nearly so fancy, but a paypal account and the ability to donate might be nice... Thoughts? - [[elig]]<br />
<br />
:: I just now noticed the PayPal donate button on the lower left side of the page. Is that new? I definitely think it should be given a more prominent place on the website if it is! Maybe a nice spot on the front page, and one on the left right under the logo, maybe. Glad to see this place has a donate button now, though! Everybody donate! :D [[elig]]<br />
<br />
::: That's been there forever. Before everybody donates I think someone should email the address shown and see if you get a reply. (I don't think Bjorn has edited anything here all the time I've been here?). [[User:PaulBlay|PaulBlay]]<br />
<br />
:: This is being discussed at http://www.roguetemple.com/forums/index.php?topic=413 , thanks for your interest! --[[User:Slash|Slash]] 07:18, 2 July 2009 (CEST)<br />
<br />
== Wiki backup / duplicate? ==<br />
<br />
With the current situation (not sure who runs RogueBasin, not sure who has the admin account for the wiki, out of date mediawiki version) would it be possible for someone to duplicate / backup the wiki content? Worst case it wouldn't all be lost if it goes south. Best case someone might be willing to set up a new host with better spam-protection and less bugs. [[User:PaulBlay|PaulBlay]]<br />
<br />
::I agree, it would be a great benefit to the entire community if we were able to duplicate/mirror this wiki. If anyone could duplicate it, we could set up some mirrors in case the main site ever goes down. Plus, this has the added advantage of independent members of the community being able to download a backup copy. We definitely need an easy way to mirror/download/backup Roguebasin, IMO. [[elig]]<br />
<br />
::: There's a special page for Exporting pages for import to another '''MediaWiki''' wiki. [[Special:Export]]. Not sure how well it works. Or you can ''just'' manually copy each page source. Possibly to a wiki host like PBWorks ??? [[User:PaulBlay|PaulBlay]]<br />
<br />
:::: I have written/grabbed a few scripts to begin automating the backup process and I've also used them to make a complete backup of the roguebasin wiki. Both the scripts and the initial backup are available in a package at: EDIT: Download scripts at http://www.xmission.com/~tyrecius/roguebasin-backup-scripts.zip and backup at: http://www.xmission.com/~tyrecius/roguebasin/backups/ /EDIT so grab a copy and keep it just in case. If somebody feels ambitious, they can finish automating the process. [[User:Duerig|Duerig]] 07:05, 2 July 2009 (CEST)<br />
:::: This is awesome, Duerig! This is exactly what we needed! :D Thank you. I'm going to download it right away. [[elig]] Edit: After having downloaded it, this really is EXACTLY what we need. This is fantastic. Everyone should download this. [[elig]]<br />
<br />
::::: Ha-ha, maybe not *everyone* (surely there are bandwidth concerns?). But great news and thanks Duerig. I have just downloaded it and will experiment with how easy it is to set-up elsewhere. (It's not a backup until you've tested the restore process! ;-) I'll report in the Temple of the Roguelike thread. [[User:PaulBlay|PaulBlay]]<br />
<br />
:::::: Given your enthusiasm, I decided to bite the bullet and finish automating the process. Download the scripts and run 'backup.sh' and everything will be done for you including downloading the actual xml files and compressing them into a tarball with the current date. I converted a piece of my webspace into backup storage and I've set up a cron job to make monthly backups and stash them there. Fully automated backup scripts at: http://www.xmission.com/~tyrecius/roguebasin-backup-scripts.zip and backup index at: http://www.xmission.com/~tyrecius/roguebasin/backups/ I plan to leave things running and available until/unless my provider complains. [[User:Duerig|Duerig]] 09:32, 2 July 2009 (CEST)<br />
<br />
::::::: Scautura has made the [http://www.roguetemple.com/forums/index.php?topic=413.msg3322#new very generous offer] to supply ad-free wiki hosting. Depending on whether we get any replies from Bjorn (and what those replies are) I think it might be a good idea to move RogueBasin. Obviously it will still be a good idea to make regular backups whatever else happens. Otherwise YourWiki looks like a possibility for temporary / emergency backup location. I'll be waiting a while to see how things proceed before doing more. [[User:PaulBlay|PaulBlay]]<br />
<br />
::::::: Duerig comes through once again! This is absolutely amazing stuff, and exactly what we need. Thank you! Now I can start a torrent based on the backups/ directory. This is awesome! :D [[elig]]<br />
<br />
== Weird error? ==<br />
<br />
Every time I search for Bjorn or Bergstrom the search crashes. I was trying to figure out when the new paypal button was added by searching for Bjorn Bergstrom and then seeing when he added it. Unfortunately, it crashes. Any idea why? [[elig]]<br />
<br />
: I've seen this before. Unfortunately I can't remember the exact reason for the problem (or where I wrote about it) but I think it's got something to do with the content of the pages searched for (possibly related to the way non-ascii characters get messed up). [[User:PaulBlay|PaulBlay]]<br />
<br />
== The Roguebasin torrent! ==<br />
<br />
Here is a torrent for the most recent backup of the Roguebasin. I'll be seeding it at 50kb/s pretty much forever. Remember, seeding this is completely legal and supports the preservation of the Roguebasin, so please seed!<br />
[http://www.mininova.org/tor/2742707 Get the torrent here!]<br />
<br />
::You can also save the copy on [http://www.adrive.com/static/storageplans_basic Adrive] or [http://skydrive.live.com Skydrive] --[[User:Pilotpirx|Pilotpirx]] 11:36, 8 July 2009 (CEST)<br />
<br />
== New spamers ==<br />
Think its time to update the wiki again? or do something with captha or something to lock new users... the spam is coming thick and fast [[User:Stu|Stu]] 17:39, 10 July 2009 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=RogueBasin_talk:Community_Portal&diff=18475RogueBasin talk:Community Portal2009-07-10T15:39:13Z<p>Stu: </p>
<hr />
<div>{{talkpagetool}}<br />
<br />
<table class="infobox" style="float:right;clear:right; width: 11em; border: 1px solid #93BACB; background:#E0E7EF;font-size:95%; margin:1em; line-height:1.4em;"><br />
<tr><br />
<th style="background:#C2D8EF; padding:.4em; margin:1em; font-size:105%">Archives</th><br />
</tr><br />
<tr><br />
<td><br />
* [[/Archive 1|1]]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Game Announcements ==<br />
If you have a new game/version/release to announce to the world, Make an edit to the [[News]] page, and please follow the existing format. If you want to generate discussion and receive feedback and comments, make sure to head over to [http://roguetemple.com RogueTemple] and use their forums, as well as [[rgrd]]. [[User:Stu|Stu]] 14:21, 16 May 2008 (CEST)<br />
<br />
<br />
<br />
== Link breaks wiki, News at 11 ==<br />
<br />
The following link (from 'dead-end pages') fails to display anything other than nasty error messages. Possibly due to illegal characters in title?<br />
<br />
http://roguebasin.roguelikedevelopment.org/index.php?title=Hansj%3F%84%E2%80%9A%3F%82%C2%B6rg_Malthener<br />
<br />
Other 'bug'ish news. [[SDL]] exists, but searching for SDL will return zero hits. [[User:PaulBlay|PaulBlay]]<br />
<br />
The error with Hansjoergs page are not because of illegal characters in the URL. They should be valid even though they look like at least twice encoded in Unicode. There seems to something terrible broken recently with non 7-bit characters. Database update maybe? Try searching for any special character like e.g. '????' (U+00C4 "LATIN CAPITAL LETTER A WITH DIAERESIS" if it gets mangled). Even the db search bails with an error. --[[User:Bhaak|Bhaak]] 15:58, 23 March 2009 (CET)<br />
<br />
== Spambots ==<br />
<br />
There was a small spambot attack recently, dunno how they overrid the spam protection (what is the current spam protection)? I had no luck blocking them via the sysop special pages. Is there any way to delete user accounts?<br />
<br />
--[[User:Slash|Slash]] 01:08, 12 Apr 2007 (CEST)<br />
<br />
I think it may be useful to update MediaWiki software to the latest version. The one that's currently installed is so old, the mind boggles. The current version has captchas and other stuff, and it's much easier to revert vandalism. [[User:Grue|Grue]] 10:23, 12 Apr 2007 (CEST)<br />
<br />
IIRC Bj????rn set up the latest version when the server translation was performed? Also, this is plain vandalism, not even spam (deleting '+' and everything after a '&', what use would that have?<br />
--[[User:Slash|Slash]] 17:19, 12 Apr 2007 (CEST)<br />
:It can't be the latest version. For example when you look at the diff between two revisions, there's no link to edit the revision. This feature was in Wikipedia since I joined it, probably, and that was very long time ago. So, to revert vandalism one has to click three times instead of two, pretty annoying. I don't know, maybe it's configured incorrectly, but it definitely looks very outdated. [[User:Grue|Grue]] 10:52, 13 Apr 2007 (CEST)<br />
<br />
:It's definitely an old version, the [[Special:Version]] page shows as using version 1.3.9 ''(The 1.3.x line was last updated in November 2005)''. The newest release is 1.10.0 although most modern versions of MediaWiki require PHP5 though ''(since version 1.7)''. The latest version that still supports PHP4 is 1.6.10 available [http://www.mediawiki.org/wiki/Download here]. 1.6.10 was released on 20th February 2007. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
::THe Wiki is currently running MediaWiki 1.6.10. Hopefully we won't see any more spam attacks. -- Bjorn 09:50 3 Jul 2007<br />
<br />
There was another spammer, although it could be a person doing it, rather than a bot. It was [[User:Yaxiaexx099|this account]] doing it, and [http://roguebasin.roguelikedevelopment.org/index.php?title=Dalhxf&oldid=12449 this] was was what he did.<br />
<br />
Here we go again, looks like the spambots are returning? Three new pages filled with.. something. [[Aldan|Here]], [[Generosity|here]] and [[Nourished|here]], created by three (new?) users in a short succession. Are there any anti-spambot guidelines somewhere, since I'm not sure of what to do, except for reporting? [[User:Solarnus|Solarnus]] 23:48, 8 January 2009 (CET)<br />
<br />
:Wonder if there is any way we can give rights to some users to approve new users so we dont have these spambots sign up, or we need to modify the captcha code to stop this crap. [[User:Stu|Stu]] 14:31, 12 January 2009 (CET)<br />
<br />
::I would suggest try giving a selected few, trusted users the rights to approve new users. The use of CAPTCHAs is kinda useless as of today (well, except for scaring off scriptkiddies), since it's an out of date "security measure" and there's some various techniques to bypass it. It's also a problem for ie, visual impaired people having trouble reading the characters (more info over at wikipedia, for those of you not being convinced it's a crappy technology..). [[User:Solarnus|Solarnus]] 15:50, 23 January 2009 (CET)<br />
<br />
<br />
<br />
<br />
<br />
== All those guides! ==<br />
<br />
Where did all those good guides at http://www.roguelikedevelopment.org/ go? according to the news, the content has been moved to this wiki but I can't find any of those guides! me want's 'em badly!<br />
[[User:Solarnus|Solarnus]] 11:28, 16 January 2008 (CET)<br />
:Sorry, I meant of course that alot of guides are missing, as least most of the map algorithm stuff previously found on the old site is missing here at the wiki. Anyone got copies of those guides, please? [[User:Solarnus|Solarnus]] 14:28, 23 January 2008 (CET)<br />
::And you looked in the map section of [[Articles]]? All the ones I recall are there. Perhaps you can use the wayback machine to calculate which ones seem to be missing? [[User:Duerig|Duerig]] 17:12, 23 January 2008 (CET)<br />
:::lol, the wayback what..? No, realy, I know there's alot missing from the site. Some examples are the guides written by Mike Anderson (Dungeon-Building Algorithm, Fractal Landscapes) and Radomir "The Sheep" Dopieralski (Recursive LvL Generation) [[User:Solarnus|Solarnus]] 17:52, 23 January 2008 (CET)<br />
::::Look at this URL. It is from www.archive.org, the wayback machine for the Internet: http://web.archive.org/web/20060114055601/http://roguelikedevelopment.org/ but before you go adding all of the articles to the wiki, you should know that there was some effort to move them over, but only if the original authors could be found to give permission. So you should check with an admin here about what to do. [[User:Duerig|Duerig]] 08:50, 24 January 2008 (CET)<br />
:::::Oh crap, I thought I could just go and add what I managed to find, since it had already been released on the site o.0' Pardon me, I'm too quick sometimes, doing stuff without thinking first. <br /> But, IMHO, not moving over all that stuff just because the original author couldn't be found kinda buggers me, that's just wast of time and good knowledge, stupidlly forcing to "reinvent the wheel". And it buggers me even more, since obvisiouly (spelling?) it can still be found on the web thanks to that wayback machine you're talking about (thanks for that link btw, would've never thought of that). <br /> Thanks for telling me dude, I'll try slowing down/backing off and poke an admin about it before doing anything else.<br /> <br />Anyway, should the "previously missing" [[Dungeon-Building Algorithm]] article I dug up yesterday be removed, or just leave it for now and hope for the better? [[User:Solarnus|Solarnus]] 13:50, 24 January 2008 (CET)<br />
<br />
<br />
::::::Is there any chance of the articles being reposted on the original site until they can be ported here? They're only text documents, and a number of them were very good references. Most of the original files are not stored on wayback machine, so forn ow they are lost for good. [[User:lapoubelle|lapoubelle]] 30 April 2008<br />
<br />
I have spent most of today searching for and collecting all of the articles that were on the old system but not on roguebasin. I was able to recover all but two. Those two and links to the archives are at [[User:Duerig]]. That way they should be safe until we can decide how to handle them. If the admins have a problem with this, I'll host them on my own domain if I have to. Let me know if you can find information on either of the two remaining articles. [[User:Duerig|Duerig]] 21:53, 1 May 2008 (CEST)<br />
<br />
<br />
<br />
<br />
== Game or project? ==<br />
<br />
Template [[Template:Angband-variant]] asks for status field. Then game entry is added to "status games" category. This works well for stable games and defunct games but fails for alpha, beta and talkie talkie *projects*. Thus any Angband variants which classify themselves as having alpha or beta status do not get included in proper category. Any ideas how to correct that without destroying too much existing work? I would opt for removing status field and adding all variants to categories manually. Other choice is to spilt template into several like it was done with [[Template:Gameinfo]]. What are others opinions on this? <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 16:18, 19 August 2008 (CEST)<br />
<br />
: I think the best bet is to split the template like the Gameinfo did. I presume there was a good reason to do that split rather than use the status field cleverly. I don't like people having to manually add the category tag as that will result in people forgetting to categorize the variant at all. --[[User:JeffLait|JeffLait]] 05:21, 21 August 2008 (CEST)<br />
<br />
:: Foundations are lain. I am going to wait some more time before proceeding to change all Angband variant pages in case better ideas show up or someone has objections. <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 15:03, 25 August 2008 (CEST)<br />
<br />
== 1krl ==<br />
<br />
We should add this to the wiki, but I'm not sure where.<br />
http://1024brl.googlepages.com/<br />
(and a link to the rgrd posts of course.<br />
--[[User:Soyweiser|Soyweiser]] 02:00, 22 August 2008 (CEST)<br />
<br />
== Rule of thumb for new -> old news? ==<br />
<br />
How many months (or how many posts) should be in [[News]] before you should move some to Old News? I would suggest that four months or so is enough as the 'News' section is currently longer than the rest of the Main page. [[User:PaulBlay|PaulBlay]]<br />
<br />
:I think that we should move all news from 2008 to Old News. We actually don't really need the [[News]] page to show news older than a month, as it is intended to show '''new''' releases. I will move all news from 2008 now. [[User:Nate879|Nathan Stoddard]] 22:34, 22 March 2009 (CET)<br />
<br />
== More bug-ish behaviour - support for unicode/multi-byte characters ==<br />
<br />
I've just noticed that Japanese text typed in my user page spontaneously changed into gibberish (technically 'mojibake' ;-). The interesting point is that '''initially''' it displayed properly, only after a day or two did it turn into unintelligible characters. Similar behaviour can be seen at [[POWDER/Russian translation]]. For test purposes I will now write something in Japanese. ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? [[User:PaulBlay|PaulBlay]]<br />
<br />
== talkie = pre-alpha / planning ? ==<br />
<br />
The 'talkie' category appears to be a little off compared to the line-up of "alpha, beta, stable". Should I understand it to include games that are pre-alpha / planning or should "pre-alpha" be a new category? <br />
<br />
A significant number of 'alpha' projects include no download. I was under the impression that 'alpha' meant that you could run it and see something even though it might not be a playable game yet. [[User:PaulBlay|PaulBlay]]<br />
:Yes, I think that games that are in 'alpha' but have no downloads should be moved to 'talkie'. [[User:Nate879|Nathan Stoddard]] 23:23, 12 April 2009 (CEST)<br />
<br />
== Image uploads? ==<br />
<br />
I see that file uploads are disabled. I'd like to be able to upload a few small icons for alpha/beta/stable/defunct (after I find/create them ;-). If I can't do it myself, is there an admin who I could email or something? [[User:PaulBlay|PaulBlay]]<br />
:It's not possible to upload files, but you can use images from other sites. Put the image's URL on the page, without any special formatting (look at [[Downfall]] for an example). If you need a site to upload to, I recommend [http://imgur.com/ Imgur]. [[User:Nate879|Nathan Stoddard]] 23:26, 12 April 2009 (CEST)<br />
<br />
== RGRD Wiki Project ==<br />
<br />
I see this hasn't had any new names added since August 2008. As such perhaps it shouldn't be so prominent in the Contribute section. Maybe ...<br />
<br />
<br />
<nowiki>=Contribute=</nowiki><br />
If you'd like to contribute to RogueBasin, simply create an account and log in. Feel very free to edit! We especially need more information added to the [[:category:roguelike games|games pages]] and the [[list of roguelike games|lists]] - if you're a developer, consider updating your game's page, and making sure that it (and you) are included in the relevant lists.<br />
<br />
If you're an experienced developer, consider writing articles about creating Roguelikes. There are many people new to Roguelike development, and they often need help. It's especially helpful to write articles about problems you have experienced yourself. Also you can add your name to the [[RGRD Wiki Project]] (directly, or by posting a message on [[rgrd]] saying how you want to participate). If someone sees a relevant post by you, they'll upload it to this wiki as an [[articles|article]].<br />
<br />
[[User:PaulBlay|PaulBlay]]<br />
:I think this will be fine. You can go ahead and change it if you want. [[User:Nate879|Nathan Stoddard]] 23:27, 12 April 2009 (CEST)<br />
<br />
== New main page ==<br />
<br />
I like the appearance of the new main page :) --[[User:Slash|Slash]] 05:32, 13 April 2009 (CEST)<br />
<br />
I like it too, nice work! I'd like the contribute part to be blue though, [[User:Colonp/maintest]].. Not perfect right now. [[User:Colonp|Colonp]] 04:17, 17 April 2009 (CEST)<br />
<br />
== STATUS in game templates ==<br />
<br />
A number of games have |status= lines in the info box, but it does not display anything on the screen. The content is generally a duplicate of the type indicated by the template name (e.g. game-beta is status [[Beta]], etc.)<br />
<br />
Are these lines left over from an earlier set of templates? Can the STATUS information safely be called redundant and removed? [[User:PaulBlay|PaulBlay]]<br />
<br />
== 'roguelikes' section of Main page. ==<br />
<br />
I think that ''influential'' would be clearer (and less controversial) than ''popular''. There are arguably many recent roguelike games that are more popular than ToME, but few (if any) that have been more influential. <br />
<br />
I suggest that [[Major roguelikes|Major Roguelikes]], [[Roguelike Reviews]], [[Tree of roguelike evolution]], and [[Recently Updated Roguelikes]] be added to the 'inclusion' page [[list of roguelikes|Lists of Roguelikes]], and the text changed as below:<br />
<br />
<nowiki>= Roguelikes =</nowiki><br />
Many Roguelikes are freely available online. The most <strike>popular</strike> influential are:<br />
<br />
<div style="text-align:center">[[ADOM]] '''·''' [[Angband]] '''·''' [[Crawl]] '''·''' [[NetHack]] '''·''' [[ToME]]</div><br />
<br />
Since the control systems of these Roguelikes are geared towards "expert" players, the novice player may be interested in trying a 'lighter' game like some of the '''[[coffeebreak roguelike]]s''' or just dive in at the deep end and find a '''[[:Category:Roguelike_games|game]]''' to suit you.<strike>. The following may help you find out more: <br />
<br />
*[[:category:roguelike games|Categorized Roguelikes]]<br />
*[[list of roguelikes|Lists of Roguelikes]]<br />
*[[Major roguelikes|Major Roguelikes]]<br />
*[[Roguelike Reviews]] <br />
*[[Tree of roguelike evolution]]<br />
*[[Recently Updated Roguelikes]]</strike><br />
<br />
== Also ... ==<br />
<br />
See [[Talk:List of roguelikes]] for possible replacement for the content of that page. [[User:PaulBlay|PaulBlay]]<br />
<br />
== Featured game section? ==<br />
<br />
How about a 'featured game' section (bottom left of main page). Suggested content: Short description, mini-review, link to RogueBasin page and main review (if present). I'd suggest choosing games that have been updated in the last month and are at least 'beta'. [[User:PaulBlay|PaulBlay]]<br />
<br />
: Well, I've done one. Maybe someone will replace it with a different game in a week or two. [[User:PaulBlay|PaulBlay]]<br />
:: Looks great! I actually have a C64 in a joystick system that has this game on it. [[User:Elig|elig]]<br />
<br />
== Location instead of Nationality? ==<br />
<br />
In the developer info, I think it would be more fun to have a Location option instead of a Nationality option. With location, people can put in however much information on their location they want. They could type things like "Sacramento, CA, USA" or just "Arizona, USA" or even "France". The Nationality field limits this information purely to the country where the person is from, which in many cases might not be as interesting as the state in that country that the person lives in. <br />
<br />
So, the advantage with using the word Location instead is that it provides people the flexibility to put in however much or little information they want, and it can still contain the exact same information that Nationality does. Also, upgrading is easy because we can just replace all instances of Nationality with Location. Although this might be considered a minor issue because people can enter their state and so on into the Nationality field, the Nationality field still encourages new contributions to contain as little information as possible on the location of the developer. Renaming it Location would encourage them to put in as much information as they wanted to. - [[elig]]<br />
<br />
: I'm not hard against it, but it doesn't sound that great a move. I doubt the excitement would keep you awake at nights if I told you that I live in Wiltshire now but Berkshire before I moved. ;-) States are mostly only going to be interesting if you happen to live in the same country. That said, go ahead and do it if you want, it's no big deal either way. [[User:PaulBlay|PaulBlay]]<br />
<br />
: The biggest problem with this is that every developer would have to change their developer info. It would be better to create a new template with the nationality changed to location, but then some developers would have a "location" field and others would have a "nationality" field, which could be confusing. I don't think it's worth it to change it. [[User:Nate879|Nathan Stoddard]] 00:38, 8 May 2009 (CEST)<br />
<br />
== Important links on front page? ==<br />
<br />
What about having some closely related important community links on the front page? There are very few major resources aside from Roguebasin, pretty much just Temple of the Roguelike, the rgrd newsgroup, #rgrd and Temple of the Roguelike's forums. The RGRD links are currently under articles, perhaps for lack of a better place. They're not articles and it seems a little confusing to me to have them under there. Links might be appropriate, but since there are so few other major resources for the roguelike community, why not highlight them directly on the main page? I feel this would really help people who find Roguebasin for the first time to enter the community. At least, I think all these links should be placed in a single location that is easy to access and properly labeled. Thoughts? - [[elig]]<br />
<br />
I have now added this to the front page, to show how I think it might look. Feel free to take it off ofcourse if you absolutely hate it, but I think it could be a valuable addition to the front page. Thoughts? - [[elig]]<br />
<br />
A few [[User:PaulBlay|PaulBlay]]<br />
<br />
# Although I like "Temple of the Roguelike" it doesn't really need two links.<br />
<br />
# r.g.r.d Newsgroup and R.G.R.D IRC Chatroom could have direct links as well as (instead of?) the links to RogueBasin pages.* <br />
<br />
# angband.oook.cz deserves a mention.<br />
<br />
# You've just stolen the space I wanted to use for the "Featured game section" ;-) (But I can't complain too much as I didn't take the time away from [[Angband/65]] development to feature even one game)<br />
<br />
NOTE: r.g.r.d Newsgroup should probably have a Google groups link - many people won't have a browser that supports things like news://msnews.microsoft.com/microsoft.public.pocketpc. If there was a browser equivalent for IRC:// I'd probably say the same about that.<br />
<br />
Also note that there's a "links" link at the top of the page. I'd suggest that page could be made more user-friendly and updated.<br />
<br />
<br />
Featured games is a good idea. We can always put it above or below the community links. But it should definitely have a featured games thing on the front page. The other changes are all good, I'll probably just leave the Temple of the Roguelike forum, since this page already has news physically on it. The r.g.r.d. newsgroup should be a direct google link IMO as well. IRC I think it would be better to have a seperate page for, just because there's no easy way to specify an IRC server's address, to my knowledge. I'll also add angband.oook.cz - [[elig]]<br />
<br />
I've also added a temporary space for the future featured Roguelike section. Feel free to remove/edit it of course. Just figured I'd reserve the space :) Also, feel free to put it above the Roguelike community links if you want. Also, what about having the featured roguelike at the very top of the page? Like, in the space where "What is a Roguelike?" is now, with "What is a Roguelike?" right below it? It might be something neat to entice any new visitors to try a Roguelike. - [[elig]]<br />
<br />
== Specific games.. ==<br />
<br />
''"I don't think we should have links to sites about specific games"''<br />
<br />
http://angband.oook.cz/ is not about a single game, it is about an entire genre of roguelike games. As evidenced by the fact that there are 82 *band variants in the [[List of Angband variants]]. There are at least as many posts on variants as on 'vanilla' Angband and frankly it gets more traffic than http://www.roguetemple.com/ by a long way. [[User:PaulBlay|PaulBlay]]<br />
:Okay. From the description of the site, I assumed it was primarily about Angband. I didn't even look at the site. I will re-add it. :) [[User:Nate879|Nathan Stoddard]] 21:50, 14 May 2009 (CEST)<br />
<br />
== Reorganize site? ==<br />
<br />
Right now, this site serves two main purposes: to describe existing Roguelike games and have articles about creating new Roguelikes. I think that at least for the average user, it might be confusing to have the two "mixed" like they are. For example, I think the news section of the main page should be divided into two sections: games and development tools. What do you think? [[User:Nate879|Nathan Stoddard]] 21:54, 14 May 2009 (CEST)<br />
<br />
: I don't think the development tools should be split out of news, but I do agree that something of a reorganisation is needed. The site is, IMO, more accessible for game information than it is for development help. The great majority of game information is in one of two types - 1) Lists and categories, 2) Individual game information. That is basically all that's needed - ways of finding a suitable game efficiently and information on the game itself. <br />
<br />
: Development articles (and related content) are trickier. For one thing I suspect many of the articles may be old fashioned. There are also quite a few articles that are 'locked' (can't be edited). They are spread around between different languages and I think there are big gaps in difficulty level between them. What I think would be great would be if there was a series of articles all in the same language (preferably one accessible to new learners and usable on many platforms) that cover all major aspects of development. Don't worry about having the most efficient algorithms, worry more about understandability and consistency between articles. Make use of stable libraries if appropriate. Basically with the intent that someone starting at the first article and finishing at the last could go from newbie to having made a basic functional roguelike game. That series could form a stable "trunk" and generous inclusion of links to other relevant articles would provide branches off to the details and options that more experienced developers (and those using other languages) will need. [[User:PaulBlay|PaulBlay]]<br />
<br />
:: I think that's a good idea. It might be best to use [[Python]], because it is easy to learn, fast to develop in, and portable. It's slow (some say it's 100 times slower than C++), but as you said, efficiency isn't very important. I have some experience with Python, so I could help write some of the articles. [[User:Nate879|Nathan Stoddard]] 01:42, 15 May 2009 (CEST)<br />
<br />
::: As I understand it the latest version has improved quite markedly in speed, hasn't it? <br />
<br />
::: I'm pretty much booked up working on [[Angband/65]] as far as my free time goes up till the end of August so I'm afraid I won't be of much use (and I don't know python). [[User:PaulBlay|PaulBlay]]<br />
<br />
:: Definitely, the game info is far more accessable than the development info. What we're desperately lacking is more information on development, a better organization of that information, and a better way to access that information. I'm not entirely sure how to fix these problems, except for maybe creating a generic Roguelike Development page that is linked to from the front page. Aside from that, I'm not sure. :\ I've thought about adding articles from time to time, but I never know what to name them or where to properly add them. - [[elig]]<br />
<br />
== Library template(s) ==<br />
<br />
I've added [[Template:Library]] and applied it to the pages in category:library. While doing so two points came up to be resolved: <br />
<br />
1. Should there be -alpha, -beta, -stable and -defunct divisions for libraries?<br />
<br />
2. Should [[Roguelike Library For Java]] and [[Roguelike Library For Perl]] be changed to use the library template I added? <br />
<br />
P.S. Feel free to change / or comment on the library template I made. [[User:PaulBlay|PaulBlay]]<br />
<br />
: IMO all libraries should follow the same format, and I love the alpha beta stable etc. thing. Sounds good to me! - [[elig]]<br />
:: I also like that curses uses a library like template to specify that curses is a series of libraries. [[elig]]<br />
<br />
== Who's minding the store? ==<br />
<br />
That is to say, who is it that does the admin stuff like delete pages in the delete category, pay for the domain name, update the mediawiki version? I'm just asking because it would be a real shame if I came back here one day and it was all 404'ed or something. [[User:PaulBlay|PaulBlay]]<br />
<br />
Not sure, might be slashie. I was thinking of just such an awful idea myself recently. Maybe we should start some kind of fund to financially support roguebasin. Erowid for instance has a non-profit donation based organization that pays their bills. Of course, we wouldn't be able to do anything nearly so fancy, but a paypal account and the ability to donate might be nice... Thoughts? - [[elig]]<br />
<br />
:: I just now noticed the PayPal donate button on the lower left side of the page. Is that new? I definitely think it should be given a more prominent place on the website if it is! Maybe a nice spot on the front page, and one on the left right under the logo, maybe. Glad to see this place has a donate button now, though! Everybody donate! :D [[elig]]<br />
<br />
::: That's been there forever. Before everybody donates I think someone should email the address shown and see if you get a reply. (I don't think Bjorn has edited anything here all the time I've been here?). [[User:PaulBlay|PaulBlay]]<br />
<br />
:: This is being discussed at http://www.roguetemple.com/forums/index.php?topic=413 , thanks for your interest! --[[User:Slash|Slash]] 07:18, 2 July 2009 (CEST)<br />
<br />
== Wiki backup / duplicate? ==<br />
<br />
With the current situation (not sure who runs RogueBasin, not sure who has the admin account for the wiki, out of date mediawiki version) would it be possible for someone to duplicate / backup the wiki content? Worst case it wouldn't all be lost if it goes south. Best case someone might be willing to set up a new host with better spam-protection and less bugs. [[User:PaulBlay|PaulBlay]]<br />
<br />
::I agree, it would be a great benefit to the entire community if we were able to duplicate/mirror this wiki. If anyone could duplicate it, we could set up some mirrors in case the main site ever goes down. Plus, this has the added advantage of independent members of the community being able to download a backup copy. We definitely need an easy way to mirror/download/backup Roguebasin, IMO. [[elig]]<br />
<br />
::: There's a special page for Exporting pages for import to another '''MediaWiki''' wiki. [[Special:Export]]. Not sure how well it works. Or you can ''just'' manually copy each page source. Possibly to a wiki host like PBWorks ??? [[User:PaulBlay|PaulBlay]]<br />
<br />
:::: I have written/grabbed a few scripts to begin automating the backup process and I've also used them to make a complete backup of the roguebasin wiki. Both the scripts and the initial backup are available in a package at: EDIT: Download scripts at http://www.xmission.com/~tyrecius/roguebasin-backup-scripts.zip and backup at: http://www.xmission.com/~tyrecius/roguebasin/backups/ /EDIT so grab a copy and keep it just in case. If somebody feels ambitious, they can finish automating the process. [[User:Duerig|Duerig]] 07:05, 2 July 2009 (CEST)<br />
:::: This is awesome, Duerig! This is exactly what we needed! :D Thank you. I'm going to download it right away. [[elig]] Edit: After having downloaded it, this really is EXACTLY what we need. This is fantastic. Everyone should download this. [[elig]]<br />
<br />
::::: Ha-ha, maybe not *everyone* (surely there are bandwidth concerns?). But great news and thanks Duerig. I have just downloaded it and will experiment with how easy it is to set-up elsewhere. (It's not a backup until you've tested the restore process! ;-) I'll report in the Temple of the Roguelike thread. [[User:PaulBlay|PaulBlay]]<br />
<br />
:::::: Given your enthusiasm, I decided to bite the bullet and finish automating the process. Download the scripts and run 'backup.sh' and everything will be done for you including downloading the actual xml files and compressing them into a tarball with the current date. I converted a piece of my webspace into backup storage and I've set up a cron job to make monthly backups and stash them there. Fully automated backup scripts at: http://www.xmission.com/~tyrecius/roguebasin-backup-scripts.zip and backup index at: http://www.xmission.com/~tyrecius/roguebasin/backups/ I plan to leave things running and available until/unless my provider complains. [[User:Duerig|Duerig]] 09:32, 2 July 2009 (CEST)<br />
<br />
::::::: Scautura has made the [http://www.roguetemple.com/forums/index.php?topic=413.msg3322#new very generous offer] to supply ad-free wiki hosting. Depending on whether we get any replies from Bjorn (and what those replies are) I think it might be a good idea to move RogueBasin. Obviously it will still be a good idea to make regular backups whatever else happens. Otherwise YourWiki looks like a possibility for temporary / emergency backup location. I'll be waiting a while to see how things proceed before doing more. [[User:PaulBlay|PaulBlay]]<br />
<br />
::::::: Duerig comes through once again! This is absolutely amazing stuff, and exactly what we need. Thank you! Now I can start a torrent based on the backups/ directory. This is awesome! :D [[elig]]<br />
<br />
== Weird error? ==<br />
<br />
Every time I search for Bjorn or Bergstrom the search crashes. I was trying to figure out when the new paypal button was added by searching for Bjorn Bergstrom and then seeing when he added it. Unfortunately, it crashes. Any idea why? [[elig]]<br />
<br />
: I've seen this before. Unfortunately I can't remember the exact reason for the problem (or where I wrote about it) but I think it's got something to do with the content of the pages searched for (possibly related to the way non-ascii characters get messed up). [[User:PaulBlay|PaulBlay]]<br />
<br />
== The Roguebasin torrent! ==<br />
<br />
Here is a torrent for the most recent backup of the Roguebasin. I'll be seeding it at 50kb/s pretty much forever. Remember, seeding this is completely legal and supports the preservation of the Roguebasin, so please seed!<br />
[http://www.mininova.org/tor/2742707 Get the torrent here!]<br />
<br />
::You can also save the copy on [http://www.adrive.com/static/storageplans_basic Adrive] or [http://skydrive.live.com Skydrive] --[[User:Pilotpirx|Pilotpirx]] 11:36, 8 July 2009 (CEST)<br />
<br />
== New spamers ==<br />
Think its time to update the wiki again? or do something with captha or something to lock new users... the spam is coming thick and fast [[User:Stu|Stu]] 17:39, 10 July 2009 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=Talk:Text_tags&diff=16690Talk:Text tags2009-04-04T20:31:19Z<p>Stu: </p>
<hr />
<div>Proposed set of 'text tags' for marking type of game in lists, tables, etc. <br />
<br />
Comments, suggested changes, etc. are welcome. [[User:PaulBlay|PaulBlay]]<br />
<br />
: I like the concept, I dislike the 'leetness' aspect, I'd rather see plain/normal fonts so its readable. The colours look fine to me, tho the defunct colour I think should be different than the wiki theme background (ie: anything but white.. maybe a brown or something.....) [[User:Stu|Stu]] 22:31, 4 April 2009 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=Talk:Major_roguelikes&diff=16253Talk:Major roguelikes2009-03-24T02:41:30Z<p>Stu: </p>
<hr />
<div>IMBO [[ToME]] as more than enough players to not fall in the [[Stable_games|"stable but not much played"]] category.<br />
<br />
----<br />
<br />
There has been some miscommunication if it is believed that the [[Stable_games]] category means that the games are not much played! I have been opposed to this hierarchy from the beginning due to just this sort of problems.<br />
<br />
I think this category should be reserved for genre defining roguelikes. I do not have any clear criterion for determining this (which is why I think trying to categorize this way is foolish and likely to just lead to bad feelings), but I do not believe [[ToME]] is there.<br />
<br />
One approach to make this more systematic would be just to limit [[Major Roguelikes]] to those with USENET groups. This would remove [[Crawl]], but if it allows us to move forward without needless infighting, I'm all for it.<br />
<br />
----<br />
<br />
Perhaps the category should be renamed to Influential Roguelikes, where the game's influence is defined by how much the game is being copied by other popular games and having other popular games derived from the game.<br />
<br />
This would have a bias toward games with sources available and licensed to allow derived works, but that seems reasonable to me. The more open a game is, the more it CAN influence other game developers.<br />
<br />
So, if we look at the tree that was just put on the [[Major Roguelikes]] page, everything with a child node influenced its children, and should count as an [[Influential Roguelikes]]. List the leaf nodes in the Stable section, including [[Adom]], [[Crawl]], [[SLASH'EM]]. [[ZAngband]] seems on the border to me, since it seems to have spawned as many variants as Angband has.<br />
<br />
----<br />
<br />
# Influential isn't driven by open source. One hardly needs the source code to be influenced by another game!<br />
# I like the idea of branching based on evolution/game type. I'm most interested in branching based on game type. This is the reason for the [[HackLike]] vs [[Band]] distinction.<br />
# I'm curious as to why you include [[Nethack]] on the list but exclude [[Adom]]. If you count variants based purely on code, both are equally sparse and should be crowded out by [[ZAngband]] and other [[Angband Variants]]. If you count variants based on style, however, I would contend that there is no shortage of [[Adom]] deriviatives. [[Avanor]], for example, clearly lists itself as Adom inspired.<br />
# I think any organizatin of [[Major Roguelikes]] should at a minimum include the rec.games.roguelike.* "approved" roguelikes.<br />
<br />
----<br />
<br />
If you can find popular games that copy Adom, then by all means put it in! My explanation in that last paragraph was working from the tree diagram, which focuses more on what I called the 'derivation' aspect of Influence, as opposed to the 'copying' aspect.<br />
<br />
I think Usenet should be ignored, because the games listed and omitted there are chosen more by accident of history and bureaucracy than they are by merit. The rec.games.roguelike hierarchy is a historial artifact, but this page is attempting to describe the way things are now.<br />
<br />
----<br />
<br />
Okay, I have moved the Usenet listing to the end, and having the free-for-all listing as the first. With luck, the number of roguelikes added to the canon this way will be small enough that we don't need to get sucked into arguing what constitutes "popular" or "influential".<br />
<br />
== Suggested addition ==<br />
<br />
Hiya, I'd like to add [[Dwarf Fortress]] to the lis of Major Roguelikes. It has a very large fanbase and I hink it is deserving of such status. Also, it is a new genre of roguelikes.--[[User:GlassInMyEyeguy|GlassInMyEyeguy]] 23:13, 23 March 2009 (CET)<br />
<br />
:: Wii bowling has a large fan base. Wii bolwing is not a roguelike. Dwarf Fortress is not a roguelike, its more of a resource micromanagement simulation. [[User:Stu|Stu]] 01:16, 24 March 2009 (CET)<br />
<br />
::: Your argument is not backed up well (i.e. at all) by the "What is a Roguelike?" definition given on the main page. Moreover Dwarf Fortress can be played in 'Adventure Mode' which has pretty much everything you'd want from a strict definition of roguelike. I was initially tentatively against including Dwarf Fortress on the basis that it has not been around long enough to be sure that its popularity will be lasting. However I changed my mind when seeing that the Dwarf Fortress Wiki has around 6 times as many visitors as RogueBasin itself does. Perhaps it would introduce a little fresh air to have a modern [[Major Roguelikes | Major Roguelike]] in the list. Afterall this is already a genre which has a tendency to stuffiness and conservatism. [[User:PaulBlay|PaulBlay]]<br />
<br />
:::: I'm sure you'll add it to the list and the world will keep turning, because we cant have a list that has not been updated in a while, despite that nothing worth adding to the list has come along (maybe powder but I'm not sure it yet qualifies as major roguelike). To be a major roguelike, it needs to have had great influence over current roguelikes, and nothing really hits that outside of what is currently the big ones (nethack, adom, *angbands, crawl). The great majority of DF players don't even bother with the tacked on adventure mode (its like a 5:1, 6:1 ratio of posts in the dwarf mode to adventure mode forums). [[User:Stu|Stu]] 03:41, 24 March 2009 (CET)<br />
<br />
== Powder ==<br />
<br />
I think Powder may be deserving of major roguelike status one day seeing as it has the 2nd most posts on R.G.R.M. after DCSS.</div>Stuhttp://roguebasin.com/index.php?title=Talk:Major_roguelikes&diff=16249Talk:Major roguelikes2009-03-24T00:16:34Z<p>Stu: added my opinion</p>
<hr />
<div>IMBO [[ToME]] as more than enough players to not fall in the [[Stable_games|"stable but not much played"]] category.<br />
<br />
----<br />
<br />
There has been some miscommunication if it is believed that the [[Stable_games]] category means that the games are not much played! I have been opposed to this hierarchy from the beginning due to just this sort of problems.<br />
<br />
I think this category should be reserved for genre defining roguelikes. I do not have any clear criterion for determining this (which is why I think trying to categorize this way is foolish and likely to just lead to bad feelings), but I do not believe [[ToME]] is there.<br />
<br />
One approach to make this more systematic would be just to limit [[Major Roguelikes]] to those with USENET groups. This would remove [[Crawl]], but if it allows us to move forward without needless infighting, I'm all for it.<br />
<br />
----<br />
<br />
Perhaps the category should be renamed to Influential Roguelikes, where the game's influence is defined by how much the game is being copied by other popular games and having other popular games derived from the game.<br />
<br />
This would have a bias toward games with sources available and licensed to allow derived works, but that seems reasonable to me. The more open a game is, the more it CAN influence other game developers.<br />
<br />
So, if we look at the tree that was just put on the [[Major Roguelikes]] page, everything with a child node influenced its children, and should count as an [[Influential Roguelikes]]. List the leaf nodes in the Stable section, including [[Adom]], [[Crawl]], [[SLASH'EM]]. [[ZAngband]] seems on the border to me, since it seems to have spawned as many variants as Angband has.<br />
<br />
----<br />
<br />
# Influential isn't driven by open source. One hardly needs the source code to be influenced by another game!<br />
# I like the idea of branching based on evolution/game type. I'm most interested in branching based on game type. This is the reason for the [[HackLike]] vs [[Band]] distinction.<br />
# I'm curious as to why you include [[Nethack]] on the list but exclude [[Adom]]. If you count variants based purely on code, both are equally sparse and should be crowded out by [[ZAngband]] and other [[Angband Variants]]. If you count variants based on style, however, I would contend that there is no shortage of [[Adom]] deriviatives. [[Avanor]], for example, clearly lists itself as Adom inspired.<br />
# I think any organizatin of [[Major Roguelikes]] should at a minimum include the rec.games.roguelike.* "approved" roguelikes.<br />
<br />
----<br />
<br />
If you can find popular games that copy Adom, then by all means put it in! My explanation in that last paragraph was working from the tree diagram, which focuses more on what I called the 'derivation' aspect of Influence, as opposed to the 'copying' aspect.<br />
<br />
I think Usenet should be ignored, because the games listed and omitted there are chosen more by accident of history and bureaucracy than they are by merit. The rec.games.roguelike hierarchy is a historial artifact, but this page is attempting to describe the way things are now.<br />
<br />
----<br />
<br />
Okay, I have moved the Usenet listing to the end, and having the free-for-all listing as the first. With luck, the number of roguelikes added to the canon this way will be small enough that we don't need to get sucked into arguing what constitutes "popular" or "influential".<br />
<br />
== Suggested addition ==<br />
<br />
Hiya, I'd like to add Dwarf Fortress to the lis of Major Roguelikes. It has a very large fanbase and I hink it is deserving of such status. Also, it is a new genre of roguelikes.--[[User:GlassInMyEyeguy|GlassInMyEyeguy]] 23:13, 23 March 2009 (CET)<br />
<br />
:: Wii bowling has a large fan base. Wii bolwing is not a roguelike. Dwarf Fortress is not a roguelike, its more of a resource micromanagement simulation. [[User:Stu|Stu]] 01:16, 24 March 2009 (CET)</div>Stuhttp://roguebasin.com/index.php?title=Talk:Recently_Updated_Roguelikes&diff=15180Talk:Recently Updated Roguelikes2009-03-19T15:32:36Z<p>Stu: </p>
<hr />
<div>For convenience I am not including 7DRL or similar quicky roguelikes (that are well covered elsewhere anyway). Also only including those where you can download the game (preferably have a home page and source as well).<br />
<br />
: Cracks and Crevices is alphabetised down in the S's, i'd move it but I'd have to alter all the alternate line colouring which I didnt want to mess with such an update touching every line..... [[User:Stu|Stu]] 15:12, 19 March 2009 (CET)<br />
<br />
:: Thanks. I wouldn't worry too much about the shading. There'll probably be a few more to be added yet. [[User:PaulBlay|PaulBlay]]<br />
<br />
::: Shame we can't have this kind of thing automated. When a new release is made, so many pages need to be touched. [[User:Stu|Stu]] 16:32, 19 March 2009 (CET)</div>Stuhttp://roguebasin.com/index.php?title=Talk:Recently_Updated_Roguelikes&diff=15166Talk:Recently Updated Roguelikes2009-03-19T14:12:04Z<p>Stu: </p>
<hr />
<div>For convenience I am not including 7DRL or similar quicky roguelikes (that are well covered elsewhere anyway). Also only including those where you can download the game (preferably have a home page and source as well).<br />
<br />
: Cracks and Crevices is alphabetised down in the S's, i'd move it but I'd have to alter all the alternate line colouring which I didnt want to mess with such an update touching every line..... [[User:Stu|Stu]] 15:12, 19 March 2009 (CET)</div>Stuhttp://roguebasin.com/index.php?title=Talk:Grid_Based_Dungeon_Generator&diff=15134Talk:Grid Based Dungeon Generator2009-03-19T00:06:37Z<p>Stu: </p>
<hr />
<div>This is the method described in [[QHack]] by [[Thomas Biskup]]. Divide and conquer via segmentation.<br />
[[User:Stu|Stu]] 01:06, 19 March 2009 (CET)</div>Stuhttp://roguebasin.com/index.php?title=Stu_George&diff=15036Stu George2009-03-17T16:17:22Z<p>Stu: Update some info</p>
<hr />
<div>{{developerinfo|name = Stu George<br />
|alias = [[User:Stu|Stu]], DF<br />
|nationality = Australian<br />
|languages = [[C]]<br />
|site = http://bloodycactus.com<br />
|games = [[UnderDark]], [[Cracks and Crevices]], [[Tomb of Rawdin]]<br />
|projects =<br />
}}<br />
<br />
Stu, formerly of Australia, then of England and now of the United States of America (East Coast).<br />
<br />
I've four public roguelikes, [[UnderDark]] (abandoned), SRL (only saw one release) and my current project [[Cracks and Crevices]].<br />
<br />
I did a [[2009 Out of Challenge 7DRLs|out of challenge]] 2009 7DRL Entry called [[Tomb of Rawdin]]</div>Stuhttp://roguebasin.com/index.php?title=List_of_roguelikes_by_year&diff=14749List of roguelikes by year2009-02-08T15:04:25Z<p>Stu: all these little pages one needs to edit.....</p>
<hr />
<div>This is a '''list of Roguelikes''', ordered by year of release.<br />
{| id="toc" border="0"<br />
! {{MediaWiki:Toc}}:<br />
| <br />
{| style="background:none; border-bottom-width: 1px; border-bottom-color: #999; border-bottom-style: solid; "<br />
|- <br />
| align="right" | [[#1974|1974]] [[#1975|1975]] 1976 1977 1978 1979<br />
|-<br />
|<br />
[[#1980|1980]] 1981 1982 1983 1984 [[#1985|1985]] [[#1986|1986]] [[#1987|1987]] 1988 1989<br />
|-<br />
|<br />
[[#1990|1990]] 1991 [[#1992|1992]] [[#1993|1993]] [[#1994|1994]] [[#1995|1995]] [[#1996|1996]] [[#1997|1997]] [[#1998|1998]] [[#1999|1999]]<br />
|-<br />
|<br />
[[#2000|2000]] [[#2001|2001]] [[#2002|2002]] [[#2003|2003]] [[#2004|2004]] [[#2005|2005]] [[#2006|2006]] [[#2007|2007]] [[#2008|2008]] [[#2009|2009]]<br />
|}<br />
[[#Related topics|Related topics]]<br />
__NOTOC__<br />
__NOEDITSECTION__<br />
|}<br />
== The games ==<br />
<br />
=== 1974 ===<br />
* [[DnD]]<br />
<br />
=== 1975 ===<br />
* [[Dungeon]]<br />
<br />
=== 1980 ===<br />
* [[Rogue]]<br />
<br />
=== 1983 ===<br />
* [[Moria]]<br />
<br />
=== 1985 ===<br />
* [[Hack]]<br />
<br />
=== 1986 ===<br />
* [[Larn]]<br />
<br />
=== 1987 ===<br />
* [[NetHack]]<br />
* [[Omega]]<br />
<br />
=== 1990 ===<br />
* [[Angband]]<br />
* [[BOSS]]<br />
<br />
=== 1992 ===<br />
* [[Crossfire]]<br />
<br />
=== 1993 ===<br />
* [[Dungeon Hack]]<br />
<br />
=== 1994 ===<br />
* [[ADOM]] (Ancient Domains of Mystery)<br />
* [[Alphaman]]<br />
* [[Ragnarok]]<br />
* [[Zangband]]<br />
<br />
=== 1995 ===<br />
* [[Alphaman]]<br />
* [[Linley's Dungeon Crawl]]<br />
<br />
=== 1996 ===<br />
* [[Diablo]] (heavily influenced by the Roguelike genre)<br />
* [[The Minstrel's Song]]<br />
<br />
=== 1997 ===<br />
* [[MAngband]]<br />
* [[UnAngband]]<br />
<br />
=== 1998 ===<br />
* [[The Legend of Saladir]]<br />
* [[ToME]] (Troubles of Middle Earth)<br />
* [[UnderDark]]<br />
<br />
=== 1999 ===<br />
* [[Kharne]]<br />
* [[Star Rogue]]<br />
* [[Tyrant]]<br />
<br />
=== 2000 ===<br />
* [[Diablo II]]<br />
* [[Domain Country]]<br />
* [[Egoboo]]<br />
* [[Slaves to Armok]]<br />
<br />
=== 2001 ===<br />
* [[Avanor]]<br />
* [[DeadCold]]<br />
* [[IVAN]]<br />
<br />
=== 2002 ===<br />
* [[Abura Tan]]<br />
* [[GearHead]]<br />
* [[Warp Rogue]]<br />
* [[Xenocide]]<br />
<br />
=== 2003 ===<br />
* [[Dungeon Monkey]]<br />
* [[POWDER]]<br />
<br />
=== 2004 ===<br />
* [[DoomRL]]<br />
* [[Guild]]<br />
<br />
=== 2005 ===<br />
* [[ANK]]<br />
* [[CastlevaniaRL]]<br />
* [[DiabloRL]]<br />
* [[Quick_Angband]]<br />
* [[You Only Live Once]]<br />
* [[Z-Day]]<br />
<br />
=== 2006 ===<br />
* [[Berserk!]]<br />
* [[Bone to be Wild]]<br />
* [[CryptRL]]<br />
* [[Frozen Depths]]<br />
* [[LambdaRogue]]<br />
* [[Letter Hunt]]<br />
* [[Magic Monsters]]<br />
* [[MetroidRL]]<br />
* [[Mt. Drash: the Roguelike]]<br />
* [[PrinceVSZombies]]<br />
* [[Slaves to Armok II: Dwarf Fortress]]<br />
* [[Subterrane]]<br />
<br />
=== 2007 ===<br />
* [[AliensRL]]<br />
* [[Artisan]]<br />
* [[Beggar]]<br />
* [[Cracks and Crevices]]<br />
* [[Lair of the Demon Ape]]<br />
* [[Neon]]<br />
* [[Portralis]]<br />
* [[Save Scummer]]<br />
* [[SewerJacks]]<br />
* [[Tower]]<br />
* [[Incursion]]<br />
* [[War of Wizards]]<br />
* [[ZeldaRL]]<br />
* [[Zomband]]<br />
<br />
=== 2008 ===<br />
* [[CryptRover]]<br />
* [[Fatherhood]]<br />
* [[IronBand]]<br />
* [[MetaCollider]]<br />
* [[Triangle Wizard]]<br />
<br />
=== 2009 ===<br />
* [[Gruesome]]<br />
* [[Tomb of Rawdin]]<br />
<br />
== Related topics ==<br />
* [[Categories]]</div>Stuhttp://roguebasin.com/index.php?title=List_of_roguelikes_by_name&diff=14748List of roguelikes by name2009-02-08T15:02:46Z<p>Stu: </p>
<hr />
<div>{| id="toc" border="0"<br />
! {{MediaWiki:Toc}}:<br />
| [[#0-9|0-9]] [[#A|A]] [[#B|B]] [[#C|C]] [[#D|D]] [[#E|E]] [[#F|F]] [[#G|G]] [[#H|H]] [[#I|I]] [[#J|J]] [[#K|K]] [[#L|L]] [[#M|M]] [[#N|N]] [[#O|O]] [[#P|P]] [[#Q|Q]] [[#R|R]] [[#S|S]] [[#T|T]] [[#U|U]] [[#V|V]] [[#W|W]] [[#X|X]] [[#Y|Y]] [[#Z|Z]]<br />
__NOTOC__<br />
|}<br />
<br />
== A ==<br />
* [[Abura Tan]]<br />
* [[ADND]] (Another DnD)<br />
* [[ADOM]] (Ancient Domains of Mystery)<br />
* [[Alphaman]]<br />
* [[Angband]]<br />
* [[ANK]]<br />
* [[Artisan]]<br />
* [[Avanor]]<br />
<br />
== B ==<br />
* [[Bone to be Wild]]: Summoning Gone Wrong<br />
* [[Berserk!]]<br />
* [[BOSS]]<br />
<br />
== C ==<br />
* [[Castle of the Winds]]<br />
* [[CastlevaniaRL]]<br />
* [[Cracks and Crevices]]<br />
* [[Crawl]]<br />
* [[Crossfire]]<br />
* [[CryptRL]]<br />
* [[CryptRover]]<br />
* [[CyberRogue]]<br />
<br />
== D ==<br />
* [[DaJAngband]]<br />
* [[DeadCold]]<br />
* [[Deliantra]]<br />
* [[Diablo II]]<br />
* [[Diablo]]<br />
* [[DiabloRL]]<br />
* [[DnD]]<br />
* [[Downfall]]<br />
* [[Domain Country]]<br />
* [[DoomRL]]<br />
* [[Dungeon Crawl]]<br />
* [[Dungeon Hack]]<br />
* [[Dungeon Monkey]]<br />
* [[Dungeon]]<br />
* [[Dweller]]<br />
<br />
== E ==<br />
* [[Egoboo]]<br />
* [[Evolution]]<br />
<br />
== F ==<br />
* [[Frozen Depths]]<br />
<br />
== G ==<br />
* [[GearHead]]<br />
* [[Goodfire]]<br />
* [[Gruesome]]<br />
* [[Guild]]<br />
<br />
== H ==<br />
* [[Hack]]<br />
* [[Heroic Adventure!]]<br />
* [[Hokuto no Rogue]]<br />
<br />
== I ==<br />
* [[I, Monster]]<br />
* [[Incursion]]<br />
* [[IronBand]]<br />
* [[IVAN]]<br />
* Izuna: Legend of the Unemployed Ninja [http://en.wikipedia.org/wiki/Izuna:_Legend_of_the_Unemployed_Ninja]<br />
<br />
== J ==<br />
<br />
== K ==<br />
* [[KAngband]]<br />
* [[KAmband]]<br />
* [[Kharne]]<br />
* [[KING]]<br />
<br />
== L ==<br />
* [[Labyrinth of Reptoran]]<br />
* [[Lair of the Demon Ape]]<br />
* [[LambdaRogue]]<br />
* [[Larn]]<br />
* [[The Legend of Saladir]]<br />
* [[Legerdemain]]<br />
* [[Letter Hunt]]<br />
* [[Lords of DarkHall]]<br />
<br />
== M ==<br />
* [[MAngband]]<br />
* [[MazeCrawl]]<br />
* [[MetaCollider]]<br />
* [[The Minstrel's Song]]<br />
* [[Moria]]<br />
* [[Mt. Drash: the Roguelike]]<br />
* [[Mines Of Morgoth]]<br />
<br />
== N ==<br />
* [[Neon]]<br />
* [[NetHack]]<br />
* [[Numbers]]<br />
<br />
== O ==<br />
* [[Omega]]<br />
<br />
== P ==<br />
* [[Papaki]]<br />
* [[Paprika]]<br />
* [[Portralis]]<br />
* [[POWDER]]<br />
* [[PrinceVSZombies]]<br />
* [[Pyro]]<br />
<br />
== Q ==<br />
* [[QuickQuest]]<br />
* [[Quick_Angband]]<br />
<br />
== R ==<br />
* [[Ragnarok]]<br />
* [[Rogue]]<br />
* [[RogueRunner]]<br />
* [[Rolf]]<br />
<br />
== S ==<br />
* [[SewerJacks]]<br />
* [[Slaves to Armok]]<br />
* [[Slaves to Armok II: Dwarf Fortress]]<br />
* [[Star Hammer]]<br />
* [[Star Rogue]]<br />
* [[Subterrane]]<br />
* [[Sigmore Mines]]<br />
* [[Sigmore Mines 2]]<br />
<br />
== T ==<br />
* [[Tiamyth]]<br />
* [[Tomb of Rawdin]]<br />
* [[ToME]] (Troubles of Middle Earth)<br />
* [[Tower]]<br />
* [[TrapRogue]]<br />
* [[Triangle Wizard]]<br />
* [[TwilightMMORL]]<br />
* [[Tyrant]]<br />
<br />
== U ==<br />
* [[Umbrarum Regnum]]<br />
* [[UnAngband]]<br />
* [[UnderDark]]<br />
* [[UnReal World]]<br />
<br />
== V ==<br />
* [[Valengard]]<br />
<br />
== W ==<br />
* [[War of Wizards]]<br />
* [[Warlock's Mountain]]<br />
* [[Warp Rogue]]<br />
<br />
== X ==<br />
* [[Xenocide]]<br />
<br />
== Y ==<br />
* [[You Only Live Once]]<br />
<br />
== Z ==<br />
* [[Zangband]]<br />
* [[Z-Day]]<br />
* [[Zomband]]</div>Stuhttp://roguebasin.com/index.php?title=Developers&diff=14722Developers2009-02-06T20:19:00Z<p>Stu: /* G */</p>
<hr />
<div>This is an alphabetical list of roguelike '''developers''', ordered by last name when they've got one, or by nickname.<br />
<br />
You can also find info about developers and their projects at [[The Roguelike World Map]]. See also: [[:Category:Developers]].<br />
<br />
{| id="toc" border="0"<br />
! {{MediaWiki:Toc}}:<br />
| [[#0-9|0-9]] [[#A|A]] [[#B|B]] [[#C|C]] [[#D|D]] [[#E|E]] [[#F|F]] [[#G|G]] [[#H|H]] [[#I|I]] [[#J|J]] [[#K|K]] [[#L|L]] [[#M|M]] [[#N|N]] [[#O|O]] [[#P|P]] [[#Q|Q]] [[#R|R]] [[#S|S]] [[#T|T]] [[#U|U]] [[#V|V]] [[#W|W]] [[#X|X]] [[#Y|Y]] [[#Z|Z]]<br />
__NOTOC__<br />
|}<br />
<br />
== The people ==<br />
<br />
=== A ===<br />
* [[ABCGi]] (''[[Beyond]]'')<br />
* [[Ashiz Alibhai]]<br />
* [[Mike Anderson]] (''[[Tyrant]]'')<br />
* [[Antoine]] (''[[Guild]]'', ''[[Quickband]]'', ''[[IronBand]]'')<br />
* [[Ken Arnold]] (''[[Rogue]]'')<br />
* [[Andy Astrand]] (''[[Angband]]'')<br />
* [[Erik Aronesty]] (''[[rll.pm]]'')<br />
* [[Atharus]] (''[[Khaotica]]'')<br />
* [[Auric__]] ("???")<br />
<br />
=== B ===<br />
* [[Bay 12 Games]] (''[[Dwarf Fortress]]'')<br />
* [[Michal Bielinski]] (''[[Evolution]]'')<br />
* [[Thomas Biskup]] (''[[ADOM]]'')<br />
* [[Bjorn Bergstrom]] (''[[Dweller]]'')<br />
* [[Eric Bock]] (''[[Rangband]]'', ''[[Zceband]]'')<br />
* [[Brigand]] (''[[Lords of DarkHall]]'')<br />
* [[D. Brodale]]<br />
* [[Laurence Brothers]] (''[[Omega]]'')<br />
<br />
=== C ===<br />
* [[copx]] (''[[Warp Rogue]]'')<br />
* [[Phil Cordier]] (''[[Ularn]]'')<br />
* [[corremn]] (''[[Warlock's Mountain]]'', ''[[SewerJacks]]'')<br />
* [[Alex Cutler]] (''[[Angband]]'')<br />
<br />
=== D ===<br />
* [[David Damerell]]<br />
* [[DarkGod]] (''[[ToME]]'', ''[[ToMENET]]'', ''[[T-Engine]]'', ''[[ODE]]'', ''[[Bone to be Wild]]'')<br />
* [[Ddragoon]]<br />
* [[Eric Dexter]] (''[[Land of cigo]]'')<br />
* [[Jakub Debski]] (''[[Xenocide]]'', ''[http://www.alamak0ta.republika.pl/br-win.zip Bomberrogue]'')<br />
* [[The Deliantra Development Team]] (''[[Deliantra]]'')<br />
* [[The DevTeam]] (''[[NetHack]]'')<br />
* [[Ray Dillinger]]<br />
* [[Joseph William Dixon]] (''[[Gumband]]'')<br />
* [[Mario Donick]] (''[[LambdaRogue]]'')<br />
* [[DopeD]] (''[[DoppeRogue]]''))<br />
* [[Andrew Doull]] (''[[UnAngband]]'')<br />
* [[Andy Driver]] (''[[JRR]]'')<br />
<br />
=== E ===<br />
<br />
* [[Elbin]] (''[[Artisan]]'')<br />
* [[Eyenot]] (''[[Kobold Mines]]'')<br />
<br />
=== F ===<br />
<br />
=== G ===<br />
* [[Gamer_2k4]] (''[[Labyrinth of Reptoran]]'',''[[Magic Monsters]]'')<br />
* [[David Gentle]]<br />
* [[Stu George]] (''[[Cracks and Crevices]]'',''[[UnderDark]]'', ''[[Tomb of Rawdin]]'')<br />
* [[gerryq]] (''[[Lair of the Demon Ape]]'')<br />
* [[Glowie]] (''[[Frozen Depths]]'')<br />
* [[Darren Grey]] (''[[Gruesome]]'')<br />
<br />
=== H ===<br />
* [[Ben Harrison]] (''[[Angband]]'')<br />
* [[R Dan Henry]] (''[[Dangband]]'', ''[[Gumband]]'', ''[[Prototype]]'')<br />
* [[Linley Henzell]] (''[[Crawl]]'')<br />
* [[Joseph Hewitt]] (''[[DeadCold]]'', ''[[Dungeon Monkey]], ''[[GearHead]]'', ''[[GearHead 2]]'')<br />
* [[Geoff Hill]] (''[[Angband]]'')<br />
* [[Mark 'Kamikaze' Hughes]] (''[[Noctyr]]'')<br />
* [[Simen Endsj? Haugen]]<br />
* [[Jude Hungerford]] [http://arid.sourceforge.net (ARID)]<br />
<br />
=== I ===<br />
* [[I_Own_The_Letter_O]] (RogueScape)<br />
* [[Ido]] (''[[CryptRover]]'')<br />
<br />
=== J ===<br />
* [[Kevin James (Pointless)]] (''[[MetaCollider]]'')<br />
* [[JimmyB]] (or [[jimrandomh]]) (''[[CalcRogue]]'')<br />
<br />
=== K ===<br />
* [[konijn]]<br />
* [[Kornel Kisielewicz]] (''[[Carceri]]'', ''[[DiabloRL]], ''[[DoomRL]]'', ''[[GenRogue]]'',''[[Berserk!]]'')<br />
* [[Robert Alan Koeneke]] (''[[VMS Moria]]'')<br />
* [[Kostatus]]<br />
* [[Gero Kunter]] (''[[Shuruppak]]'')<br />
<br />
=== L ===<br />
* [[Jeff Lait]] (''[[POWDER]]'', ''[[You Only Live Once]]'', ''[[Letter Hunt]]'')<br />
* [[LeonTorres]]<br />
* [[Julian Lighton]] (''[[Angband]]'')<br />
<br />
=== M ===<br />
* [[Sami Maaranen]] (''[[UnReal World]]'')<br />
* [[Colin MacIntyre]] (''[[Caravan]]'')<br />
* [[Hansjoerg Malthener]] (''[[H-World]]'')<br />
* [[Leon Marrick]] (''[[Oangband]]'')<br />
* [[Sean Marsh]] (''[[Angband]]'')<br />
* [[Gary D. McAdoo]] (''[[VMS Moria]]'')<br />
* [[Julian Mensch]] (''[[Incursion]]'')<br />
* [[R. Alan Monroe]]<br />
* [[Noah Morgan]] (''[[Larn]]'')<br />
<br />
=== N ===<br />
* [[Mark A. Nicolosi]] ("I've finally got a little '@' walking around the screen")<br />
* [[NIm]]<br />
* [[Nathan Stoddard]] ([[Downfall]], [[RLLib]])<br />
<br />
=== O ===<br />
<br />
=== P ===<br />
* [[Krice | Paul 'Krice' Pekkarinen]] (''[[Kaduria]]'')<br />
* [[Pfhoenix]] (''[[Adeo]]'')<br />
* [[AlexPomeranz | Alex Pomeranz]] (''[[Subterrane]]'')<br />
* [[Timothy Pruett]] (''[[HotelRL]]'', ''[[Necropolis]]'')<br />
<br />
=== Q ===<br />
* [[Qbert911]] (''[[PrinceVSZombies]]'')<br />
<br />
=== R ===<br />
* [[Martin Read]] (''[[Martin's Dungeon Bash]]'')<br />
* [[Chris Reuter]] (''[[Quest for Pants]]'', entry for [[the 7DRL Contest]])<br />
* [[Brent Richie]]<br />
* [[Robert Ruehlmann]] (''[[Angband]]'')<br />
* [[Robson]] (''[[War of Wizards]]'', ''[[Numbers]]'')<br />
<br />
=== S ===<br />
* [[User:Scautura|Scautura]] (''[[CyberRogue]]'')<br />
* [[Anthony Sequitar]]<br />
* [[Tom Seufert]] (''[[SimpleGame]]'')<br />
* [[Darshan Shaligram]] (''[[Crawl]]'' patches)<br />
* [[Timofei Shatrov]] (''[[The Rougelike]]'', ''[[The Sewer Massacre]]'')<br />
* [[John Shedletsky]] (''[[Witherwyn: Adventures in the Infinite Realm]]'')<br />
* [[The Sheep]] (''[[Z-Day]]'')<br />
* [[ShockFrost]]<br />
* [[Slash]] (''[[CastlevaniaRL]]'', ''[[Mt. Drash: the Roguelike]]'', ''[[Guardian Angel]]'', ''[[MetroidRL]]'', ''[[ZeldaRL]]'')<br />
* [[Larry Smith]]<br />
* [[Mike Stephenson]] (original ''[[NetHack]]'')<br />
* [[Steve Segreto]] ''[[ADND]]]]<br />
* [[Jim Strathmeyer]]<br />
* [[Charles Swiger]] (''[[Angband]]'')<br />
<br />
=== T ===<br />
* [[Charles Teague]] (''[[Angband]]'')<br />
* [[Thijs can Ommen]]<br />
* [[Jimmey Wayne Todd Jr.]] (''[[VMS Moria]]'')<br />
* [[Michael Toy]] (''[[Rogue]]'')<br />
* [[Twisted One]] (or [[Neo]])<br />
<br />
=== U ===<br />
<br />
=== V ===<br />
* [[Antonio Vazquez]] (''[[GAME]]'')<br />
* [[Crypt | Primault 'Crypt' Vincent]] (''[[CryptRL]]'')<br />
<br />
=== W ===<br />
* [[Amy Wang]]<br />
* [[Glen Wheeler]]<br />
* [[Glenn Wichman]] (''[[Rogue]], [[The Seven Day Quest]]'')<br />
* [[Ken Wigle]] (''[[Kangband]]'')<br />
* [[James E. Wilson]] (''[[Umoria]]'')<br />
* [[Martin Woodward]] (''[[Tombs]]'')<br />
<br />
=== Y ===<br />
* [[Topi Ylinen]] (''[[Zangband]]'')<br />
<br />
=== Z ===<br />
* [[The Zangband Devteam]] (''[[Zangband]]'')<br />
* [[Vasilis Zoumpourlis]] (''[[Papaki]]'')<br />
* [[User:zzo38|zzo38]] (''[[KING]]'')<br />
<br />
[[Category:Developers|*]]</div>Stuhttp://roguebasin.com/index.php?title=Tomb_of_Rawdin&diff=14721Tomb of Rawdin2009-02-06T20:17:11Z<p>Stu: 7DRL release</p>
<hr />
<div>{{game-7drl| name = Tomb of Rawdin<br />
|developer = [[Stu George]]<br />
|theme = Fantasy<br />
|influences = Rogue<br />
|released = 2009 Feb 06<br />
|updated = 2009 Feb 06<br />
|licensing = GPL<br />
|language = C<br />
|platforms = Windows, Linux<br />
|interface = [[Graphical ascii tiles]], [[Keyboard]]<br />
|length = short<br />
|site = http://redmine.bloodycactus.com/projects/rawdin/wiki<br />
}}<br />
<br />
<br />
''Tomb of Rawdin'' is a graphical ascii roguelike game written by Stu, using [[SDL]] and the [[Doryen_library]]. It is designed to be a short roguelike with only 10 levels.<br />
<br />
==External Links==<br />
* [http://redmine.bloodycactus.com/projects/rawdin/files Downloads]<br />
* [http://redmine.bloodycactus.com/projects/rawdin/issues Buglist]</div>Stuhttp://roguebasin.com/index.php?title=Cracks_and_Crevices&diff=14720Cracks and Crevices2009-02-06T20:15:17Z<p>Stu: Fix url's, minor typos</p>
<hr />
<div>{{game-alpha| name = Cracks and Crevices<br />
|developer = [[Stu George]]<br />
|theme = Fantasy<br />
|influences = Underdark<br />
|released = 2007 Feb 24<br />
|updated = 2008 Feb 18<br />
|licensing = GPL<br />
|language = C<br />
|platforms = Windows, Linux<br />
|interface = [[Graphical ascii tiles]], [[Keyboard]]<br />
|length = short<br />
|site = http://redmine.bloodycactus.com/projects/show/sdlrl<br />
}}<br />
<br />
''Cracks and Crevices'' is a graphical ascii roguelike game written by Stu, using [[SDL]]. It takes ideas from my other roguelikes like [[UnderDark]] and [[SRL]].<br />
<br />
The originally idea was to keep things simple in order to create an actual working game instead of a huge mountain of ideas that never get implemented or see the light of day.<br />
<br />
Its designed to not be so hardcore as [[NetHack]] and [[Crawl]] but not be as easy as [[Larn]]. It does provide help for the beginner and cue's when the game starts.<br />
<br />
== Story ==<br />
''Cracks and Crevices'' is about life in the small village of ''Danforths Outcrop'', hewn into the rock at an opening to a large crevice. The game starts with you, a young person of the village on the verge of your adulthood test, which is to survive two days in the labyrinth of the crevice before you will be allowed back into town. Only the strong survive to increase the strength of the village, and if you survive you will be allowed back into town, there you can explore or re-enter the labyrinth or take up some quests offered by the town clerk.<br />
<br />
<br />
== Features ==<br />
* Semi real-time gameplay<br />
* Facing FOV<br />
* Stackable spell / weapon system<br />
* Magic System based on MP that regenerates over time or by wielding/wearing mage type items<br />
* Weapons, Potions, Spell books, mushrooms, rings, armor, shields, etc<br />
* No preset classes or skill systems. Development of @'s class is up to the player.<br />
* Customer key configuration<br />
* Message Logs<br />
* Character dumps<br />
* Save / Load<br />
* Permadeath<br />
* Working towns (shops, inns, banks, etc)<br />
* Special NPC's<br />
<br />
<br />
== Time and Modes ==<br />
''Cracks and Crevices'' uses semi-realtime to set the game play. There is an Easy / Medium / Hard mode of play.<br />
<br />
=== Easy ===<br />
* Easy mode gives you 3 seconds to make a move before you loose your current turn and all the monsters get to move. <br />
* More Money to start the game with<br />
* Circular FOV<br />
<br />
=== Medium ===<br />
* 1.5 seconds per move<br />
* Facing directional cone FOV<br />
<br />
=== Hard ===<br />
* 1 second per move<br />
* Facing directional cone FOV<br />
<br />
== Class System ==<br />
There is no preset class system or skill system in the game. It is left up to the player to choose the direction of development, if they want to focus on pure melee fighter type or mage type or something in between. There is no restriction on wielding swords and casting spells at the same time. There are pros and cons to each and heavy armor may not be the best choice for a spellcaster...<br />
<br />
<br />
== Current Status ==<br />
0.4 has many changes<br />
* BIG Rewrote mainloop code (fixed some subtle round bugs).<br />
* Rounds now work properly for all NPC's and the PC<br />
* Timers work correctly<br />
* Rewrote attribute code<br />
* Gold drops on floor now<br />
* Monsters die correctly!<br />
* Initial quest time shortened to make it more attainable.<br />
* Messages are now counted and displayed as Msg (x) if repeated to stop cluttering the display.<br />
* Remove character dump when starting a new game<br />
* Dont save character dump when saving game<br />
* Stopped monsters and drops from appearing in the message window (doh!)<br />
* Stopped saving from doing an explicit call to exit instead of falling through the game loop like quit does, which revealed some mem leaks that were plugged.<br />
* Gold drops were dropping underneath the player not monster!<br />
* Spells in spellbooks<br />
* Start spell when buying first spellbook<br />
* Attack/Target Cycling/Cast Spell commands<br />
* Implemented 99% of the spell attributes<br />
* Casting spells now works! (no whizzbang animation. it just works)<br />
* auto pickup working<br />
* Pickup key words<br />
* Fixed : When selling item, unequip it automatically<br />
* Added circular fov for easy games<br />
* Bumpbed facing fov for medium + hard games<br />
* Added leveling up<br />
* Added ctrl-c as break all from program<br />
* Added ESC as means to close out most all dialogues<br />
* Made some defaults sane (no mixing cursor + keypad)<br />
<br />
==External Links==<br />
* [http://redmine.bloodycactus.com/projects/sdlrl/files Downloads]<br />
* [http://redmine.bloodycactus.com/projects/sdlrl/issues Buglist]</div>Stuhttp://roguebasin.com/index.php?title=News&diff=14719News2009-02-06T20:08:16Z<p>Stu: 7DRL Tomb of Rawdin released</p>
<hr />
<div>== 06 Feb 2009 ==<br />
* [[Tomb of Rawdin]] 0.1 [http://redmine.bloodycactus.com/projects/rawdin/files released]<br />
<br />
== 31 Jan 2009 ==<br />
* [[crashRun]] 0.3.0 [http://crashrun.org released]<br />
<br />
== 27 Jan 2009 ==<br />
* [[GearHead2]] 0.534 [http://www.gearheadrpg.com/?p=52 released]<br />
<br />
== 21 Jan 2009 ==<br />
* [[Gruesome]] 0.0.3 [http://www.gruesomegames.com/gruesome0.0.3.zip released]<br />
<br />
== 18 Jan 2009 ==<br />
* [[Gruesome]] 0.0.2 [http://www.gruesomegames.com/gruesome0.0.2.zip released]<br />
<br />
== 23 Dec 2008 ==<br />
* [[LambdaRogue]] 1.4 [http://lambdarogue.net/dl-showentry.php?n=101 released]<br />
* [[GearHead2]] 0.530 [http://www.gearheadrpg.com/?p=40 released]<br />
<br />
== 18 Dec 2008 ==<br />
* [[SewerJacks]] 0.8.7c [http://sewerjacks.sourceforge.net released]<br />
<br />
== 11 Dec 2008 ==<br />
* [[Mage Guild]] 1.2 [http://glistenimages.com/Lukos/lukosMageGuild.htm released]<br />
<br />
== 22 Nov 2008 ==<br />
* [[LambdaRogue]] 1.3 [http://lambdarogue.net/dl-showentry.php?n=79 released]<br />
<br />
== 21 Nov 2008 ==<br />
* [[Mage Guild]] 1.1 [http://glistenimages.com/Lukos/lukosMageGuild.htm released]<br />
<br />
== 16 Nov 2008 ==<br />
* [[libtcod-net]] 0.3 [http://code.google.com/p/libtcod-net/ released]<br />
<br />
== 30 Oct 2008 ==<br />
* [[GearHead2]] 0.520 [http://www.gearheadrpg.com/?p=33 released]<br />
<br />
== 24 Oct 2008 ==<br />
* [[UnReal World]] 3.11b [http://www.jmp.fi/~smaarane/urw.html released]<br />
<br />
== 16 Oct 2008 ==<br />
* [[Mage Guild]] 1.0 [http://glistenimages.com/Lukos/lukosMageGuild.htm released]<br />
<br />
== 02 Oct 2008 ==<br />
* [[GearHead2]] 0.511 [http://www.gearheadrpg.com/?p=28 released]<br />
<br />
<div style="text-align:right"><br />
''See also: [[Old news]]''<br />
</div></div>Stuhttp://roguebasin.com/index.php?title=RogueBasin_talk:Community_Portal&diff=14544RogueBasin talk:Community Portal2009-01-12T13:31:14Z<p>Stu: /* Spambots */</p>
<hr />
<div>{{talkpagetool}}<br />
<br />
<table class="infobox" style="float:right;clear:right; width: 11em; border: 1px solid #93BACB; background:#E0E7EF;font-size:95%; margin:1em; line-height:1.4em;"><br />
<tr><br />
<th style="background:#C2D8EF; padding:.4em; margin:1em; font-size:105%">Archives</th><br />
</tr><br />
<tr><br />
<td><br />
* [[/Archive 1|1]]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Game Announcements ==<br />
If you have a new game/version/release to announce to the world, Make an edit to the [[News]] page, and please follow the existing format. If you want to generate discussion and receive feedback and comments, make sure to head over to [http://roguetemple.com RogueTemple] and use their forums, as well as [[rgrd]]. [[User:Stu|Stu]] 14:21, 16 May 2008 (CEST)<br />
<br />
<br />
<br />
== Spambots ==<br />
<br />
There was a small spambot attack recently, dunno how they overrid the spam protection (what is the current spam protection)? I had no luck blocking them via the sysop special pages. Is there any way to delete user accounts?<br />
<br />
--[[User:Slash|Slash]] 01:08, 12 Apr 2007 (CEST)<br />
<br />
I think it may be useful to update MediaWiki software to the latest version. The one that's currently installed is so old, the mind boggles. The current version has captchas and other stuff, and it's much easier to revert vandalism. [[User:Grue|Grue]] 10:23, 12 Apr 2007 (CEST)<br />
<br />
IIRC Bj????rn set up the latest version when the server translation was performed? Also, this is plain vandalism, not even spam (deleting '+' and everything after a '&', what use would that have?<br />
--[[User:Slash|Slash]] 17:19, 12 Apr 2007 (CEST)<br />
:It can't be the latest version. For example when you look at the diff between two revisions, there's no link to edit the revision. This feature was in Wikipedia since I joined it, probably, and that was very long time ago. So, to revert vandalism one has to click three times instead of two, pretty annoying. I don't know, maybe it's configured incorrectly, but it definitely looks very outdated. [[User:Grue|Grue]] 10:52, 13 Apr 2007 (CEST)<br />
<br />
:It's definitely an old version, the [[Special:Version]] page shows as using version 1.3.9 ''(The 1.3.x line was last updated in November 2005)''. The newest release is 1.10.0 although most modern versions of MediaWiki require PHP5 though ''(since version 1.7)''. The latest version that still supports PHP4 is 1.6.10 available [http://www.mediawiki.org/wiki/Download here]. 1.6.10 was released on 20th February 2007. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
::THe Wiki is currently running MediaWiki 1.6.10. Hopefully we won't see any more spam attacks. -- Bjorn 09:50 3 Jul 2007<br />
<br />
There was another spammer, although it could be a person doing it, rather than a bot. It was [[User:Yaxiaexx099|this account]] doing it, and [http://roguebasin.roguelikedevelopment.org/index.php?title=Dalhxf&oldid=12449 this] was was what he did.<br />
<br />
Here we go again, looks like the spambots are returning? Three new pages filled with.. something. [[Aldan|Here]], [[Generosity|here]] and [[Nourished|here]], created by three (new?) users in a short succession. Are there any anti-spambot guidelines somewhere, since I'm not sure of what to do, except for reporting? [[User:Solarnus|Solarnus]] 23:48, 8 January 2009 (CET)<br />
<br />
:Wonder if there is any way we can give rights to some users to approve new users so we dont have these spambots sign up, or we need to modify the captcha code to stop this crap. [[User:Stu|Stu]] 14:31, 12 January 2009 (CET)<br />
<br />
== Remove the news? ==<br />
<br />
I was wondering if it is a good idea to keep the news box on the main page. My thoughts:<br />
<br />
* We have three main news sites: RGRA, Temple of the Roguelike and the RogueBasin. That's a lot of duplicating.<br />
* I feel that the RGRA and Temple of the Roguelike are way more suited to displaying news. I see the RogueBasin as a resource of articles, guides and information about roguelikes.<br />
* The news box could be used to display other things. Such as new articles here, articles that we would like to improve and featured roguelikes.<br />
<br />
What do people think? [[User:Icey|Icey]] 14:45, 27 May 2007 (CEST)<br />
<br />
: I agree, both RGRA and TotR seem better places for sources of news (But saying that I do have TotR as a Live Bookmark in Firefox) although I have no problem having a smaller box with the last couple of items. I'd sooner see the space taken with new articles, articles for improvement and featured roguelikes as suggested. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
:RGRA and Temple are moderated, which means the news don't appear ASAP. For example both of these mediums haven't covered The Sewer Massacre 1.0 yet (and not for my lack of trying ;)). The main principle behind news is that they are new. A day later is already old news. Imagine if JADE is released, and the news don't appear anywhere for a day. Wiki solves this problem perfectly. [[User:Grue|Grue]] 23:09, 28 May 2007 (CEST)<br />
<br />
:::::::That's one of the cons of a moderated media :) also, RGRA is moderated, but moderation commonly takes less than 1 hour in my Experience --[[User:Slash|Slash]] 16:35, 4 Jun 2007 (CEST)<br />
<br />
::That is a good point, I hadn't really thought about the moderation aspect. Perhaps having a slightly different main page design would accommodate having sections for articles and featured items? [[User:Pucechan|Pucechan]] 18:36, 29 May 2007 (CEST)<br />
<br />
:::I've made a quick mockup of an idea, so colours and content (especially the top-right links) are just placeholders, this uses the fairly "traditional" block wiki format. The content is just copy-pasted but you get the idea. The news would be for each month (probably in a smaller font). See it here [[User:Pucechan/MainIdea]]. What do people think?<br />
<br />
::::I like it a lot. I've expanded the idea a bit: [[User:Icey/MainIdea]]. It's more wikipedia-like, has a little tag line so people know what the RogueBasin is, added the links to the top, added a featured article section, added a bit of colour and changes a few other things. [[User:Icey|Icey]] 02:12, 2 Jun 2007 (CEST)<br />
<br />
:::::I like the changes you've made, the little splash of colour helps. I prefer your simple set of links rather than my bundle (I didn't really sort them in any way but your way is much nicer). I really like it. [[User:Pucechan|Pucechan]] 11:19, 2 Jun 2007 (CEST)<br />
<br />
::::::Thanks Pucechan. Let's wait a few days to see if anyone else would like to improve/approve it and then decide what to do from there. [[User:Icey|Icey]] 13:19, 3 Jun 2007 (CEST)<br />
<br />
:::::::I like it a lot too... I have always thought roguebasin needs a better front page... perhaps changing "Current news" for "News for June 2007"? <br />
:::::::Also, it is pretty wordy, some images may help.. probably :P<br />
:::::::Thanks! --[[User:Slash|Slash]] 16:35, 4 Jun 2007 (CEST)<br />
<br />
:::::::: Images would be good, but uploading images is disabled :P A little cropped screenshot of a roguelike would be nice to go with the description. Like [http://www.reloaded.org/images/games/reviews/66/review07.png this] or [http://www.gamesetwatch.com/atplay/adom-8.gif this]. [[User:Icey|Icey]] 20:14, 7 Jun 2007 (CEST)<br />
<br />
::::::::: I have enabled uploads for a trial period. [[User:Bjorn|Bjorn]] 09:50, 3 Jul 2007 (CEST)<br />
<br />
== External community links ==<br />
<br />
One thing I think is missing from the main page is a list of external community links. The existing [[Roguelike_Links]] doesn't have [[Temple of the Roguelike]], [[@ Play]] and other current resources like forums for various roguelike games listed (and dare I say it [[Ascii Dreams]] ;) )<br />
<br />
Are people happy for me to tidy up the Links section, to include the above, a 'Press' section within Links for listing where external media have talked about roguelike games, and a Forums section within Links for listing the various game specific web forums such as [http://angband.oook.cz/forum the Angband forums], Angband variant web forums and others (Live Journal, other variants and so on)? I'd like to see more ways of people getting in touch with fellow roguelike players/developers listed somewhere convenient...<br />
<br />
: That's an excellent idea. Perhaps we could use [[Links]] as a comprehensive list and then do a cut down version for the main page?<br />
<br />
: Perhaps the Links page could have a Roguelike Blog section (or a name like that) for your site and others like [http://doryen.blogspot.com/] [http://kaduria.blogspot.com/]<br />
<br />
: [[User:Icey|Icey]] 18:52, 5 September 2007 (CEST)<br />
<br />
== All those guides! ==<br />
<br />
Where did all those good guides at http://www.roguelikedevelopment.org/ go? according to the news, the content has been moved to this wiki but I can't find any of those guides! me want's 'em badly!<br />
[[User:Solarnus|Solarnus]] 11:28, 16 January 2008 (CET)<br />
:Sorry, I meant of course that alot of guides are missing, as least most of the map algorithm stuff previously found on the old site is missing here at the wiki. Anyone got copies of those guides, please? [[User:Solarnus|Solarnus]] 14:28, 23 January 2008 (CET)<br />
::And you looked in the map section of [[Articles]]? All the ones I recall are there. Perhaps you can use the wayback machine to calculate which ones seem to be missing? [[User:Duerig|Duerig]] 17:12, 23 January 2008 (CET)<br />
:::lol, the wayback what..? No, realy, I know there's alot missing from the site. Some examples are the guides written by Mike Anderson (Dungeon-Building Algorithm, Fractal Landscapes) and Radomir "The Sheep" Dopieralski (Recursive LvL Generation) [[User:Solarnus|Solarnus]] 17:52, 23 January 2008 (CET)<br />
::::Look at this URL. It is from www.archive.org, the wayback machine for the Internet: http://web.archive.org/web/20060114055601/http://roguelikedevelopment.org/ but before you go adding all of the articles to the wiki, you should know that there was some effort to move them over, but only if the original authors could be found to give permission. So you should check with an admin here about what to do. [[User:Duerig|Duerig]] 08:50, 24 January 2008 (CET)<br />
:::::Oh crap, I thought I could just go and add what I managed to find, since it had already been released on the site o.0' Pardon me, I'm too quick sometimes, doing stuff without thinking first. <br /> But, IMHO, not moving over all that stuff just because the original author couldn't be found kinda buggers me, that's just wast of time and good knowledge, stupidlly forcing to "reinvent the wheel". And it buggers me even more, since obvisiouly (spelling?) it can still be found on the web thanks to that wayback machine you're talking about (thanks for that link btw, would've never thought of that). <br /> Thanks for telling me dude, I'll try slowing down/backing off and poke an admin about it before doing anything else.<br /> <br />Anyway, should the "previously missing" [[Dungeon-Building Algorithm]] article I dug up yesterday be removed, or just leave it for now and hope for the better? [[User:Solarnus|Solarnus]] 13:50, 24 January 2008 (CET)<br />
<br />
<br />
::::::Is there any chance of the articles being reposted on the original site until they can be ported here? They're only text documents, and a number of them were very good references. Most of the original files are not stored on wayback machine, so forn ow they are lost for good. [[User:lapoubelle|lapoubelle]] 30 April 2008<br />
<br />
I have spent most of today searching for and collecting all of the articles that were on the old system but not on roguebasin. I was able to recover all but two. Those two and links to the archives are at [[User:Duerig]]. That way they should be safe until we can decide how to handle them. If the admins have a problem with this, I'll host them on my own domain if I have to. Let me know if you can find information on either of the two remaining articles. [[User:Duerig|Duerig]] 21:53, 1 May 2008 (CEST)<br />
<br />
<br />
== THIS IS NOT A GAME ANNOUNCEMENT PAGE ==<br />
Don't post game announcements here, there are other pages for that. [[User:Stu|Stu]] (I forgot to sign my edit..)<br />
<br />
:Probably would have been a little nicer and a whole lot more helpful to give a link to the appropriate location and to not all-caps/scream the header, especially since the [[Help:Contents|Help]] section is ''completely'' blank (the most important part of any wiki that wants new contributors and knowledgeable editors), and the main Community Portal page just redirects straight here, making it totally useless as well to direct such notices to their appropriate location. Personally, I can't find a page that really matches what [[User:Caeonosphere|Caeonosphere]] appears to have been looking for. '''[[News]]''' seems to be the closest thing, but not really much of an announcement page for game developers so that they can get feedback. The site is a bit of a mess organizationally. Unfortunately, because of this, errant notices such as the one that you deleted are to be expected. [[User:Kiefer|Kiefer]] 13:44, 15 May 2008 (CEST)<br />
<br />
:: You seem to confuse the idea of a wiki vs a forum. This is not a place to post and get feedback and comments and criticisms. Thats what [[rec.games.roguelike.development]] or [http://roguetemple.com RogueTemple] is for. Game releases go on the [[News]] page, preferably linking to your game info page, but that is not required. RogueTemple also does game announcements, and takes comments in return on its front page and forums. [[User:Stu|Stu]] 14:54, 15 May 2008 (CEST)<br />
<br />
:::I think it's pretty clear that I'm not confusing anything. I didn't say that the announcement was correctly placed. In fact, I described it as an "errant notice." However, a Community Portal often ''does'' include a spot for the wiki's community to get together and discuss things that relate to the subject of the wiki. Sometimes that involves requests for feedback like the one you deleted. I'm guessing that Caeonosphere put the request in the most likely place he thought it should go, since (once again) there was no main Community Portal page to direct him.<br />
<br />
:::I think instead that it's pretty clear that my point was: '''You didn't treat the user with the respect that they deserved.''' You should have guided them in the right direction, instead of assuming that they should already know what to do. (But, once again, '''''how''''' should they know?) Instead of helping, you deleted their message, added a header that shouts at the user should they return, and then said that "there are other pages for that" without leaving even a clue as to what that might mean. And, apparently from what you just wrote in your reply, there '''aren't''' other pages for that here - the developer would have to go someplace else entirely. (A user can't even ask an admin for guidance or help, as there isn't a list of sysops posted on the Main Page from which to get help!)<br />
<br />
:::It's a matter of treating the users with respect, and helping them out instead of essentially saying "bugger off." [[User:Kiefer|Kiefer]] 07:35, 16 May 2008 (CEST)<br />
<br />
:::: I agree, I was an arse, and after looking around it really isn't very clear where to go or what to do. I tried to edit the help page but dont have rights to do so. I think the front page needs a revamp to make things clearer. It is too cluttered. I added a little blurb to the top of the community page that might help. I also added the two games I deleted to the News page. [[User:Stu|Stu]] 14:21, 16 May 2008 (CEST)<br />
<br />
:::::You da man! My flying monkeys of death have been recalled and sun is shining again across the land. So, who do we have to bribe to get the help pages started and a non-redirecting Community Portal page created? I've worked on similar elsewhere, but everything is protected, and I don't really know what the "vision" of the site is. Ah well. [[User:Kiefer|Kiefer]] 17:54, 16 May 2008 (CEST)<br />
<br />
::::::I get an SQL error if I try to unprotect those pages. Thus, I've gone with the simpler answer of redirecting both to user-editable pages. I really don't know what a community portal should consist of, so left that page blank with a link back to this talk. The Help page I spliced together from existing stuff. Please let me know if there are other needs. --[[User:JeffLait|JeffLait]] 18:02, 28 July 2008 (CEST)<br />
<br />
== Game or project? ==<br />
<br />
Template [[Template:Angband-variant]] asks for status field. Then game entry is added to "status games" category. This works well for stable games and defunct games but fails for alpha, beta and talkie talkie *projects*. Thus any Angband variants which classify themselves as having alpha or beta status do not get included in proper category. Any ideas how to correct that without destroying too much existing work? I would opt for removing status field and adding all variants to categories manually. Other choice is to spilt template into several like it was done with [[Template:Gameinfo]]. What are others opinions on this? <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 16:18, 19 August 2008 (CEST)<br />
<br />
: I think the best bet is to split the template like the Gameinfo did. I presume there was a good reason to do that split rather than use the status field cleverly. I don't like people having to manually add the category tag as that will result in people forgetting to categorize the variant at all. --[[User:JeffLait|JeffLait]] 05:21, 21 August 2008 (CEST)<br />
<br />
:: Foundations are lain. I am going to wait some more time before proceeding to change all Angband variant pages in case better ideas show up or someone has objections. <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 15:03, 25 August 2008 (CEST)<br />
<br />
== 1krl ==<br />
<br />
We should add this to the wiki, but I'm not sure where.<br />
http://1024brl.googlepages.com/<br />
(and a link to the rgrd posts of course.<br />
--[[User:Soyweiser|Soyweiser]] 02:00, 22 August 2008 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=RogueBasin_talk:Community_Portal&diff=14543RogueBasin talk:Community Portal2009-01-12T13:30:56Z<p>Stu: /* Spambots */</p>
<hr />
<div>{{talkpagetool}}<br />
<br />
<table class="infobox" style="float:right;clear:right; width: 11em; border: 1px solid #93BACB; background:#E0E7EF;font-size:95%; margin:1em; line-height:1.4em;"><br />
<tr><br />
<th style="background:#C2D8EF; padding:.4em; margin:1em; font-size:105%">Archives</th><br />
</tr><br />
<tr><br />
<td><br />
* [[/Archive 1|1]]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Game Announcements ==<br />
If you have a new game/version/release to announce to the world, Make an edit to the [[News]] page, and please follow the existing format. If you want to generate discussion and receive feedback and comments, make sure to head over to [http://roguetemple.com RogueTemple] and use their forums, as well as [[rgrd]]. [[User:Stu|Stu]] 14:21, 16 May 2008 (CEST)<br />
<br />
<br />
<br />
== Spambots ==<br />
<br />
There was a small spambot attack recently, dunno how they overrid the spam protection (what is the current spam protection)? I had no luck blocking them via the sysop special pages. Is there any way to delete user accounts?<br />
<br />
--[[User:Slash|Slash]] 01:08, 12 Apr 2007 (CEST)<br />
<br />
I think it may be useful to update MediaWiki software to the latest version. The one that's currently installed is so old, the mind boggles. The current version has captchas and other stuff, and it's much easier to revert vandalism. [[User:Grue|Grue]] 10:23, 12 Apr 2007 (CEST)<br />
<br />
IIRC Bj????rn set up the latest version when the server translation was performed? Also, this is plain vandalism, not even spam (deleting '+' and everything after a '&', what use would that have?<br />
--[[User:Slash|Slash]] 17:19, 12 Apr 2007 (CEST)<br />
:It can't be the latest version. For example when you look at the diff between two revisions, there's no link to edit the revision. This feature was in Wikipedia since I joined it, probably, and that was very long time ago. So, to revert vandalism one has to click three times instead of two, pretty annoying. I don't know, maybe it's configured incorrectly, but it definitely looks very outdated. [[User:Grue|Grue]] 10:52, 13 Apr 2007 (CEST)<br />
<br />
:It's definitely an old version, the [[Special:Version]] page shows as using version 1.3.9 ''(The 1.3.x line was last updated in November 2005)''. The newest release is 1.10.0 although most modern versions of MediaWiki require PHP5 though ''(since version 1.7)''. The latest version that still supports PHP4 is 1.6.10 available [http://www.mediawiki.org/wiki/Download here]. 1.6.10 was released on 20th February 2007. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
::THe Wiki is currently running MediaWiki 1.6.10. Hopefully we won't see any more spam attacks. -- Bjorn 09:50 3 Jul 2007<br />
<br />
There was another spammer, although it could be a person doing it, rather than a bot. It was [[User:Yaxiaexx099|this account]] doing it, and [http://roguebasin.roguelikedevelopment.org/index.php?title=Dalhxf&oldid=12449 this] was was what he did.<br />
<br />
Here we go again, looks like the spambots are returning? Three new pages filled with.. something. [[Aldan|Here]], [[Generosity|here]] and [[Nourished|here]], created by three (new?) users in a short succession. Are there any anti-spambot guidelines somewhere, since I'm not sure of what to do, except for reporting? [[User:Solarnus|Solarnus]] 23:48, 8 January 2009 (CET)<br />
<br />
:Wonder if there is any way we can give rights to some users to approve new users so we dont have these spambots sign up, or we need to modify the captcha code to stop this crap.<br />
<br />
== Remove the news? ==<br />
<br />
I was wondering if it is a good idea to keep the news box on the main page. My thoughts:<br />
<br />
* We have three main news sites: RGRA, Temple of the Roguelike and the RogueBasin. That's a lot of duplicating.<br />
* I feel that the RGRA and Temple of the Roguelike are way more suited to displaying news. I see the RogueBasin as a resource of articles, guides and information about roguelikes.<br />
* The news box could be used to display other things. Such as new articles here, articles that we would like to improve and featured roguelikes.<br />
<br />
What do people think? [[User:Icey|Icey]] 14:45, 27 May 2007 (CEST)<br />
<br />
: I agree, both RGRA and TotR seem better places for sources of news (But saying that I do have TotR as a Live Bookmark in Firefox) although I have no problem having a smaller box with the last couple of items. I'd sooner see the space taken with new articles, articles for improvement and featured roguelikes as suggested. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
:RGRA and Temple are moderated, which means the news don't appear ASAP. For example both of these mediums haven't covered The Sewer Massacre 1.0 yet (and not for my lack of trying ;)). The main principle behind news is that they are new. A day later is already old news. Imagine if JADE is released, and the news don't appear anywhere for a day. Wiki solves this problem perfectly. [[User:Grue|Grue]] 23:09, 28 May 2007 (CEST)<br />
<br />
:::::::That's one of the cons of a moderated media :) also, RGRA is moderated, but moderation commonly takes less than 1 hour in my Experience --[[User:Slash|Slash]] 16:35, 4 Jun 2007 (CEST)<br />
<br />
::That is a good point, I hadn't really thought about the moderation aspect. Perhaps having a slightly different main page design would accommodate having sections for articles and featured items? [[User:Pucechan|Pucechan]] 18:36, 29 May 2007 (CEST)<br />
<br />
:::I've made a quick mockup of an idea, so colours and content (especially the top-right links) are just placeholders, this uses the fairly "traditional" block wiki format. The content is just copy-pasted but you get the idea. The news would be for each month (probably in a smaller font). See it here [[User:Pucechan/MainIdea]]. What do people think?<br />
<br />
::::I like it a lot. I've expanded the idea a bit: [[User:Icey/MainIdea]]. It's more wikipedia-like, has a little tag line so people know what the RogueBasin is, added the links to the top, added a featured article section, added a bit of colour and changes a few other things. [[User:Icey|Icey]] 02:12, 2 Jun 2007 (CEST)<br />
<br />
:::::I like the changes you've made, the little splash of colour helps. I prefer your simple set of links rather than my bundle (I didn't really sort them in any way but your way is much nicer). I really like it. [[User:Pucechan|Pucechan]] 11:19, 2 Jun 2007 (CEST)<br />
<br />
::::::Thanks Pucechan. Let's wait a few days to see if anyone else would like to improve/approve it and then decide what to do from there. [[User:Icey|Icey]] 13:19, 3 Jun 2007 (CEST)<br />
<br />
:::::::I like it a lot too... I have always thought roguebasin needs a better front page... perhaps changing "Current news" for "News for June 2007"? <br />
:::::::Also, it is pretty wordy, some images may help.. probably :P<br />
:::::::Thanks! --[[User:Slash|Slash]] 16:35, 4 Jun 2007 (CEST)<br />
<br />
:::::::: Images would be good, but uploading images is disabled :P A little cropped screenshot of a roguelike would be nice to go with the description. Like [http://www.reloaded.org/images/games/reviews/66/review07.png this] or [http://www.gamesetwatch.com/atplay/adom-8.gif this]. [[User:Icey|Icey]] 20:14, 7 Jun 2007 (CEST)<br />
<br />
::::::::: I have enabled uploads for a trial period. [[User:Bjorn|Bjorn]] 09:50, 3 Jul 2007 (CEST)<br />
<br />
== External community links ==<br />
<br />
One thing I think is missing from the main page is a list of external community links. The existing [[Roguelike_Links]] doesn't have [[Temple of the Roguelike]], [[@ Play]] and other current resources like forums for various roguelike games listed (and dare I say it [[Ascii Dreams]] ;) )<br />
<br />
Are people happy for me to tidy up the Links section, to include the above, a 'Press' section within Links for listing where external media have talked about roguelike games, and a Forums section within Links for listing the various game specific web forums such as [http://angband.oook.cz/forum the Angband forums], Angband variant web forums and others (Live Journal, other variants and so on)? I'd like to see more ways of people getting in touch with fellow roguelike players/developers listed somewhere convenient...<br />
<br />
: That's an excellent idea. Perhaps we could use [[Links]] as a comprehensive list and then do a cut down version for the main page?<br />
<br />
: Perhaps the Links page could have a Roguelike Blog section (or a name like that) for your site and others like [http://doryen.blogspot.com/] [http://kaduria.blogspot.com/]<br />
<br />
: [[User:Icey|Icey]] 18:52, 5 September 2007 (CEST)<br />
<br />
== All those guides! ==<br />
<br />
Where did all those good guides at http://www.roguelikedevelopment.org/ go? according to the news, the content has been moved to this wiki but I can't find any of those guides! me want's 'em badly!<br />
[[User:Solarnus|Solarnus]] 11:28, 16 January 2008 (CET)<br />
:Sorry, I meant of course that alot of guides are missing, as least most of the map algorithm stuff previously found on the old site is missing here at the wiki. Anyone got copies of those guides, please? [[User:Solarnus|Solarnus]] 14:28, 23 January 2008 (CET)<br />
::And you looked in the map section of [[Articles]]? All the ones I recall are there. Perhaps you can use the wayback machine to calculate which ones seem to be missing? [[User:Duerig|Duerig]] 17:12, 23 January 2008 (CET)<br />
:::lol, the wayback what..? No, realy, I know there's alot missing from the site. Some examples are the guides written by Mike Anderson (Dungeon-Building Algorithm, Fractal Landscapes) and Radomir "The Sheep" Dopieralski (Recursive LvL Generation) [[User:Solarnus|Solarnus]] 17:52, 23 January 2008 (CET)<br />
::::Look at this URL. It is from www.archive.org, the wayback machine for the Internet: http://web.archive.org/web/20060114055601/http://roguelikedevelopment.org/ but before you go adding all of the articles to the wiki, you should know that there was some effort to move them over, but only if the original authors could be found to give permission. So you should check with an admin here about what to do. [[User:Duerig|Duerig]] 08:50, 24 January 2008 (CET)<br />
:::::Oh crap, I thought I could just go and add what I managed to find, since it had already been released on the site o.0' Pardon me, I'm too quick sometimes, doing stuff without thinking first. <br /> But, IMHO, not moving over all that stuff just because the original author couldn't be found kinda buggers me, that's just wast of time and good knowledge, stupidlly forcing to "reinvent the wheel". And it buggers me even more, since obvisiouly (spelling?) it can still be found on the web thanks to that wayback machine you're talking about (thanks for that link btw, would've never thought of that). <br /> Thanks for telling me dude, I'll try slowing down/backing off and poke an admin about it before doing anything else.<br /> <br />Anyway, should the "previously missing" [[Dungeon-Building Algorithm]] article I dug up yesterday be removed, or just leave it for now and hope for the better? [[User:Solarnus|Solarnus]] 13:50, 24 January 2008 (CET)<br />
<br />
<br />
::::::Is there any chance of the articles being reposted on the original site until they can be ported here? They're only text documents, and a number of them were very good references. Most of the original files are not stored on wayback machine, so forn ow they are lost for good. [[User:lapoubelle|lapoubelle]] 30 April 2008<br />
<br />
I have spent most of today searching for and collecting all of the articles that were on the old system but not on roguebasin. I was able to recover all but two. Those two and links to the archives are at [[User:Duerig]]. That way they should be safe until we can decide how to handle them. If the admins have a problem with this, I'll host them on my own domain if I have to. Let me know if you can find information on either of the two remaining articles. [[User:Duerig|Duerig]] 21:53, 1 May 2008 (CEST)<br />
<br />
<br />
== THIS IS NOT A GAME ANNOUNCEMENT PAGE ==<br />
Don't post game announcements here, there are other pages for that. [[User:Stu|Stu]] (I forgot to sign my edit..)<br />
<br />
:Probably would have been a little nicer and a whole lot more helpful to give a link to the appropriate location and to not all-caps/scream the header, especially since the [[Help:Contents|Help]] section is ''completely'' blank (the most important part of any wiki that wants new contributors and knowledgeable editors), and the main Community Portal page just redirects straight here, making it totally useless as well to direct such notices to their appropriate location. Personally, I can't find a page that really matches what [[User:Caeonosphere|Caeonosphere]] appears to have been looking for. '''[[News]]''' seems to be the closest thing, but not really much of an announcement page for game developers so that they can get feedback. The site is a bit of a mess organizationally. Unfortunately, because of this, errant notices such as the one that you deleted are to be expected. [[User:Kiefer|Kiefer]] 13:44, 15 May 2008 (CEST)<br />
<br />
:: You seem to confuse the idea of a wiki vs a forum. This is not a place to post and get feedback and comments and criticisms. Thats what [[rec.games.roguelike.development]] or [http://roguetemple.com RogueTemple] is for. Game releases go on the [[News]] page, preferably linking to your game info page, but that is not required. RogueTemple also does game announcements, and takes comments in return on its front page and forums. [[User:Stu|Stu]] 14:54, 15 May 2008 (CEST)<br />
<br />
:::I think it's pretty clear that I'm not confusing anything. I didn't say that the announcement was correctly placed. In fact, I described it as an "errant notice." However, a Community Portal often ''does'' include a spot for the wiki's community to get together and discuss things that relate to the subject of the wiki. Sometimes that involves requests for feedback like the one you deleted. I'm guessing that Caeonosphere put the request in the most likely place he thought it should go, since (once again) there was no main Community Portal page to direct him.<br />
<br />
:::I think instead that it's pretty clear that my point was: '''You didn't treat the user with the respect that they deserved.''' You should have guided them in the right direction, instead of assuming that they should already know what to do. (But, once again, '''''how''''' should they know?) Instead of helping, you deleted their message, added a header that shouts at the user should they return, and then said that "there are other pages for that" without leaving even a clue as to what that might mean. And, apparently from what you just wrote in your reply, there '''aren't''' other pages for that here - the developer would have to go someplace else entirely. (A user can't even ask an admin for guidance or help, as there isn't a list of sysops posted on the Main Page from which to get help!)<br />
<br />
:::It's a matter of treating the users with respect, and helping them out instead of essentially saying "bugger off." [[User:Kiefer|Kiefer]] 07:35, 16 May 2008 (CEST)<br />
<br />
:::: I agree, I was an arse, and after looking around it really isn't very clear where to go or what to do. I tried to edit the help page but dont have rights to do so. I think the front page needs a revamp to make things clearer. It is too cluttered. I added a little blurb to the top of the community page that might help. I also added the two games I deleted to the News page. [[User:Stu|Stu]] 14:21, 16 May 2008 (CEST)<br />
<br />
:::::You da man! My flying monkeys of death have been recalled and sun is shining again across the land. So, who do we have to bribe to get the help pages started and a non-redirecting Community Portal page created? I've worked on similar elsewhere, but everything is protected, and I don't really know what the "vision" of the site is. Ah well. [[User:Kiefer|Kiefer]] 17:54, 16 May 2008 (CEST)<br />
<br />
::::::I get an SQL error if I try to unprotect those pages. Thus, I've gone with the simpler answer of redirecting both to user-editable pages. I really don't know what a community portal should consist of, so left that page blank with a link back to this talk. The Help page I spliced together from existing stuff. Please let me know if there are other needs. --[[User:JeffLait|JeffLait]] 18:02, 28 July 2008 (CEST)<br />
<br />
== Game or project? ==<br />
<br />
Template [[Template:Angband-variant]] asks for status field. Then game entry is added to "status games" category. This works well for stable games and defunct games but fails for alpha, beta and talkie talkie *projects*. Thus any Angband variants which classify themselves as having alpha or beta status do not get included in proper category. Any ideas how to correct that without destroying too much existing work? I would opt for removing status field and adding all variants to categories manually. Other choice is to spilt template into several like it was done with [[Template:Gameinfo]]. What are others opinions on this? <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 16:18, 19 August 2008 (CEST)<br />
<br />
: I think the best bet is to split the template like the Gameinfo did. I presume there was a good reason to do that split rather than use the status field cleverly. I don't like people having to manually add the category tag as that will result in people forgetting to categorize the variant at all. --[[User:JeffLait|JeffLait]] 05:21, 21 August 2008 (CEST)<br />
<br />
:: Foundations are lain. I am going to wait some more time before proceeding to change all Angband variant pages in case better ideas show up or someone has objections. <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 15:03, 25 August 2008 (CEST)<br />
<br />
== 1krl ==<br />
<br />
We should add this to the wiki, but I'm not sure where.<br />
http://1024brl.googlepages.com/<br />
(and a link to the rgrd posts of course.<br />
--[[User:Soyweiser|Soyweiser]] 02:00, 22 August 2008 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=Cracks_and_Crevices&diff=14322Cracks and Crevices2008-12-07T02:16:52Z<p>Stu: Removed portnumber for redmine link</p>
<hr />
<div>{{game-alpha| name = Cracks and Crevices<br />
|developer = [[Stu George]]<br />
|theme = Fantasy<br />
|influences = Underdark<br />
|released = 2007 Feb 24<br />
|updated = 2008 Feb 18<br />
|licensing = GPL<br />
|language = C<br />
|platforms = Windows, Linux<br />
|interface = [[Graphical ascii tiles]], [[Keyboard]]<br />
|length = short<br />
|site = http://redmine.bloodycactus.com/projects/show/sdlrl<br />
}}<br />
<br />
''Cracks and Crevices'' is a graphical ascii roguelike game written by Stu, using [[SDL]]. It takes ideas from my other roguelikes like [[UnderDark]] and [[SRL]].<br />
<br />
The originaly idea was to keep things simple in order to create an actual working game instead of a huge mountain of ideas that never get implemented or see the light of day.<br />
<br />
Its designed to not be so hardcore as [[NetHack]] and [[Crawl]] but not be as easy as [[Larn]]. It does provide help for the beginner and cue's when the game starts.<br />
<br />
== Story ==<br />
''Cracks and Crevices'' is about life in the small village of ''Danforths Outcrop'', hewn into the rock at an opening to a large crevice. The game starts with you, a young person of the village on the verge of your adulthood test, which is to survive two days in the labyrinth of the crevice before you will be allowed back into town. Only the strong survive to increase the strength of the village, and if you survive you will be allowed back into town, there you can explore or re-enter the labyrinth or take up some quests offered by the town clerk.<br />
<br />
<br />
== Features ==<br />
* Semi realtime gameplay<br />
* Facing FOV<br />
* Stackable spell / weapon system<br />
* Magic System based on MP that regerates over time or by wielding/wearing mage type items<br />
* Weapons, Potions, Spell books, mushrooms, rings, armor, shields, etc<br />
* No preset classes or skill systems. Development of @'s class is up to the player.<br />
* Customer key configuration<br />
* Message Logs<br />
* Character dumps<br />
* Save / Load<br />
* Permadeath<br />
* Working towns (shops, inns, banks, etc)<br />
* Special NPC's<br />
<br />
<br />
== Time and Modes ==<br />
''Cracks and Crevices'' uses semi-realtime to set the game play. There is an Easy / Medium / Hard mode of play.<br />
<br />
=== Easy ===<br />
* Easy mode gives you 3 seconds to make a move before you loose your current turn and all the monsters get to move. <br />
* More Money to start the game with<br />
* Circular FOV<br />
<br />
=== Medium ===<br />
* 1.5 seconds per move<br />
* Facing directional cone FOV<br />
<br />
=== Hard ===<br />
* 1 second per move<br />
* Facing directional cone FOV<br />
<br />
== Class System ==<br />
There is no preset class system or skill system in the game. It is left up to the player to choose the direction of development, if they want to focus on pure melee fighter type or mage type or something in between. There is no restriction on wielding swords and casting spells at the same time. There are pros and cons to each and heavy armor may not be the best choice for a spellcaster...<br />
<br />
<br />
== Current Status ==<br />
0.4 has many changes<br />
* BIG Rewrote mainloop code (fixed some subtle round bugs).<br />
* Rounds now work properly for all NPC's and the PC<br />
* Timers work correctly<br />
* Rewrote attribute code<br />
* Gold drops on floor now<br />
* Monsters die correctly!<br />
* Initial quest time shortened to make it more attainable.<br />
* Messages are now counted and displayed as Msg (x) if repeated to stop cluttering the display.<br />
* Remove character dump when starting a new game<br />
* Dont save character dump when saving game<br />
* Stopped monsters and drops from appearing in the message window (doh!)<br />
* Stopped saving from doing an explicit call to exit instead of falling through the game loop like quit does, which revealed some mem leaks that were plugged.<br />
* Gold drops were dropping underneath the player not monster!<br />
* Spells in spellbooks<br />
* Start spell when buying first spellbook<br />
* Attack/Target Cycling/Cast Spell commands<br />
* Implemented 99% of the spell attributes<br />
* Casting spells now works! (no whizzbang animation. it just works)<br />
* auto pickup working<br />
* Pickup key words<br />
* Fixed : When selling item, unequip it automatically<br />
* Added circular fov for easy games<br />
* Bumpbed facing fov for medium + hard games<br />
* Added leveling up<br />
* Added ctrl-c as break all from program<br />
* Added ESC as means to close out most all dialogues<br />
* Made some defaults sane (no mixing cursor + keypad)<br />
<br />
==External Links==<br />
* [http://redmine.bloodycactus.com:3085/projects/list_files/sdlrl Downloads]<br />
* [http://redmine.bloodycactus.com:3085/projects/sdlrl/issues Buglist]</div>Stuhttp://roguebasin.com/index.php?title=Things_which_are_hard_to_code&diff=14033Things which are hard to code2008-09-03T01:32:05Z<p>Stu: Minor updates + wiki'ized my name</p>
<hr />
<div>''Compilation by [[User:Kisielewicz|Kornel Kisielewicz]] of the thead on [[rgrd]]''<br />
<br />
== Things which are harder to code than one might initially think ==<br />
<br />
=== [[Antoine]] ===<br />
* Invisibility<br />
* Polymorph-self<br />
* Charm monster<br />
* Stacking objects<br />
* Friendly NPCs in the dungeon<br />
<br />
=== [[The Sheep]] ===<br />
* Selling items<br />
* Timed events<br />
* Animation<br />
* Persistent levels<br />
* Monsters moving between levels<br />
* Monsters with FOV<br />
* Pets<br />
* Random artifacts<br />
* Random monster races<br />
* Doors with keys<br />
* Throwing items<br />
* Monster inventory<br />
* Running<br />
<br />
=== [[Kornel Kisielewicz]] ===<br />
* Random Quests<br />
* Random Plot<br />
* Random Overworld<br />
* Adding content<br />
* Balancing<br />
* Polishing <br />
<br />
=== [[Stu George]] ===<br />
* Balance<br />
* Sense of time<br />
* Food <br />
* Q&A, Testing, Documenting, Planning<br />
* Water (infinitely divisible)<br />
* Fire (I want to burn everything!)<br />
* Mixing liquids<br />
* Economy<br />
<br />
=== konjin ===<br />
* Stealth<br />
<br />
=== Ray Dillinger ===<br />
* Rope<br />
<br />
=== [[Michal Bielinski]] ===<br />
* Inter-monster fights<br />
<br />
=== [[Stoolmaker]] ===<br />
[Not part of Kornel's kompilation.] I think it depends on the whole framework of code. In my world, for instance, making critters invisible is a rather simple task because of how I've implemented [[Line of Sight]]. Making them dead is harder :) That said: I find that balancing everything is a delicate task. Randomizing quests, equipments, races etc. is also an interesting challenge. Regarding these, however, I think its possible to find some short cuts just by writing imaginative pieces of sentences/elements and combining them in unpredictably large structures (needn't be so huge). For example: put n kinds of "wandlikes" in a list (wands, lamps, bottles (uncork to release effect) etc.), have n kinds of "range models" (cones, rays, single adjacent/far points, zones (eg. fireball), clouds which start to drift and finally dissolve...), and n kinds of effects (elemental damage, teleport etc.). Already you'll have weird objects popping up: from the presumably predictable ("copper wand: ray of ice"), by means of the useful ("painted calabash: cloud of panic") and all the way to the outright silly ("ugly conjurers hat: rain of polymorph").<br />
<br />
[[Category:Articles]]</div>Stuhttp://roguebasin.com/index.php?title=User_talk:R2&diff=13615User talk:R22008-07-27T14:23:35Z<p>Stu: </p>
<hr />
<div>==(standardization of dates)==<br />
Whoa, what happened here. Was this site-wide change discussed anywhere? [[User:Kiefer|Kiefer]] 07:14, 21 July 2008 (CEST)<br />
<br />
: It wasn't discussed on this wiki (so I doubt that the discussion, even if it exists, "counts"). Furthermore, it's not a uniform readability improvement. -- [[User:Bessarion|Bessarion]] 8:18 21 July 2008 (CDT)<br />
<br />
: The reasons for standardization are at http://www.roguetemple.com/forums/index.php?topic=62 --[[User:R2|R2]] 19:53, 21 July 2008 (CEST)<br />
<br />
:: That <b>doesn't</b> count, unless there's some undocumented management integration between the two sites. Fixing that application (a function that takes a gloppy date, and returns a standard-formed date if possible) is the correct approach. If I was to propose any (unnecessary) standardization, I would suggest four-digit years, and months as <b>text</b>. That way, the difference between U.S. dates and EU dates doesn't cause confusion.<br />
<br />
:: As it is, anyone from the EU who doesn't know the standardization convention is going to think the correct format for Dec 3 2008 is 2008/3/12, which breaks your abstractor application without <b>any</b> chance of recovery.<br />
<br />
:: I'm going to make up my mind on whether to revert this spam for Zaiband and YADS later, once the emotional reasoning no longer is in the way. -- [[User:Bessarion|Bessarion]] 17:54 21 July 2008 (CDT)<br />
<br />
::: The standard I used (YYYY MM DD) is an ISO standard (ISO-8601) for international date format, a UE standard (EN 28601), and also is the most logical format (as the usual big endian sorting works correctly on it). (The US date format is as far as I know MM/DD/YYYY and cannot be confused because of the 4-digit year which is immediately recognized. DD/MM/YYYY also should not be confused for the same reason. YYYY/DD/MM potentially could be confused, but I think it is not used anywhere as a date standard.) You are right that displaying months as text would be also a good option, and also would eliminate any risk of confusion, and would be more readable for some. But I suggest to make the template make clear that "YYYY/MM/DD" is the format to use. --[[User:R2|R2]]<br />
<br />
::: [[User:Bessarion|Bessarion]]'s suggestion to standardize with textual months in full is the most human readable and the simplest. I for one would be happy with it. To achieve machine readability, a standard must be used. But it doesn't matter which one. So lets have a standard so that [[User:R2|R2]] gets what they want. And lets make it unambiguous for humans and easy to read like [[User:Bessarion|Bessarion]] wants. Everybody wins. [[User:Duerig|Duerig]] 01:59, 22 July 2008 (CEST)<br />
<br />
:::: Oh, it doesn't have to be in full -- C gets by perfectly well with three-character abbreviations for asctime. (IMO, the date standardizer for the abstractor application should handle both abbreviations and full names). I do prefer something where a legitimate transposition oversight doesn't change the meaning. (I use a YYYYMMDD file part myself on files not meant for public consumption to get the lexical sorting to line up with the date sorting, but that doesn't mean I think such unintuitive constructs belong in prose. I certainly wouldn't expect a non-programmer to have a clue what 2008/12/3 was supposed to mean. 2008 Dec 3 merely looks grammatically weird, but is readable.) -- [[User:Bessarion|Bessarion]] 19:36 21 July 2008 (CDT)<br />
<br />
::: OK, I will wait until the discussion ends, and change the format to "2008 Dec 03" if there is no new input. --[[User:R2|R2]] 10:39, 22 July 2008 (CEST)<br />
<br />
::I don't see anything at http://www.roguetemple.com/forums/index.php?topic=62 that has anything to do with how to standardize dates. Also, it doesn't appear that (YYYY MM DD) was what was always used, as the change on the POWDER page (http://roguebasin.roguelikedevelopment.org/index.php?title=POWDER&curid=782&diff=13431&oldid=13296) uses (YYYY DD MM). For readability, using text for the month is really needed, at least if this site is meant to be more international, as opposed to regional. [[User:Kiefer|Kiefer]] 06:08, 22 July 2008 (CEST)<br />
<br />
::: Sorry for breaking POWDER date. This link was only a quick explanation. A table which shows release dates for many roguelikes looks better when all the dates follow the same format, and is also more reasonable to implement when they follow a standard. I used YYYY MM DD because it's the most logical for me and because it does not need any further work. --[[User:R2|R2]] 10:39, 22 July 2008 (CEST)<br />
<br />
::: I do not expect impulsive decisions to be well-documented. The idea was to reduce date ordering to string-compare ordering (which is tangentially mentioned), but at the time no consideration was documented of the agonizingly obvious idea of a date format canonicalizer in the abstractor. Such a canonicalizer also would allow extending the abstractor application to more than just Roguebasin. -- [[User:Bessarion|Bessarion]] 8:03 22 July 2008 (CDT)<br />
<br />
:::: I believe that standardizing dates on Roguebasin is a better approach than making the abstractor understand all the date formats possible. In our case, it is just easier to eliminate the special formats (by editting) than to recognize them aumatically. Both Roguebasin and abstractor are cleaner that way, and also it makes the job simpler for anyone in the future who wants to use the data for some purpose. Having non-standardized data is like carrying a separate charger for each of your 10 electronic devices, and having a standard is like have one charger working for all of them. --[[User:R2|R2]] 17:19, 22 July 2008 (CEST)<br />
<br />
::::: Pardon my ignorance, but is the wiki being implemented into some other project where those dates are going to be grabbed? (Once again, the lack of a Community Portal page and Help section for the wiki leaves me ignorant about this, if this is the case.) [[User:Kiefer|Kiefer]] 19:17, 22 July 2008 (CEST)<br />
<br />
:::::: While there is an informal relation between RogueTemple and RogueBasin (e.g., the article backup feature), the formal administrator of this Wiki being AWOL makes tracing such things difficult. -- [[User:Bessarion|Bessarion]] 13:08 22 July 2008 (CDT)<br />
<br />
::::: We shall just have to disagree then; I'm not the one maintaining that abstractor. I <b>have</b> written such an omni-date converter in Perl (needed it for some log translation for one of my clients), so it's [sarcasm]trivial[/sarcasm] to write one (I would expect under two hours total time including design and testing in anything higher than assembly language, maybe about an hour in Perl). -- [[User:Bessarion|Bessarion]] 13:08 22 July 2008 (CDT)<br />
<br />
::::::Okay, so what I get from this discussion is that the dates aren't used anywhere else, but if they are to be in the future, they should be uniform. For programmers, that is best done as (YYYY/MM/DD), but for actual visitors to the Roguebasin wiki, (Month DD, YYYY) or (Mon. DD, YYYY) is more readable and understandable. I'm all for a wiki being implemented in other applications/sites/whatever, but I always think of a wiki as primarily a resource for a human being, and human being "scan" things differently and can read things incorrectly. I think that's shown in the POWDER date being messed up. Sometimes things have to be done in manner that benefits the general audience, rather than the needs of programmers. <small>oh, I know ''that's'' going to go over well with this audience, he says to himself. :-)</small><br />
::::::So, who's the head admin here, anyway? 5 admins, and [[User:Slash]] appears to be the only one that has had a serious presence here in 2008. [[User:Kiefer|Kiefer]] 05:58, 24 July 2008 (CEST)<br />
<br />
:::::::I like the YYYY MM DD format. Also yyyy?????mm???dd????? is another possible format. Example: 2008?????07???24????? if you don't understand this Japanese format or you don't have this font install then you might confuse, but it tell you which one is the year, month, and day. Another way you could put hyperlink on the date, or a tooltop on the date, tell you which format it is, in case you don't know. --[[User:Zzo38|Zzo38]] 17:46, 24 July 2008 (CEST)<br />
<br />
::::::::The "2002 Mar 18" format looks like arse. I'd rather see "18-Mar-2002", because right now it reads "backwards". [[User:Stu|Stu]] 19:17, 24 July 2008 (CEST)<br />
<br />
:::::::::But "18-Mar-2002" is backwards! YYYY MM DD (in numbers, optionally follow by kanji symbols) is good way. --[[User:Zzo38|Zzo38]] 19:34, 24 July 2008 (CEST)<br />
<br />
::::::::::Actually, '''18 Mar 2008''' is the wiki way for dates, as shown by our signatures, and not backwards. Kanji would be fine if the wiki was a Japanese-only wiki. As it is, it doesn't appear that this wiki supports the kanji symbols, as another one that I go to functions fine with kanji, but this one doesn't show the characters at all. [[User:Kiefer|Kiefer]] 05:22, 25 July 2008 (CEST)<br />
<br />
:::::::::::OK. You can use the way that is used in the signatures (I still think it is backwards though, but if that is the wiki way then obviously it should be used). The wiki way however uses the full month name, not the abbreviation. Kanji is not needed, but it did display correctly (except the summary) until you edited this page. When you edited, then it did mess up the kanji. I don't know if that is a bug. It doesn't need to be fix unless someone else uses Unicode writing in these pages for some reason (such as their Roguelike games using those special characters that must be indicated in the description). --[[User:Zzo38|Zzo38]] 05:45, 25 July 2008 (CEST)<br />
<br />
:: Wait, you changed the date format only to fit a program you wrote? It seems to me changing the way how IRLDb processes these numbers would be both easier and less work. <b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 05:50, 27 July 2008 (CEST)<br />
::: So what date is "1/2/08" ? Is it 1st of Feb 2008 or is it January 2nd 2008?? Do you understand now why the change...[[User:Stu|Stu]] 16:23, 27 July 2008 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=User_talk:R2&diff=13599User talk:R22008-07-24T17:17:08Z<p>Stu: </p>
<hr />
<div>==(standardization of dates)==<br />
Whoa, what happened here. Was this site-wide change discussed anywhere? [[User:Kiefer|Kiefer]] 07:14, 21 July 2008 (CEST)<br />
<br />
: It wasn't discussed on this wiki (so I doubt that the discussion, even if it exists, "counts"). Furthermore, it's not a uniform readability improvement. -- [[User:Bessarion|Bessarion]] 8:18 21 July 2008 (CDT)<br />
<br />
: The reasons for standardization are at http://www.roguetemple.com/forums/index.php?topic=62 --[[User:R2|R2]] 19:53, 21 July 2008 (CEST)<br />
<br />
:: That <b>doesn't</b> count, unless there's some undocumented management integration between the two sites. Fixing that application (a function that takes a gloppy date, and returns a standard-formed date if possible) is the correct approach. If I was to propose any (unnecessary) standardization, I would suggest four-digit years, and months as <b>text</b>. That way, the difference between U.S. dates and EU dates doesn't cause confusion.<br />
<br />
:: As it is, anyone from the EU who doesn't know the standardization convention is going to think the correct format for Dec 3 2008 is 2008/3/12, which breaks your abstractor application without <b>any</b> chance of recovery.<br />
<br />
:: I'm going to make up my mind on whether to revert this spam for Zaiband and YADS later, once the emotional reasoning no longer is in the way. -- [[User:Bessarion|Bessarion]] 17:54 21 July 2008 (CDT)<br />
<br />
::: The standard I used (YYYY MM DD) is an ISO standard (ISO-8601) for international date format, a UE standard (EN 28601), and also is the most logical format (as the usual big endian sorting works correctly on it). (The US date format is as far as I know MM/DD/YYYY and cannot be confused because of the 4-digit year which is immediately recognized. DD/MM/YYYY also should not be confused for the same reason. YYYY/DD/MM potentially could be confused, but I think it is not used anywhere as a date standard.) You are right that displaying months as text would be also a good option, and also would eliminate any risk of confusion, and would be more readable for some. But I suggest to make the template make clear that "YYYY/MM/DD" is the format to use. --[[User:R2|R2]]<br />
<br />
::: [[User:Bessarion|Bessarion]]'s suggestion to standardize with textual months in full is the most human readable and the simplest. I for one would be happy with it. To achieve machine readability, a standard must be used. But it doesn't matter which one. So lets have a standard so that [[User:R2|R2]] gets what they want. And lets make it unambiguous for humans and easy to read like [[User:Bessarion|Bessarion]] wants. Everybody wins. [[User:Duerig|Duerig]] 01:59, 22 July 2008 (CEST)<br />
<br />
:::: Oh, it doesn't have to be in full -- C gets by perfectly well with three-character abbreviations for asctime. (IMO, the date standardizer for the abstractor application should handle both abbreviations and full names). I do prefer something where a legitimate transposition oversight doesn't change the meaning. (I use a YYYYMMDD file part myself on files not meant for public consumption to get the lexical sorting to line up with the date sorting, but that doesn't mean I think such unintuitive constructs belong in prose. I certainly wouldn't expect a non-programmer to have a clue what 2008/12/3 was supposed to mean. 2008 Dec 3 merely looks grammatically weird, but is readable.) -- [[User:Bessarion|Bessarion]] 19:36 21 July 2008 (CDT)<br />
<br />
::: OK, I will wait until the discussion ends, and change the format to "2008 Dec 03" if there is no new input. --[[User:R2|R2]] 10:39, 22 July 2008 (CEST)<br />
<br />
::I don't see anything at http://www.roguetemple.com/forums/index.php?topic=62 that has anything to do with how to standardize dates. Also, it doesn't appear that (YYYY MM DD) was what was always used, as the change on the POWDER page (http://roguebasin.roguelikedevelopment.org/index.php?title=POWDER&curid=782&diff=13431&oldid=13296) uses (YYYY DD MM). For readability, using text for the month is really needed, at least if this site is meant to be more international, as opposed to regional. [[User:Kiefer|Kiefer]] 06:08, 22 July 2008 (CEST)<br />
<br />
::: Sorry for breaking POWDER date. This link was only a quick explanation. A table which shows release dates for many roguelikes looks better when all the dates follow the same format, and is also more reasonable to implement when they follow a standard. I used YYYY MM DD because it's the most logical for me and because it does not need any further work. --[[User:R2|R2]] 10:39, 22 July 2008 (CEST)<br />
<br />
::: I do not expect impulsive decisions to be well-documented. The idea was to reduce date ordering to string-compare ordering (which is tangentially mentioned), but at the time no consideration was documented of the agonizingly obvious idea of a date format canonicalizer in the abstractor. Such a canonicalizer also would allow extending the abstractor application to more than just Roguebasin. -- [[User:Bessarion|Bessarion]] 8:03 22 July 2008 (CDT)<br />
<br />
:::: I believe that standardizing dates on Roguebasin is a better approach than making the abstractor understand all the date formats possible. In our case, it is just easier to eliminate the special formats (by editting) than to recognize them aumatically. Both Roguebasin and abstractor are cleaner that way, and also it makes the job simpler for anyone in the future who wants to use the data for some purpose. Having non-standardized data is like carrying a separate charger for each of your 10 electronic devices, and having a standard is like have one charger working for all of them. --[[User:R2|R2]] 17:19, 22 July 2008 (CEST)<br />
<br />
::::: Pardon my ignorance, but is the wiki being implemented into some other project where those dates are going to be grabbed? (Once again, the lack of a Community Portal page and Help section for the wiki leaves me ignorant about this, if this is the case.) [[User:Kiefer|Kiefer]] 19:17, 22 July 2008 (CEST)<br />
<br />
:::::: While there is an informal relation between RogueTemple and RogueBasin (e.g., the article backup feature), the formal administrator of this Wiki being AWOL makes tracing such things difficult. -- [[User:Bessarion|Bessarion]] 13:08 22 July 2008 (CDT)<br />
<br />
::::: We shall just have to disagree then; I'm not the one maintaining that abstractor. I <b>have</b> written such an omni-date converter in Perl (needed it for some log translation for one of my clients), so it's [sarcasm]trivial[/sarcasm] to write one (I would expect under two hours total time including design and testing in anything higher than assembly language, maybe about an hour in Perl). -- [[User:Bessarion|Bessarion]] 13:08 22 July 2008 (CDT)<br />
<br />
::::::Okay, so what I get from this discussion is that the dates aren't used anywhere else, but if they are to be in the future, they should be uniform. For programmers, that is best done as (YYYY/MM/DD), but for actual visitors to the Roguebasin wiki, (Month DD, YYYY) or (Mon. DD, YYYY) is more readable and understandable. I'm all for a wiki being implemented in other applications/sites/whatever, but I always think of a wiki as primarily a resource for a human being, and human being "scan" things differently and can read things incorrectly. I think that's shown in the POWDER date being messed up. Sometimes things have to be done in manner that benefits the general audience, rather than the needs of programmers. <small>oh, I know ''that's'' going to go over well with this audience, he says to himself. :-)</small><br />
::::::So, who's the head admin here, anyway? 5 admins, and [[User:Slash]] appears to be the only one that has had a serious presence here in 2008. [[User:Kiefer|Kiefer]] 05:58, 24 July 2008 (CEST)<br />
<br />
:::::::I like the YYYY MM DD format. Also yyyy?????mm???dd????? is another possible format. Example: 2008?????07???24????? if you don't understand this Japanese format or you don't have this font install then you might confuse, but it tell you which one is the year, month, and day. Another way you could put hyperlink on the date, or a tooltop on the date, tell you which format it is, in case you don't know. --[[User:Zzo38|Zzo38]] 17:46, 24 July 2008 (CEST)<br />
<br />
::::::::The "2002 Mar 18" format looks like arse. I'd rather see "18-Mar-2002", because right now it reads "backwards". [[User:Stu|Stu]] 19:17, 24 July 2008 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=User_talk:R2&diff=13598User talk:R22008-07-24T17:16:39Z<p>Stu: </p>
<hr />
<div>==(standardization of dates)==<br />
Whoa, what happened here. Was this site-wide change discussed anywhere? [[User:Kiefer|Kiefer]] 07:14, 21 July 2008 (CEST)<br />
<br />
: It wasn't discussed on this wiki (so I doubt that the discussion, even if it exists, "counts"). Furthermore, it's not a uniform readability improvement. -- [[User:Bessarion|Bessarion]] 8:18 21 July 2008 (CDT)<br />
<br />
: The reasons for standardization are at http://www.roguetemple.com/forums/index.php?topic=62 --[[User:R2|R2]] 19:53, 21 July 2008 (CEST)<br />
<br />
:: That <b>doesn't</b> count, unless there's some undocumented management integration between the two sites. Fixing that application (a function that takes a gloppy date, and returns a standard-formed date if possible) is the correct approach. If I was to propose any (unnecessary) standardization, I would suggest four-digit years, and months as <b>text</b>. That way, the difference between U.S. dates and EU dates doesn't cause confusion.<br />
<br />
:: As it is, anyone from the EU who doesn't know the standardization convention is going to think the correct format for Dec 3 2008 is 2008/3/12, which breaks your abstractor application without <b>any</b> chance of recovery.<br />
<br />
:: I'm going to make up my mind on whether to revert this spam for Zaiband and YADS later, once the emotional reasoning no longer is in the way. -- [[User:Bessarion|Bessarion]] 17:54 21 July 2008 (CDT)<br />
<br />
::: The standard I used (YYYY MM DD) is an ISO standard (ISO-8601) for international date format, a UE standard (EN 28601), and also is the most logical format (as the usual big endian sorting works correctly on it). (The US date format is as far as I know MM/DD/YYYY and cannot be confused because of the 4-digit year which is immediately recognized. DD/MM/YYYY also should not be confused for the same reason. YYYY/DD/MM potentially could be confused, but I think it is not used anywhere as a date standard.) You are right that displaying months as text would be also a good option, and also would eliminate any risk of confusion, and would be more readable for some. But I suggest to make the template make clear that "YYYY/MM/DD" is the format to use. --[[User:R2|R2]]<br />
<br />
::: [[User:Bessarion|Bessarion]]'s suggestion to standardize with textual months in full is the most human readable and the simplest. I for one would be happy with it. To achieve machine readability, a standard must be used. But it doesn't matter which one. So lets have a standard so that [[User:R2|R2]] gets what they want. And lets make it unambiguous for humans and easy to read like [[User:Bessarion|Bessarion]] wants. Everybody wins. [[User:Duerig|Duerig]] 01:59, 22 July 2008 (CEST)<br />
<br />
:::: Oh, it doesn't have to be in full -- C gets by perfectly well with three-character abbreviations for asctime. (IMO, the date standardizer for the abstractor application should handle both abbreviations and full names). I do prefer something where a legitimate transposition oversight doesn't change the meaning. (I use a YYYYMMDD file part myself on files not meant for public consumption to get the lexical sorting to line up with the date sorting, but that doesn't mean I think such unintuitive constructs belong in prose. I certainly wouldn't expect a non-programmer to have a clue what 2008/12/3 was supposed to mean. 2008 Dec 3 merely looks grammatically weird, but is readable.) -- [[User:Bessarion|Bessarion]] 19:36 21 July 2008 (CDT)<br />
<br />
::: OK, I will wait until the discussion ends, and change the format to "2008 Dec 03" if there is no new input. --[[User:R2|R2]] 10:39, 22 July 2008 (CEST)<br />
<br />
::I don't see anything at http://www.roguetemple.com/forums/index.php?topic=62 that has anything to do with how to standardize dates. Also, it doesn't appear that (YYYY MM DD) was what was always used, as the change on the POWDER page (http://roguebasin.roguelikedevelopment.org/index.php?title=POWDER&curid=782&diff=13431&oldid=13296) uses (YYYY DD MM). For readability, using text for the month is really needed, at least if this site is meant to be more international, as opposed to regional. [[User:Kiefer|Kiefer]] 06:08, 22 July 2008 (CEST)<br />
<br />
::: Sorry for breaking POWDER date. This link was only a quick explanation. A table which shows release dates for many roguelikes looks better when all the dates follow the same format, and is also more reasonable to implement when they follow a standard. I used YYYY MM DD because it's the most logical for me and because it does not need any further work. --[[User:R2|R2]] 10:39, 22 July 2008 (CEST)<br />
<br />
::: I do not expect impulsive decisions to be well-documented. The idea was to reduce date ordering to string-compare ordering (which is tangentially mentioned), but at the time no consideration was documented of the agonizingly obvious idea of a date format canonicalizer in the abstractor. Such a canonicalizer also would allow extending the abstractor application to more than just Roguebasin. -- [[User:Bessarion|Bessarion]] 8:03 22 July 2008 (CDT)<br />
<br />
:::: I believe that standardizing dates on Roguebasin is a better approach than making the abstractor understand all the date formats possible. In our case, it is just easier to eliminate the special formats (by editting) than to recognize them aumatically. Both Roguebasin and abstractor are cleaner that way, and also it makes the job simpler for anyone in the future who wants to use the data for some purpose. Having non-standardized data is like carrying a separate charger for each of your 10 electronic devices, and having a standard is like have one charger working for all of them. --[[User:R2|R2]] 17:19, 22 July 2008 (CEST)<br />
<br />
::::: Pardon my ignorance, but is the wiki being implemented into some other project where those dates are going to be grabbed? (Once again, the lack of a Community Portal page and Help section for the wiki leaves me ignorant about this, if this is the case.) [[User:Kiefer|Kiefer]] 19:17, 22 July 2008 (CEST)<br />
<br />
:::::: While there is an informal relation between RogueTemple and RogueBasin (e.g., the article backup feature), the formal administrator of this Wiki being AWOL makes tracing such things difficult. -- [[User:Bessarion|Bessarion]] 13:08 22 July 2008 (CDT)<br />
<br />
::::: We shall just have to disagree then; I'm not the one maintaining that abstractor. I <b>have</b> written such an omni-date converter in Perl (needed it for some log translation for one of my clients), so it's [sarcasm]trivial[/sarcasm] to write one (I would expect under two hours total time including design and testing in anything higher than assembly language, maybe about an hour in Perl). -- [[User:Bessarion|Bessarion]] 13:08 22 July 2008 (CDT)<br />
<br />
::::::Okay, so what I get from this discussion is that the dates aren't used anywhere else, but if they are to be in the future, they should be uniform. For programmers, that is best done as (YYYY/MM/DD), but for actual visitors to the Roguebasin wiki, (Month DD, YYYY) or (Mon. DD, YYYY) is more readable and understandable. I'm all for a wiki being implemented in other applications/sites/whatever, but I always think of a wiki as primarily a resource for a human being, and human being "scan" things differently and can read things incorrectly. I think that's shown in the POWDER date being messed up. Sometimes things have to be done in manner that benefits the general audience, rather than the needs of programmers. <small>oh, I know ''that's'' going to go over well with this audience, he says to himself. :-)</small><br />
::::::So, who's the head admin here, anyway? 5 admins, and [[User:Slash]] appears to be the only one that has had a serious presence here in 2008. [[User:Kiefer|Kiefer]] 05:58, 24 July 2008 (CEST)<br />
<br />
:::::::I like the YYYY MM DD format. Also yyyy?????mm???dd????? is another possible format. Example: 2008?????07???24????? if you don't understand this Japanese format or you don't have this font install then you might confuse, but it tell you which one is the year, month, and day. Another way you could put hyperlink on the date, or a tooltop on the date, tell you which format it is, in case you don't know. --[[User:Zzo38|Zzo38]] 17:46, 24 July 2008 (CEST)<br />
<br />
::::::::The "2002 Mar 18" format looks like arse. I'd rather see "18-Mar-2002", because right now it reads "backwards".</div>Stuhttp://roguebasin.com/index.php?title=Talk:Wuxia&diff=13349Talk:Wuxia2008-07-13T17:12:44Z<p>Stu: </p>
<hr />
<div>I think Wuxia would be great for a roguelike. The greatest difficulty would really be the '3rd dimension' regarding implementation.</div>Stuhttp://roguebasin.com/index.php?title=List_of_roguelikes_by_year&diff=13295List of roguelikes by year2008-07-04T01:22:55Z<p>Stu: Added to 2007 list</p>
<hr />
<div>This is a '''list of Roguelikes''', ordered by year of release.<br />
{| id="toc" border="0"<br />
! {{MediaWiki:Toc}}:<br />
| <br />
{| style="background:none; border-bottom-width: 1px; border-bottom-color: #999; border-bottom-style: solid; "<br />
|- <br />
| align="right" | [[#1974|1974]] [[#1975|1975]] 1976 1977 1978 1979<br />
|-<br />
|<br />
[[#1980|1980]] 1981 1982 1983 1984 [[#1985|1985]] [[#1986|1986]] [[#1987|1987]] 1988 1989<br />
|-<br />
|<br />
[[#1990|1990]] 1991 [[#1992|1992]] [[#1993|1993]] [[#1994|1994]] [[#1995|1995]] [[#1996|1996]] [[#1997|1997]] [[#1998|1998]] [[#1999|1999]]<br />
|-<br />
|<br />
[[#2000|2000]] [[#2001|2001]] [[#2002|2002]] [[#2003|2003]] [[#2004|2004]] [[#2005|2005]] [[#2006|2006]] [[#2007|2007]]<br />
|}<br />
[[#Related topics|Related topics]]<br />
__NOTOC__<br />
__NOEDITSECTION__<br />
|}<br />
== The games ==<br />
<br />
=== 1974 ===<br />
* [[DnD]]<br />
<br />
=== 1975 ===<br />
* [[Dungeon]]<br />
<br />
=== 1980 ===<br />
* [[Rogue]]<br />
<br />
=== 1983 ===<br />
* [[Moria]]<br />
<br />
=== 1985 ===<br />
* [[Hack]]<br />
<br />
=== 1986 ===<br />
* [[Larn]]<br />
<br />
=== 1987 ===<br />
* [[NetHack]]<br />
* [[Omega]]<br />
<br />
=== 1990 ===<br />
* [[Angband]]<br />
* [[BOSS]]<br />
<br />
=== 1992 ===<br />
* [[Crossfire]]<br />
<br />
=== 1993 ===<br />
* [[Dungeon Hack]]<br />
<br />
=== 1994 ===<br />
* [[ADOM]] (Ancient Domains of Mystery)<br />
* [[Alphaman]]<br />
* [[Ragnarok]]<br />
* [[Zangband]]<br />
<br />
=== 1995 ===<br />
* [[Alphaman]]<br />
* [[Linley's Dungeon Crawl]]<br />
<br />
=== 1996 ===<br />
* [[Diablo]] (heavily influenced by the Roguelike genre)<br />
* [[The Minstrel's Song]]<br />
<br />
=== 1997 ===<br />
* [[Mangband]]<br />
* [[UnAngband]]<br />
<br />
=== 1998 ===<br />
* [[The Legend of Saladir]]<br />
* [[ToME]] (Troubles of Middle Earth)<br />
* [[UnderDark]]<br />
<br />
=== 1999 ===<br />
* [[Kharne]]<br />
* [[Star Rogue]]<br />
* [[Tyrant]]<br />
<br />
=== 2000 ===<br />
* [[Diablo II]]<br />
* [[Domain Country]]<br />
* [[Egoboo]]<br />
* [[Slaves to Armok]]<br />
<br />
=== 2001 ===<br />
* [[Avanor]]<br />
* [[DeadCold]]<br />
* [[IVAN]]<br />
<br />
=== 2002 ===<br />
* [[AburaTan]]<br />
* [[GearHead]]<br />
* [[Warp Rogue]]<br />
* [[Xenocide]]<br />
<br />
=== 2003 ===<br />
* [[Dungeon Monkey]]<br />
* [[POWDER]]<br />
<br />
=== 2004 ===<br />
* [[DoomRL]]<br />
<br />
=== 2005 ===<br />
* [[ANK]]<br />
* [[CastlevaniaRL]]<br />
* [[DiabloRL]]<br />
* [[You Only Live Once]]<br />
* [[Z-Day]]<br />
<br />
=== 2006 ===<br />
* [[Berserk!]]<br />
* [[Bone to be Wild]]<br />
* [[CryptRL]]<br />
* [[Frozen Depths]]<br />
* [[LambdaRogue]]<br />
* [[Letter Hunt]]<br />
* [[Magic Monsters]]<br />
* [[MetroidRL]]<br />
* [[Mt. Drash: the Roguelike]]<br />
* [[PrinceVSZombies]]<br />
* [[Slaves to Armok II: Dwarf Fortress]]<br />
* [[Subterrane]]<br />
<br />
=== 2007 ===<br />
* [[AliensRL]]<br />
* [[Artisan]]<br />
* [[Beggar]]<br />
* [[Cracks and Crevices]]<br />
* [[Lair of the Demon Ape]]<br />
* [[Neon]]<br />
* [[Portralis]]<br />
* [[Save Scummer]]<br />
* [[SewerJacks]]<br />
* [[Tower]]<br />
* [[Incursion]]<br />
* [[War of Wizards]]<br />
* [[ZeldaRL]]<br />
* [[Zomband]]<br />
<br />
=== 2008 ===<br />
* [[CryptRover]]<br />
* [[Fatherhood]]<br />
<br />
== Related topics ==<br />
* [[Categories]]</div>Stuhttp://roguebasin.com/index.php?title=List_of_Roguelikes_by_Theme&diff=13294List of Roguelikes by Theme2008-07-04T01:22:05Z<p>Stu: Added CnC to fantasy list</p>
<hr />
<div>=== Fantasy (rather pure) ===<br />
* [[ADOM]] (Ancient Domains of Mystery)<br />
* [[Angband]] (Tolkien)<br />
* [[Artisan]]<br />
* [[Avanor]]<br />
* [[Berserk!]]<br />
* [[Bone to be Wild]]<br />
* [[CalcRogue]]<br />
* [[Castle of the Winds]] (Norse mythology)<br />
* [[CastlevaniaRL]] (Gothic)<br />
* [[Cracks and Crevices]]<br />
* [[Crawl]]<br />
* [[Diablo]]<br />
* [[DiabloRL]]<br />
* [[DnD]]<br />
* [[Dungeon Crawl]]<br />
* [[Dungeon Monkey]]<br />
* [[Dweller]]<br />
* [[FAAngband]] (Tolkien, 1st Age)<br />
* [[FATE]] (commercial, roguelikeness questionable)<br />
* [[Frozen Depths]]<br />
* [[GenRogue]]<br />
* [[GUILD]]<br />
* [[Gumband]] (Michael Moorcock's Multiverse)<br />
* [[Incursion]]<br />
* [[JADE]]<br />
* [[Larn]]<br />
* [[Lair of the Demon Ape]]<br />
* [[land of cigo]]<br />
* [[MAngband]] (Tolkien)<br />
* [[Moria]] (Tolkien)<br />
* [[Mt. Drash: the Roguelike]] (Ultima)<br />
* [[POWDER]]<br />
* [[QuickQuest]]<br />
* [[Ragnarok]] (Norse mythology)<br />
* [[Rogue]]<br />
* [[SCOURGE]]<br />
* [[Slaves to Armok II: Dwarf Fortress]]<br />
* [[The Legend of Saladir]]<br />
* [[Subterrane]]<br />
* [[ToME]] (Trouble of Middle Earth, Tolkien)<br />
* [[Umbrarum Regnum]]<br />
* [[UnAngband]] (Tolkien, 3rd Age)<br />
* [[UnderDark]]<br />
* [[Utumno]]<br />
* [[You Only Live Once]]<br />
* [[Warlock's Mountain]]<br />
* [[Zangband]] (Zelazny)<br />
<br />
=== Fantasy (with elements from other themes) ===<br />
* [[Falcon's Eye]]<br />
* [[IVAN]] (Iter Vehemens ad Necem)<br />
* [[NetHack]]<br />
* [[Omega]]<br />
* [[SLASH'EM]]<br />
* [[CryptRL]]<br />
<br />
=== Science fiction ===<br />
* [[3059]]<br />
* [[Adeo]]<br />
* [[Alphaman]] (post-apocalyptic)<br />
* [[Boss]]<br />
* [[DeadCold]]<br />
* [[Decker]] (cyberpunk)<br />
* [[DoomRL]]<br />
* [[GearHead]] (mecha)<br />
* [[LambdaRogue]] (cyberpunk-post-apocalyptic)<br />
* [[Real World]] (post-apocalyptic)<br />
* [[Shade]] (cyberpunk)<br />
* [[Star Rogue]]<br />
* [[SteamBand]] (Victorian/steampunk/pulp)<br />
* [[Warp Rogue]] (gothic science fantasy)<br />
* [[Xenocide]]<br />
* [[ZapM]]<br />
* [[JauntTrooper series]]<br />
<br />
=== Historical ===<br />
* [[UnReal World]] (Finnish setting)<br />
<br />
=== Arcade ===<br />
* [[Bomberogue]]<br />
* [[CryptRover]]<br />
* [[Letter Hunt]]<br />
<br />
=== Generic Engines ===<br />
* [[Carceri]]<br />
* [[H-World]]<br />
* [[Neon]] roguelike engine<br />
* [[QHack]]<br />
* [[T-Engine]]<br />
<br />
=== Yet unclassified ===<br />
* [[Abura Tan]]<br />
* [[ANK]]<br />
* [[Beyond]]<br />
* [[Caves of Golorp]]<br />
* [[Crossfire]]<br />
* [[Cryptic Light]]<br />
* [[Domain Country]]<br />
* [[Dragon]]<br />
* [[Dungeon Hack]]<br />
* [[Dungeon]]<br />
* [[DungeonDoom]]<br />
* [[Egoboo]]<br />
* [[Guardian Angel]]<br />
* [[Hack]]<br />
* [[Hengband]]<br />
* [[Heroic Adventure!]]<br />
* [[iRogue]]<br />
* [[JRR]]<br />
* [[Kaduria]]<br />
* [[Kharne]]<br />
* [[Lost Labyrinth]]<br />
* [[MazeCrawl]]<br />
* [[Necrophobia]]<br />
* [[Netchaos]]<br />
* [[Papaki]]<br />
* [[PrinceVSZombies]]<br />
* [[Rolf]]<br />
* [[Slaves to Armok]]<br />
* [[Sword of Fargoal]]<br />
* [[The Minstrel's Song]]<br />
* [[The Woods of Torbin]]<br />
* [[Tyrant]]<br />
* [[Valengard]]<br />
* [[Wa]]<br />
* [[World of Darkness RogueLike]]<br />
* [[Z-Day]]<br />
* [[Zomband]]</div>Stuhttp://roguebasin.com/index.php?title=User_talk:Dz012220&diff=13193User talk:Dz0122202008-06-13T14:01:38Z<p>Stu: despam. Someone block this user.</p>
<hr />
<div></div>Stuhttp://roguebasin.com/index.php?title=User_talk:Fdfwfdg&diff=13179User talk:Fdfwfdg2008-06-10T15:36:15Z<p>Stu: despam</p>
<hr />
<div></div>Stuhttp://roguebasin.com/index.php?title=News&diff=12966News2008-05-16T12:21:22Z<p>Stu: Added the two notices I removed from the community talk page</p>
<hr />
<div>== 15 May 2008 ==<br />
* [[RogueLite]] 0.7 [http://citadel-studios.com/downloads/RogueLitev0_7.zip released]<br />
* [[Goblinhack]] 1.13 [https://sourceforge.net/project/showfiles.php?group_id=175454 released]<br />
<br />
== 13 May 2008 ==<br />
* [[GearHead2]] 0.502 [http://www.gearheadrpg.com/ released]<br />
<br />
== 10 May 2008 ==<br />
* [[LambdaRogue]] 0.3.0.1 (gamma 1) [http://donick.net/lr/dl-showentry.php?n=4 released]<br />
<br />
== 8 May 2008 ==<br />
* [[UnReal World]] 3.10-1 [http://www.jmp.fi/~smaarane/urw.html released]<br />
<br />
== 6 May 2008 ==<br />
* [[LambdaRogue]] 0.3 (gamma 1) [http://donick.net/lr/dl-showentry.php?n=4 released]<br />
<br />
== 5 May 2008 ==<br />
* [[Incursion]] 0.6.8A [http://www.incursion-roguelike.org/download.html released]<br />
<br />
== 1 May 2008 ==<br />
* [[Warlock's Mountain]] 0.3.2a [http://members.dodo.com.au/~savre/DemiseRL/ released]<br />
<br />
== 29 April 2008 ==<br />
* [[DoomRL]] 0.9.8.10 [http://doom.chaosforge.org/index.php?module=downloads released]<br />
* [[LambdaRogue]] 0.2 (beta 7) [http://sourceforge.net/projects/lambdarogue/ released]<br />
* [[Legerdemain]] 0.9.6 [http://roguelikefiction.com/?page_id=6 released]<br />
<br />
== 23 April 2008 ==<br />
* [[First Age Angband]] v0.3.4 [http://angband.oook.cz/faangband/ released]<br />
<br />
== 22 April 2008 ==<br />
* [[UnReal World]] 3.10 [http://www.jmp.fi/~smaarane/urw.html released]<br />
<br />
== 20 April 2008 ==<br />
* [[Unangband]] 0.6.2-gold [http://unangband.blogspot.com/2008/04/unangband-062-gold-released.html released]<br />
<br />
== 24 March 2008 ==<br />
* [[Deep]] 2.21e [http://www.deep.homepage.t-online.de/ released]<br />
<br />
== 21 March 2008 ==<br />
* [[Mines of Elderlore]] 1.0 beta 4 [http://landsof.elderlore.com/?q=node/81 released]<br />
<br />
== 20 March 2008 ==<br />
* [[UnAngband]] 0.6.2 beta 2 [http://unangband.blogspot.com/2008/03/unangband-062-beta-2-has-been-released.html released]<br />
<br />
== 18 March 2008 ==<br />
* [[GearHead2]] 0.501 [http://gearhead.roguelikedevelopment.org/ released]<br />
<br />
== 16 March 2008 ==<br />
* [[Numbers]] 7DRL released<br />
<br />
== 15 March 2008 ==<br />
* [[TrapRogue]] 7DRL released<br />
<br />
== 10 March 2008 ==<br />
* [[SewerJacks]] 0.8.6d [http://sewerjacks.sourceforge.net/ released]<br />
* [[GearHead2]] 0.500 [http://gearhead.roguelikedevelopment.org/ released]<br />
<br />
== 5 March 2008 ==<br />
* [[First Age Angband]] v0.3.3 [http://angband.oook.cz/faangband/ released]<br />
<br />
== 3 March 2008 ==<br />
* [[Incursion]] 0.6.5B [http://www.incursion-roguelike.org released]<br />
* [[Legerdemain]] 0.9.5 [http://roguelikefiction.com/?page_id=6 released]<br />
<br />
== 26 February 2008 ==<br />
* [[First Age Angband]] v0.3.2 [http://angband.oook.cz/faangband/ released]<br />
<br />
== 24 February 2008 ==<br />
* [[Caverns of Underkeep]] Updated Beta [http://www.tinyfrogsoftware.com/cavernsbeta/ released]<br />
* [[Dwarf Fortress]] 0.27.176.38c [http://www.bay12games.com/dwarves released].<br />
<br />
== 18 February 2008 ==<br />
* [[Cracks and Crevices]] v0.4 [http://www.mega-tokyo.com/blog/index.php/site/cracks_and_crevices_release_04/ released]<br />
<br />
== 8 February 2008 ==<br />
* [[Labyrinth of Reptoran]] v0.2.8 [http://reptoran.rogueforge.net/ released]<br />
<br />
<div style="text-align:right"><br />
&nbsp;<br />
''See also: [[Old news]]''<br />
</div></div>Stuhttp://roguebasin.com/index.php?title=RogueBasin_talk:Community_Portal&diff=12965RogueBasin talk:Community Portal2008-05-16T12:21:01Z<p>Stu: </p>
<hr />
<div>{{talkpagetool}}<br />
<br />
<table class="infobox" style="float:right;clear:right; width: 11em; border: 1px solid #93BACB; background:#E0E7EF;font-size:95%; margin:1em; line-height:1.4em;"><br />
<tr><br />
<th style="background:#C2D8EF; padding:.4em; margin:1em; font-size:105%">Archives</th><br />
</tr><br />
<tr><br />
<td><br />
* [[/Archive 1|1]]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Game Announcements ==<br />
If you have a new game/version/release to announce to the world, Make an edit to the [[News]] page, and please follow the existing format. If you want to generate discussion and receive feedback and comments, make sure to head over to [http://roguetemple.com RogueTemple] and use their forums, as well as [[rgrd]]. [[User:Stu|Stu]] 14:21, 16 May 2008 (CEST)<br />
<br />
<br />
<br />
== Spambots ==<br />
<br />
There was a small spambot attack recently, dunno how they overrid the spam protection (what is the current spam protection)? I had no luck blocking them via the sysop special pages. Is there any way to delete user accounts?<br />
<br />
--[[User:Slash|Slash]] 01:08, 12 Apr 2007 (CEST)<br />
<br />
I think it may be useful to update MediaWiki software to the latest version. The one that's currently installed is so old, the mind boggles. The current version has captchas and other stuff, and it's much easier to revert vandalism. [[User:Grue|Grue]] 10:23, 12 Apr 2007 (CEST)<br />
<br />
IIRC Bj????rn set up the latest version when the server translation was performed? Also, this is plain vandalism, not even spam (deleting '+' and everything after a '&', what use would that have?<br />
--[[User:Slash|Slash]] 17:19, 12 Apr 2007 (CEST)<br />
:It can't be the latest version. For example when you look at the diff between two revisions, there's no link to edit the revision. This feature was in Wikipedia since I joined it, probably, and that was very long time ago. So, to revert vandalism one has to click three times instead of two, pretty annoying. I don't know, maybe it's configured incorrectly, but it definitely looks very outdated. [[User:Grue|Grue]] 10:52, 13 Apr 2007 (CEST)<br />
<br />
:It's definitely an old version, the [[Special:Version]] page shows as using version 1.3.9 ''(The 1.3.x line was last updated in November 2005)''. The newest release is 1.10.0 although most modern versions of MediaWiki require PHP5 though ''(since version 1.7)''. The latest version that still supports PHP4 is 1.6.10 available [http://www.mediawiki.org/wiki/Download here]. 1.6.10 was released on 20th February 2007. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
::THe Wiki is currently running MediaWiki 1.6.10. Hopefully we won't see any more spam attacks. -- Bjorn 09:50 3 Jul 2007<br />
<br />
There was another spammer, although it could be a person doing it, rather than a bot. It was [[User:Yaxiaexx099|this account]] doing it, and [http://roguebasin.roguelikedevelopment.org/index.php?title=Dalhxf&oldid=12449 this] was was what he did.<br />
<br />
== Remove the news? ==<br />
<br />
I was wondering if it is a good idea to keep the news box on the main page. My thoughts:<br />
<br />
* We have three main news sites: RGRA, Temple of the Roguelike and the RogueBasin. That's a lot of duplicating.<br />
* I feel that the RGRA and Temple of the Roguelike are way more suited to displaying news. I see the RogueBasin as a resource of articles, guides and information about roguelikes.<br />
* The news box could be used to display other things. Such as new articles here, articles that we would like to improve and featured roguelikes.<br />
<br />
What do people think? [[User:Icey|Icey]] 14:45, 27 May 2007 (CEST)<br />
<br />
: I agree, both RGRA and TotR seem better places for sources of news (But saying that I do have TotR as a Live Bookmark in Firefox) although I have no problem having a smaller box with the last couple of items. I'd sooner see the space taken with new articles, articles for improvement and featured roguelikes as suggested. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
:RGRA and Temple are moderated, which means the news don't appear ASAP. For example both of these mediums haven't covered The Sewer Massacre 1.0 yet (and not for my lack of trying ;)). The main principle behind news is that they are new. A day later is already old news. Imagine if JADE is released, and the news don't appear anywhere for a day. Wiki solves this problem perfectly. [[User:Grue|Grue]] 23:09, 28 May 2007 (CEST)<br />
<br />
:::::::That's one of the cons of a moderated media :) also, RGRA is moderated, but moderation commonly takes less than 1 hour in my Experience --[[User:Slash|Slash]] 16:35, 4 Jun 2007 (CEST)<br />
<br />
::That is a good point, I hadn't really thought about the moderation aspect. Perhaps having a slightly different main page design would accommodate having sections for articles and featured items? [[User:Pucechan|Pucechan]] 18:36, 29 May 2007 (CEST)<br />
<br />
:::I've made a quick mockup of an idea, so colours and content (especially the top-right links) are just placeholders, this uses the fairly "traditional" block wiki format. The content is just copy-pasted but you get the idea. The news would be for each month (probably in a smaller font). See it here [[User:Pucechan/MainIdea]]. What do people think?<br />
<br />
::::I like it a lot. I've expanded the idea a bit: [[User:Icey/MainIdea]]. It's more wikipedia-like, has a little tag line so people know what the RogueBasin is, added the links to the top, added a featured article section, added a bit of colour and changes a few other things. [[User:Icey|Icey]] 02:12, 2 Jun 2007 (CEST)<br />
<br />
:::::I like the changes you've made, the little splash of colour helps. I prefer your simple set of links rather than my bundle (I didn't really sort them in any way but your way is much nicer). I really like it. [[User:Pucechan|Pucechan]] 11:19, 2 Jun 2007 (CEST)<br />
<br />
::::::Thanks Pucechan. Let's wait a few days to see if anyone else would like to improve/approve it and then decide what to do from there. [[User:Icey|Icey]] 13:19, 3 Jun 2007 (CEST)<br />
<br />
:::::::I like it a lot too... I have always thought roguebasin needs a better front page... perhaps changing "Current news" for "News for June 2007"? <br />
:::::::Also, it is pretty wordy, some images may help.. probably :P<br />
:::::::Thanks! --[[User:Slash|Slash]] 16:35, 4 Jun 2007 (CEST)<br />
<br />
:::::::: Images would be good, but uploading images is disabled :P A little cropped screenshot of a roguelike would be nice to go with the description. Like [http://www.reloaded.org/images/games/reviews/66/review07.png this] or [http://www.gamesetwatch.com/atplay/adom-8.gif this]. [[User:Icey|Icey]] 20:14, 7 Jun 2007 (CEST)<br />
<br />
::::::::: I have enabled uploads for a trial period. [[User:Bjorn|Bjorn]] 09:50, 3 Jul 2007 (CEST)<br />
<br />
== External community links ==<br />
<br />
One thing I think is missing from the main page is a list of external community links. The existing [[Roguelike_Links]] doesn't have [[Temple of the Roguelike]], [[@ Play]] and other current resources like forums for various roguelike games listed (and dare I say it [[Ascii Dreams]] ;) )<br />
<br />
Are people happy for me to tidy up the Links section, to include the above, a 'Press' section within Links for listing where external media have talked about roguelike games, and a Forums section within Links for listing the various game specific web forums such as [http://angband.oook.cz/forum the Angband forums], Angband variant web forums and others (Live Journal, other variants and so on)? I'd like to see more ways of people getting in touch with fellow roguelike players/developers listed somewhere convenient...<br />
<br />
: That's an excellent idea. Perhaps we could use [[Links]] as a comprehensive list and then do a cut down version for the main page?<br />
<br />
: Perhaps the Links page could have a Roguelike Blog section (or a name like that) for your site and others like [http://doryen.blogspot.com/] [http://kaduria.blogspot.com/]<br />
<br />
: [[User:Icey|Icey]] 18:52, 5 September 2007 (CEST)<br />
<br />
== All those guides! ==<br />
<br />
Where did all those good guides at http://www.roguelikedevelopment.org/ go? according to the news, the content has been moved to this wiki but I can't find any of those guides! me want's 'em badly!<br />
[[User:Solarnus|Solarnus]] 11:28, 16 January 2008 (CET)<br />
:Sorry, I meant of course that alot of guides are missing, as least most of the map algorithm stuff previously found on the old site is missing here at the wiki. Anyone got copies of those guides, please? [[User:Solarnus|Solarnus]] 14:28, 23 January 2008 (CET)<br />
::And you looked in the map section of [[Articles]]? All the ones I recall are there. Perhaps you can use the wayback machine to calculate which ones seem to be missing? [[User:Duerig|Duerig]] 17:12, 23 January 2008 (CET)<br />
:::lol, the wayback what..? No, realy, I know there's alot missing from the site. Some examples are the guides written by Mike Anderson (Dungeon-Building Algorithm, Fractal Landscapes) and Radomir "The Sheep" Dopieralski (Recursive LvL Generation) [[User:Solarnus|Solarnus]] 17:52, 23 January 2008 (CET)<br />
::::Look at this URL. It is from www.archive.org, the wayback machine for the Internet: http://web.archive.org/web/20060114055601/http://roguelikedevelopment.org/ but before you go adding all of the articles to the wiki, you should know that there was some effort to move them over, but only if the original authors could be found to give permission. So you should check with an admin here about what to do. [[User:Duerig|Duerig]] 08:50, 24 January 2008 (CET)<br />
:::::Oh crap, I thought I could just go and add what I managed to find, since it had already been released on the site o.0' Pardon me, I'm too quick sometimes, doing stuff without thinking first. <br /> But, IMHO, not moving over all that stuff just because the original author couldn't be found kinda buggers me, that's just wast of time and good knowledge, stupidlly forcing to "reinvent the wheel". And it buggers me even more, since obvisiouly (spelling?) it can still be found on the web thanks to that wayback machine you're talking about (thanks for that link btw, would've never thought of that). <br /> Thanks for telling me dude, I'll try slowing down/backing off and poke an admin about it before doing anything else.<br /> <br />Anyway, should the "previously missing" [[Dungeon-Building Algorithm]] article I dug up yesterday be removed, or just leave it for now and hope for the better? [[User:Solarnus|Solarnus]] 13:50, 24 January 2008 (CET)<br />
<br />
<br />
::::::Is there any chance of the articles being reposted on the original site until they can be ported here? They're only text documents, and a number of them were very good references. Most of the original files are not stored on wayback machine, so forn ow they are lost for good. [[User:lapoubelle|lapoubelle]] 30 April 2008<br />
<br />
I have spent most of today searching for and collecting all of the articles that were on the old system but not on roguebasin. I was able to recover all but two. Those two and links to the archives are at [[User:Duerig]]. That way they should be safe until we can decide how to handle them. If the admins have a problem with this, I'll host them on my own domain if I have to. Let me know if you can find information on either of the two remaining articles. [[User:Duerig|Duerig]] 21:53, 1 May 2008 (CEST)<br />
<br />
<br />
== THIS IS NOT A GAME ANNOUNCEMENT PAGE ==<br />
Don't post game announcements here, there are other pages for that. [[User:Stu|Stu]] (I forgot to sign my edit..)<br />
<br />
:Probably would have been a little nicer and a whole lot more helpful to give a link to the appropriate location and to not all-caps/scream the header, especially since the [[Help:Contents|Help]] section is ''completely'' blank (the most important part of any wiki that wants new contributors and knowledgeable editors), and the main Community Portal page just redirects straight here, making it totally useless as well to direct such notices to their appropriate location. Personally, I can't find a page that really matches what [[User:Caeonosphere|Caeonosphere]] appears to have been looking for. '''[[News]]''' seems to be the closest thing, but not really much of an announcement page for game developers so that they can get feedback. The site is a bit of a mess organizationally. Unfortunately, because of this, errant notices such as the one that you deleted are to be expected. [[User:Kiefer|Kiefer]] 13:44, 15 May 2008 (CEST)<br />
<br />
:: You seem to confuse the idea of a wiki vs a forum. This is not a place to post and get feedback and comments and criticisms. Thats what [[rec.games.roguelike.development]] or [http://roguetemple.com RogueTemple] is for. Game releases go on the [[News]] page, preferably linking to your game info page, but that is not required. RogueTemple also does game announcements, and takes comments in return on its front page and forums. [[User:Stu|Stu]] 14:54, 15 May 2008 (CEST)<br />
<br />
:::I think it's pretty clear that I'm not confusing anything. I didn't say that the announcement was correctly placed. In fact, I described it as an "errant notice." However, a Community Portal often ''does'' include a spot for the wiki's community to get together and discuss things that relate to the subject of the wiki. Sometimes that involves requests for feedback like the one you deleted. I'm guessing that Caeonosphere put the request in the most likely place he thought it should go, since (once again) there was no main Community Portal page to direct him.<br />
<br />
:::I think instead that it's pretty clear that my point was: '''You didn't treat the user with the respect that they deserved.''' You should have guided them in the right direction, instead of assuming that they should already know what to do. (But, once again, '''''how''''' should they know?) Instead of helping, you deleted their message, added a header that shouts at the user should they return, and then said that "there are other pages for that" without leaving even a clue as to what that might mean. And, apparently from what you just wrote in your reply, there '''aren't''' other pages for that here - the developer would have to go someplace else entirely. (A user can't even ask an admin for guidance or help, as there isn't a list of sysops posted on the Main Page from which to get help!)<br />
<br />
:::It's a matter of treating the users with respect, and helping them out instead of essentially saying "bugger off." [[User:Kiefer|Kiefer]] 07:35, 16 May 2008 (CEST)<br />
<br />
:::: I agree, I was an arse, and after looking around it really isn't very clear where to go or what to do. I tried to edit the help page but dont have rights to do so. I think the front page needs a revamp to make things clearer. It is too cluttered. I added a little blurb to the top of the community page that might help. I also added the two games I deleted to the News page. [[User:Stu|Stu]] 14:21, 16 May 2008 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=RogueBasin_talk:Community_Portal&diff=12949RogueBasin talk:Community Portal2008-05-15T12:54:46Z<p>Stu: </p>
<hr />
<div>{{talkpagetool}}<br />
<br />
<table class="infobox" style="float:right;clear:right; width: 11em; border: 1px solid #93BACB; background:#E0E7EF;font-size:95%; margin:1em; line-height:1.4em;"><br />
<tr><br />
<th style="background:#C2D8EF; padding:.4em; margin:1em; font-size:105%">Archives</th><br />
</tr><br />
<tr><br />
<td><br />
* [[/Archive 1|1]]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Spambots ==<br />
<br />
There was a small spambot attack recently, dunno how they overrid the spam protection (what is the current spam protection)? I had no luck blocking them via the sysop special pages. Is there any way to delete user accounts?<br />
<br />
--[[User:Slash|Slash]] 01:08, 12 Apr 2007 (CEST)<br />
<br />
I think it may be useful to update MediaWiki software to the latest version. The one that's currently installed is so old, the mind boggles. The current version has captchas and other stuff, and it's much easier to revert vandalism. [[User:Grue|Grue]] 10:23, 12 Apr 2007 (CEST)<br />
<br />
IIRC Bj????rn set up the latest version when the server translation was performed? Also, this is plain vandalism, not even spam (deleting '+' and everything after a '&', what use would that have?<br />
--[[User:Slash|Slash]] 17:19, 12 Apr 2007 (CEST)<br />
:It can't be the latest version. For example when you look at the diff between two revisions, there's no link to edit the revision. This feature was in Wikipedia since I joined it, probably, and that was very long time ago. So, to revert vandalism one has to click three times instead of two, pretty annoying. I don't know, maybe it's configured incorrectly, but it definitely looks very outdated. [[User:Grue|Grue]] 10:52, 13 Apr 2007 (CEST)<br />
<br />
:It's definitely an old version, the [[Special:Version]] page shows as using version 1.3.9 ''(The 1.3.x line was last updated in November 2005)''. The newest release is 1.10.0 although most modern versions of MediaWiki require PHP5 though ''(since version 1.7)''. The latest version that still supports PHP4 is 1.6.10 available [http://www.mediawiki.org/wiki/Download here]. 1.6.10 was released on 20th February 2007. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
::THe Wiki is currently running MediaWiki 1.6.10. Hopefully we won't see any more spam attacks. -- Bjorn 09:50 3 Jul 2007<br />
<br />
There was another spammer, although it could be a person doing it, rather than a bot. It was [[User:Yaxiaexx099|this account]] doing it, and [http://roguebasin.roguelikedevelopment.org/index.php?title=Dalhxf&oldid=12449 this] was was what he did.<br />
<br />
== Remove the news? ==<br />
<br />
I was wondering if it is a good idea to keep the news box on the main page. My thoughts:<br />
<br />
* We have three main news sites: RGRA, Temple of the Roguelike and the RogueBasin. That's a lot of duplicating.<br />
* I feel that the RGRA and Temple of the Roguelike are way more suited to displaying news. I see the RogueBasin as a resource of articles, guides and information about roguelikes.<br />
* The news box could be used to display other things. Such as new articles here, articles that we would like to improve and featured roguelikes.<br />
<br />
What do people think? [[User:Icey|Icey]] 14:45, 27 May 2007 (CEST)<br />
<br />
: I agree, both RGRA and TotR seem better places for sources of news (But saying that I do have TotR as a Live Bookmark in Firefox) although I have no problem having a smaller box with the last couple of items. I'd sooner see the space taken with new articles, articles for improvement and featured roguelikes as suggested. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
:RGRA and Temple are moderated, which means the news don't appear ASAP. For example both of these mediums haven't covered The Sewer Massacre 1.0 yet (and not for my lack of trying ;)). The main principle behind news is that they are new. A day later is already old news. Imagine if JADE is released, and the news don't appear anywhere for a day. Wiki solves this problem perfectly. [[User:Grue|Grue]] 23:09, 28 May 2007 (CEST)<br />
<br />
:::::::That's one of the cons of a moderated media :) also, RGRA is moderated, but moderation commonly takes less than 1 hour in my Experience --[[User:Slash|Slash]] 16:35, 4 Jun 2007 (CEST)<br />
<br />
::That is a good point, I hadn't really thought about the moderation aspect. Perhaps having a slightly different main page design would accommodate having sections for articles and featured items? [[User:Pucechan|Pucechan]] 18:36, 29 May 2007 (CEST)<br />
<br />
:::I've made a quick mockup of an idea, so colours and content (especially the top-right links) are just placeholders, this uses the fairly "traditional" block wiki format. The content is just copy-pasted but you get the idea. The news would be for each month (probably in a smaller font). See it here [[User:Pucechan/MainIdea]]. What do people think?<br />
<br />
::::I like it a lot. I've expanded the idea a bit: [[User:Icey/MainIdea]]. It's more wikipedia-like, has a little tag line so people know what the RogueBasin is, added the links to the top, added a featured article section, added a bit of colour and changes a few other things. [[User:Icey|Icey]] 02:12, 2 Jun 2007 (CEST)<br />
<br />
:::::I like the changes you've made, the little splash of colour helps. I prefer your simple set of links rather than my bundle (I didn't really sort them in any way but your way is much nicer). I really like it. [[User:Pucechan|Pucechan]] 11:19, 2 Jun 2007 (CEST)<br />
<br />
::::::Thanks Pucechan. Let's wait a few days to see if anyone else would like to improve/approve it and then decide what to do from there. [[User:Icey|Icey]] 13:19, 3 Jun 2007 (CEST)<br />
<br />
:::::::I like it a lot too... I have always thought roguebasin needs a better front page... perhaps changing "Current news" for "News for June 2007"? <br />
:::::::Also, it is pretty wordy, some images may help.. probably :P<br />
:::::::Thanks! --[[User:Slash|Slash]] 16:35, 4 Jun 2007 (CEST)<br />
<br />
:::::::: Images would be good, but uploading images is disabled :P A little cropped screenshot of a roguelike would be nice to go with the description. Like [http://www.reloaded.org/images/games/reviews/66/review07.png this] or [http://www.gamesetwatch.com/atplay/adom-8.gif this]. [[User:Icey|Icey]] 20:14, 7 Jun 2007 (CEST)<br />
<br />
::::::::: I have enabled uploads for a trial period. [[User:Bjorn|Bjorn]] 09:50, 3 Jul 2007 (CEST)<br />
<br />
== External community links ==<br />
<br />
One thing I think is missing from the main page is a list of external community links. The existing [[Roguelike_Links]] doesn't have [[Temple of the Roguelike]], [[@ Play]] and other current resources like forums for various roguelike games listed (and dare I say it [[Ascii Dreams]] ;) )<br />
<br />
Are people happy for me to tidy up the Links section, to include the above, a 'Press' section within Links for listing where external media have talked about roguelike games, and a Forums section within Links for listing the various game specific web forums such as [http://angband.oook.cz/forum the Angband forums], Angband variant web forums and others (Live Journal, other variants and so on)? I'd like to see more ways of people getting in touch with fellow roguelike players/developers listed somewhere convenient...<br />
<br />
: That's an excellent idea. Perhaps we could use [[Links]] as a comprehensive list and then do a cut down version for the main page?<br />
<br />
: Perhaps the Links page could have a Roguelike Blog section (or a name like that) for your site and others like [http://doryen.blogspot.com/] [http://kaduria.blogspot.com/]<br />
<br />
: [[User:Icey|Icey]] 18:52, 5 September 2007 (CEST)<br />
<br />
== All those guides! ==<br />
<br />
Where did all those good guides at http://www.roguelikedevelopment.org/ go? according to the news, the content has been moved to this wiki but I can't find any of those guides! me want's 'em badly!<br />
[[User:Solarnus|Solarnus]] 11:28, 16 January 2008 (CET)<br />
:Sorry, I meant of course that alot of guides are missing, as least most of the map algorithm stuff previously found on the old site is missing here at the wiki. Anyone got copies of those guides, please? [[User:Solarnus|Solarnus]] 14:28, 23 January 2008 (CET)<br />
::And you looked in the map section of [[Articles]]? All the ones I recall are there. Perhaps you can use the wayback machine to calculate which ones seem to be missing? [[User:Duerig|Duerig]] 17:12, 23 January 2008 (CET)<br />
:::lol, the wayback what..? No, realy, I know there's alot missing from the site. Some examples are the guides written by Mike Anderson (Dungeon-Building Algorithm, Fractal Landscapes) and Radomir "The Sheep" Dopieralski (Recursive LvL Generation) [[User:Solarnus|Solarnus]] 17:52, 23 January 2008 (CET)<br />
::::Look at this URL. It is from www.archive.org, the wayback machine for the Internet: http://web.archive.org/web/20060114055601/http://roguelikedevelopment.org/ but before you go adding all of the articles to the wiki, you should know that there was some effort to move them over, but only if the original authors could be found to give permission. So you should check with an admin here about what to do. [[User:Duerig|Duerig]] 08:50, 24 January 2008 (CET)<br />
:::::Oh crap, I thought I could just go and add what I managed to find, since it had already been released on the site o.0' Pardon me, I'm too quick sometimes, doing stuff without thinking first. <br /> But, IMHO, not moving over all that stuff just because the original author couldn't be found kinda buggers me, that's just wast of time and good knowledge, stupidlly forcing to "reinvent the wheel". And it buggers me even more, since obvisiouly (spelling?) it can still be found on the web thanks to that wayback machine you're talking about (thanks for that link btw, would've never thought of that). <br /> Thanks for telling me dude, I'll try slowing down/backing off and poke an admin about it before doing anything else.<br /> <br />Anyway, should the "previously missing" [[Dungeon-Building Algorithm]] article I dug up yesterday be removed, or just leave it for now and hope for the better? [[User:Solarnus|Solarnus]] 13:50, 24 January 2008 (CET)<br />
<br />
<br />
::::::Is there any chance of the articles being reposted on the original site until they can be ported here? They're only text documents, and a number of them were very good references. Most of the original files are not stored on wayback machine, so forn ow they are lost for good. [[User:lapoubelle|lapoubelle]] 30 April 2008<br />
<br />
I have spent most of today searching for and collecting all of the articles that were on the old system but not on roguebasin. I was able to recover all but two. Those two and links to the archives are at [[User:Duerig]]. That way they should be safe until we can decide how to handle them. If the admins have a problem with this, I'll host them on my own domain if I have to. Let me know if you can find information on either of the two remaining articles. [[User:Duerig|Duerig]] 21:53, 1 May 2008 (CEST)<br />
<br />
<br />
== THIS IS NOT A GAME ANNOUNCEMENT PAGE ==<br />
Don't post game announcements here, there are other pages for that. [[User:Stu|Stu]] (I forgot to sign my edit..)<br />
<br />
:Probably would have been a little nicer and a whole lot more helpful to give a link to the appropriate location and to not all-caps/scream the header, especially since the [[Help:Contents|Help]] section is ''completely'' blank (the most important part of any wiki that wants new contributors and knowledgeable editors), and the main Community Portal page just redirects straight here, making it totally useless as well to direct such notices to their appropriate location. Personally, I can't find a page that really matches what [[User:Caeonosphere|Caeonosphere]] appears to have been looking for. '''[[News]]''' seems to be the closest thing, but not really much of an announcement page for game developers so that they can get feedback. The site is a bit of a mess organizationally. Unfortunately, because of this, errant notices such as the one that you deleted are to be expected. [[User:Kiefer|Kiefer]] 13:44, 15 May 2008 (CEST)<br />
<br />
:: You seem to confuse the idea of a wiki vs a forum. This is not a place to post and get feedback and comments and criticisms. Thats what [[rec.games.roguelike.development]] or [http://roguetemple.com RogueTemple] is for. Game releases go on the [[News]] page, preferably linking to your game info page, but that is not required. RogueTemple also does game announcements, and takes comments in return on its front page and forums. [[User:Stu|Stu]] 14:54, 15 May 2008 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=RogueBasin_talk:Community_Portal&diff=12933RogueBasin talk:Community Portal2008-05-13T12:48:31Z<p>Stu: </p>
<hr />
<div>{{talkpagetool}}<br />
<br />
<table class="infobox" style="float:right;clear:right; width: 11em; border: 1px solid #93BACB; background:#E0E7EF;font-size:95%; margin:1em; line-height:1.4em;"><br />
<tr><br />
<th style="background:#C2D8EF; padding:.4em; margin:1em; font-size:105%">Archives</th><br />
</tr><br />
<tr><br />
<td><br />
* [[/Archive 1|1]]<br />
</td><br />
</tr><br />
</table><br />
<br />
== Spambots ==<br />
<br />
There was a small spambot attack recently, dunno how they overrid the spam protection (what is the current spam protection)? I had no luck blocking them via the sysop special pages. Is there any way to delete user accounts?<br />
<br />
--[[User:Slash|Slash]] 01:08, 12 Apr 2007 (CEST)<br />
<br />
I think it may be useful to update MediaWiki software to the latest version. The one that's currently installed is so old, the mind boggles. The current version has captchas and other stuff, and it's much easier to revert vandalism. [[User:Grue|Grue]] 10:23, 12 Apr 2007 (CEST)<br />
<br />
IIRC Bj????rn set up the latest version when the server translation was performed? Also, this is plain vandalism, not even spam (deleting '+' and everything after a '&', what use would that have?<br />
--[[User:Slash|Slash]] 17:19, 12 Apr 2007 (CEST)<br />
:It can't be the latest version. For example when you look at the diff between two revisions, there's no link to edit the revision. This feature was in Wikipedia since I joined it, probably, and that was very long time ago. So, to revert vandalism one has to click three times instead of two, pretty annoying. I don't know, maybe it's configured incorrectly, but it definitely looks very outdated. [[User:Grue|Grue]] 10:52, 13 Apr 2007 (CEST)<br />
<br />
:It's definitely an old version, the [[Special:Version]] page shows as using version 1.3.9 ''(The 1.3.x line was last updated in November 2005)''. The newest release is 1.10.0 although most modern versions of MediaWiki require PHP5 though ''(since version 1.7)''. The latest version that still supports PHP4 is 1.6.10 available [http://www.mediawiki.org/wiki/Download here]. 1.6.10 was released on 20th February 2007. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
::THe Wiki is currently running MediaWiki 1.6.10. Hopefully we won't see any more spam attacks. -- Bjorn 09:50 3 Jul 2007<br />
<br />
There was another spammer, although it could be a person doing it, rather than a bot. It was [[User:Yaxiaexx099|this account]] doing it, and [http://roguebasin.roguelikedevelopment.org/index.php?title=Dalhxf&oldid=12449 this] was was what he did.<br />
<br />
== Remove the news? ==<br />
<br />
I was wondering if it is a good idea to keep the news box on the main page. My thoughts:<br />
<br />
* We have three main news sites: RGRA, Temple of the Roguelike and the RogueBasin. That's a lot of duplicating.<br />
* I feel that the RGRA and Temple of the Roguelike are way more suited to displaying news. I see the RogueBasin as a resource of articles, guides and information about roguelikes.<br />
* The news box could be used to display other things. Such as new articles here, articles that we would like to improve and featured roguelikes.<br />
<br />
What do people think? [[User:Icey|Icey]] 14:45, 27 May 2007 (CEST)<br />
<br />
: I agree, both RGRA and TotR seem better places for sources of news (But saying that I do have TotR as a Live Bookmark in Firefox) although I have no problem having a smaller box with the last couple of items. I'd sooner see the space taken with new articles, articles for improvement and featured roguelikes as suggested. -- [[User:Pucechan|Pucechan]] 01:18, 28 May 2007 (CEST)<br />
<br />
:RGRA and Temple are moderated, which means the news don't appear ASAP. For example both of these mediums haven't covered The Sewer Massacre 1.0 yet (and not for my lack of trying ;)). The main principle behind news is that they are new. A day later is already old news. Imagine if JADE is released, and the news don't appear anywhere for a day. Wiki solves this problem perfectly. [[User:Grue|Grue]] 23:09, 28 May 2007 (CEST)<br />
<br />
:::::::That's one of the cons of a moderated media :) also, RGRA is moderated, but moderation commonly takes less than 1 hour in my Experience --[[User:Slash|Slash]] 16:35, 4 Jun 2007 (CEST)<br />
<br />
::That is a good point, I hadn't really thought about the moderation aspect. Perhaps having a slightly different main page design would accommodate having sections for articles and featured items? [[User:Pucechan|Pucechan]] 18:36, 29 May 2007 (CEST)<br />
<br />
:::I've made a quick mockup of an idea, so colours and content (especially the top-right links) are just placeholders, this uses the fairly "traditional" block wiki format. The content is just copy-pasted but you get the idea. The news would be for each month (probably in a smaller font). See it here [[User:Pucechan/MainIdea]]. What do people think?<br />
<br />
::::I like it a lot. I've expanded the idea a bit: [[User:Icey/MainIdea]]. It's more wikipedia-like, has a little tag line so people know what the RogueBasin is, added the links to the top, added a featured article section, added a bit of colour and changes a few other things. [[User:Icey|Icey]] 02:12, 2 Jun 2007 (CEST)<br />
<br />
:::::I like the changes you've made, the little splash of colour helps. I prefer your simple set of links rather than my bundle (I didn't really sort them in any way but your way is much nicer). I really like it. [[User:Pucechan|Pucechan]] 11:19, 2 Jun 2007 (CEST)<br />
<br />
::::::Thanks Pucechan. Let's wait a few days to see if anyone else would like to improve/approve it and then decide what to do from there. [[User:Icey|Icey]] 13:19, 3 Jun 2007 (CEST)<br />
<br />
:::::::I like it a lot too... I have always thought roguebasin needs a better front page... perhaps changing "Current news" for "News for June 2007"? <br />
:::::::Also, it is pretty wordy, some images may help.. probably :P<br />
:::::::Thanks! --[[User:Slash|Slash]] 16:35, 4 Jun 2007 (CEST)<br />
<br />
:::::::: Images would be good, but uploading images is disabled :P A little cropped screenshot of a roguelike would be nice to go with the description. Like [http://www.reloaded.org/images/games/reviews/66/review07.png this] or [http://www.gamesetwatch.com/atplay/adom-8.gif this]. [[User:Icey|Icey]] 20:14, 7 Jun 2007 (CEST)<br />
<br />
::::::::: I have enabled uploads for a trial period. [[User:Bjorn|Bjorn]] 09:50, 3 Jul 2007 (CEST)<br />
<br />
== External community links ==<br />
<br />
One thing I think is missing from the main page is a list of external community links. The existing [[Roguelike_Links]] doesn't have [[Temple of the Roguelike]], [[@ Play]] and other current resources like forums for various roguelike games listed (and dare I say it [[Ascii Dreams]] ;) )<br />
<br />
Are people happy for me to tidy up the Links section, to include the above, a 'Press' section within Links for listing where external media have talked about roguelike games, and a Forums section within Links for listing the various game specific web forums such as [http://angband.oook.cz/forum the Angband forums], Angband variant web forums and others (Live Journal, other variants and so on)? I'd like to see more ways of people getting in touch with fellow roguelike players/developers listed somewhere convenient...<br />
<br />
: That's an excellent idea. Perhaps we could use [[Links]] as a comprehensive list and then do a cut down version for the main page?<br />
<br />
: Perhaps the Links page could have a Roguelike Blog section (or a name like that) for your site and others like [http://doryen.blogspot.com/] [http://kaduria.blogspot.com/]<br />
<br />
: [[User:Icey|Icey]] 18:52, 5 September 2007 (CEST)<br />
<br />
== All those guides! ==<br />
<br />
Where did all those good guides at http://www.roguelikedevelopment.org/ go? according to the news, the content has been moved to this wiki but I can't find any of those guides! me want's 'em badly!<br />
[[User:Solarnus|Solarnus]] 11:28, 16 January 2008 (CET)<br />
:Sorry, I meant of course that alot of guides are missing, as least most of the map algorithm stuff previously found on the old site is missing here at the wiki. Anyone got copies of those guides, please? [[User:Solarnus|Solarnus]] 14:28, 23 January 2008 (CET)<br />
::And you looked in the map section of [[Articles]]? All the ones I recall are there. Perhaps you can use the wayback machine to calculate which ones seem to be missing? [[User:Duerig|Duerig]] 17:12, 23 January 2008 (CET)<br />
:::lol, the wayback what..? No, realy, I know there's alot missing from the site. Some examples are the guides written by Mike Anderson (Dungeon-Building Algorithm, Fractal Landscapes) and Radomir "The Sheep" Dopieralski (Recursive LvL Generation) [[User:Solarnus|Solarnus]] 17:52, 23 January 2008 (CET)<br />
::::Look at this URL. It is from www.archive.org, the wayback machine for the Internet: http://web.archive.org/web/20060114055601/http://roguelikedevelopment.org/ but before you go adding all of the articles to the wiki, you should know that there was some effort to move them over, but only if the original authors could be found to give permission. So you should check with an admin here about what to do. [[User:Duerig|Duerig]] 08:50, 24 January 2008 (CET)<br />
:::::Oh crap, I thought I could just go and add what I managed to find, since it had already been released on the site o.0' Pardon me, I'm too quick sometimes, doing stuff without thinking first. <br /> But, IMHO, not moving over all that stuff just because the original author couldn't be found kinda buggers me, that's just wast of time and good knowledge, stupidlly forcing to "reinvent the wheel". And it buggers me even more, since obvisiouly (spelling?) it can still be found on the web thanks to that wayback machine you're talking about (thanks for that link btw, would've never thought of that). <br /> Thanks for telling me dude, I'll try slowing down/backing off and poke an admin about it before doing anything else.<br /> <br />Anyway, should the "previously missing" [[Dungeon-Building Algorithm]] article I dug up yesterday be removed, or just leave it for now and hope for the better? [[User:Solarnus|Solarnus]] 13:50, 24 January 2008 (CET)<br />
<br />
<br />
::::::Is there any chance of the articles being reposted on the original site until they can be ported here? They're only text documents, and a number of them were very good references. Most of the original files are not stored on wayback machine, so forn ow they are lost for good. [[User:lapoubelle|lapoubelle]] 30 April 2008<br />
<br />
I have spent most of today searching for and collecting all of the articles that were on the old system but not on roguebasin. I was able to recover all but two. Those two and links to the archives are at [[User:Duerig]]. That way they should be safe until we can decide how to handle them. If the admins have a problem with this, I'll host them on my own domain if I have to. Let me know if you can find information on either of the two remaining articles. [[User:Duerig|Duerig]] 21:53, 1 May 2008 (CEST)<br />
<br />
<br />
== THIS IS NOT A GAME ANNOUNCEMENT PAGE ==<br />
Don't post game announcements here, there are other pages for that.</div>Stuhttp://roguebasin.com/index.php?title=User_talk:Duerig&diff=12897User talk:Duerig2008-05-09T01:06:50Z<p>Stu: </p>
<hr />
<div>I'd rather see articles automatically included in this site requiring explicit removal.<br />
Some people dissappear off the net, if we cant track them down they cant agree to add their content.<br />
<br />
I'd rather remove it when asked to than loose it forever...<br />
[[User:Stu|Stu]] 20:11, 1 May 2008 (CEST)<br />
<br />
That is exactly my feelings now. I can find most of them after some googling and other searching around, but there are some that already seem lost. I'm putting them all here. If the admin doesn't like having them here, I'll host them on my own site at my own risk. Almost done taking a census of what articles are still findable. [[User:Duerig|Duerig]] 20:19, 1 May 2008 (CEST)<br />
<br />
I am the author of "Direct screen output" article. If you read it then you will notice that I am signed there. Back ago I also participated in moving articles from DungeonDweller to RogueBasin. My decision was to leave out this article on purpose. It was still useful back then but nowadays it is not just junk - it is actually harmful. It advocates coding only for DOS platform and doing it in a very unportable way. Sure, it beats many ways of screen output with great speed but now it is hardly important. There exist many libraries that handle the thing well enough and in portable manner. Thus, I refuse to give permission to copy it. Also I ask you to remove the article from archives.<br />
<b><i>[[User:Ancient|–Michal Bielinski]]<sup>[[User_talk:Ancient|Talk]]</sup></i></b> 20:41, 8 May 2008 (CEST)<br />
<br />
: Thanks for responding! I have removed the article as you requested. Moving these articles to the archive is about trying to make sure that we can actually make a decision about whether they are useful enough to keep. The alternative is letting them fade away, the good and the bad alike. [[User:Duerig|Duerig]] 02:59, 9 May 2008 (CEST)<br />
<br />
I assume you are aware of the names on this list who accented to move stuff (since mine was on it but you didnt have it at the time...) http://roguebasin.roguelikedevelopment.org/index.php?title=RGRD_Wiki_Project (plus it doesnt really come back if you search for it for people who agreed to have stuff moved...</div>Stuhttp://roguebasin.com/index.php?title=User:Stu&diff=12854User:Stu2008-05-03T00:39:09Z<p>Stu: </p>
<hr />
<div>= Me =<br />
I am Stu, formerly of Australia, then of England and now of the United States of America (East Coast).<br />
<br />
I've three public roguelikes, [[UnderDark]] (abandoned), SRL (only saw one release) and my current project [[Cracks and Crevices]].<br />
<br />
= Old Articles =<br />
:About your old articles: The reason that they are in limbo and had not been transferred over to RogueBasin was that your permission could not be procured. If I have your permission, I can pull them out of the archive pages and turn them into proper articles here on RogueBasin. [[User:Duerig|Duerig]] 20:59, 2 May 2008 (CEST)<br />
<br />
:: Weird. my name is on a page somewhere giving permission.. found it. http://roguebasin.roguelikedevelopment.org/index.php?title=RGRD_Wiki_Project [[User:Stu|Stu]] 02:39, 3 May 2008 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=User:Duerig/Archive2&diff=12848User:Duerig/Archive22008-05-02T13:34:40Z<p>Stu: removed duplicate article that apperas in archive #6</p>
<hr />
<div>= How to write a roguelike gameengine - Esa Ilari Vuokko [eivuokko@mbnet.fi].txt =<br />
<br />
Some ideas that could be useful ?<br />
As shared by Esa Ilari Vuokko.<br />
Comments and bugfixes ;) to eivuokko@mbnet.fi<br />
<br />
<br />
<br />
I've played roguelike games for 7 years now. First I hacked Moria,<br />
which I got from friend (no modem or net connection :(). Then I got<br />
Omega which I still play (newer version, thought ;). At that time I<br />
got rid of Basic I was programming with and got Turbo Pascal. Well,<br />
I tried to do some pathetic games myself but they were just dead<br />
as they were real mode programs. Then (not earlier) I got nethack<br />
which I didn't like at that time. I hated djgpp (it's not bad, it's<br />
ugly in msdos) so I was bounded to real mode. Then I got Linux and<br />
installed it few times with no success (one time I installed it on<br />
broken hd, guess did it work, no - it just paniced suddenly ;). And<br />
I played ADOM, a lot. And then little Nethack and Omega.<br />
<br />
<br />
Because Linux I got all so mighty gcc and make. After playing for a<br />
while with graphics stuff (in linux and in win) and in winenv doing<br />
some accounting program (with delphi, thought I quitted after it<br />
started compiling wrong - I mean(debugged) it) I got an idea. In an<br />
accounting program we move money from one account to another (I'm sorry<br />
I know finnish terminology better than english). Well those accounts<br />
must be linked list because : they must be easy to create, modify and<br />
delete. Nothing new - a linked list. Of course all objects in rg should<br />
be in linked lists. But the what if even attributes were linked lists ?<br />
So that we had a linked list which can store data (some 16 bytes is enough)<br />
and a name (string) and children list.<br />
<br />
<br />
Listing attributes, skills, and everything that describes object with<br />
such presentation would be quite flexible. But if one does such game,<br />
and many people contribute to it ? It can go way off road as everybody<br />
add something new. A bloated memory use, and unneeded complexity are<br />
real threats. As normally, say ADOM, player char needs more memory<br />
(more variables) than npc. But in this approach we give npc only those<br />
skills and attributes it needs and we are still able to use same routines<br />
on both, player and npc.<br />
<br />
<br />
Of course above system can be optimized. I've defined it like this :<br />
Okey, I've got a bit more complex.<br />
class List {<br />
private:<br />
List *child,*next,*parent;<br />
int id;<br />
int data[4];<br />
Link(List *);<br />
Unlink(List *);<br />
Query(int,int,int,int,int);<br />
public:<br />
int *Data();<br />
char *Name();<br />
int *Data(char *);<br />
List *Name(char *);<br />
int *Data(int,int,int,int,int);<br />
List *Name(int,int,int,int,int);<br />
Item *Index(int);<br />
int Index(Item *);<br />
int Count();<br />
List *Add();<br />
List *Remove();<br />
} ;<br />
<br />
Quite clear, I think. Id can be converted (by another class) to char.<br />
Almost all ints are for quick query. I use dot as delimiter between child<br />
and parent and I don't have plurals. "skill.weapon.blade.short".<br />
<br />
Then I wanted an engine that doesn't need special cases. It would be<br />
(sorry for saying this) stupid to do special levels, which have special<br />
if of switch statement in level code. How could one have such a really<br />
flexible system ? Well I read Thomas Biskup's ideas of JADE. I don't know<br />
whetever he meant the same as I with the mentioning everything to be<br />
event based. So what I'm chasing here is that every object should have<br />
message handler list, which would handle requests to do something.<br />
<br />
Say we have a character A. A has handler list of next functions<br />
(stacked):<br />
creature_shield_deflector,<br />
creature_ro_poison_res,<br />
creature_basic_poison,<br />
player_non_ai,<br />
basic_creature_handler.<br />
<br />
First a monster(mage) B would shoot an firebolt to A. Firebolt code would<br />
send a message to A that some fire damage is coming. First this message <br />
would reach first handler in list, creature_shield_deflector. That would <br />
say "no,no fire damage" and that would be it, no damage to creature. Then<br />
B would throw a acidbolt. Well this time deflector would say nothing as <br />
wouldn't other before basic_creature_handler. That would make some damage <br />
to creature and spare some to inventory too (and send approciate messages <br />
to items). Then would engine send TIMEUPDATE to creature, which would be <br />
handled first by creature_basic_poison. Well it seems this creature has <br />
poisoning and handler would notice that it just ending. First it sends to <br />
creature A (self) damage message of poison, which would end to <br />
creature_ro_poison_res, and no damage. Then it would return <br />
UNLINK_AND_CONTINUE so that it would be removed from list and message <br />
(TIMEUPDATE) would be sent on. Then message would reach basic_handler which<br />
would add some speed to energy (ADOM) or add a timepulse (nethack,angband).<br />
If it would be creature's turn to move, it would send message ACTION to <br />
itself (creature A). That would be caught by player_non_ai which would wait <br />
for keypress and then do whatever is defined and player wishes to do.<br />
<br />
Because paragraph above seems a bit unclear ;) I'll do an easier<br />
table here :<br />
1 creature_shield_deflector,<br />
2 creature_ro_poison_res,<br />
3 creature_basic_poison,<br />
4 player_non_ai,<br />
5 basic_creature_handler.<br />
<br />
Messages :<br />
Fire damage<br />
1 - take message (do nothing) return KEEP_AND_STOP -> that's it.<br />
Acid damage<br />
1 - no action, return KEEP_AND_CONTINUE<br />
2 - no action, return KEEP_AND_CONTINUE<br />
3 - no action, return KEEP_AND_CONTINUE<br />
4 - no action, return KEEP_AND_CONTINUE<br />
5 - Share damage to creature and inventory, send damage message to<br />
inventory. Return KEEP_AND_STOP.<br />
TIMEUPDATE<br />
1 - no action, return KEEP_AND_CONTINUE<br />
2 - no action, return KEEP_AND_CONTINUE<br />
3 - Check if it's poison time. If it is send poison damage to self:<br />
Poison damage<br />
1 - no action, return KEEP_AND_CONTINUE<br />
2 - Take message (do nothing) and return KEEP_AND_STOP.<br />
If poison is diluted enough return UNLINK_AND_CONTINUE<br />
else return KEEP_AND_CONTINUE<br />
4 - no action return KEEP_AND_CONTINUE<br />
5 - Check whetever it's time to move or not (some way to count time<br />
compared to time). If it is send ACTION to self.<br />
ACTION<br />
1 - no action, return KEEP_AND_CONTINUE<br />
2 - no action, return KEEP_AND_CONTINUE<br />
3 - no action, return KEEP_AND_CONTINUE<br />
4 - Normal player's turn in roguelike games.<br />
return KEEP_AND_STOP.<br />
<br />
KEEP_AND_CONTINUE, UNLINK_AND_STOP etc mean whatever function which<br />
handles handler lists should keep sending message on in list and if<br />
handler should be removed from list.<br />
<br />
<br />
Yes, I know, this is really heavy way to do things. But if we can count<br />
on fast 486, it is REALLY flexible. I think that with handlers lists and<br />
description lists we can mimic any game we want or make just about anything<br />
we want (well world conquest is a _bit_ hard maybe, but as rg game anything)<br />
<br />
I'm sorry if there's too many errors in my english. I didn't mean to<br />
be offensive either but I needed to make my point clear (if it can be<br />
done at all). If someone has implemented this allready, good, sorry to<br />
say that I were to late.<br />
<br />
I'm sorry if there is something that have been published before and<br />
I don't want to claim that I've been first to thing this kind of things<br />
but I haven't seen anything like this before (I haven't read too much).<br />
Anyway Copyright 2000 Esa Ilari Vuokko. I don't (of course) take any<br />
responsibility of anything you do or don't do with this text. It can be<br />
freely copied and published electronically as long as it isn't modified.<br />
<br />
= Heap Space Conservation - Steve Segreto [ssegreto@titan.com]. =<br />
<br />
Or How to have LOTS of monsters and LOTS of treasure in your Roguelike.<br />
<br />
Here are some tips for conserving precious heap space, so that you<br />
will be able to populate each of your dungeon levels with as many <br />
monsters and items as you want! This is a good alternative to having to<br />
write a protected mode program, and while it may be a little too slow<br />
for some 386s, the algorithms can be tuned as needed. The basic concept<br />
is that you will only store in RAM as little as you possibly need to <br />
know about all the monsters and items. All the rest of the stuff <br />
(specific information about a monster or item) you store on the <br />
player's hard drive. The speed versus memory usage trade-off is obvious.<br />
You will use a lot less RAM by only storing the indices into the disk<br />
files in a linked list in memory, but your game will be slightly slower<br />
because you must frequently return to the hard drive and read/write<br />
information from it (this is VERY slow compared to reading/writing from<br />
RAM).<br />
<br />
Anyway, here is some sample code for storing indices for monsters and<br />
items using ANSI C and assuming that each of your dungeon levels is 80<br />
cells by 25 cells, for a total of 2000 square cells (this may be<br />
smaller or larger than what you want for your roguelike). My ANSI C is<br />
pretty rusty (I prefer Pascal) so please be aware that this code does<br />
contain syntax errors.<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// BEGIN CODE FRAGMENT<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
#define MAX_ROWS 25<br />
#define MAX_COLS 80<br />
typedef unsigned int word; // 16-bit quantity<br />
typedef unsigned char byte; // 8-bit quantity<br />
typedef enum NodeTypes = { MONSTER, ITEMS }; // Different sorts of<br />
data files you will have<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// A singly linked list of indices.<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
typedef struct index_list_node;<br />
typedef index_list_node *index_list_node_ptr;<br />
struct<br />
{<br />
word index;<br />
NodeTypes node_type;<br />
index_list_node_ptr link;<br />
} index_list_node; // Size = 7 bytes<br />
// Related list functions are new_list(), free_list(),<br />
insert_before(), insert_after(), is_empty(), is_full()<br />
// advance_list(), reset_list(), read_list_from_disk(),<br />
write_list_to_disk()<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// Records to hold monsters and items on diskette.<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
typedef struct<br />
{<br />
byte row, col, depth;<br />
char symbol; // Whatever data you will have to represent a<br />
monster: name, hit points, AC, etc.<br />
}monster_record;<br />
<br />
typedef struct<br />
{<br />
byte row, col, depth;<br />
char symbol; // Whatever data you will have to represent an<br />
item: weight, damage, etc.<br />
}item_record;<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// Global array of index_list_nodes for each square of the dungeon.<br />
// Initiallly this array will be MAX_ROWS * MAX_COLS * sizeof<br />
(index_list_node) bytes large<br />
// 80 * 25 * 7 = 14,000 bytes plus 7 bytes for every monster/item<br />
added.<br />
// Assuming about 150 monsters and 200 items per level, this gives<br />
you 14,000 + (7 * 350)=16,450 bytes<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
index_list_node object_array[MAX_ROWS][MAX_COLS];<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// Because the above list will only contain INDICES into permanent<br />
disk files, deleting elements from the list<br />
// such as when an item is picked up or a monster slain, will be<br />
extremely slow (because the entire level file<br />
// on disk will have to be re-written minus one single record). To<br />
alleviate this, simply keep a second linked<br />
// index list of all the indices which need to be deleted from the<br />
permanent disk file when the player leaves this<br />
// dungeon level (these indices have already been deleted from the<br />
object_array linked lists.) Remember to<br />
// insert indices into this list EVERY time a monster is killed or<br />
an item is picked up (you might want to<br />
// have a function delete_monster(which_row, which_col, what_index)<br />
which removes the specified node<br />
// from the object_array[] linked list and also inserts it into the<br />
deleted_list [Do you see why you need to<br />
// pass in what_index? That's right, so you can go to the<br />
appropriate (what_row, what_col) element in object_array<br />
// and traverse that linked list until currPtr->index == what_index,<br />
then you can delete this node and insert the<br />
// what_index into the deleted_list!] ).<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
index_list_node deleted_list;<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// You will also have two disk files per dungeon level, one for<br />
MONSTERS and one for ITEMS.<br />
// You must devise a naming scheme for each (LEVEL01.MON and<br />
LEVEL01.ITM for example)<br />
// LEVEL01.MON is a random-access file of monster_records and<br />
LEVEL01.ITM is a random-<br />
// access file of item_records, one record per monster on that level<br />
and one record per item on the<br />
// level. Note that these disk files may be quite large<br />
(sizeof(monster_record) * num_records bytes).<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// stock_depth()<br />
// Call this function at the start of the game or whenever the level<br />
needs to be completely re-stocked:<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
void stock_depth ()<br />
{<br />
// 1. Open the appropriate monster level file (LEVEL01.MON for<br />
example)<br />
// 2. Read each monster_record one at a time into a local<br />
variable, m<br />
// 3. Based on the m's (row, col, depth) triple, use the<br />
appropriate element of the global object_array[].<br />
// For example, if m.row = 10 and m.col = 10 then<br />
object_array[10][10] would have a singly linked list<br />
// of index_list_nodes.<br />
// 4. Insert the index into the linked list (use insert_after()<br />
from the basic list routines above).<br />
// 5. Do the same thing for the item level file.<br />
item_record i;<br />
monster_record m;<br />
FILE *infile;<br />
word index = 0;<br />
<br />
// Add all the monsters to our array of linked lists.<br />
infile = fopen ("LEVEL01.MON") // This line is not syntactically<br />
correct<br />
while (!eof(infile))<br />
{<br />
fread (infile, m); // Wrong also!<br />
insert_after (object_array[m.row][m.col], index, MONSTER);<br />
// The index is the record number and the linked list is<br />
<br />
// at (m.row, m.col)<br />
index++; // Move on to the next record<br />
}<br />
<br />
// If there are not enough monsters on this level, ADD monsters<br />
until there are enough.<br />
<br />
// Add all the items to our array of linked lists.<br />
index = 0;<br />
infile = fopen ("LEVEL01.ITM") // This line is not syntactically<br />
correct<br />
while (!eof(infile))<br />
{<br />
fread (infile, m); // Wrong also!<br />
insert_after (object_array[i.row][i.col], index, ITEM); //<br />
The index is the record number and the linked list is<br />
<br />
// at (m.row, m.col)<br />
index++; // Move on to the next record<br />
}<br />
}<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// change_depth()<br />
// Call this function every time the player changes dungeon levels,<br />
including at the end of the game:<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
void change_depth ()<br />
{<br />
// 1. Open the current monster level file (LEVEL01.MON for<br />
example)<br />
// 2. Open a temporary file<br />
// 3. Read each record one at a time into a local variable, m.<br />
// 4. If this record number (index) is NOT in the deleted_list<br />
(see above) then write this<br />
// record to the temp file (otherwise DON'T write the record<br />
to the temp file).<br />
// 5. Close and delete the monster level file.<br />
// 6. Rename the temp file to the same name as the monster level<br />
file.<br />
// 7. Now the temp file contains all the records except those<br />
which have been deleted (dead monsters).<br />
// 8. Do the same with the item level file.<br />
// 9. Call free_list() to destroy the linked index list.<br />
// 10. Based on the new depth, call stock_depth() with the new<br />
depth number to load/build the new index_list.<br />
}<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// square_has_monster()<br />
// Simply scan the linked list at object_array[which_row][which_col]<br />
and return TRUE as soon as one of<br />
// the nodes has a node_type of MONSTER.<br />
// You can devise a similar function for square_has_item().<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
boolean square_has_monster (byte which_row, byte which_col)<br />
{<br />
// List at this square is empty (square has neither monster nor<br />
items)<br />
if (object_array[which_row][which_col] == NULL) return (FALSE);<br />
<br />
index_list_node currPtr = object_array[which_row][which_col];<br />
while (currPtr != NULL)<br />
{<br />
if (currPtr->node_type == MONSTER) return (TRUE);<br />
<br />
// Move down the list<br />
currPtr = currPtr->link;<br />
}<br />
return (FALSE);<br />
}<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// END CODE FRAGMENT<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
= Handing Out Experience - Rick Carson.txt =<br />
<br />
Roguelikes are part of a family of games in which the participant builds <br />
something over time. Relatives are of course roleplaying games and other <br />
storytelling games. Distant relatives are games such as Civilization.<br />
<br />
Since players often fail to achieve the primary goal (e.g. retrieve the <br />
artifact of lint removal which will cleanse the bellybuttons of everyone <br />
in the universe thereby ending world hunger) the secondary rewards (or payoffs <br />
(or utility for all you economists out there in RL land)) become very important. <br />
Too much advancement too quickly (kill a kobold - get to 35th level) devalues <br />
the payoff, whereas too slow an advancement (kill everything in the whole <br />
game and maybe get halfway to level 2) means that they never even get to <br />
feel rewarded.<br />
<br />
Of course experience might be handed out for a range of activities, not <br />
just killing things. such a list is certainly not limited to: solving quests; <br />
receiving damage; causing damage; casting spells; using skills; getting <br />
treasure; idle gossip; donations to the (un)worthy cause of your choice; <br />
doing nothing or resting; healing; travelling, mapping, making other players <br />
laugh....<br />
<br />
So lets consider the case of a fairly generic dungeon bashing roguelike. <br />
The dungeon has sixteen levels, a predetermined number of monsters per <br />
level, and unique monsters. There are no 'random' monsters. We'll call <br />
our theoretical roguelike Jiavlo and code it in Java. (Stop me if I infringe <br />
any copyrights ;-) <br />
<br />
Experience is only handed out when we generate a monster killing event.<br />
<br />
Our first realization is that in this scenario there are a fixed number <br />
of monsters, and that this means that there is an upper limit for how much <br />
experience the player will ever get.<br />
<br />
We need to decide how many levels we want the players to be able to gain. <br />
So what constitutes a good number of levels that could be gained? Most <br />
of the audience will have at least a passing familiarity with the D&D game <br />
family, in which you start at level one, and progress is technically unlimited,<br />
but which is less meaningful once you get into double digits. And certainly <br />
once you get into the low twenties you are in danger of being accussed (unjustly <br />
of course) of being a 'power gamer'. So most of the target audience is <br />
going to be happy with a top level of around 15 to 30. Twenty is a nice <br />
round number in that range which should give a decent payoff in terms of <br />
achievement.<br />
<br />
Note that the point is not to mirror any particular published system for <br />
which one runs the risk of being sued and losing the shirt off ones back,<br />
but rather to recognise and take advantage of this subconscious assumption <br />
that most people are going to make, ie that getting to level 20 is a superhuman <br />
feat and that getting to level 12 (say) is pretty spectacular.<br />
<br />
The other thing to do is to make the experience scale exponential (this <br />
means that each level requires more experience to get to than the level <br />
before it). Mathematically there is no reason for this, but people will <br />
expect it, and because of their expectation they will not feel as much of <br />
a payoff if they get the same amount of experience for killing a dragon <br />
as a kobold. Because of this, I recommend using a spreadsheet to play around <br />
with the numbers till you some that you like. Hopefully you won't need <br />
a spreadsheet to follow this article though!<br />
<br />
It is useful to consider the linear case here though, because it forms a <br />
basis from which you can build the exponential formula, and if you do so <br />
you will be much more likely to get a well balanced game. But before we <br />
look at the linear model, lets examine the constant model. This is even <br />
worse in terms of payoffs, but much simpler again to balance properly.<br />
<br />
For every monster you kill you get 1 xp.<br />
There are 50 monsters per level. (Times 16 levels is 800 xp)<br />
We can now say something like, for every 40 xp you have, you go up a level. <br />
(800 divided by 20).<br />
Note that you start at level 1, so you would get to level 20 after killing <br />
760 creatures, ie you max out your levels shortly before you kill the UberLintDaemon <br />
which drops the game ending artifact, so that you have time to enjoy maxing <br />
out on levels before the game ends.<br />
<br />
If the monsters on deeper levels get harder to kill, then logically players <br />
would try to clear a level before progressing to the next in order to get <br />
the 'easiest' xp first (minimise risk, maximise payoff).<br />
<br />
Note that we are requiring them to kill 40 monsters in order to advance <br />
to second level. This is far too harsh, and for many first time players <br />
this will take too long for them to get hooked. Ten is a much more reasonable <br />
number. And we want them to be able to get to say level 5 or 6 fairly quickly <br />
before it becomes hard slog. So lets break it down, lets say that by the <br />
end of dungeon level 15 they are level 20, and they gain a level per level <br />
they clear back till say the player is level 10. That means that we then <br />
need to plot the xp from 0 (at level 1) to 250 (which they have after clearing <br />
5 levels at level 10). We could go back and rewrite our assumptions, and <br />
have them start at level 0, and then have them gain a level every 25 points. <br />
That makes it nice and easy for us in terms of maths.<br />
<br />
The effect this has on the game though, is to make the clearing of each <br />
level a hard thing at first, and then get easier halfway through each level. <br />
This is actually not too bad in terms of payoffs, because the player begins <br />
to notice that the monsters are easier to clear after going up the level.<br />
<br />
So lets modify how players go up levels. Here is the table (level, xp required):<br />
1 0<br />
2 5<br />
3 15<br />
4 30<br />
5 50<br />
6 75<br />
7 105<br />
8 140<br />
9 180<br />
10 225<br />
(and 50 per level after that). <br />
<br />
So at the end of clearing level 1 (50xp), they are fifth level, clearing <br />
level 2 puts them at sixth level verging on seventh, etc. This uses a clear <br />
progression, in order to go up a level, you need as much extra xp as the <br />
last time you went up a level, plus five, until you get to needing 50 a <br />
level where it tops out).<br />
<br />
Despite the plain maths behind this, I would be tempted to fiddle with it <br />
even more, because fifth level after clearing only one level of monsters <br />
seems 'too much'.<br />
<br />
But lets take this 'constant' model, and see what happens when we make it <br />
'linear'.<br />
We assume that all the monsters on level x of the dungeon are 'level x monsters' <br />
and we give x points for killing them. The maximum amount of experience <br />
in the game is now: 6800. The maths for working this out is starting to <br />
get more complicated, but the formula is: (((n squared) plus n) divided <br />
by 2) times the number of monsters per level). Where n is the number of <br />
levels, and the number of monsters per level is still 50.<br />
<br />
Obviously we cannot now just multiply the cost of going up levels by 8.5 <br />
(6800 divided by 800) because that would mean we would need 85 xp to get <br />
to second level, which means clearing all of level 1, and a third of level <br />
2. All of a sudden things look a lot harder! One way of solving this, <br />
is to try to match monsters killed to levels gained, assuming that all the <br />
low level monsters are killed first. This is easier than it sounds for <br />
levels 10 through 20, because we already know that we want the player to <br />
advance at the mid point of the level. And this is not too hard to work <br />
out (especially with a spreadsheet).<br />
<br />
&gtFrom 10th level and up (level, xp required):<br />
10 900<br />
11 1225<br />
12 1600<br />
13 2025<br />
14 2500<br />
15 3025<br />
16 3600<br />
17 4225<br />
18 4900<br />
19 5625<br />
20 6400<br />
<br />
(The formula for this is: (((n squared) plus n) / divided by 2) plus (25 <br />
times (n plus 1)) where n = level required minus 5. The minus five is <br />
because we have five more experience levels than the last level of the dungeon <br />
that we cleared)<br />
<br />
Now if we want to keep the same progression, that is, getting to level five <br />
after clearing the first level of the dungeon (yuck!) we leave that bit <br />
of the table alone, and figure out a progression from 5th level to 10th <br />
level. Or, we can choose another formula to govern low level advancement,<br />
such as: (n times n) plus (14 times n) minus 1, where n is the current <br />
level which yields:<br />
1 0<br />
2 14<br />
3 45<br />
4 95<br />
5 166<br />
6 260<br />
7 379<br />
8 525<br />
9 700<br />
<br />
Which is a much nicer fit to the lower levels of the dungeon and how fast <br />
they should advance. Unfortunately I've just noticed that it bears a striking <br />
similiarity to the xp curve in Crawl. What a shame :-)<br />
<br />
But of course noone wants to get 12 xp for killing a Dragon, so we need <br />
to think about how much xp we want to hand out for killing a monster of <br />
each level. I suggested at the start of the article that making it exponential <br />
is probably more in fitting with the players expectations. Lets say that <br />
on level one you get 1 xp per monster killed, and on level 16 you get 10,<br />
000 xp per monster (so level 16 has half a million xp of monsters on it <br />
- suitably impressive amount :-)<br />
<br />
A 'basic' formula for this would be: (n to the power of ((n minus 1) divided <br />
by (15 divided by 4)))<br />
<br />
Which gives these results:<br />
1 1<br />
2 1.847849797<br />
3 3.414548874<br />
4 6.309573445<br />
5 11.65914401<br />
6 21.5443469<br />
7 39.81071706<br />
8 73.56422545<br />
9 135.9356391<br />
10 251.1886432<br />
11 464.1588834<br />
12 857.6958986<br />
13 1584.893192<br />
14 2928.644565<br />
15 5411.695265<br />
16 10000<br />
<br />
<br />
You then need to figure out how many xp are needed for each level (use a <br />
spreadsheet!), and split the difference between levels, and then somehow <br />
figure out a formula for advancing. I came up with (2 to the power of n) <br />
plus (n cubed) minus (25 times n). Which is ok, but given more time we <br />
could come up with something better. In particular, I'd reduce the base <br />
number of the power to something in the range of 1.97 to 1.99 so as to get <br />
closer to the 'ideal' value for that last level (you would get to 20th level <br />
with three creatures remaining given the formula above).<br />
<br />
Some things to think about: do the rewards actually match the difficulty. <br />
For instance if a level 12 monster isn't really much harder to kill than <br />
a level 8 monster, why hand out ten times as much xp for killing it?<br />
<br />
In fact, the difficulty of balancing even a limited scenario as outlined <br />
above means that you are far better off having a 'complicated' function <br />
for handing out experience, than aiming for some mathematically pure function.<br />
<br />
An example: Offense * Defense is a very good measure of combat capability <br />
(ignoring the effects of swarming, assume that the character can always <br />
retreat such that they only fight one monster at a time). Offense is the <br />
average damage they do (ie chance to hit times average damage times number <br />
of attacks) and defense is how much damage they can take on average (ie <br />
chance to avoid damage times hit points).<br />
<br />
Example 1: a rat which does 1-2 points of damage, has a 1 in 3 chance of <br />
hitting, has no chance of dodging and 2 hitpoints would be worth 1 xp. <br />
((1.5 times (1 divided by 3)) times 2)<br />
Example 2: a balrog which does 10-20 points of damage, has a 100% chance <br />
of hitting, gets three attacks a round, avoids (dodges/deflects/counterspells/whatever) <br />
50% of attacks and has 100 hit points would be worth (15 times 3) times <br />
((100 divided by 50) times 100) or 9000 xp. Actually, that might not be <br />
enough :-)<br />
<br />
You can increase the spread by raising the amount of xp from the above formula <br />
by some power greater than 1, try 1.1 or 1.2. 9,000 to the power of 1.2 <br />
is 55,602 which should keep the players happy. Whereas 1 to the power of <br />
anything is still 1.<br />
<br />
Other factors to consider are the dungeon level the character has gotten <br />
to, what resistances the monster has, whether the monster has ranged attacks <br />
(these are really nasty in roguelikes, you may wish to reward the players <br />
accordingly) and whether it drops items that help the player (which are <br />
a reward in themselves in that they improve the character) when it dies. <br />
Of course killing an Elder Dragon and having the experience it gives you <br />
reduced by 10% because it dropped a +1 dagger, would suck.<br />
<br />
In terms of experience to go up levels, something to avoid is requiring <br />
as mush xp to go from 1 to 2 as from 2 to 3. This can happen when you use <br />
an exponential curve that doubles for a while. Just as a wild totally random <br />
example, take a fighter that needs 2000xp to get to level 2, and 4000xp <br />
to get to level 3, and 8000 xp to get to level 4 etc. Now think about this,<br />
in order to get to level 2, the fighter had to gain only 2000xp, but this <br />
is also the amount they need to gain in order to get to the next level, <br />
but now they have an extra levels worth of hitpoints, better chances to <br />
hit etc, which means that it is easier to get from 2 to 3 than it was to <br />
go from 1 to 2. And the game shouldn't get easier as they go up levels.<br />
<br />
cheers,<br />
<br />
Rick<br />
<br />
= Allocating Experience and Character Advancement - Matthias E. Giwer [mgiwer@ij.net]. =<br />
<br />
First, a brief bit about my experience in this area:<br />
<br />
I've been an active player of "pencil and paper" role playing <br />
games since 1987, encompassing more than thirty (truthfully, I've <br />
forgotten all the games I've played) different systems, as well as a<br />
number of "tactical" games such as BattleTech, Warhammer, etc.<br />
<br />
I've spent (wasted :) hundreds of hours in roguelikes such as <br />
Larn, Moria, Nethack, (A-Z)ngband, ADOM, etc. I attempted to develop<br />
my own on several occasions, the most recent attempt being Saga, a Perl<br />
roguelike.<br />
<br />
I do not claim to be the worlds most serious gamer, nor the <br />
worlds best software engineer, but I do feel I have enough experience <br />
on this subject to be able to offer some useful information.<br />
<br />
<br />
Now, on to the meat:<br />
<br />
How you implement character advancement will depend heavily on <br />
your choice of game mechanics. For example, is it a level based system <br />
where a 10th level being will be ten times more capable than a 1st <br />
level being? a hundred? Or is it entirely skills based, where <br />
facility with a particular weapon or ability is to be developed <br />
independently of any other capability?<br />
<br />
The majority of current roguelikes seems to be dominated by <br />
levels and level/skills hybrids. This is fine, though while I <br />
personally advocate an entirely skills-based approach, it is truly a <br />
matter of taste.<br />
<br />
The base idea is that individual actions performed by the <br />
characters will return (on success, failure or both) some measure of <br />
"experience", either generic or towards the skill governed by the <br />
action. In order to develop a mental yardstick, I usually try to get <br />
a firm idea of what a brand new, baseline character is capable of. In<br />
most roguelikes today, that would be a human fighter.<br />
<br />
Next, try to imagine what this character would be capable of, if <br />
his abilities were taken to their absolute limits, without regard to <br />
items and equipment that may boost her capabilities. This should give<br />
you a continuum of capability that will let you look at, and gauge, <br />
difficulty of things like quests, unique creatures, and so on.<br />
<br />
It also usually helps me to think of creatures that this <br />
character may face as based on this brand new beginning fighter. In <br />
other words, a Grey Kobold is about half the power of a beginning <br />
fighter, but an Elite Orc Guardsman is six times more powerful than <br />
the baseline.<br />
<br />
Yes, there is a LOT of tweaking and experimentation involved to<br />
get it right. Also, many abilities can make combat orders of magnitude <br />
simpler (teleportation, ranged attacks, etc) so this has to be taken <br />
into account when trying to judge anything other than a raw fighter<br />
type. Again, there is no perfect measure, experimentation is the key <br />
to balance here.<br />
<br />
If you wish to model the real world, most performance type <br />
skills (dancing, martial arts, typing, etc) are developed in terms of <br />
plateaus that may take months or years to break through, usually on a <br />
sliding scale of time. The first plateau might take only a few weeks <br />
to reach, but the next may take a few months, etc. Roguelikes (and <br />
many traditional RPG's) model this with each "level" requiring <br />
progressively larger amounts of experience points to reach.<br />
<br />
However, because most games give out larger amounts of <br />
experience for more difficult and more powerful creatures, the result <br />
is that most characters end up on a hyper-accelerated track, and can <br />
reach quite amazing levels of skill in relatively short amounts of <br />
game time. Now, as a fantasy game goes, that is perfectly acceptable,<br />
but it does make it more difficult to judge when a player is ready to <br />
face the "Deep dwelling Thing from Beyond". Then again, people don't <br />
play roguelikes because they are easy. ;)<br />
<br />
I would have no issue with this, if it was a one-time event. <br />
For example, the first time you wipe out a Grey Ooze, get the full <br />
experience value for it. For each one after, only bestow a standard <br />
action credit that doesn't change, for all actions of that type. New <br />
things, and new challenges help you grow a lot, practice helps you a <br />
little (which is why you have to keep at it).<br />
<br />
An extension of this idea is experience for, say, casting <br />
spells. You get full experience value the first time you cast a new <br />
spell, but only a small "cast spell" value each time thereafter. The <br />
idea works for any ability that is action based, rather than intrinsic<br />
or "always-on".<br />
<br />
For added realism (ha :), it may be worth investigating a <br />
"decay" function for skills and abilities that go unused for long <br />
periods of time, with the time before decay increasing the higher the <br />
level of skill.<br />
<br />
<br />
Like the design of any game system, this article is two parts <br />
experience and one part prejudice. I hope that, at least, mentioning <br />
these issues will prompt roguelike designers to devote more thought <br />
game mechanics issues, and to question some accepted standards.<br />
<br />
I do apologize if you were looking for code examples, but the entire <br />
issue of character development is so tightly bound to the specific <br />
system and other game mechanics to make even pseudo code examples <br />
just about worthless.<br />
<br />
Feel free to write me with questions, comments, etc. Please keep the <br />
flames constructive, thanks! :)<br />
<br />
-Matthias E. Giwer<br />
mgiwer@ij.net<br />
<br />
= Creating A Player - Brian Bucklew [bbucklew@inteletek.com]. =<br />
<br />
Section 1 : The Definition<br />
<br />
[Note : I will be using C++ Class definitions]<br />
<br />
So, let's pretend we have a nice endless dungeon filled with<br />
vile demonic beasts, heaps of gold, and piles of flaming swords of instant<br />
monster to magic item transmutation. Mabey we even have an engine to make<br />
the ubiquitous '@' saunter around in this great dungeon.<br />
Now, what we really need is some way to make that little '@' into<br />
a daring adventurer, with Herculean strength and an intelligence to<br />
rival Hawking (or perhaps the lack of the same...).<br />
First off, we need to have some basic statistics and attributes.<br />
perhaps we need a Name, a Race, and a Class... We also need some numbers<br />
to represent the Hero's strength, and intelligence as well as his other<br />
important attributes.<br />
Now, in any RL, a player's Statistics are going to go up and<br />
down during the course of play, whether it's from going up a level or<br />
getting hit by a Lecherous Walking Carrot Of Charisma Sapping. So we should<br />
really represent each score by two numbers, a current score and a base score:<br />
<br />
class Stat<br />
{<br />
public:<br />
int Base;<br />
int Current;<br />
}<br />
<br />
All of our calculations done in the game should be based off of the<br />
current score, but the base score will allow us to revert to the Player's<br />
origional score or hit-point total after a magical-effect or damage wares<br />
off.<br />
<br />
Having the basic stat class, let's go ahead and derive a class to<br />
contain a basic RL character:<br />
<br />
class Player<br />
{<br />
public:<br />
char Name[256]; // A String to hold the player's name<br />
int Race; // let's say, 0=Human 1=Elf 2=Frog...<br />
int Class; // hmm... 0=Fighter 1=Mage 2=Tourist... <br />
<br />
Stat Str; // How Strong<br />
Stat Int; // How Smart<br />
Stat Dex; // How Fast<br />
Stat Hlt; // How Healthy<br />
Stat Cha; // How Well-Liked<br />
<br />
Stat HP; // How much damage you can take<br />
Stat AR; // Your armor-rating<br />
Stat SP; // Spell-points... How many kobold you can toast<br />
};<br />
<br />
That should be a good starting point for developing a unique character<br />
representation for your RL...<br />
<br />
Section 2 : The Creation<br />
<br />
The actual creation of the character is accomplished by somehow<br />
assigning a score to each of the stats... There are two main ways<br />
to accomplish this; Random Rolling and Point Distribution.<br />
Random Rolling would display all of the statistics, and allow<br />
the player to hit a key to "Roll" (or randomly assign numbers, say between<br />
1 and 100) to each main statistic. The player would then continue rolling<br />
until they have a set of numbers that is agreeable to them.<br />
Point Distribution would give the player's a number of points, say<br />
100, and allow them to distribute those points to their attributes in any<br />
way they wish; Thus allowing the player to design a character that they want<br />
to play.<br />
<br />
Usually, the player's chosen race affects the statistics in some way.<br />
For instance if our player picked:<br />
<br />
A Human - No change; Humans should be pretty standard fare.<br />
An Elf - +2 Dex, -2 Str; Elfs are quick, but weaker than humans<br />
A Frog - +2 Int, -2 Cha; Frogs are obviously intelligent, but ugly...<br />
<br />
Classes are generally restricted by attributes... <br />
<br />
Fighters - No basics; Everyone can pick up a stick and hit something...<br />
Mage - At least a 12 Int; A Mage has to read, at least...<br />
Tourist - At least a 12 Dex; You have to move fast, only 36 days left of<br />
vacation...<br />
<br />
The player might be given some basic equipment based on his class, and<br />
that's about it... That '@' has everything it needs to thump some Kobolds!<br />
<br />
The Author:<br />
Brian Bucklew, 18<br />
bbucklew@inteletek.com<br />
Current RL Project : Dungeon or "This game needs a new name"... :)<br />
Projected Beta Release : Early 98<br />
<br />
= Pretty Pictures - Darren Hebden [rogue@skoardy.demon.co.uk].txt =<br />
<br />
Some thoughts on Graphics in Roguelike Games.<br />
by Darren Hebden [rogue@skoardy.demon.co.uk]<br />
<br />
<br />
Traditionally, if you suggested graphics to a roguelike-<br />
stalwart, you would have found yourself out on your ear for speaking <br />
such heresy. Many would argue that being text-based is a defining <br />
feature of the roguelike genre. Others want more and look upon <br />
graphics as a natural progression. <br />
<br />
Many people (purveyors of quality knee-jerk reactions and 'The<br />
end is Nigh' flavoured rantings) warn of the old-style being phased <br />
out or graphic-based roguelikes lacking the same depth of text-based.<br />
Personally, I like to believe that both can exist quite happily and<br />
that the addition of graphics in roguelike games is a bonus, not a <br />
replacement. It is a new feature and it's use within the roguelikes<br />
is still being explored. <br />
<br />
This document talks a little about the uses of graphics in <br />
roguelikes, the different styles and some graphic techniques. Not <br />
being an expert on all systems (or the one I own, come to that), I'll <br />
try to make my article non-machine-specific. If you know a little <br />
about the packages you own, you should be able understand my texts.<br />
<br />
----//---- <br />
<br />
# Why Graphics.<br />
<br />
PROS.<br />
1) It's a "draw".<br />
The visual style attracts the eye to games that many of the <br />
uneducated heathens (sorry, I mean -- people who haven't encountered<br />
roguelike games before) would ignore and pass over because of their<br />
archaic text-editor style appearance. <br />
<br />
2) It's expected.<br />
Unfortunately, the expectations of todays game player have been<br />
adversely influenced by big budget, multi-cd, flashy productions. I<br />
don't exactly find this a pleasant situation but ignoring it or <br />
"taking a stand" won't help you or your game. <br />
<br />
3) So what's a 'Furgikan-bug'?<br />
Although a great deal of people are up on Tolkien lore and AD&D <br />
monster theory 101, but an unknown creature shown as a 'F' character <br />
on-screen may leave several of your players scratching their heads. A<br />
well-drawn image, however, is instantly recognisable and gives a <br />
better impression of the creatures appearance.<br />
<br />
CONS.<br />
1) Graphics kill the imagination.<br />
The original roguelike style counts on the players imagination <br />
to transform a simple red 'D' into the terrifying bulk of Fire Dragon<br />
flesh. No matter how detailed your graphics are, they may not be able<br />
to live up to the visions swirling around an over-active imagination.<br />
<br />
2) Bigger programs.<br />
The storage of large amounts of graphics data all adds to the <br />
overall archive size for your game. It's very difficult to produce a<br />
competent roguelike game with a small selection of graphics without<br />
compromising the colour-depth or tile size. Whichever way you even<br />
things out, graphics mean an increased game footprint.<br />
<br />
3) Bad graphics drag a game down.<br />
Good graphics can really add to the atmosphere of a game but in<br />
the same way, a bad set of graphics can seriously hamper a game which<br />
is technically competent and full of depth. Will you be able to supply<br />
good graphics for your game or would the game be better served staying<br />
with a text only display? Don't treat graphics like the current<br />
band-wagon to climb aboard.<br />
<br />
----//---- <br />
<br />
# Graphic Styles.<br />
<br />
Although all through this document I speak of older roguelikes<br />
being text based, simple texts characters _are_ a form of graphics. A<br />
'g' from a gremlin may be missing a few limbs and that mad glint in<br />
his eye but people soon become lost within the game world and accept<br />
that a horde of crazed 'g's bearing down on a weakened adventurer is<br />
not a good sign.<br />
<br />
There are several different styles that you can use when representing <br />
your dungeon on-screen. <br />
<br />
1) Flat Tiles.<br />
The most typical use of graphics in roguelikes is a one-for-one <br />
replacement of the ascii-characters themselves. A wall character is <br />
replaced with a brick pattern, a water character by a lump of blue. <br />
<br />
A little work is needed re-assigning what is displayed or how <br />
they are arranged on screen but often, this method restricts the <br />
artist in getting the best from the tile size and colour depth <br />
available. Due to the forced nature of the way the tiles may be <br />
arranged, the artist could be unable to introduce some details that <br />
would improve the overall look.<br />
<br />
This style doesn't _have_ to suffer from badly arranged tiles if <br />
the artist uses the way the tiles are placed to his benefit and the <br />
programmer is willing to make slight alterations to get the best out <br />
of the tiles provided. The perfect solution is to be programmer and <br />
artist :-)<br />
<br />
Badly drawn example... XXXXX<br />
XXXXX<br />
XXXXX<br />
XXXXX <br />
XXXXX<br />
<br />
<br />
2) Pseudo-3D Flat Tiles.<br />
The next style is very similar to the first but instead of flat <br />
patterns for tiles, the impression of depth is given by drawing front <br />
edges on lower half of the tile for the walls. It's a cheap trick but <br />
is quite effective. The illusion is only spoiled by the fact that the <br />
player cannot walk behind the tiles as they occupy the same space as a <br />
normal wall tile. A little 'walk-behind' effect can be gained if the <br />
tiles are overlapped. It okay but you also begin to lose a little of <br />
the floorspace of the tile above.<br />
<br />
All in all, a popular choice and for tiles that need a little <br />
more work when it comes to designing them to fit together. It means <br />
more graphics but generally, it's worth it.<br />
<br />
Badly drawn example... XXXXX<br />
XXXXX<br />
XXXXX<br />
||||| <br />
|||||<br />
<br />
<br />
3) Isometric Tiles.<br />
These tiles create the impression that the level is viewed from <br />
an angle of 45 degrees to the left/right. As they go, this style gives <br />
a very good illusion of depth (apart from the total lack of <br />
perspective, ofcourse). <br />
<br />
A problem with this style is that these tiles really need to <br />
overlap. I've tried some experiments with not overlapping them and <br />
they looked very bizarre. The overlap causes a bit of lost floorspace <br />
of the tiles drawn above the walls but this can be reduced by having <br />
shorter walls. <br />
<br />
As with the overlapping from the previous style, don't go over the top <br />
with the shortened walls though or you'll have levels looking like a <br />
stunted hedge-maze.<br />
<br />
A solution would be to make any wall that overlaps a floorspace <br />
semi-transparent. This effect can be achieved by either some rather <br />
clever palette mixing tricks on the programmers side of things (which <br />
is rather a bit of overkill for a roguelike) or by a chess-board style <br />
hashing of the pixels over the overlapped area -- one pixel of the <br />
wall, one of the floor, etc. It is a bit of a cop-out but quite <br />
effective. <br />
<br />
Badly drawn example... X<br />
XXX <br />
XXXXX<br />
|XXX|<br />
||X||<br />
|||<br />
|<br />
<br />
<br />
4) Tunnel Vision (or That-Style-From-Dungeon-Master).<br />
The player is presented with a full perspective view of a<br />
corridor/tunnel of the dungeon. Items in the distance are smaller and<br />
tunnels lead off from the original at right angles. Movement is <br />
generally made in steps and switching the direction viewed usually<br />
snaps round ninety degrees.<br />
<br />
This style allows for more detail on the wall/floor tiles as the<br />
tiles closest to the player are quite large on screen. I've yet to <br />
see this used in a roguelike game although it has been suggested <br />
quite a few times. Other games have used this style and in some<br />
ways, you could argue that Dungeon Master, Eye of the Beholder, etc.<br />
are in essence roguelike.<br />
<br />
One reason for it not being implemented is that the player can<br />
only see in one direction at a time. Usual roguelikes have forces<br />
coming at the player from all sides. This may put several players off<br />
due to the confusing nature of this 'realistic' feature. Other <br />
windows containing the left/right/back views may help this situation.<br />
<br />
Badly drawn example... .........<br />
|.......|<br />
||.....||<br />
||| |||<br />
||| |||<br />
||.....||<br />
|.......|<br />
.........<br />
<br />
<br />
5) 3D Texture Mapped.<br />
The last style I'm going to cover is texture mapping. So far <br />
(without making a massive leap with the definition of the genre), no <br />
roguelike game has ever used texture mapped 3D graphics. I'm sure if <br />
you visualise a game like Quake, or whatever the current splurge of <br />
the month is, you'll realise what I'm getting at here.<br />
<br />
One problem with texture mapping is that to get a good <br />
definition on the walls, floors, etc. the textures need to be of a <br />
fair size otherwise, close inspection of a wall reveals a horrible <br />
level of pixelisation. 3D accelerator cards (and a certain console) <br />
can provide techniques to smooth the textures but now we're getting <br />
into silly-land. Roguelike game with texture-mapped polygons needing a <br />
3D accelerator card? Hmm. One day maybe...? ;-)<br />
<br />
Anyway, it's really up to you as to what looks right and at what <br />
point it stops looking like a wall pattern and more like a bunch of <br />
large square pixels. Working towards high quality textures means <br />
bigger textures and even more space taken up by the graphics. <br />
<br />
Obviously, programming such a view for just a roguelike game<br />
is no small fear either when compared to the original text-mode (or<br />
even the other styles mentioned in this document). How you present <br />
your 3D environment is up to you. Possible options are the fully<br />
submersing environments of Quake/Mario64. Or you could go for an<br />
isometric display such as Bullfrog's Dungeon Keeper. <br />
<br />
Badly drawn example... Yeah, right.<br />
<br />
----//---- <br />
<br />
# Issues<br />
<br />
Some problems you might want to take into consideration when working<br />
on your graphics...<br />
<br />
# Colour Depth.<br />
<br />
Colour depth is essentially how many colours you're allowed to <br />
create your wondrous and vivid roguelike graphics. Basically there is <br />
two camps. The programmers want the less number of colours possible <br />
and the artists generally want the most. The exception to the <br />
programmers is when the programmer in question doesn't care how much <br />
space the game takes or already has the code to handle higher colour <br />
depths. The exception with artist is when you find an artist who knows <br />
they can get the same effect with less colours.<br />
<br />
A set of tiles that only use a palette of 16 colours but have <br />
been stored as in a graphic format that utilises 65,000 colours uses <br />
up more memory than exactly the same tile set in a format that only <br />
allows for only 16 colours needed. If your tiles only take up a small <br />
range of colours, that 16bit (or 24bit) mode could be a waste of time. <br />
And if you can get beautiful tiles with 16 colours, programmers will <br />
love you. :)<br />
<br />
Again, it's a balance. Try some test tiles first. If you've got<br />
a list of the tiles needed, experiment with some fairly mis-matched <br />
sets and see how they stand up to the lower colour depths. If you're <br />
not happy with how they are working out, move up to the next depth. <br />
Remember though, an artist may have to compromise the graphics he/she <br />
creates to work within limits. Do the best you can with the tools <br />
available and the boundaries you are set.<br />
<br />
<br />
# Tile Size & Screen Size.<br />
<br />
In a perfect world, all players would have limitless hard-drive <br />
space, screen-resolutions that stretch into the ten-thousands and <br />
download the several hundred meg your game takes up in a second. <br />
Problem is, it doesn't work like that. Once again, file-size is <br />
affected by the choice you make over tile sizes. Deciding to expand <br />
your tiles from 16x16 pixels to 32x32 pixels will increase the file <br />
space each tiles takes up by 4. If the programming has decided they <br />
want tiles for each of the five-hundred different flavours of gnome <br />
they've implemented, we're talking of a big increase.<br />
<br />
Can you do everything you want with 16x16? Can you get all the <br />
detail you need and is the detail really necessary? In some cases, a <br />
good artist can 'imply' detail in a very small space. Do you really <br />
need to see the texture on the knight's chain mail or would a light <br />
grey mesh give the same impression?<br />
<br />
Another point to take into consideration is the screen size. A <br />
small screen size and a large tile size could cause trouble and <br />
restrict the amount of 'dungeon' you can see at one time. Small tiles <br />
on a huge screen could mean the player has trouble making out the <br />
tiles and misses out important details. Again - balance.<br />
<br />
See what the programmer wants. How many tiles do they want <br />
onscreen. Make sure that they understand how big that would allow you <br />
to make the tiles. A sample screen knocked up in five minutes is <br />
usually a good visual aid for both you and the programmer. Does it <br />
look right?<br />
<br />
If there is a lot of other information needed onscreen, the <br />
amount of screen left over to the level window may be cut down. Make <br />
sure you take all of that into consideration.<br />
<br />
<br />
# Resizing or Reducing Colours.<br />
<br />
Okay. You've created all your tiles. Five hundred gnomes of all <br />
shapes, sizes and colours. All in 64x64 pixel, 24bit colour tiles. The <br />
programmer gets in touch and tells you that they can't use them. They <br />
need 16x16, 16 colour. Bugger...<br />
<br />
Well, you've got three choices - call it a day, move to Tibet <br />
and take up the serene life of a monk or restart from scratch or start <br />
reducing tile size and colour depth. In the extreme case stated above, <br />
the reduction is going to pretty much murder your graphics and perhaps <br />
restarting is the only way to go. In other situations, when you only <br />
need to reduce the colour depth or just resize, you might just get <br />
away with it.<br />
<br />
One thing to remember when reducing colours, it always helps to <br />
choose a good utility/art package. The best way to test this is to use <br />
it with other graphics first. Choose a picture (maybe a scan of some <br />
sort) with a fair spread of colours and detail. Reduce the colours. If <br />
you're coming down from 24bit to 16bit, chances are you won't notice <br />
the reduction but down to anything less and the package has to create <br />
it's own palette of used colours.<br />
<br />
Most often, it's a best-fit and most-used kind of technique. <br />
Some packages offer different methods for reduction and some use a <br />
dithering algorithms to fool the eye. Sometimes it even works. <br />
Remember though, you may be reducing the colours of some fairly small <br />
tiles and when they begin to repeat in the game, the pattern these <br />
dithered tiles create may become very noticeable. The key to reduction <br />
is getting a good palette. Again, this depends on the tool you use.<br />
<br />
One thing I have noticed is once your package has reduce the <br />
colours, it tends to organise the colours in the palette in a manner <br />
which I find a little 'random'. Personally, I like my colours divided <br />
up into nice hue sets but after reduction, most packages generate <br />
light-to-dark range or that bizarre mac-style organisation that I <br />
dislike so much :) It's a little gripe but remember that if you're <br />
drawing more tiles after the reduction, finding the exact colour <br />
you're after may become a pain in the ass.<br />
<br />
Resizing is another matter. Most resizing does cause your tiles <br />
to lose all their detail and essentially makes touching-up afterwards <br />
a must. Some packages anti-alias or blur the tiles to cover the loss <br />
of detail. This is all very nice within the tile but you've got tiles <br />
with areas that are supposed to be transparent (for overlaying onto <br />
floor tiles, etc.) then the program tends to blur the edges of the <br />
shapes and destroy the clean edge you need. A good package will allow <br />
you turn this off. <br />
<br />
<br />
# 1001 Monsters.<br />
<br />
Not just monsters but potions, swords, shields, helmets, <br />
scrolls, spell-books, traps, walls, floor, stairs, food... well, you <br />
get the idea. When you think of all the tiles you may be called on to <br />
draw, you start begin longing for those simple ascii-characters. When <br />
drawing your tiles, it's always a good start to have some sort of idea <br />
of how many monsters, etc. will be required. If you need several <br />
different types of mold (green mold, yellow mold, red mold, blah-blah-<br />
blah), you would probably be able to get away with the same graphic<br />
but with changes to the colour. It saves time and allows you <br />
concentrate on making the basic mold design stand out from your other <br />
creatures.<br />
<br />
It is also useful to find a theme within creatures. If you need <br />
several ranks of orc, maybe changing their size and armour might help. <br />
If you have a set of monsters that have a specific trait (nether <br />
beasts, lava beasts), it'll help player recognition if you style those <br />
creatures similarly. <br />
<br />
<br />
# 3D packages.<br />
<br />
All styles can enjoy the benefits that using a 3D package can <br />
give. For the 2D bitmap tiles, building your objects and monsters with <br />
a 3D package means that size or colour depth isn't really an issue any <br />
more. The object you create can be rendered from any angle, at any <br />
size and with varying amounts of colour (if the package you're using <br />
is any good in the first place). And because the output is from the 3D <br />
package itself, outputting a smaller render will generally give a <br />
better result than trying to reduce the size of the tile with another <br />
graphics utility. <br />
<br />
Ofcourse, the amount of work required initially is massively <br />
increased as you need to model all the objects you wish to show. The <br />
benefit comes from the flexibility afterwards. For the user wishing to <br />
create modeled creatures for a Quake-style roguelike, a 3D package is <br />
essential. I'm sure there are people out there who can quite happily <br />
create some very good models with a pencil and graph paper but with<br />
so many cheap and shareware modelers on the market, save yourself the <br />
bother.<br />
<br />
<br />
# Size matters? <br />
<br />
Okay, first you're asked to draw a mouse and then you're asked <br />
for a poison breathing dragon. Do your work in scale? Draw a mouse <br />
that takes up a tile then draw a dragon that fills half the screen? <br />
'Course not. If you're drawing a dragon that takes up a tile but a <br />
mouse in scale would be hard pushed to fill a pixel. It takes some <br />
getting used to be it's usually a good idea to throw scale out of the <br />
window. Just pretend that mouse is really, really, really close. :)<br />
<br />
<br />
# Conclusion.<br />
<br />
As you've probably gathered by now, how you go about creating <br />
your graphics depends largely on the games needs. If you have been set <br />
limits either by the programmer or the hardware you're aiming for, <br />
always experiment to get the best you can from the tools you have <br />
available. If you're given an open-ended project with no definite <br />
requirements, planning will save you a lot of work in the long run. <br />
Decide which colour depth and tile size is best for the game and stick <br />
with it.<br />
<br />
Whatever style you choose, its all a question of whether your <br />
roguelike needs these graphics. Do they honestly add something to the <br />
game? Ignore those who automatically scream 'no!' or have built up <br />
some kind of barrier to considering the option. Graphics are just <br />
another feature to add to your game. Like everything you add, whether <br />
it works or not is up to you.<br />
<br />
= Object Representation - Sean Middleditch [sean.middleditch@iname.com]. =<br />
<br />
Representing objects in a roguelike. A difficult thing to do, in fact. When<br />
I started War of the Runes, I wasn't sure exactly how to go about doing it.<br />
Would everything be hard coded into the game? Would objects be malleable?<br />
What kinds of different objects need to be represented?<br />
<br />
Well, for starts, I knew I didn't want anything to be hard coded. One thing<br />
about War of the Runes is that EVERYTHING would need to be able to be changed.<br />
So objects need to be stored in external files, with all descriptions of the<br />
object need to be stored; from description, to behavior, to properties. And<br />
this also means all objects needed to be malleable. the state of an object can<br />
change at any time through any number of ways. And what kinds of objects were<br />
there? There's weapons and armor, food and drink, doors, chests, bags, rings,<br />
books, anything that can exist in a real world.<br />
<br />
So what is the best way to represent objects in a roguelike? Well, first we<br />
need to start with an object class:<br />
<br />
class Object {<br />
public:<br />
<br />
What kind of data do we need for objects? For starts, we need to know what<br />
the object is. We can do this with a name and a description;<br />
<br />
char *Name, *Desc;<br />
<br />
That's fairly self-explanatory. Information about where the object is would<br />
be useful, too:<br />
<br />
int X, Y;<br />
<br />
There are lots of different objects in the roguelike universe. Armor,<br />
weapons, books, rings, potions, lawn-chairs, etc. Each object can only be<br />
of one type.<br />
<br />
int ObjType;<br />
<br />
This field will be set to a value we define with #define's.<br />
<br />
#OBJ_WEAPON 1<br />
#OBJ_ARMOR 2<br />
#OBJ_POTION 3<br />
<br />
You get the idea. Every different type of object in the game would need a<br />
separate number. This will help in a LOT of areas. For example, characters<br />
can only equip items of type 2 (armor).<br />
<br />
Since I'm sure some of you may be a bit confused (I know I'm not the best of<br />
teachers) why don't we start defining an example item before we continue? A<br />
longsword.<br />
<br />
We'd set the Name field to point to "long sword". Simple enough. The Desc<br />
field would be "a long, sharp, metal stick". Well, you may want to use<br />
something other than that.<br />
<br />
The X,Y coordinates can be set to whatever... let's say 2,10.<br />
<br />
What about the object type? 1 (OBJ_WEAPON) of course!<br />
<br />
Now what? What does a longsword do? The game knows it's a weapon, but the<br />
game needs more information than that.<br />
<br />
Let's make a class to define what an object does.<br />
<br />
class ObjArg {<br />
public:<br />
<br />
Each ObjArg will define one aspect of an object. We'll need a way to store<br />
what each ObjArg defines.<br />
<br />
int ArgType;<br />
<br />
We'll give this meaning through the use of more defines.<br />
<br />
#define OARG_ATTACK 1<br />
#define OARG_DEFEND 2<br />
#define OARG_HEAL 3<br />
<br />
Now we know what an ObjArg defines. Now we need to store the actual<br />
definition. We'll do this by storing an array of 5 integers.<br />
<br />
int Args[5];<br />
<br />
And that's all there is to the ObjArg class. The meaning of the Args<br />
array's field will depend on the value of ArgType.<br />
<br />
Now, we want every object to be pretty versatile, so we'll make it so<br />
every object has 5 of the ObjArg classes.<br />
<br />
} Defines[5];<br />
<br />
And that's all we need for a basic Object class<br />
<br />
};<br />
<br />
So how does the ObjArg class work? Well, for our longsword, we'll need<br />
only one. It's ArgType will be set OARG_WEAPON. Now what about the<br />
Args array? Let's say for ArgType 1 (weapon), the first field of Args<br />
is the number of damage dice, the second field is sides per die, the<br />
third field is damage modifier, and the fourth field is the modifier<br />
to the character's skill. The fifth field will be unused.<br />
<br />
So, if we wanted long sword's to cause 1 to 8 damage, with no<br />
additional modifiers to damage or attack skill. So...<br />
<br />
Args[0] = 1<br />
Args[1] = 8<br />
Args[2] = 0<br />
Args[3] = 0<br />
<br />
Now if the character equips the long sword and attacks, we'll first<br />
check to see what kind of object is in the character's hand. We see<br />
the ObjType field is set to 1 (weapon). OK, so he/she can attack with<br />
that object. Now we'll look through the Defines array until we find an<br />
ObjArg entry whose ArgType is set to 1 (attack). The game see that<br />
Defines[0].ArgType = 2, so we'll use that ObjArg to look up the weapon's<br />
statistics. The game checks Defines[0].Args[3] = 0, so there's no skill<br />
modifier. The game does whatever combat system and determines the<br />
character hit. It check the damage (Args fields 0, 1, 2) and sees that<br />
the long sword does 1d8+0 damage. The game rolls the damage, hurts the<br />
target, etc.<br />
<br />
Well, that's all you need for simple objects. Although, you could do a<br />
LOT more, using the sample code I've given here as a base. For example,<br />
some ObjArgs are in effect whenever an item is equipped (the long sword's<br />
attack field, or armor's defend field). Some objects, like potions,<br />
don't effect unless a character uses the object (or in the case of objects<br />
with ObjType = 3, the character quaffs the potion). Only then will their<br />
ObjArg fields (like healing, in the case of a potion of healing) take<br />
effect. So you might want to store how many times an object can be used,<br />
and how many times it has been used.<br />
<br />
The complete code for the Object class is:<br />
<br />
#define OBJ_WEAPON 1<br />
#define OBJ_ARMOR 2<br />
#define OBJ_POTION 3<br />
<br />
#define OARG_ATTACK 1<br />
#define OARG_DEFEND 2<br />
#define OARG_HEAL 3<br />
<br />
class Object {<br />
public:<br />
<br />
char *Name, *Desc;<br />
<br />
int X, Y;<br />
<br />
int ObjType;<br />
<br />
class ObjArg {<br />
public:<br />
<br />
int ArgType;<br />
<br />
int Args[5];<br />
} Defines[5];<br />
};<br />
<br />
If you have any questions, feel free to e-mail me at<br />
sean.middleditch@iname.com<br />
<br />
The End<br />
<br />
= Inventory Abstraction - Kenneth Power [uncle_wiggly@bigfoot.com]. =<br />
<br />
An Inventory tracks Items in Storage. Items are anything you deem <br />
trackable: gloves, clubs, food, coins, flowers. Storage is anything<br />
defined as able to hold items: chests, sacks, hands, buildings.<br />
<br />
A basic Inventory does not care about extraneous fluff, such as <br />
container limitations. Keeping inventory implementation basic enables <br />
code reuse as discussed later.<br />
<br />
Throughout this paper, psuedo code is used to model examples. The <br />
examples use the following sample item definition:<br />
<br />
define Item:<br />
variable Name<br />
<br />
<br />
Tracking items<br />
There are two basic ways to track items. First is with a simple list, <br />
rather like writing a list of groceries. Lists usually are FIFO (First <br />
in First out) or LIFO (Last in First out). Other ways may exist. Indeed <br />
in some languages, there are very exotic forms of lists. A trouble with <br />
lists is the retrieval of information from the middle of the list. The <br />
list is examined from either end until the information is located.<br />
<br />
Our example simple list:<br />
<br />
list define Inventory<br />
<br />
Second is through a more complex scheme wherein more than the item is <br />
tracked. Also tracked is information about the item. This is so items <br />
may be grouped. Grouping has its pro's and con's like anything else. <br />
Use of grouping, for example, allows easier display of items (in my own <br />
opinion of course). In a way, grouping is a more esoteric list form, <br />
using such things as dictionaries, maps and other terms. <br />
<br />
In this example, the items are tracked by their name. Example:<br />
<br />
list define Inventory:<br />
list define itemNames<br />
keyedList define qtys<br />
<br />
<br />
Add items<br />
What use is an Inventory if you are not able to add items to it? Thus,<br />
the first function we define is the add() function. <br />
<br />
In basic form, add() only wants to place the passed item to the list:<br />
<br />
List define Inventory:<br />
define add(item):<br />
insert item<br />
<br />
With the complex form, add() is more detailed. Questions are raised: <br />
is the item already in inventory - this might affect or tracking <br />
feature-? Did I/you make an adjustment to the tracking feature if <br />
necessary? Note how this is done in the example: <br />
<br />
list define Inventory:<br />
list define itemNames<br />
keyedList define qtys<br />
define add(item):<br />
if item is in me.itemNames #do I exist?<br />
then me.qtys.key(item.name) = +1<br />
if item is not in me.itemNames #I don't exist<br />
then me.qtys.key.add(item.name)<br />
me.itemNames.add(item.name)<br />
me.qtys.key(item.name) = +1 <br />
<br />
<br />
Remove items<br />
The remove() function is really the opposite of add(). Find the item <br />
passed and remove it from the list. Let's examin it with our two <br />
pseudo codes.<br />
<br />
Of course, this example doesn't take into consideration language <br />
dependent behavior (C - did you fix your pointers?). Thus the <br />
abstraction is the same for add():<br />
<br />
List define Inventory:<br />
define remove(item):<br />
delete item<br />
<br />
Here, as in the complex add() function, more work needs accomplished. <br />
We not only find the item, but we make certain our tracking feature <br />
is adjusted accordingly.<br />
<br />
list define Inventory:<br />
list define itemNames<br />
keyedList define qtys<br />
define remove(item):<br />
if item is in me.itemNames<br />
then me.qtys.key(item.name) = -1<br />
if me.qtys.key(item.name) == 0<br />
then me.qtys.delete(item.name)<br />
if item is not in me.itemNames<br />
then error<br />
<br />
At the completion, our example would show the proper quantity for the <br />
item. Plus, if we have no more item in inventory, no quantity or <br />
listing will exist.<br />
<br />
<br />
Display items (opt.)<br />
This is listed as optional, because you may not code Inventory display <br />
as part of your Inventory. It may be in your UI code. However, during <br />
testing, having a simple Inventory Display feature is very useful.<br />
<br />
Like always, the simplest way is the list method. Merely iterate the <br />
list, printing each item: <br />
<br />
List define Inventory:<br />
define display():<br />
For each item in Inventory:<br />
print item.name<br />
<br />
Because of our tracking feature, we need print item and qty. Otherwise <br />
uncertainty will exist. The only added feature of the complex over <br />
simple is the header printed "Item Qty". <br />
<br />
List define Inventory:<br />
define display():<br />
print "Item Qty"<br />
for each item in me.itemNames:<br />
print item, me.qtys.key(item.name)<br />
<br />
<br />
Possible benefits<br />
For developers using OO style languages (C++, SmallTalk, Java, etc), <br />
having a simple Inventory Object lets you easily include it in other <br />
areas of the game. Containers (combinations of Items and Inventory), <br />
Buildings (Structure and Inventory), and more can be made. Of course <br />
non-OO languages(C, Pascal, Basic) can use Inventory as functions in <br />
other parts of the game. The point is: once you define what a basic <br />
inventory will be in your game, find how to use it in more areas.<br />
<br />
An Example<br />
Here is an example inventory, using the Python language. I find Python <br />
to be a grat language for prototyping. It is easy to spot errors, fix <br />
them, etc. Then you may easily recode in any other language.<br />
<br />
The Item Object - <br />
class Item:<br />
def __init__(self, name): #object constructor<br />
self.name = name<br />
The Inventory Object -<br />
class Inventory:<br />
def __init__(self):<br />
self. NameList = [] #a list of item names<br />
self.qtys = {} #a dictionary of item quantities<br />
self.contents = [] #a list of actual items<br />
def add(self, itemList = []):<br />
for item in itemList:<br />
#Check item is self<br />
if item is self:<br />
print 'Cannot store', item,' in itself!'<br />
if item in self.contents:<br />
print 'You already have this item!'<br />
else:<br />
#Check if item is in nameList<br />
if item.name in self.NameList:<br />
#merely insert<br />
self.qtys[item.name] = self.qtys[item.name] + 1<br />
#otherwise add to nameList<br />
else:<br />
self.qtys[item.name] = 1<br />
self.nameList.append(item.name)<br />
self.contents.append(item)<br />
def remove(self, item):<br />
#does item exist?<br />
If item not in self.contents:<br />
print item.name, 'is not in your inventory'<br />
else:<br />
self.qtys[item.name] = self.qtys[item.name] - 1<br />
if self.qtys[item.name] == 0:<br />
del self.qtys[item.name]<br />
self.NameList.remove(item.name)<br />
self.contents.remove(item)<br />
def display(self):<br />
#let's show everything!<br />
Print "Item\tQty"<br />
for item in self.NameList:<br />
print item,"\t", self.qtys[item]<br />
<br />
<br />
More Info<br />
For information about Python, visit: http://www.python.org<br />
Please send all comments, queries, and error notifications to the author.<br />
Written by: Ken Power email: uncle_wiggly@bigfoot.com<br />
Version: 1.0 Date: Oct. 25, 1999</div>Stuhttp://roguebasin.com/index.php?title=User:Duerig/Archive4&diff=12847User:Duerig/Archive42008-05-02T13:32:02Z<p>Stu: Fix another really old article of mine</p>
<hr />
<div>= Recursive Level Generation - Radomir 'The Sheep' Dopieralski [sheep@venus.wmid.amu.edu.pl] =<br />
<br />
Introduction.<br />
-------------<br />
This article contains some of my thoughts about level generation in roguelike<br />
games. It's inspired with an algorithm used in Alphaman to generate buildings,<br />
some articles red on Roguelike News and, that's a little odd, Bison and Yacc<br />
input files format. The ideas may seem a little complicated and hard to<br />
implement, but I hope the article proves useful in some way.<br />
<br />
<br />
Overview.<br />
---------<br />
The idea is to describe the level in form similar to BNF (Backus-Naur Form),<br />
used usually for describing context-free grammars.<br />
<br />
<br />
It's natural for humans to describe large and complicated objects in terms of<br />
more simple ones. So we can describe a level.<br />
For example:<br />
<br />
a level is either: a maze, a dungeon, a cave, a castle, etc...<br />
<br />
<br />
a maze is a set of connected corridors and crossroads.<br />
<br />
<br />
a corridor is a vertical or horizontal line of floor tiles, surrounded<br />
by walls on each side, opened at at least one end.<br />
<br />
<br />
a crossroad is a single floor tile with walls around, opened in at least two directions.<br />
<br />
<br />
a dungeon is a set of rooms, crossroads and corridors.<br />
<br />
<br />
a room is either: a vault, a minor vault, an ordinary room.<br />
etc...<br />
<br />
<br />
There are some rules not covered here. For example, we'd like to ensure each<br />
place of the level is reachable. It's not very easy to do, so we won't try to<br />
describe any level type, like in the example above. We'll try to only describe<br />
(and then generate) some special level type, constructed by dividing rooms.<br />
<br />
<br />
Alphaman's buildings.<br />
---------------------<br />
We will use an algorithm similar to this used in Alphaman. I'll first describe<br />
the original algorithm. It is quite simple:<br />
<br />
<br />
1. Start with a large, empty room.<br />
XXXXXXXXXXXXXXXXX<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
XXXXXXXXXXXXXXXXX<br />
<br />
<br />
2. Pick an acxis (horizontal or vertical) and a point within the room (far from walls).<br />
Let's suppose we have picked horizontal axis and point marked with '1'.<br />
XXXXXXXXXXXXXXXXX<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X......1........X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
XXXXXXXXXXXXXXXXX<br />
<br />
3. Make a wall in selected axis, crossing the chosen point, ending at the<br />
room's walls and with door in point '1'.<br />
XXXXXXXXXXXXXXXXX<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X######+########X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
XXXXXXXXXXXXXXXXX<br />
<br />
4. You get two new rooms. Repeat the procedure with those of them, that arte large enough.<br />
XXXXXXXXXXXXXXXXX<br />
X...............X<br />
X...............X<br />
X###########+###X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X######+########X<br />
X.........#.....X<br />
X.........+.....X<br />
X.........#.....X<br />
X.........#.....X<br />
X.........#.....X<br />
XXXXXXXXXXXXXXXXX<br />
<br />
5. You end up with set of interconnected rooms, with exactly one way between<br />
every two rooms. Something like a tree.<br />
<br />
The procedure is simple, but the result is not very nice. It's always a<br />
labirynth of rooms and you usually have to walk a lot to explore it. We'll try<br />
to make the result better.<br />
<br />
Adding corridors.<br />
-----------------<br />
We can try to add some corridors, so our level will look more naturally and<br />
there will be more connections between rooms.<br />
So, instead of adding a wall, we'll add two parallel walls, making a corridor.<br />
We also add doorways at the ends of the corridors, so there will be more<br />
connections. The algorithm goes like this:<br />
<br />
1. Start with a large, empty room.<br />
XXXXXXXXXXXXXXXXX<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
XXXXXXXXXXXXXXXXX<br />
<br />
2. Pick an acxis (horizontal or vertical) and a point within the room (far from walls).<br />
Let's suppose we have picked horizontal axis and point marked with '1'.<br />
XXXXXXXXXXXXXXXXX<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X......1........X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
XXXXXXXXXXXXXXXXX<br />
<br />
3. Make a corridor in selected axis, crossing the chosen point, ending at the<br />
room's walls. If the walls at it's ends are not permanent, make some doorways<br />
there.<br />
XXXXXXXXXXXXXXXXX<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X###############X<br />
X......1........X<br />
X###############X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
XXXXXXXXXXXXXXXXX<br />
<br />
4. Make some doors along the corridor's walls. There should be at leas one door<br />
in each wall, so you make sure all the rooms are connected.<br />
XXXXXXXXXXXXXXXXX<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X####+######+###X<br />
X......1........X<br />
X###+###########X<br />
X...............X<br />
X...............X<br />
X...............X<br />
X...............X<br />
XXXXXXXXXXXXXXXXX<br />
<br />
5. You get two new rooms. Repeat the procedure with those of them, that are large enough.<br />
XXXXXXXXXXXXXXXXX<br />
X...............X<br />
X###+###########X<br />
X...........2...X<br />
X#####+#####+###X<br />
X...............X<br />
X...............X<br />
X####+######+###X<br />
X......1........X<br />
X###+#####.#####X<br />
X........#3#....X<br />
X........#.+....X<br />
X........+.#....X<br />
X........#.#....X<br />
XXXXXXXXXXXXXXXXX<br />
<br />
The result doesn't look so bad, especially if the rooms left at the end are big<br />
enough (in the example there isn't much place). <br />
But there is another problem -- how to fill the rooms with appropriate contents<br />
(that is items and monsters)? How to make sure the rooms are connected with<br />
some logic?<br />
<br />
Level definitions.<br />
------------------<br />
Here's what we can do. We don't just split in two similar rooms. We will have<br />
to name these rooms and provide some rules how to split them. For example, for<br />
a scientific level in sf roguelike:<br />
<br />
a level may: (put some probabilities here)<br />
be a scientific level;<br />
<br />
a scientific level must:<br />
be at least SIZE large, but not larger than SIZE;<br />
<br />
a scientific level may:<br />
consist of two scientific sections, divided (horizontally or<br />
vertically) with a scientific hall;<br />
<br />
a scientific hall may:<br />
be a very wide corridor, with large doors at each end and at least one<br />
door at each side;<br />
there may be some plants or statues;<br />
there may be some scientific guards;<br />
there may be some scientific monsters;<br />
tehre may even be some scientific scientifists;<br />
<br />
a scientific section may:<br />
consist of two scientific sections divided (horizontally or vertically)<br />
with a scientific corridor;<br />
<br />
a scientific corridor may:<br />
be a wide corridor with open doorways at each end and at least one door<br />
at each side;<br />
<br />
a scientific section must:<br />
be at least SIZE large, but not larger than SIZE;<br />
<br />
a scientific section may:<br />
consist of two scientific labs divided (horizontally or vertically)<br />
with a scientific corridor;<br />
<br />
a scientific lab must:<br />
be at least SIZE large, but not larger than SIZE;<br />
<br />
a scientific lab may:<br />
consist of two scientific labs divided with a scientific wall;<br />
<br />
a scientific wall may:<br />
be a wall with door in the middle;<br />
<br />
a scientific lab may:<br />
be a room with tiled floor;<br />
there may be some scientific artifacts;<br />
there may be some scientific monsters;<br />
there may even be some scientific scientifists;<br />
<br />
Building a level.<br />
-----------------<br />
Now, let's see how to produce a random level from such an information.<br />
First, we want to build a level. So we look at the definitions and see that our<br />
level may be a scientific level with such-and-such probability. But there may<br />
be also other level definitions, so we have to choose (randomly) which level<br />
definition to choose. Let's suppose we have chosen the scientific level. We<br />
see that it has to be such-and-such big, so we provide an empty starting room<br />
of given size.<br />
Now we look into the definion and see that we have to split our level in two<br />
with a scientific hall and put a scientific section on each side. So we pick a<br />
point, pick an axis, put aour corridor in the middle and a scientific section<br />
at each side. It would be good to pay attention on the minimal size of each of<br />
the sections while picking a point to split the level. Then, we have to make<br />
our scientific sections. As we look into definitions, we see that we have two<br />
choices. So we pick randomly one of them.<br />
We can either split these sections into smaller ones, or into scientific labs.<br />
At some points, we'll have to do the second thing, because there will be no<br />
place to put a scientific section (which is supposedly larger than a lab). We<br />
continue down the tree of level fetures, until we arrive at the 'atom' ones,<br />
that is the features that doesn't consist of other features, and taht we can<br />
generate using other algorithms.<br />
Sometimes there may be need for the algorithm to 'back up' wrong decissions,<br />
because there is no way it can get to the atoms. This is because of the size<br />
limitations. It's a drawback and I don't know how to make sure it ever<br />
completes the level.<br />
But I believe it can be solved somehow.<br />
<br />
Level representation.<br />
---------------------<br />
With this algorithm you can use different level representations. The most<br />
common, simple two-dimensional array will do. But you can also have a linked<br />
list of features, or even a binary tree. If there were no doors at the ends of<br />
the corridors, you could even generete only these parts of the level you need<br />
at the moment, making all the fetures from the root of the tree to the node you<br />
want to know.<br />
<br />
-- <br />
The Sheep<br />
<br />
= Finding Explorable Regions - Ross Morgan-Linial [rmorgan@jetcity.com]. =<br />
<br />
This program takes a map and divides it into regions that are fully <br />
connected - that is, not split in half by walls, so the player can <br />
get anywhere in the region starting from a random point. I wrote it <br />
to determine if all of a dungeon level can be reached from the <br />
stairs, but you might find other uses for it; for example, you could <br />
use the results to find out where corridors need to be added to <br />
result in a fully connected level. Without further ado, here it is.<br />
<br />
#include <stdio.h><br />
<br />
/*<br />
* This program divides a set of 'grids', which can be either wall or<br />
* floor, into connected regions. Every grid in a region is connected<br />
* to every other square in that region by vertical or horizontal (not<br />
* diagonal) connections, and not connected to grids in any other<br />
* region.<br />
*<br />
* We maintain a map that shows which region each grid is in. To avoid<br />
* iterating over the entire map every time we discover two candidate<br />
* regions are joined, we use a table that maps the numbers used on<br />
* the grid to actual region numbers. At the end of the computation,<br />
* we renumber the grid using this table.<br />
*/<br />
<br />
/* Change this to 1 to see how it works */<br />
#define debug 0<br />
<br />
#define MAP_WIDTH 12<br />
#define MAP_HEIGHT 12<br />
<br />
/*<br />
* Our map - 0 is wall, 1 is floor.<br />
*<br />
* We have to have a border of walls, or we may get strange errors.<br />
*/<br />
char grid[MAP_HEIGHT][MAP_WIDTH] = {<br />
{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},<br />
{0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0},<br />
{0, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 0},<br />
{0, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1, 0},<br />
{0, 1, 1, 0, 0, 0, 0, 1, 1, 0, 0, 0},<br />
{0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 1, 0},<br />
{0, 0, 1, 1, 0, 1, 1, 0, 0, 0, 1, 0},<br />
{0, 0, 0, 1, 1, 1, 0, 0, 0, 1, 1, 0},<br />
{0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0},<br />
{0, 1, 1, 1, 0, 0, 0, 0, 1, 1, 0, 0},<br />
{0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0},<br />
{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}};<br />
<br />
#define MAX_REGIONS 16<br />
#define NO_REGION 0 /* 0 is also a valid region */<br />
<br />
int region_grid[MAP_HEIGHT][MAP_WIDTH];<br />
int region_map[MAX_REGIONS];<br />
int num_regions;<br />
<br />
/*<br />
* To reduce processing time, when two regions are found to connect<br />
* (they're really the same region), we just mark them as the same<br />
* without actually renumbering grids. At the end of the computation,<br />
* or if we run out of region numbers, we use this function to update<br />
* all grids to true region numbers. It also compacts the region<br />
* numbers, so that afterwards all region numbers 0..num_regions-1<br />
* are still used.<br />
*/<br />
void remap_regions(void)<br />
{<br />
int region_index[MAX_REGIONS];<br />
int region_index2[MAX_REGIONS];<br />
int new_regions;<br />
int x, y;<br />
int i;<br />
<br />
new_regions = 0;<br />
<br />
/*<br />
* Iterate through the regions, and assign a new number to each<br />
* non-remapped region so that they'll end up compacted.<br />
*/<br />
for (i = 0; i < num_regions; i++)<br />
{<br />
/* Has this region not been mapped to another region? */<br />
if (region_map[i] == i)<br />
{<br />
/* No, it hasn't. Assign it a new region number. */<br />
if (debug)<br />
{<br />
printf("Mapping region: #%i -> #%i\n", i, <br />
new_regions);<br />
}<br />
region_index[i] = new_regions++;<br />
}<br />
else<br />
{<br />
/* It's been renumbered. Check for processing errors. */<br />
if (region_map[region_map[i]] != region_map[i])<br />
{<br />
/*<br />
* We've encountered a bug: this region has been<br />
* mapped to a region that has also been mapped. Give<br />
* an error and abort.<br />
*/<br />
fprintf(stderr, "Map %i->%i->%i\n", i, region_map[i],<br />
region_map[region_map[i]]);<br />
abort();<br />
}<br />
<br />
/* Assign an in-bounds but otherwise meaningless value. */<br />
region_index[i] = NO_REGION;<br />
}<br />
}<br />
<br />
/*<br />
* Construct a table of the double-indirection through remapping<br />
* and compaction.<br />
*/<br />
for (i = 0; i < num_regions; i++)<br />
region_index2[i] = region_index[region_map[i]];<br />
<br />
/* Renumber the grids, using the table we just computed. */<br />
for (y = 0; y < MAP_HEIGHT; y++)<br />
for (x = 0; x < MAP_WIDTH; x++)<br />
region_grid[y][x] = region_index2[region_grid[y][x]];<br />
<br />
/* Create a new do-nothing region mapping table. */<br />
for (i = 0; i < new_regions; i++)<br />
region_map[i] = i;<br />
<br />
/* Save the new number of regions. */<br />
num_regions = new_regions;<br />
}<br />
<br />
/*<br />
* Join two candidate regions together. This just involves updating<br />
* the region remapping table.<br />
*/<br />
void join_regions(int r1, int r2)<br />
{<br />
int i;<br />
int r1_map, r2_map;<br />
<br />
/* We have to operate on primary (unremapped) regions here */<br />
r1_map = region_map[r1];<br />
r2_map = region_map[r2];<br />
<br />
if (debug)<br />
{<br />
printf("Joining regions #%i (%i) and #%i (%i)\n", r1, r1_map,<br />
r2, r2_map);<br />
}<br />
<br />
/* Modify the region mapping table. */<br />
for (i = 0; i < num_regions; i++)<br />
if (region_map[i] == r2_map)<br />
{<br />
if (debug)<br />
{<br />
printf("Mapping region #%i (%i) -> #%i\n", i,<br />
region_map[i], r1_map);<br />
}<br />
region_map[i] = r1_map;<br />
}<br />
}<br />
<br />
/*<br />
* Create a new region.<br />
*/<br />
int new_region(void)<br />
{<br />
int i;<br />
<br />
/* If we're out of regions, compact them. */<br />
if (num_regions >= MAX_REGIONS)<br />
{<br />
if (debug)<br />
printf("Remapping regions\n");<br />
remap_regions();<br />
}<br />
<br />
/* If we're still out of regions, we have a problem. */<br />
if (num_regions >= MAX_REGIONS)<br />
{<br />
fprintf(stderr, "Too many regions\n");<br />
abort();<br />
}<br />
<br />
/* Allocate a new region. */<br />
i = num_regions++;<br />
region_map[i] = i;<br />
<br />
if (debug)<br />
printf("New region: #%i\n", i);<br />
<br />
return i;<br />
}<br />
<br />
void find_regions(void)<br />
{<br />
int x, y;<br />
int i;<br />
<br />
if (debug)<br />
printf("Clearing region grid\n");<br />
<br />
/* Clear the region grid to a valid (but meaningless) value. */<br />
for (y = 0; y < MAP_HEIGHT; y++)<br />
for (x = 0; x < MAP_WIDTH; x++)<br />
region_grid[y][x] = NO_REGION;<br />
<br />
/* Initialize the remapping table to a null map. */<br />
for (i = 0; i < MAX_REGIONS; i++)<br />
region_map[i] = i;<br />
<br />
/* Start with no regions. */<br />
num_regions = 0;<br />
<br />
/* Consider each grid, except the borders (leave them as walls) */<br />
for (y = 1; y < MAP_HEIGHT - 1; y++)<br />
{<br />
for (x = 1; x < MAP_WIDTH - 1; x++)<br />
{<br />
/* Skip wall grids. */<br />
if (!grid[y][x])<br />
continue;<br />
<br />
if (debug)<br />
printf("(%i, %i) ", x, y);<br />
<br />
/* <br />
* Consider the possible combinations of left, above<br />
* grids.<br />
*/<br />
if (!grid[y - 1][x])<br />
{<br />
if (!grid[y][x - 1])<br />
{<br />
/* No floor left or above */<br />
region_grid[y][x] = new_region();<br />
}<br />
else<br />
{<br />
/* Floor left, but not above */<br />
if (debug)<br />
{<br />
printf("Copying over #%i\n", <br />
region_grid[y][x - 1]);<br />
}<br />
region_grid[y][x] = region_grid[y][x - 1];<br />
}<br />
}<br />
else<br />
{<br />
if (!grid[y][x - 1])<br />
{<br />
/* Floor above, but not left */<br />
if (debug)<br />
{<br />
printf("Copying down #%i\n", <br />
region_grid[y - 1][x]);<br />
}<br />
region_grid[y][x] = region_grid[y - 1][x];<br />
}<br />
else<br />
{<br />
/*<br />
* Floor both left and above - are they the same <br />
* region?<br />
*/<br />
if (region_map[region_grid[y - 1][x]] !=<br />
region_map[region_grid[y][x - 1]])<br />
{<br />
/* No, join them. */<br />
join_regions(region_grid[y - 1][x],<br />
region_grid[y][x - 1]);<br />
}<br />
<br />
/* They're now the same region, so copy one. */<br />
if (debug)<br />
{<br />
printf("Copying down #%i\n", <br />
region_grid[y - 1][x]);<br />
}<br />
region_grid[y][x] = region_grid[y - 1][x];<br />
}<br />
}<br />
}<br />
}<br />
<br />
/* Do a final remapping, to make the region_grid[][] accurate. */<br />
remap_regions();<br />
}<br />
<br />
/*<br />
* Print our results.<br />
*/<br />
void print_map(void)<br />
{<br />
int x, y;<br />
<br />
for (y = 1; y < MAP_HEIGHT - 1; y++)<br />
{<br />
for (x = 1; x < MAP_WIDTH - 1; x++)<br />
{<br />
if (grid[y][x])<br />
{<br />
printf("%c", 'A' + region_grid[y][x]);<br />
}<br />
else<br />
printf(" ");<br />
}<br />
printf("\n");<br />
}<br />
}<br />
<br />
int main(void)<br />
{<br />
find_regions();<br />
<br />
print_map();<br />
<br />
return 0;<br />
}<br />
<br />
= Representing the Dungeon - Brian Bucklew [bbucklew@inteletek.com]. =<br />
<br />
[Note: C++ Class Definitions Will Be Used Throughout]<br />
<br />
Section 1 : The Question<br />
<br />
One of the most important things in writing a computer game of<br />
any sort is the way in which you represent the universe the game takes<br />
place in. In a rogue-like, you will need to represent several things:<br />
<br />
#1. The Dungeon<br />
#2. The Slimy Things in The Dungeon<br />
#3. The Pointy Things with which a player kills Slimy Things<br />
#4. The Player that holds the Pointy Things<br />
<br />
This Article will cover #1: The Dungeon.<br />
<br />
Section 2 : The Dungeon<br />
<br />
Alright, we need to find some way to represent the corridors and<br />
rooms of The Dungeon itself. One of the easiest and most flexible methods<br />
of doing this is to create a two-dimensional array of cells. Each cell will<br />
be a wall, a floor, a door, a hideous spiked pit of death, or any number of<br />
other things we might want to represent as one tile:<br />
<br />
class Tile<br />
{<br />
public:<br />
<br />
int Type; // 0-Wall 1-Floor 2-Water 3-Open Door 4-Closed Door...<br />
unsigned int Flags; // see below...<br />
}<br />
<br />
Section 2b : Bit-Flags<br />
<br />
One of the more important and space-saving methods of information tracking<br />
is the use of bit-flags. As you know, a number in a computer is represented<br />
in binary, which is a series of ones and zeros... For instance the number<br />
14 might be represented as:<br />
00001110<br />
<br />
Now, say we need to keep track of a number of things about a tile... Is it<br />
lit? Is it explored? Is is permenatly dark? Is it hairy?<br />
<br />
We can use each individual bit in an integer to keep track of a true/false<br />
answer for questions like these.<br />
<br />
So, how do you single out an individual bit? Well, bitwise operators come to<br />
save the day.<br />
<br />
We can single out individual bits of a number by using the & (bitwise AND)<br />
operator. Each bit represents a power of two... So the first bit is 1, the<br />
second is 2 the third is 4 the fourth is 8 and so on... The & Operator<br />
takes two integers and returns an integer that only has 1 bits where the two<br />
origional integers BOTH had 1 bits... So to single out a bit, we take the<br />
variable containing the flags (Flags, in this case), and & it with the number<br />
represented by the bit we wish to read. If the returned number isn't zero,<br />
the flag is set, if it is zero the flag is not set...<br />
<br />
This is a bit confusing, I'm sure, so here's some examples:<br />
<br />
Example 1: (We'll use 16-bit integers to save space)<br />
<br />
Flags : 0101000010010100<br />
We want This Bit-^<br />
It's the fifth bit, so 2^4 = 16.<br />
16 is 0000000000010000... so<br />
<br />
Flags & 16 = ?<br />
<br />
Flags:0101000010010100 <br />
&&&&&&&&&&&&&&&&<br />
16:0000000000010000<br />
================<br />
0000000000010000;<br />
<br />
Which is greater than 0, so the flag is set...<br />
<br />
Example 2: <br />
<br />
Flags : 0101000010010100<br />
We want This Bit--^<br />
It's the fourth bit, so 2^3 = 8.<br />
8 is 0000000000001000... so<br />
<br />
Flags & 8 = ?<br />
<br />
Flags:0000000010010100<br />
&&&&&&&&&&&&&&&&<br />
8:0000000000001000<br />
================<br />
0000000000000000;<br />
<br />
Which is 0, so the flag is not set...<br />
<br />
Section 2c : Returning to The Dungeon...<br />
<br />
So we have our basic Tile class defined. All we need to do now is create<br />
an array of these tiles:<br />
<br />
Tile Map[256][256];<br />
<br />
Now, apply your favorite dungeon-generation method to this array of tiles and<br />
viola! You have a dungeon.<br />
<br />
Section 3 : Positional Representation<br />
<br />
Anything in your Dungeon is going to have a position within the<br />
Dungeon. This position is simply defined as an x and y coordinate within<br />
the 2D array of Tiles. If a player is at 16,19 we could look up the tile<br />
he is in using the line : Map[16][19], If the player is at 31,53 we could<br />
use Map[31][53]... So we can generalize and say that if the player had<br />
a position holding X and Y we could use the line : Map[Player.X][Player.Y];<br />
<br />
We might also want to extend a position definition by giving it a facing...<br />
<br />
8 1 2<br />
\ | /<br />
\|/<br />
7--*--3<br />
/|\<br />
/ | \<br />
6 5 4<br />
<br />
So...<br />
<br />
class Position<br />
{<br />
public:<br />
<br />
int X,Y; // Our (X,Y) Coordinates<br />
int Facing; // The direction this object is facing.<br />
}<br />
<br />
Everything in your dungeon should have a position. Each Monster,<br />
each item that is lying on the ground, and the player. This will allow you<br />
to keep track of each thing and their relations to one-another.<br />
<br />
The Author:<br />
Brian Bucklew, 18<br />
bbucklew@inteletek.com<br />
Current RL Project : Dungeon or "This game needs a new name"... :)<br />
Projected Beta Release : Early 98<br />
<br />
= Fun with dungeongeneration in QBasic - R.Alan Monroe.txt =<br />
<br />
I wondered what it would be like to do a random dungeon by repeatedly<br />
placing random sized "L" shaped hallways, each with a random 90 degree<br />
orientation, all over the map. Here's the results.<br />
<br />
This method doesn't guarantee that all areas are reachable. You get a<br />
lot of cul-de-sacs, which could be good or bad depending on your<br />
game...<br />
<br />
[fixed width font]<br />
<br />
#####################################################################<br />
#####################################################################<br />
################### ####### ######### ####### ########## # ##########<br />
################### ### ### ######## ####### ### ###### # ##########<br />
######## ######### ### ## ### ### ##### ### ###### # ### ######<br />
######## ## ## # ## ## # # ######<br />
######## ## # ### # ## ## ### ## # #<br />
##### ## # # # # #####<br />
#### #### # # # # ### ## ## # # #####<br />
###### # # # ## # # ## # # #####<br />
#### ## # ## # # # # #### # # # #####<br />
##### # ### # # ### ## # ## ##### #######<br />
##### ###### # # # # ## # ## ### ######<br />
##### ## #### # ##### ###### # #####<br />
##### # ############ ##### # ## # # ########### ########### #####<br />
##### ############## ########### # ########################## ######<br />
###### ########################## ############################ ######<br />
#####################################################################<br />
#####################################################################<br />
<br />
#####################################################################<br />
####### #################### ################################ #######<br />
####### ################ ### ### ############### ########### #######<br />
####### ############# ## ### ### ## #### # ##### #### ###### #######<br />
####### ######## ### ## ### ### ## ### ### # #### ## ### #######<br />
### ####### # # ###<br />
##### # ### # ## ## # # # ## #####<br />
### # # ## # # ## ####<br />
## # #### # # ## # # ## ## # # ####<br />
## # #### # ## # ## ## # # # # ########<br />
###### # # ## # ### # # # ########<br />
####### #### ## # ## #####<br />
########### #### # ##### ### ###<br />
##### ## ##### ### ## #### # #####<br />
######## ## ## ###### # ### ## ####### # ### #### # # #####<br />
######## ##### # ###### # #### ## ####### # ###### ##### #########<br />
######## ####### ################## ####### # ############ #########<br />
########################################### #########################<br />
#####################################################################<br />
<br />
#####################################################################<br />
#####################################################################<br />
######################### ##### ####################################<br />
######################## ##### ############# #####################<br />
####### ############### ##### ######### ### # ###################<br />
##### ### ###### ## # # # ## ## ### # ### ###############<br />
##### # # # ### # # ## ## ######<br />
##### # # ## ## ### # ####### ######<br />
##### # ### ## ### # ###### ####<br />
##### ### ## #### # # ## ## ### #####<br />
####### # # ## # ## ## ## # # ## # #####<br />
#### ## ## # # ##<br />
###### # ### ### ## ## ####<br />
###### # ##### ### #### # ###<br />
###### ##### ##### #### ### ### # ### ###### ### ###### # ######<br />
###### ##### ##### #### ### ### ## #### ###### ########## # ######<br />
###### ########### ############ ############## ########### ## #######<br />
################## ############ ############## ########### ## #######<br />
#####################################################################<br />
<br />
RANDOMIZE TIMER<br />
<br />
DIM a(70, 20)<br />
<br />
begin:<br />
<br />
CLEAR<br />
CLS<br />
<br />
FOR l = 1 TO 150<br />
x = INT(RND * 59) + 6<br />
y = INT(RND * 9) + 6<br />
d = INT(RND * 4)<br />
a(x, y) = 1<br />
SELECT CASE d<br />
CASE 0<br />
FOR i = 1 TO INT(RND * 5)<br />
a(x + i, y) = 1<br />
a(x, y - i) = 1<br />
NEXT i<br />
CASE 1<br />
FOR i = 1 TO INT(RND * 5)<br />
a(x + i, y) = 1<br />
a(x, y + i) = 1<br />
NEXT i<br />
CASE 2<br />
FOR i = 1 TO INT(RND * 5)<br />
a(x - i, y) = 1<br />
a(x, y - i) = 1<br />
NEXT i<br />
CASE 3<br />
FOR i = 1 TO INT(RND * 5)<br />
a(x - i, y) = 1<br />
a(x, y + i) = 1<br />
NEXT i<br />
END SELECT<br />
<br />
NEXT l<br />
<br />
FOR row = 1 TO 19<br />
FOR col = 1 TO 69<br />
IF a(col, row) = 0 THEN<br />
PRINT "#";<br />
ELSE<br />
PRINT " ";<br />
END IF<br />
NEXT col<br />
PRINT<br />
NEXT row<br />
<br />
WHILE INKEY$ = ""<br />
WEND<br />
<br />
GOTO begin<br />
<br />
= Populating The Dungeon Of Items & NPC's =<br />
<br />
By [[Stu George]] :: 3may99<br />
<br />
<br />
I have to say up front, I have not looked in depth(if at all) at how other rogue likes approach this task.<br />
<br />
So my methods are probably not as fast or good as ones tried and tested in code like nethack + angband for the past N years they have been using it ;)<br />
<br />
<br />
Quite often one of the first tasks in a rogue like is creating the mazes... Once you have created a working maze generation routine you have to fill it, both with items, traps, monsters, stairs, etc.<br />
<br />
Kitting out your dungeon can be as hard or as easy as you like, but a lot of it has to do with how you generated your maze.<br />
<br />
I'll discuss here how I've gone about doing it.<br />
<br />
<br />
First I'll discuss how NOT to do it, I saw this example only once (in a quite basic "in development" game)...<br />
<br />
The dungeon was hewn from a static 128x128 grid and for placement of objects, a random position of x=rnd(128), y=rnd(128) was taken for every object wanting to be placed on the map, this x.y was then tested against the grid to see if it was a floor tile, if so was placed, and if not was repeatedly calling for random numbers for x.y and testing them all over the grid.<br />
<br />
Needless to say, with lots of objects and a small dungeon, this could make the computer test locations for days until it got a match...<br />
<br />
That is how NOT to do it, basically its a poor mans algorithm. (But as someone pointed out, its easy to do things this way and it does indeed work if you maze fills most of the confines of your 'grid')<br />
<br />
When I generate the maze, i store in a list all the rooms created. Hallways are just "skinny" rooms in my view, so they all get put on the list.<br />
<br />
This list is quite basic, its a linked list and contains the x1.y1-x2.y2 and a flag of every object and nothing else. the flag is just set when its wider or longer than 1 (ie flag is set when its not a "hall"), if you have to refer to the list often its easier to test a flag than to test x2-x1 + y2-y1 for every object..<br />
<br />
When I want to add say, stairs up, i just randomly pick an object from my list, then once you have your "room" randomly pick an x.y within that room y=rnd(y2)+y1, x=rnd(x2)+x1 and place the object. repeat as necessary.<br />
<br />
You can check for overlapping if you wish or simply stack items in a list.<br />
<br />
Since hallways outnumber rooms by a great number, its nice to not always have everything generated in a hallway, thats why the flag is for, so when objects from the list are selected, you can give a greater chance to gen something in a room than in a hallway...<br />
<br />
You could also store two lists, one for "rooms" and one for "halls".<br />
<br />
<br />
My dungeons are created entirely by the RNG, so when i save/load a level I only need take note of the RNG seed before creation starts, since the same seed produces the same level, the object list gets rebuilt and thus you don't have to store that list.<br />
<br />
You _do_ have to save the x.y positions of static things, ala traps (moving bear pits?) and stairs. monsters move (for the most part) so if they are not in the same spot, you could say they wandered about ;), and items, well they got picked up and moved and dropped ;). But these are weak excuses for cutting code really... ^_^<br />
<br />
<br />
When going from 1 level to another you can dump the object list for the same reasons as the load/save given above.<br />
<br />
This is of course, very simple and does not take into account someone with a digging wand adding a new corridor to your dungeon (since its user created, it wont be created with the RNG seed). Of course it would be easy to add the newly created portions to a list, stored with the RNG dungeon seed, etc.<br />
<br />
<br />
I find this method quite good, its quick and easy to "spawn" monsters with this method..<br />
<br />
<br />
The one thing I thought I should mention is the fact that my "rooms" and "hallways" are not connected. doors are placed in between as "connections" but they not connected on creation by "touching" each other, and thus doorways don't show up on my object list. (good or bad I don't know, but I'm very happy with my dun-gen routine, it also just means nothing will be placed over the top of a doorway)<br />
<br />
= A Method For Growing Rivers In A Randomly Generated World - Dana Larose [dana@pixelenvy.ca].txt =<br />
<br />
In response to a question on rec.games.roguelike.development, I coded up a demo<br />
on how one might make randomized rivers that originate in a part of the world<br />
that hasn't been generated yet.<br />
<br />
<br />
The Problem<br />
<br />
You are building a world region by region (as the player explores them), so<br />
you do not the the layout of the entire planet in advance. How to create long<br />
rivers that can span into regions that haven't be created yet? I'll present<br />
here an explanation of how this can be done and provide a demo written in<br />
Python.<br />
<br />
<br />
Summary of Algorithm (Although it's simple enough to almost not qualify as an<br />
algorithm!)<br />
<br />
<br />
Suppose you generate a 20X20 area of the world that looks like this:<br />
<br />
<br />
. . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ = water<br />
. . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ . = plains<br />
. . . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ # = trees<br />
. . . . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~ ~ ^ = hills/mountains<br />
. . . . . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~<br />
^ . . . . . . . . . . . . ~ ~ ~ ~ ~ ~ ~<br />
^ ^ . . . . . . . . . . . . ~ ~ ~ ~ ~ ~<br />
^ ^ ^ . . . . . . . . . . . . ~ ~ ~ ~ ~<br />
^ ^ ^ ^ . . . . . . . . . . . . ~ ~ ~ ~<br />
^ ^ ^ ^ ^ . . . # # # . . . . . . ~ ~ ~<br />
^ ^ ^ ^ ^ . . # # . . . . . . . . . ~ ~<br />
^ ^ ^ ^ ^ ^ # # # # . . . . . . . . . ~<br />
^ ^ ^ ^ ^ ^ ^ ^ # # # . . . . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ # # . . . . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . .<br />
<br />
<br />
Your world generation algorithm determines this lake/ocean will have a river<br />
flowing into it. Start drawing a river backwards from the ocean. For my<br />
simple demo, I used the following stopping condition for the river: If river<br />
was about to cross from an area of higher elevation to an area of lower<br />
elevation, terminate the loop. Additionally, I started with a 5% chance of<br />
terminating the river and each time the drawing loop iterates, I increase that<br />
by 5%.<br />
<br />
<br />
One particular run of my demo made the following map:<br />
<br />
<br />
. . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~<br />
. . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~<br />
. . . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~ ~ ~<br />
. . . . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~ ~<br />
. . . . . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~<br />
^ . . . . . . . . . . ~ . ~ ~ ~ ~ ~ ~ ~<br />
^ ^ . . . . . . . . ~ . . . ~ ~ ~ ~ ~ ~<br />
^ ^ ^ . . . . . . ~ . . . . . ~ ~ ~ ~ ~<br />
^ ^ ^ ^ . . . . ~ . . . . . . . ~ ~ ~ ~<br />
^ ^ ^ ^ ^ . ~ ~ # # # . . . . . . ~ ~ ~<br />
^ ^ ^ ^ ~ ~ . # # . . . . . . . . . ~ ~<br />
^ ~ ~ ~ ^ ^ # # # # . . . . . . . . . ~<br />
~ ^ ^ ^ ^ ^ ^ ^ # # # . . . . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ # # . . . . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . .<br />
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . .<br />
<br />
If your river reaches the border of a region, again terminate it. (Note that it<br />
should also terminate before crossing into region that has already been<br />
generated, my demo doesn't do this). At this point, you need to store the fact<br />
that a river has terminated at a border of the region. Python is OOP-enabled,<br />
so it was quite easy for me to add this information to the region class.<br />
I stored the instance of the terrain, it's coordinates and the last move the<br />
drawing algorithm was about to make (so I can continue drawing it in the same<br />
general direction when it is time to build the next region).<br />
<br />
When the player cross into an previously unexplored region, you will have to<br />
pass the details of already generated neighbouring regions, providing access to<br />
their lists of border features. If a neighbour is null, it hasn't been made yet<br />
and can be ignored. In the demo, when a new region is made, we see that it has<br />
a neighbour to the east, and that a river terminated at the border (row 12,<br />
column 0). After the new region is created, we need to draw a river starting at<br />
(row 12, column 19). Using the same algorithm, we draw until we hit a<br />
termination condition. In this case, the river started in the hills, so it will<br />
continue until it hits a border, or is about to cross from the hills (high<br />
elevation) to the plains (lower elevation).<br />
<br />
A sample run of my demo produce:<br />
. . . . . . . . . . . . . . . . . . . .<br />
. . . . . . . . . . . . . . . . . . . .<br />
. . . . . . . . . . . . . . . . . . . .<br />
# # # # # # # # . . . . . . . . . . . .<br />
# . . . . . . . . . . . . . . . . . . .<br />
# # # # # # # ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^<br />
# # # . . . . . . . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^<br />
# # # # # # # . . . . . ^ ^ ^ ^ ^ ^ ^ ^<br />
# # # # # # . . . . . ^ ^ ^ ^ ^ ^ ^ ^ ^<br />
# # # # # # # # ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^<br />
# # . . . . . . . . . . . ^ ^ ^ ^ ^ ^ ^<br />
# # # # # # # . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^<br />
# # # # # # # . . . . . . . ^ ^ ^ ^ ^ ~<br />
# # . . . . . . ^ ^ ^ ^ ^ * ^ ^ ^ ^ * ^<br />
# # # # . . . . . . ^ ^ ^ ^ * ^ ^ * ^ ^<br />
# # # # # # # # . . ^ ^ ^ ^ ^ * * ^ ^ ^<br />
# # . . . . . . . . . . . ^ ^ ^ ^ ^ ^ ^<br />
# . . . . . . . . . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^<br />
. . . . . . . . . . . . ^ ^ ^ ^ ^ ^ ^ ^<br />
. . . . . . . . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^<br />
<br />
(The river created is marked with *'s so they stand out a little better).<br />
<br />
Putting them side by side:<br />
. . . . . . . . . . . . . . . . . . . . . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~<br />
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~<br />
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~ ~ ~<br />
# # # # # # # # . . . . . . . . . . . . . . . . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~ ~<br />
# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ~ ~ ~ ~ ~ ~ ~ ~<br />
# # # # # # # ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . . . . . ~ . ~ ~ ~ ~ ~ ~ ~<br />
# # # . . . . . . . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . . . ~ . . . ~ ~ ~ ~ ~ ~<br />
# # # # # # # . . . . . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . ~ . . . . . ~ ~ ~ ~ ~<br />
# # # # # # . . . . . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . ~ . . . . . . . ~ ~ ~ ~<br />
# # # # # # # # ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . ~ ~ # # # . . . . . . ~ ~ ~<br />
# # . . . . . . . . . . . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ~ ~ . # # . . . . . . . . . ~ ~<br />
# # # # # # # . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ~ ~ ~ ^ ^ # # # # . . . . . . . . . ~<br />
# # # # # # # . . . . . . . ^ ^ ^ ^ ^ ~ ~ ^ ^ ^ ^ ^ ^ ^ # # # . . . . . . . . .<br />
# # . . . . . . ^ ^ ^ ^ ^ * ^ ^ ^ ^ * ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ # # . . . . . . . . .<br />
# # # # . . . . . . ^ ^ ^ ^ * ^ ^ * ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . . . . .<br />
# # # # # # # # . . ^ ^ ^ ^ ^ * * ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . . . .<br />
# # . . . . . . . . . . . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . . .<br />
# . . . . . . . . . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . . .<br />
. . . . . . . . . . . . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . . .<br />
. . . . . . . . ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ . . . . .<br />
<br />
A nice, slightly winding river is created in one region, then continued in the<br />
bordering region when it comes time to generate the neighbour.<br />
<br />
<br />
Notes About The Demo<br />
- The demo was slapped together in about an hour, so please don't judge my<br />
coding skills on it! It probably has bugs, invalid assumptions, poor coding<br />
standards/styles, inefficiencies and/or redundant code!<br />
<br />
- There are probably plenty of ways to generate nicer looking rivers, I just<br />
used a couple of ideas that popped into my head while coding. Mine often<br />
generates straight lines, which look silly (it took me a couple tries to get a<br />
nice looking river for this page). But again, that wasn't the point of the demo!<br />
<br />
- The termination condititions could be improved. For instance, if you are<br />
stopping because you are about to cross into another region, you could back the<br />
drawing up one square so it doesn't look like the river originates at the border<br />
of two elevations.<br />
<br />
- It would be neat to look for good likely termination points. Suppose a lake<br />
was generated at the same (or higher) elevation as the river, it would make a<br />
good candidate for a termination point. (Hmm - confusing terminology - when I<br />
speak of termination point, I mean where the algorithm stops drawing, which is<br />
the origin point for the river in the geographic sense)<br />
<br />
- The demo doesn't generate terrain, I don't know if my roguelike is going to<br />
have random or fixed wildernesses, I just wanted to offer a solution to the<br />
question on the newsgroup.<br />
<br />
- The demo is cooked to draw a river that starts at the lake and ends at the<br />
border of the first region (the cooked functions are labeled as such). See<br />
previous point.<br />
<br />
- My method only draws rivers from the mouth of the river backwards to the<br />
spring, but it woulddn't take a great leap to make a version that draws from a<br />
spring to a terminatition point. Indeed, since you would be drawing into a<br />
region that has not been determined, you could force the generator to create a<br />
nice termination point for your river.<br />
<br />
- Written and tested in Python 2.2.1, probably works with Python 2.x.x, might<br />
even work with Python 1.5.x<br />
<br />
<br />
There are three main classes used in the demo:<br />
<br />
Terrain - Represents an individual square of terrain. Uses fields ch (the<br />
character to display), type (the type of terrain and elevation - integer<br />
saying how high the terrain is. I used ocean/lake = 0, plains/trees = 1 and<br />
hills = 2. An interesting idea would be to store a floating point number and<br />
use that to determine where the river should flow from the geography of the<br />
land?<br />
<br />
Region - stores information about the section of the world this represents. In<br />
the demo, this is essentially a collection of Terrain squares and a little<br />
additional info used in the demo (such as the border features of this region).<br />
In a full game, this would need to store a fair amount of additional<br />
information.<br />
<br />
RegionGenerator - builds a region of land. Note that in the demo, the regions<br />
are cooked and the river in the first region is partially cooked.<br />
<br />
The code is offered without warranty or guarantee as an idea for folks writing<br />
map generators. If you want to use a substantial part of the code in your game,<br />
please ask permission. Here is grow_river.py.txt (named so because browsers<br />
sometimes complain about .py extentions, save it your harddrive and rename it<br />
grow_river.py before running).<br />
<br />
You can reach me at dana@pixelenvy.ca with questions, suggestions, etc.<br />
<br />
=Here is a list of articles from the old roguelikedevelopment.org that I am trying to salvage:<br />
<br />
Cannot Find:<br />
* How to finish your roguelike - Peter Farabaugh [pete@tbe.net].txt Found a russian translation: http://www.rlgclub.ru/pmwiki.php?n=Main.ArticlesDevRlgFinish<br />
* User Interface in Roguelikes - Jim Babcock [jimmy_b@earthlink.net].txt Found a russian translation: http://www.rlgclub.ru/pmwiki.php?n=Main.ArticlesDevUserInterface<br />
* Roguelike Step by Step Guide.txt<br />
* Mostly Turn-based Multiplayer Timing - Isaac Kuo [mechdan@yahoo.com].txt Found a russian translation: http://www.rlgclub.ru/pmwiki.php?n=Main.ArticlesDevTurnBasedMultiplayer<br />
* Lake and Oasis Generator - Adam Szczepaniak [adamshc@wp.pl].txt<br />
* Fill-area-with-rooms and Maze - algorithms - Josh VertexNortmal Tippetts [vertexnormal@email.com].txt Found russian translation: http://www.rlgclub.ru/pmwiki.php?n=Main.ArticlesDevMazeGen<br />
* Recursive randomized world-map generation Phillip C. Culliton [pcullit@hotmail.com].txt<br />
* 3D Representation for Roguelike Worlds - Jimmy Babcock [jimmy_b@earthlink.net].txt<br />
* Random Dungeon Algo in QBasic - Andrew Collins [andrewcollins@hotmail.com].txt<br />
* Nest of Ants - Jakub Debski [jakub@mks.com.pl].txt<br />
* Passable Cave Building Algorithm - Josh Tippets [vertexnormal@email.com].txt<br />
<br />
TODO:<br />
* Add a link to blah.tar.gz<br />
* add a link to name.zip for Random Name Generation Using Regular Expressions<br />
<br />
= Representing Magick Spells - Sean Middleditch [sean.middleditch@iname.com].txt =<br />
<br />
This article describes the basics of representing and using Magick Spells in roguelikes.<br />
The general techniques are very similar to those used in my article on Object<br />
representation.<br />
<br />
For starts, we need a class to hold the information for a specific spell.<br />
<br />
class Spell {<br />
public:<br />
<br />
OK. Now, let's give the spell a name.<br />
<br />
char *Name;<br />
<br />
There. Now, every magick spell costs Mana Points (well, if you're using a magick system<br />
similar to most others). So we need to define the spell's cost in MP.<br />
<br />
int MPCost;<br />
<br />
Also, every spell has a level: how difficult a spell it is. Only more powerful casters can<br />
use more powerful spells.<br />
<br />
int Level;<br />
<br />
There. Now all we need to know is what in Gehenna the spell does. We'll make a <br />
sub-class called Effect to store this information.<br />
<br />
class Effect: {<br />
friend Spell;<br />
<br />
OK, so what does a specific spell do? We'll make a simple int to describe what a specific<br />
Effect describes.<br />
<br />
int Type;<br />
<br />
So what does Type mean? We'll use some #define's to specify.<br />
<br />
#define HEAL 0<br />
#define SCORCH 1<br />
#define TICKLE 2<br />
#define CREATE_OBJ 3<br />
<br />
You can of course add as many as you want. Now, we know what an Effect does, but<br />
that's not enough. For example, for a HEAL Effect, how much HP does it heal? We<br />
could base everything of level (making a rigid and uniform magick system, which may<br />
be what you want: predictability), or we could give each Effect a set of arguments to<br />
define in more detial what it does. We'll do this through the use of 5 int's.<br />
<br />
int Args[5];<br />
<br />
What do the fields of Args mean? That's based on what Type is equal to. For an Effect<br />
with Type HEAL, we might say that:<br />
<br />
Args[0] is Number of Dice<br />
Args[1] is Sides per Die<br />
Args[3] is Roll Mod<br />
<br />
So an Effect of type HEAL with Args[0] = 2, Args[1] = 6, Args[3] = 2 would heal 2d6+2<br />
HP. Pretty simple, eh?<br />
<br />
Anyways, we can close of the Effect class. We want each Spell to have 5 Effect's (so<br />
every spell can have lots of flexibility).<br />
<br />
} Effects[5];<br />
<br />
We can now close of the Spell class.<br />
<br />
};<br />
<br />
So that's all there is to a basic magick class.<br />
<br />
Casting the spell is just as simple. Make a function called Cast or whatever (I used an<br />
object method inside the Spell class, since I'm a C++ OOP freak). The function would<br />
take as arguments the spell to cast, the target, etc.<br />
<br />
void Cast ( Spell *SpellToCast, int TX, int TY );<br />
<br />
Then we go with a big, evil, switch statement based on effect. This actually works<br />
VERY well. The flexibility is astounding...<br />
<br />
Of course, how each spell takes effect is based on how you've programmed the rest<br />
of your roguelike. Because of the OO nature of WotR, I found it very easy to create<br />
simple object Methods for spell effects.<br />
<br />
For the HEAL Spell Effect Type, you might to do something as simple as loop through<br />
all the Characters (NPC's and Players) in the target loc (defined by TX and TY), and<br />
heal them based on the arguments listed above... 2d6+2, or whatever.<br />
<br />
Anyways, this is just the basics. The advanced stuff all depends on your magick<br />
system and how you programmed the rest of the game.<br />
<br />
The complete source for the Spell class is:<br />
<br />
#define HEAL 0<br />
#define SCORCH 1<br />
#define TICKLE 2<br />
#define CREATE_OBJ 3<br />
<br />
class Spell {<br />
public:<br />
char *Name;<br />
<br />
int MPCost;<br />
int Level;<br />
<br />
class Effect: {<br />
friend Spell;<br />
<br />
int Type;<br />
<br />
int Args[5];<br />
} Effects[5];<br />
};<br />
<br />
Any questions, comments, threats, etc., e-mail me at<br />
sean.middleditch@iname.com<br />
Well, I don't really want any threats.<br />
<br />
The End<br />
<br />
<br />
= RL Dev Code 0.6 - Kornel _ Anubis_ Kisielewicz [kisiel@fulbrightweb.org].txt =<br />
<br />
<br />
RL Developer Code<br />
Version 0.6.0<br />
Designed by Kornel \"Anubis\" Kisielewicz<br />
(kisiel@fulbrightweb.org)<br />
<br />
Hey, I noticed that both Angband and NetHack users have their own<br />
GeekCode. Why not us? ;). This is the first draft, and it\'s realy<br />
RLDev specific. I think that a Roguelike Dev Code will be especialy<br />
useful, because it may make us more aware of the others ideas. I\'m<br />
open to all new ideas, or corrections. In all project specific<br />
questions answer about your current project. A sample of the code is<br />
on the bottom of the document.<br />
<br />
I encourage to at least post your code once, so someone can collect<br />
them and post somewhere :).<br />
<br />
---------------------------------------------<br />
1. General info about the developers methods<br />
---------------------------------------------<br />
<br />
\"L\": Language used to program your roguelike project.<br />
<br />
L:C C<br />
L:C++ C++<br />
L:VC++ Visual C++<br />
L:Java Java<br />
L:FP FreePascal<br />
L:TP Turbo Pascal<br />
L:DP Delphi (Pascal)<br />
L:Pyt Python<br />
?L I still didn\'t decide<br />
!L I\'m a designer<br />
[more]<br />
<br />
--------------------------------------------------<br />
<br />
\"E\": Experience in programing.<br />
<br />
E+++ I\'m a professional programmer<br />
E++ I program as a part time job<br />
E+ I program quite well, as a hobby<br />
E- I\'ve read a few books and made some programs<br />
E-- I\'ve made a few simple programs<br />
E--- I\'m learning while I write a roguelike<br />
<br />
!E I\'m just a designer ;)<br />
?E What do I need programming for?<br />
<br />
--------------------------------------------------<br />
<br />
\"T\": Time invested in rl-development. Choose the most true one :).<br />
<br />
T+++ Every minute of my spare time!<br />
T++ Most of my free time<br />
T+ Regulary<br />
T- From time to time<br />
T-- As a recreation<br />
T--- Rarely<br />
<br />
!T I don\'t write yet!<br />
<br />
--------------------------------------------------<br />
<br />
\"R\": Rewrites. A rewrite is writing your code from scratch, using only<br />
old libraries, and fragments of the old code.<br />
<br />
R+++ more than 5<br />
R++ 3-4 rewrites<br />
R+ 1-2 rewrites<br />
R- not yet<br />
R-- I\'ve just started<br />
R--- I do not program yet<br />
<br />
?R What are rewrites?<br />
!R My game doesn\'t need rewrites, cause I write error-free!<br />
<br />
--------------------------------------------------<br />
<br />
\"P\": Porting to other systems<br />
<br />
P+++ My game will be ported to most known platforms<br />
P++ Linux and DOS/Win<br />
P+ I try to keep the code portable.<br />
P- Why the hell? I write only for Linux/DOS (you may recompile it<br />
though)<br />
P-- DOS/WIN only<br />
P--- Windows only!<br />
<br />
!P I use Java (or something similar)<br />
<br />
--------------------------------------------------<br />
<br />
\"D\": Importance of design before programming<br />
<br />
D+++ I had a detailed DesignDoc before I started programming<br />
D++ I had many notes and information before I started coding<br />
D+ I keep my designdoc ahead of the project, but update it regulary<br />
D- I had a few notes before I started coding<br />
D-- I had a general image of what I\'m trying to do<br />
<br />
!D Who the hell needs a DesignDoc? I make everything on the fly!<br />
?D What\'s a DesignDoc?<br />
<br />
--------------------------------------------------<br />
<br />
\"G\": The generic engine, that is, how generic your game will be.<br />
<br />
G+++ You will be able to make a hard-sci-fi game out of my engine, by<br />
just changing the info-files!<br />
G++ My engine is very generic -- you will be able to make a<br />
different game by changing the info files<br />
G+ I have info files for maps, monsters, items and dungeon<br />
generators<br />
G- I have a few general info files<br />
G-- I keep everything in the code<br />
<br />
!G Why the hell generic engine? I wan\'t to make a GAME.<br />
<br />
--------------------------------------------------<br />
<br />
\"F\": Favourite Roguelike<br />
<br />
F:ToME<br />
F:ADoM<br />
F:V Vanilla Angband<br />
F:*band *bands in general<br />
F:Rogue Yeah :).<br />
F:Moria<br />
F:NHack NetHack<br />
F:Hack<br />
F:GH Gearhead<br />
F:DC DeadCold<br />
[more]<br />
<br />
--------------------------------------------------<br />
<br />
\"RL\": Your roguelike definition<br />
<br />
RL+++ A roguelike MUST be ASCII, MUST be a dungeon crawl, and MUST be<br />
based on a system similar to AD&D, and MUST be permadeath.<br />
RL++ A roguelike has to be ASCII, has to be random, and have<br />
experience levels, and permadeath.<br />
RL+ A roguelike has to be ASCII or use tiles, must have dungeons,<br />
and focus on killing things for experience. It has to be permadeath<br />
too.<br />
RL- A roguelike may have graphics but has to be rather dungeon<br />
themed permadeath game.<br />
RL-- A roguelike is a game that focuses on randomness, and features<br />
permadeath.<br />
RL--- A roguelike is a game inspired by other roguelike games.<br />
<br />
!RL This is completely unimportant<br />
?RL What is a roguelike actually?<br />
<br />
--------------------------------------------------<br />
<br />
\"RLA\": Roguelike community activity<br />
<br />
RLA+++ I\'ve created a popular game, or host one of the main roguelike<br />
sites on the web.<br />
RLA++ I\'ve created a roguelike dedicated webpage (focusing not only<br />
on my game)<br />
RLA+ I\'m a FAQ maintainer, or wrote a roguelike article, or created<br />
a roguelike document<br />
RLA- I play roguelikes and post on a few roguelike newsgroups<br />
RLA-- I post on one roguelike newsgroup<br />
<br />
!RLA Who is that guy?<br />
<br />
<br />
<br />
--------------------------------------------------<br />
2. Project specific questions<br />
--------------------------------------------------<br />
<br />
\"W\": World of the game, the genre<br />
<br />
W:F Fantasy<br />
W:DF DarkFantasy<br />
W:AF Alternative Fantasy<br />
W:SF Science Fiction<br />
W:HSF Hard Science-Fiction<br />
W:MH Mecha<br />
W:M Modern<br />
W:CP CyberPunk<br />
W:G Generic engine (give eventual default genre in bracets)<br />
<br />
--------------------------------------------------<br />
<br />
\"Q\": Quests in your project<br />
<br />
Q+++ The plot is the master! You will have random interesting quests<br />
in my game.<br />
Q++ I will add many pre-written quests.<br />
Q+ I will add a few quest for flavor, or even ToME-like random<br />
quests.<br />
Q- Maybe a few quests for flavor<br />
Q-- Kill Sauron. Kill Morgoth.<br />
Q--- No quests -- just Hack\'n\'slash.<br />
<br />
!Q Who the hell needs quests?<br />
?Q What is a quest?<br />
<br />
--------------------------------------------------<br />
<br />
\"AI\": Approach to AI in your project<br />
<br />
AI+++ AI is the key! The creatures will behave diablo inteligently and<br />
talk to you with Bot-generated messages. They will use military<br />
tactics, recognize dangers, and create traps.<br />
AI++ The NPCs will behave quite reasonable, will flee, band together,<br />
pickup and use items.<br />
AI+ The creatures will use items like wands, staves and the like.<br />
AI- The creatures will be able to pickup and equip items.<br />
AI-- No monster-inventory -- just Hack\'n\'Slash<br />
AI--- Kill player. Kill player.<br />
<br />
--------------------------------------------------<br />
<br />
\"GFX\": Approach to graphics<br />
<br />
GFX+++ The game will be graphical with nice graphics<br />
GFX++ The hame will have tiled graphics<br />
GFX+ Some popular freeware tiles<br />
GFX- Somewhere in the future I plan to add graphics<br />
GFX-- I\'d like graphics, but I\'m a poor artist<br />
<br />
!GFX Pure ASCII rulez!<br />
<br />
--------------------------------------------------<br />
<br />
\"SFX\": Approach to sound<br />
<br />
SFX+++ Digitalized Speech and Music is my aim<br />
SFX++ I will add many wave files and maybe some music<br />
SFX+ Just a few Sound-Effects<br />
SFX- Maybe in the future<br />
SFX-- I\'d like sound, but I\'m a poor at that<br />
<br />
!SFX A roguelike with sound? Buhahahaha...<br />
<br />
--------------------------------------------------<br />
<br />
\"RN\": Approach to randomness in your project<br />
<br />
RN++++ The whole world will be random, random quests, random dialogs,<br />
random plot<br />
RN+++ Same as above, but the plot will be fixed<br />
RN++ The world will be fixed, but there will be random quests,<br />
dungeons and items and monsters<br />
RN+ Random dungeons+items+monster placement<br />
RN- Just the dungeons and monster placement<br />
RN-- I plan to make everything fixed<br />
<br />
--------------------------------------------------<br />
<br />
\"PO\": Popularity of current project<br />
<br />
PO+++ I have fan-sites of my playable roguelike (reserved for ToME,<br />
NetHack, ADoM, Angband and the like :)<br />
PO++ I have a playable version on the web that can be enjoyed<br />
PO+ I have a playable version on the web that can be looked at<br />
PO- I have a designer version on the web (dungeon+items+npcs and<br />
the like)<br />
PO-- I have a few design programs (map-view, dungeon generator)<br />
PO--- I haven\'t published anything<br />
<br />
!PO I didn\'t do anything yet!<br />
<br />
--------------------------------------------------<br />
<br />
\"Hp\": Hitpoint treatment in the roguelike<br />
<br />
Hp+++ A 1-st level character has a few hitpoints, a 50th level<br />
character has a few hundred...<br />
Hp++ I keep the hitpoints rather lower.<br />
Hp+ The player rarely recieves hit-points, I don\'t use a level<br />
system.<br />
Hp- Fully skillbased<br />
Hp-- Fully skillbased and advancement doesn\'t make you realy<br />
powerfull<br />
<br />
!Hp I don\'t use hitpoints!<br />
<br />
--------------------------------------------------<br />
<br />
\"Re\": Realism in the roguelike<br />
<br />
Re+++ You can die because of disease, rusty weapon wounds, or the<br />
after-effects of an out-dated portion of speed<br />
Re++ Each fight is dangerous<br />
Re+ I\'d rather not let the player kill hordes of monsters<br />
Re- I like to keep things real as in NetHack<br />
Re-- I like to keep things real as in Angband<br />
Re--- Who needs realism? It\'s the hack\'n\'slash that counts!<br />
<br />
--------------------------------------------------<br />
<br />
\"S\": Seriousness of the world<br />
<br />
S+++ THE GAME. You think it\'s funny? You\'re talking to me?<br />
S++ The game has to be serious. I want to make an atmosphere...<br />
S+ (ADoM) From time to time a funny in-game situation is fun<br />
S- I like to keep the world rather not gloomy<br />
S-- (ZAngband) Lets keep it easy, sometimes a Barney, or Bull Gates<br />
is fun to kill<br />
S--- (NetHack) Why the hell? Let\'s have nuclear scientists, tourists,<br />
photo-cameras and sinks in a dark dungeon<br />
<br />
--------------------------------------------------<br />
<br />
regards, and I\'m waiting for your codes and opinions :),<br />
--<br />
Kornel \"Anubis\" Kisielewicz<br />
RLDev Code v.0.6<br />
L:FP E+ T+ R+++ P+ D++ G++ RL-- RLA++ F:ADoM<br />
GenRogue 0.16 V8 ( http://genrogue.felis7.civ.pl/ )<br />
W:DF Q+++ AI++ !GFX !SFX RN+++ PO--- Hp-- Re+++ S+++</div>Stuhttp://roguebasin.com/index.php?title=User:Duerig/Archive6&diff=12846User:Duerig/Archive62008-05-02T13:28:53Z<p>Stu: Fix my own old article!</p>
<hr />
<div>= Redefinable Keyboard Bindings - [[Stu George]] =<br />
<br />
Your friend is a diehard rogue player, the VI keyboard mapping is second nature to her.<br />
<br />
You have just finished your whizzbang roguelike game, only it doesnt support the VI mapping as you detest it with a passion!<br />
<br />
If you dont want to alienate some players, you need to keep them happy. You need redefinable keyboard bindings.<br />
<br />
This requires a two-tier representation of the key. An internal (to your game) representation and an external (eg: ncurses, dos, etc) representation.<br />
<br />
In my roguelike I maintained an enumeration of valid keys.<br />
<br />
<pre><br />
enum InternalKeyBindings<br />
{<br />
ik_NullKey=0,<br />
<br />
ik_KeyDown,<br />
ik_KeyLeft,<br />
ik_KeyRight,<br />
ik_KeyUp,<br />
<br />
ik_MAX_KEYS<br />
};<br />
</pre><br />
<br />
external key values are then mapped to the internal key values.<br />
<br />
<pre><br />
#define _ALIAS_COUNT 2<br />
unsigned long lngKeyBinding[ik_MAX_KEYS][_ALIAS_COUNT];<br />
</pre><br />
<br />
The _ALIAS_COUNT in the array definition shows that we can store up to two different key values per internal binding, for example, Open Door and Bash Door, say 'o' and 'b', could be an alias for the same key.<br />
<br />
For this to work properly we must translate our keypresses from external to internal.<br />
<br />
For something like NCurses,<br />
<br />
<pre><br />
unsigned long ncurses_GetKey()<br />
{<br />
return getch();<br />
}<br />
<br />
unsigned long TranslateKey()<br />
{<br />
unsigned long lngKey;<br />
unsigned long lngReturnKey;<br />
unsigned long lngLoopCount;<br />
unsigned long lngAliasCount;<br />
<br />
lngKey=ncurses_GetKey();<br />
lngReturnKey=ik_NullKey;<br />
<br />
for(lngLoopCount=1; lngLoopCount<ik_MAX_KEYS; lngLoopCount++)<br />
{<br />
for(lngAliasCount=1; lngAliasCount<_ALIAS_COUNT; lngAliasCount++)<br />
{<br />
if(lngKeyBinding[lngLoopCount][lngAliasCount]=lngKey)<br />
{<br />
lngReturnKey=lngLoopCount;<br />
/* break out of the loop faster/nicer */<br />
lngAliasCount=_ALIAS_COUNT;<br />
lngLoopCount=ik_MAX_KEYS;<br />
}<br />
}<br />
}<br />
<br />
return lngReturnKey;<br />
}<br />
</pre><br />
<br />
Now we have our translation working, we can assign keys for our VI key fans and our VI key haters!<br />
<br />
<pre><br />
void BindKeys(void)<br />
{<br />
/* binds VI only */<br />
lngKeyBidning[ik_KeyUp][0]='i';<br />
lngKeyBinding[ik_KeyUp][1]=0;<br />
lngKeyBidning[ik_KeyDown][0]='k';<br />
lngKeyBinding[ik_KeyDown][1]=0;<br />
lngKeyBidning[ik_KeyLeft][0]='j';<br />
lngKeyBinding[ik_KeyLeft][1]=0;<br />
lngKeyBidning[ik_KeyRight][0]='l';<br />
lngKeyBinding[ik_KeyRight][1]=0;<br />
<br />
/* the uppercase KEY_* are NCurses constants */<br />
/* binds non VI arrows + number movement */<br />
lngKeyBidning[ik_KeyUp][0]=KEY_UP;<br />
lngKeyBinding[ik_KeyUp][1]='8';<br />
lngKeyBidning[ik_KeyDown][0]=KEY_DOWN;<br />
lngKeyBinding[ik_KeyDown][1]='2';<br />
lngKeyBidning[ik_KeyLeft][0]=KEY_LEFT;<br />
lngKeyBinding[ik_KeyLeft][1]='4';<br />
lngKeyBidning[ik_KeyRight][0]=KEY_RIGHT;<br />
lngKeyBinding[ik_KeyRight][1]='6';<br />
<br />
/* binds both VI and non VI together */<br />
lngKeyBidning[ik_KeyUp][0]='i';<br />
lngKeyBinding[ik_KeyUp][1]=KEY_UP;<br />
lngKeyBidning[ik_KeyDown][0]='k';<br />
lngKeyBinding[ik_KeyDown][1]=KEY_DOWN;<br />
lngKeyBidning[ik_KeyLeft][0]='j';<br />
lngKeyBinding[ik_KeyLeft][1]=KEY_LEFT;<br />
lngKeyBidning[ik_KeyRight][0]='l';<br />
lngKeyBinding[ik_KeyRight][1]=KEY_RIGHT;<br />
}<br />
</pre><br />
<br />
Now you just have to remember to work with internal keys instead of external.<br />
<br />
if(keypress==ik_KeyDown) instead of a hardcoded keyboard scancode or a hardcoded NCurses constant.<br />
<br />
There are other things you can add to this, such as checking for a key that is bound two or more times.<br />
<br />
Ultimatly the next step is to have all your key bindings in a config file that your roguelike reads in on startup, that way the user can bind whatever keys they like however they like them.<br />
<br />
For my roguelike I allowed the player to bind NCurses constants into the config file (KEY_UP, etc) isntead of making them hunt down obscure scancodes for keyup \0\P etc.<br />
<br />
Adding Meta key / CTRL / ALT key support is also another issue worth considering.<br />
<br />
(*nb* the above code was written off the top of my head at work, but should be pretty much correct. Enough to get you started anyway)<br />
<br />
= How to write a roguelike gameengine - Esa Ilari Vuokko [eivuokko@mbnet.fi].txt =<br />
<br />
Some ideas that could be useful ?<br />
As shared by Esa Ilari Vuokko.<br />
Comments and bugfixes ;) to eivuokko@mbnet.fi<br />
<br />
<br />
<br />
I've played roguelike games for 7 years now. First I hacked Moria,<br />
which I got from friend (no modem or net connection :(). Then I got<br />
Omega which I still play (newer version, thought ;). At that time I<br />
got rid of Basic I was programming with and got Turbo Pascal. Well,<br />
I tried to do some pathetic games myself but they were just dead<br />
as they were real mode programs. Then (not earlier) I got nethack<br />
which I didn't like at that time. I hated djgpp (it's not bad, it's<br />
ugly in msdos) so I was bounded to real mode. Then I got Linux and<br />
installed it few times with no success (one time I installed it on<br />
broken hd, guess did it work, no - it just paniced suddenly ;). And<br />
I played ADOM, a lot. And then little Nethack and Omega.<br />
<br />
<br />
Because Linux I got all so mighty gcc and make. After playing for a<br />
while with graphics stuff (in linux and in win) and in winenv doing<br />
some accounting program (with delphi, thought I quitted after it<br />
started compiling wrong - I mean(debugged) it) I got an idea. In an<br />
accounting program we move money from one account to another (I'm sorry<br />
I know finnish terminology better than english). Well those accounts<br />
must be linked list because : they must be easy to create, modify and<br />
delete. Nothing new - a linked list. Of course all objects in rg should<br />
be in linked lists. But the what if even attributes were linked lists ?<br />
So that we had a linked list which can store data (some 16 bytes is enough)<br />
and a name (string) and children list.<br />
<br />
<br />
Listing attributes, skills, and everything that describes object with<br />
such presentation would be quite flexible. But if one does such game,<br />
and many people contribute to it ? It can go way off road as everybody<br />
add something new. A bloated memory use, and unneeded complexity are<br />
real threats. As normally, say ADOM, player char needs more memory<br />
(more variables) than npc. But in this approach we give npc only those<br />
skills and attributes it needs and we are still able to use same routines<br />
on both, player and npc.<br />
<br />
<br />
Of course above system can be optimized. I've defined it like this :<br />
Okey, I've got a bit more complex.<br />
class List {<br />
private:<br />
List *child,*next,*parent;<br />
int id;<br />
int data[4];<br />
Link(List *);<br />
Unlink(List *);<br />
Query(int,int,int,int,int);<br />
public:<br />
int *Data();<br />
char *Name();<br />
int *Data(char *);<br />
List *Name(char *);<br />
int *Data(int,int,int,int,int);<br />
List *Name(int,int,int,int,int);<br />
Item *Index(int);<br />
int Index(Item *);<br />
int Count();<br />
List *Add();<br />
List *Remove();<br />
} ;<br />
<br />
Quite clear, I think. Id can be converted (by another class) to char.<br />
Almost all ints are for quick query. I use dot as delimiter between child<br />
and parent and I don't have plurals. "skill.weapon.blade.short".<br />
<br />
Then I wanted an engine that doesn't need special cases. It would be<br />
(sorry for saying this) stupid to do special levels, which have special<br />
if of switch statement in level code. How could one have such a really<br />
flexible system ? Well I read Thomas Biskup's ideas of JADE. I don't know<br />
whetever he meant the same as I with the mentioning everything to be<br />
event based. So what I'm chasing here is that every object should have<br />
message handler list, which would handle requests to do something.<br />
<br />
Say we have a character A. A has handler list of next functions<br />
(stacked):<br />
creature_shield_deflector,<br />
creature_ro_poison_res,<br />
creature_basic_poison,<br />
player_non_ai,<br />
basic_creature_handler.<br />
<br />
First a monster(mage) B would shoot an firebolt to A. Firebolt code would<br />
send a message to A that some fire damage is coming. First this message <br />
would reach first handler in list, creature_shield_deflector. That would <br />
say "no,no fire damage" and that would be it, no damage to creature. Then<br />
B would throw a acidbolt. Well this time deflector would say nothing as <br />
wouldn't other before basic_creature_handler. That would make some damage <br />
to creature and spare some to inventory too (and send approciate messages <br />
to items). Then would engine send TIMEUPDATE to creature, which would be <br />
handled first by creature_basic_poison. Well it seems this creature has <br />
poisoning and handler would notice that it just ending. First it sends to <br />
creature A (self) damage message of poison, which would end to <br />
creature_ro_poison_res, and no damage. Then it would return <br />
UNLINK_AND_CONTINUE so that it would be removed from list and message <br />
(TIMEUPDATE) would be sent on. Then message would reach basic_handler which<br />
would add some speed to energy (ADOM) or add a timepulse (nethack,angband).<br />
If it would be creature's turn to move, it would send message ACTION to <br />
itself (creature A). That would be caught by player_non_ai which would wait <br />
for keypress and then do whatever is defined and player wishes to do.<br />
<br />
Because paragraph above seems a bit unclear ;) I'll do an easier<br />
table here :<br />
1 creature_shield_deflector,<br />
2 creature_ro_poison_res,<br />
3 creature_basic_poison,<br />
4 player_non_ai,<br />
5 basic_creature_handler.<br />
<br />
Messages :<br />
Fire damage<br />
1 - take message (do nothing) return KEEP_AND_STOP -> that's it.<br />
Acid damage<br />
1 - no action, return KEEP_AND_CONTINUE<br />
2 - no action, return KEEP_AND_CONTINUE<br />
3 - no action, return KEEP_AND_CONTINUE<br />
4 - no action, return KEEP_AND_CONTINUE<br />
5 - Share damage to creature and inventory, send damage message to<br />
inventory. Return KEEP_AND_STOP.<br />
TIMEUPDATE<br />
1 - no action, return KEEP_AND_CONTINUE<br />
2 - no action, return KEEP_AND_CONTINUE<br />
3 - Check if it's poison time. If it is send poison damage to self:<br />
Poison damage<br />
1 - no action, return KEEP_AND_CONTINUE<br />
2 - Take message (do nothing) and return KEEP_AND_STOP.<br />
If poison is diluted enough return UNLINK_AND_CONTINUE<br />
else return KEEP_AND_CONTINUE<br />
4 - no action return KEEP_AND_CONTINUE<br />
5 - Check whetever it's time to move or not (some way to count time<br />
compared to time). If it is send ACTION to self.<br />
ACTION<br />
1 - no action, return KEEP_AND_CONTINUE<br />
2 - no action, return KEEP_AND_CONTINUE<br />
3 - no action, return KEEP_AND_CONTINUE<br />
4 - Normal player's turn in roguelike games.<br />
return KEEP_AND_STOP.<br />
<br />
KEEP_AND_CONTINUE, UNLINK_AND_STOP etc mean whatever function which<br />
handles handler lists should keep sending message on in list and if<br />
handler should be removed from list.<br />
<br />
<br />
Yes, I know, this is really heavy way to do things. But if we can count<br />
on fast 486, it is REALLY flexible. I think that with handlers lists and<br />
description lists we can mimic any game we want or make just about anything<br />
we want (well world conquest is a _bit_ hard maybe, but as rg game anything)<br />
<br />
I'm sorry if there's too many errors in my english. I didn't mean to<br />
be offensive either but I needed to make my point clear (if it can be<br />
done at all). If someone has implemented this allready, good, sorry to<br />
say that I were to late.<br />
<br />
I'm sorry if there is something that have been published before and<br />
I don't want to claim that I've been first to thing this kind of things<br />
but I haven't seen anything like this before (I haven't read too much).<br />
Anyway Copyright 2000 Esa Ilari Vuokko. I don't (of course) take any<br />
responsibility of anything you do or don't do with this text. It can be<br />
freely copied and published electronically as long as it isn't modified.<br />
<br />
= Heap Space Conservation - Steve Segreto [ssegreto@titan.com]. =<br />
<br />
Or How to have LOTS of monsters and LOTS of treasure in your Roguelike.<br />
<br />
Here are some tips for conserving precious heap space, so that you<br />
will be able to populate each of your dungeon levels with as many <br />
monsters and items as you want! This is a good alternative to having to<br />
write a protected mode program, and while it may be a little too slow<br />
for some 386s, the algorithms can be tuned as needed. The basic concept<br />
is that you will only store in RAM as little as you possibly need to <br />
know about all the monsters and items. All the rest of the stuff <br />
(specific information about a monster or item) you store on the <br />
player's hard drive. The speed versus memory usage trade-off is obvious.<br />
You will use a lot less RAM by only storing the indices into the disk<br />
files in a linked list in memory, but your game will be slightly slower<br />
because you must frequently return to the hard drive and read/write<br />
information from it (this is VERY slow compared to reading/writing from<br />
RAM).<br />
<br />
Anyway, here is some sample code for storing indices for monsters and<br />
items using ANSI C and assuming that each of your dungeon levels is 80<br />
cells by 25 cells, for a total of 2000 square cells (this may be<br />
smaller or larger than what you want for your roguelike). My ANSI C is<br />
pretty rusty (I prefer Pascal) so please be aware that this code does<br />
contain syntax errors.<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// BEGIN CODE FRAGMENT<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
#define MAX_ROWS 25<br />
#define MAX_COLS 80<br />
typedef unsigned int word; // 16-bit quantity<br />
typedef unsigned char byte; // 8-bit quantity<br />
typedef enum NodeTypes = { MONSTER, ITEMS }; // Different sorts of<br />
data files you will have<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// A singly linked list of indices.<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
typedef struct index_list_node;<br />
typedef index_list_node *index_list_node_ptr;<br />
struct<br />
{<br />
word index;<br />
NodeTypes node_type;<br />
index_list_node_ptr link;<br />
} index_list_node; // Size = 7 bytes<br />
// Related list functions are new_list(), free_list(),<br />
insert_before(), insert_after(), is_empty(), is_full()<br />
// advance_list(), reset_list(), read_list_from_disk(),<br />
write_list_to_disk()<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// Records to hold monsters and items on diskette.<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
typedef struct<br />
{<br />
byte row, col, depth;<br />
char symbol; // Whatever data you will have to represent a<br />
monster: name, hit points, AC, etc.<br />
}monster_record;<br />
<br />
typedef struct<br />
{<br />
byte row, col, depth;<br />
char symbol; // Whatever data you will have to represent an<br />
item: weight, damage, etc.<br />
}item_record;<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// Global array of index_list_nodes for each square of the dungeon.<br />
// Initiallly this array will be MAX_ROWS * MAX_COLS * sizeof<br />
(index_list_node) bytes large<br />
// 80 * 25 * 7 = 14,000 bytes plus 7 bytes for every monster/item<br />
added.<br />
// Assuming about 150 monsters and 200 items per level, this gives<br />
you 14,000 + (7 * 350)=16,450 bytes<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
index_list_node object_array[MAX_ROWS][MAX_COLS];<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// Because the above list will only contain INDICES into permanent<br />
disk files, deleting elements from the list<br />
// such as when an item is picked up or a monster slain, will be<br />
extremely slow (because the entire level file<br />
// on disk will have to be re-written minus one single record). To<br />
alleviate this, simply keep a second linked<br />
// index list of all the indices which need to be deleted from the<br />
permanent disk file when the player leaves this<br />
// dungeon level (these indices have already been deleted from the<br />
object_array linked lists.) Remember to<br />
// insert indices into this list EVERY time a monster is killed or<br />
an item is picked up (you might want to<br />
// have a function delete_monster(which_row, which_col, what_index)<br />
which removes the specified node<br />
// from the object_array[] linked list and also inserts it into the<br />
deleted_list [Do you see why you need to<br />
// pass in what_index? That's right, so you can go to the<br />
appropriate (what_row, what_col) element in object_array<br />
// and traverse that linked list until currPtr->index == what_index,<br />
then you can delete this node and insert the<br />
// what_index into the deleted_list!] ).<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
index_list_node deleted_list;<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// You will also have two disk files per dungeon level, one for<br />
MONSTERS and one for ITEMS.<br />
// You must devise a naming scheme for each (LEVEL01.MON and<br />
LEVEL01.ITM for example)<br />
// LEVEL01.MON is a random-access file of monster_records and<br />
LEVEL01.ITM is a random-<br />
// access file of item_records, one record per monster on that level<br />
and one record per item on the<br />
// level. Note that these disk files may be quite large<br />
(sizeof(monster_record) * num_records bytes).<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// stock_depth()<br />
// Call this function at the start of the game or whenever the level<br />
needs to be completely re-stocked:<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
void stock_depth ()<br />
{<br />
// 1. Open the appropriate monster level file (LEVEL01.MON for<br />
example)<br />
// 2. Read each monster_record one at a time into a local<br />
variable, m<br />
// 3. Based on the m's (row, col, depth) triple, use the<br />
appropriate element of the global object_array[].<br />
// For example, if m.row = 10 and m.col = 10 then<br />
object_array[10][10] would have a singly linked list<br />
// of index_list_nodes.<br />
// 4. Insert the index into the linked list (use insert_after()<br />
from the basic list routines above).<br />
// 5. Do the same thing for the item level file.<br />
item_record i;<br />
monster_record m;<br />
FILE *infile;<br />
word index = 0;<br />
<br />
// Add all the monsters to our array of linked lists.<br />
infile = fopen ("LEVEL01.MON") // This line is not syntactically<br />
correct<br />
while (!eof(infile))<br />
{<br />
fread (infile, m); // Wrong also!<br />
insert_after (object_array[m.row][m.col], index, MONSTER);<br />
// The index is the record number and the linked list is<br />
<br />
// at (m.row, m.col)<br />
index++; // Move on to the next record<br />
}<br />
<br />
// If there are not enough monsters on this level, ADD monsters<br />
until there are enough.<br />
<br />
// Add all the items to our array of linked lists.<br />
index = 0;<br />
infile = fopen ("LEVEL01.ITM") // This line is not syntactically<br />
correct<br />
while (!eof(infile))<br />
{<br />
fread (infile, m); // Wrong also!<br />
insert_after (object_array[i.row][i.col], index, ITEM); //<br />
The index is the record number and the linked list is<br />
<br />
// at (m.row, m.col)<br />
index++; // Move on to the next record<br />
}<br />
}<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// change_depth()<br />
// Call this function every time the player changes dungeon levels,<br />
including at the end of the game:<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
void change_depth ()<br />
{<br />
// 1. Open the current monster level file (LEVEL01.MON for<br />
example)<br />
// 2. Open a temporary file<br />
// 3. Read each record one at a time into a local variable, m.<br />
// 4. If this record number (index) is NOT in the deleted_list<br />
(see above) then write this<br />
// record to the temp file (otherwise DON'T write the record<br />
to the temp file).<br />
// 5. Close and delete the monster level file.<br />
// 6. Rename the temp file to the same name as the monster level<br />
file.<br />
// 7. Now the temp file contains all the records except those<br />
which have been deleted (dead monsters).<br />
// 8. Do the same with the item level file.<br />
// 9. Call free_list() to destroy the linked index list.<br />
// 10. Based on the new depth, call stock_depth() with the new<br />
depth number to load/build the new index_list.<br />
}<br />
<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// square_has_monster()<br />
// Simply scan the linked list at object_array[which_row][which_col]<br />
and return TRUE as soon as one of<br />
// the nodes has a node_type of MONSTER.<br />
// You can devise a similar function for square_has_item().<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
boolean square_has_monster (byte which_row, byte which_col)<br />
{<br />
// List at this square is empty (square has neither monster nor<br />
items)<br />
if (object_array[which_row][which_col] == NULL) return (FALSE);<br />
<br />
index_list_node currPtr = object_array[which_row][which_col];<br />
while (currPtr != NULL)<br />
{<br />
if (currPtr->node_type == MONSTER) return (TRUE);<br />
<br />
// Move down the list<br />
currPtr = currPtr->link;<br />
}<br />
return (FALSE);<br />
}<br />
<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
// END CODE FRAGMENT<br />
/////////////////////////////////////////////////////////////////////////////////<br />
<br />
= Handing Out Experience - Rick Carson.txt =<br />
<br />
Roguelikes are part of a family of games in which the participant builds <br />
something over time. Relatives are of course roleplaying games and other <br />
storytelling games. Distant relatives are games such as Civilization.<br />
<br />
Since players often fail to achieve the primary goal (e.g. retrieve the <br />
artifact of lint removal which will cleanse the bellybuttons of everyone <br />
in the universe thereby ending world hunger) the secondary rewards (or payoffs <br />
(or utility for all you economists out there in RL land)) become very important. <br />
Too much advancement too quickly (kill a kobold - get to 35th level) devalues <br />
the payoff, whereas too slow an advancement (kill everything in the whole <br />
game and maybe get halfway to level 2) means that they never even get to <br />
feel rewarded.<br />
<br />
Of course experience might be handed out for a range of activities, not <br />
just killing things. such a list is certainly not limited to: solving quests; <br />
receiving damage; causing damage; casting spells; using skills; getting <br />
treasure; idle gossip; donations to the (un)worthy cause of your choice; <br />
doing nothing or resting; healing; travelling, mapping, making other players <br />
laugh....<br />
<br />
So lets consider the case of a fairly generic dungeon bashing roguelike. <br />
The dungeon has sixteen levels, a predetermined number of monsters per <br />
level, and unique monsters. There are no 'random' monsters. We'll call <br />
our theoretical roguelike Jiavlo and code it in Java. (Stop me if I infringe <br />
any copyrights ;-) <br />
<br />
Experience is only handed out when we generate a monster killing event.<br />
<br />
Our first realization is that in this scenario there are a fixed number <br />
of monsters, and that this means that there is an upper limit for how much <br />
experience the player will ever get.<br />
<br />
We need to decide how many levels we want the players to be able to gain. <br />
So what constitutes a good number of levels that could be gained? Most <br />
of the audience will have at least a passing familiarity with the D&D game <br />
family, in which you start at level one, and progress is technically unlimited,<br />
but which is less meaningful once you get into double digits. And certainly <br />
once you get into the low twenties you are in danger of being accussed (unjustly <br />
of course) of being a 'power gamer'. So most of the target audience is <br />
going to be happy with a top level of around 15 to 30. Twenty is a nice <br />
round number in that range which should give a decent payoff in terms of <br />
achievement.<br />
<br />
Note that the point is not to mirror any particular published system for <br />
which one runs the risk of being sued and losing the shirt off ones back,<br />
but rather to recognise and take advantage of this subconscious assumption <br />
that most people are going to make, ie that getting to level 20 is a superhuman <br />
feat and that getting to level 12 (say) is pretty spectacular.<br />
<br />
The other thing to do is to make the experience scale exponential (this <br />
means that each level requires more experience to get to than the level <br />
before it). Mathematically there is no reason for this, but people will <br />
expect it, and because of their expectation they will not feel as much of <br />
a payoff if they get the same amount of experience for killing a dragon <br />
as a kobold. Because of this, I recommend using a spreadsheet to play around <br />
with the numbers till you some that you like. Hopefully you won't need <br />
a spreadsheet to follow this article though!<br />
<br />
It is useful to consider the linear case here though, because it forms a <br />
basis from which you can build the exponential formula, and if you do so <br />
you will be much more likely to get a well balanced game. But before we <br />
look at the linear model, lets examine the constant model. This is even <br />
worse in terms of payoffs, but much simpler again to balance properly.<br />
<br />
For every monster you kill you get 1 xp.<br />
There are 50 monsters per level. (Times 16 levels is 800 xp)<br />
We can now say something like, for every 40 xp you have, you go up a level. <br />
(800 divided by 20).<br />
Note that you start at level 1, so you would get to level 20 after killing <br />
760 creatures, ie you max out your levels shortly before you kill the UberLintDaemon <br />
which drops the game ending artifact, so that you have time to enjoy maxing <br />
out on levels before the game ends.<br />
<br />
If the monsters on deeper levels get harder to kill, then logically players <br />
would try to clear a level before progressing to the next in order to get <br />
the 'easiest' xp first (minimise risk, maximise payoff).<br />
<br />
Note that we are requiring them to kill 40 monsters in order to advance <br />
to second level. This is far too harsh, and for many first time players <br />
this will take too long for them to get hooked. Ten is a much more reasonable <br />
number. And we want them to be able to get to say level 5 or 6 fairly quickly <br />
before it becomes hard slog. So lets break it down, lets say that by the <br />
end of dungeon level 15 they are level 20, and they gain a level per level <br />
they clear back till say the player is level 10. That means that we then <br />
need to plot the xp from 0 (at level 1) to 250 (which they have after clearing <br />
5 levels at level 10). We could go back and rewrite our assumptions, and <br />
have them start at level 0, and then have them gain a level every 25 points. <br />
That makes it nice and easy for us in terms of maths.<br />
<br />
The effect this has on the game though, is to make the clearing of each <br />
level a hard thing at first, and then get easier halfway through each level. <br />
This is actually not too bad in terms of payoffs, because the player begins <br />
to notice that the monsters are easier to clear after going up the level.<br />
<br />
So lets modify how players go up levels. Here is the table (level, xp required):<br />
1 0<br />
2 5<br />
3 15<br />
4 30<br />
5 50<br />
6 75<br />
7 105<br />
8 140<br />
9 180<br />
10 225<br />
(and 50 per level after that). <br />
<br />
So at the end of clearing level 1 (50xp), they are fifth level, clearing <br />
level 2 puts them at sixth level verging on seventh, etc. This uses a clear <br />
progression, in order to go up a level, you need as much extra xp as the <br />
last time you went up a level, plus five, until you get to needing 50 a <br />
level where it tops out).<br />
<br />
Despite the plain maths behind this, I would be tempted to fiddle with it <br />
even more, because fifth level after clearing only one level of monsters <br />
seems 'too much'.<br />
<br />
But lets take this 'constant' model, and see what happens when we make it <br />
'linear'.<br />
We assume that all the monsters on level x of the dungeon are 'level x monsters' <br />
and we give x points for killing them. The maximum amount of experience <br />
in the game is now: 6800. The maths for working this out is starting to <br />
get more complicated, but the formula is: (((n squared) plus n) divided <br />
by 2) times the number of monsters per level). Where n is the number of <br />
levels, and the number of monsters per level is still 50.<br />
<br />
Obviously we cannot now just multiply the cost of going up levels by 8.5 <br />
(6800 divided by 800) because that would mean we would need 85 xp to get <br />
to second level, which means clearing all of level 1, and a third of level <br />
2. All of a sudden things look a lot harder! One way of solving this, <br />
is to try to match monsters killed to levels gained, assuming that all the <br />
low level monsters are killed first. This is easier than it sounds for <br />
levels 10 through 20, because we already know that we want the player to <br />
advance at the mid point of the level. And this is not too hard to work <br />
out (especially with a spreadsheet).<br />
<br />
&gtFrom 10th level and up (level, xp required):<br />
10 900<br />
11 1225<br />
12 1600<br />
13 2025<br />
14 2500<br />
15 3025<br />
16 3600<br />
17 4225<br />
18 4900<br />
19 5625<br />
20 6400<br />
<br />
(The formula for this is: (((n squared) plus n) / divided by 2) plus (25 <br />
times (n plus 1)) where n = level required minus 5. The minus five is <br />
because we have five more experience levels than the last level of the dungeon <br />
that we cleared)<br />
<br />
Now if we want to keep the same progression, that is, getting to level five <br />
after clearing the first level of the dungeon (yuck!) we leave that bit <br />
of the table alone, and figure out a progression from 5th level to 10th <br />
level. Or, we can choose another formula to govern low level advancement,<br />
such as: (n times n) plus (14 times n) minus 1, where n is the current <br />
level which yields:<br />
1 0<br />
2 14<br />
3 45<br />
4 95<br />
5 166<br />
6 260<br />
7 379<br />
8 525<br />
9 700<br />
<br />
Which is a much nicer fit to the lower levels of the dungeon and how fast <br />
they should advance. Unfortunately I've just noticed that it bears a striking <br />
similiarity to the xp curve in Crawl. What a shame :-)<br />
<br />
But of course noone wants to get 12 xp for killing a Dragon, so we need <br />
to think about how much xp we want to hand out for killing a monster of <br />
each level. I suggested at the start of the article that making it exponential <br />
is probably more in fitting with the players expectations. Lets say that <br />
on level one you get 1 xp per monster killed, and on level 16 you get 10,<br />
000 xp per monster (so level 16 has half a million xp of monsters on it <br />
- suitably impressive amount :-)<br />
<br />
A 'basic' formula for this would be: (n to the power of ((n minus 1) divided <br />
by (15 divided by 4)))<br />
<br />
Which gives these results:<br />
1 1<br />
2 1.847849797<br />
3 3.414548874<br />
4 6.309573445<br />
5 11.65914401<br />
6 21.5443469<br />
7 39.81071706<br />
8 73.56422545<br />
9 135.9356391<br />
10 251.1886432<br />
11 464.1588834<br />
12 857.6958986<br />
13 1584.893192<br />
14 2928.644565<br />
15 5411.695265<br />
16 10000<br />
<br />
<br />
You then need to figure out how many xp are needed for each level (use a <br />
spreadsheet!), and split the difference between levels, and then somehow <br />
figure out a formula for advancing. I came up with (2 to the power of n) <br />
plus (n cubed) minus (25 times n). Which is ok, but given more time we <br />
could come up with something better. In particular, I'd reduce the base <br />
number of the power to something in the range of 1.97 to 1.99 so as to get <br />
closer to the 'ideal' value for that last level (you would get to 20th level <br />
with three creatures remaining given the formula above).<br />
<br />
Some things to think about: do the rewards actually match the difficulty. <br />
For instance if a level 12 monster isn't really much harder to kill than <br />
a level 8 monster, why hand out ten times as much xp for killing it?<br />
<br />
In fact, the difficulty of balancing even a limited scenario as outlined <br />
above means that you are far better off having a 'complicated' function <br />
for handing out experience, than aiming for some mathematically pure function.<br />
<br />
An example: Offense * Defense is a very good measure of combat capability <br />
(ignoring the effects of swarming, assume that the character can always <br />
retreat such that they only fight one monster at a time). Offense is the <br />
average damage they do (ie chance to hit times average damage times number <br />
of attacks) and defense is how much damage they can take on average (ie <br />
chance to avoid damage times hit points).<br />
<br />
Example 1: a rat which does 1-2 points of damage, has a 1 in 3 chance of <br />
hitting, has no chance of dodging and 2 hitpoints would be worth 1 xp. <br />
((1.5 times (1 divided by 3)) times 2)<br />
Example 2: a balrog which does 10-20 points of damage, has a 100% chance <br />
of hitting, gets three attacks a round, avoids (dodges/deflects/counterspells/whatever) <br />
50% of attacks and has 100 hit points would be worth (15 times 3) times <br />
((100 divided by 50) times 100) or 9000 xp. Actually, that might not be <br />
enough :-)<br />
<br />
You can increase the spread by raising the amount of xp from the above formula <br />
by some power greater than 1, try 1.1 or 1.2. 9,000 to the power of 1.2 <br />
is 55,602 which should keep the players happy. Whereas 1 to the power of <br />
anything is still 1.<br />
<br />
Other factors to consider are the dungeon level the character has gotten <br />
to, what resistances the monster has, whether the monster has ranged attacks <br />
(these are really nasty in roguelikes, you may wish to reward the players <br />
accordingly) and whether it drops items that help the player (which are <br />
a reward in themselves in that they improve the character) when it dies. <br />
Of course killing an Elder Dragon and having the experience it gives you <br />
reduced by 10% because it dropped a +1 dagger, would suck.<br />
<br />
In terms of experience to go up levels, something to avoid is requiring <br />
as mush xp to go from 1 to 2 as from 2 to 3. This can happen when you use <br />
an exponential curve that doubles for a while. Just as a wild totally random <br />
example, take a fighter that needs 2000xp to get to level 2, and 4000xp <br />
to get to level 3, and 8000 xp to get to level 4 etc. Now think about this,<br />
in order to get to level 2, the fighter had to gain only 2000xp, but this <br />
is also the amount they need to gain in order to get to the next level, <br />
but now they have an extra levels worth of hitpoints, better chances to <br />
hit etc, which means that it is easier to get from 2 to 3 than it was to <br />
go from 1 to 2. And the game shouldn't get easier as they go up levels.<br />
<br />
cheers,<br />
<br />
Rick<br />
<br />
= Allocating Experience and Character Advancement - Matthias E. Giwer [mgiwer@ij.net]. =<br />
<br />
First, a brief bit about my experience in this area:<br />
<br />
I've been an active player of "pencil and paper" role playing <br />
games since 1987, encompassing more than thirty (truthfully, I've <br />
forgotten all the games I've played) different systems, as well as a<br />
number of "tactical" games such as BattleTech, Warhammer, etc.<br />
<br />
I've spent (wasted :) hundreds of hours in roguelikes such as <br />
Larn, Moria, Nethack, (A-Z)ngband, ADOM, etc. I attempted to develop<br />
my own on several occasions, the most recent attempt being Saga, a Perl<br />
roguelike.<br />
<br />
I do not claim to be the worlds most serious gamer, nor the <br />
worlds best software engineer, but I do feel I have enough experience <br />
on this subject to be able to offer some useful information.<br />
<br />
<br />
Now, on to the meat:<br />
<br />
How you implement character advancement will depend heavily on <br />
your choice of game mechanics. For example, is it a level based system <br />
where a 10th level being will be ten times more capable than a 1st <br />
level being? a hundred? Or is it entirely skills based, where <br />
facility with a particular weapon or ability is to be developed <br />
independently of any other capability?<br />
<br />
The majority of current roguelikes seems to be dominated by <br />
levels and level/skills hybrids. This is fine, though while I <br />
personally advocate an entirely skills-based approach, it is truly a <br />
matter of taste.<br />
<br />
The base idea is that individual actions performed by the <br />
characters will return (on success, failure or both) some measure of <br />
"experience", either generic or towards the skill governed by the <br />
action. In order to develop a mental yardstick, I usually try to get <br />
a firm idea of what a brand new, baseline character is capable of. In<br />
most roguelikes today, that would be a human fighter.<br />
<br />
Next, try to imagine what this character would be capable of, if <br />
his abilities were taken to their absolute limits, without regard to <br />
items and equipment that may boost her capabilities. This should give<br />
you a continuum of capability that will let you look at, and gauge, <br />
difficulty of things like quests, unique creatures, and so on.<br />
<br />
It also usually helps me to think of creatures that this <br />
character may face as based on this brand new beginning fighter. In <br />
other words, a Grey Kobold is about half the power of a beginning <br />
fighter, but an Elite Orc Guardsman is six times more powerful than <br />
the baseline.<br />
<br />
Yes, there is a LOT of tweaking and experimentation involved to<br />
get it right. Also, many abilities can make combat orders of magnitude <br />
simpler (teleportation, ranged attacks, etc) so this has to be taken <br />
into account when trying to judge anything other than a raw fighter<br />
type. Again, there is no perfect measure, experimentation is the key <br />
to balance here.<br />
<br />
If you wish to model the real world, most performance type <br />
skills (dancing, martial arts, typing, etc) are developed in terms of <br />
plateaus that may take months or years to break through, usually on a <br />
sliding scale of time. The first plateau might take only a few weeks <br />
to reach, but the next may take a few months, etc. Roguelikes (and <br />
many traditional RPG's) model this with each "level" requiring <br />
progressively larger amounts of experience points to reach.<br />
<br />
However, because most games give out larger amounts of <br />
experience for more difficult and more powerful creatures, the result <br />
is that most characters end up on a hyper-accelerated track, and can <br />
reach quite amazing levels of skill in relatively short amounts of <br />
game time. Now, as a fantasy game goes, that is perfectly acceptable,<br />
but it does make it more difficult to judge when a player is ready to <br />
face the "Deep dwelling Thing from Beyond". Then again, people don't <br />
play roguelikes because they are easy. ;)<br />
<br />
I would have no issue with this, if it was a one-time event. <br />
For example, the first time you wipe out a Grey Ooze, get the full <br />
experience value for it. For each one after, only bestow a standard <br />
action credit that doesn't change, for all actions of that type. New <br />
things, and new challenges help you grow a lot, practice helps you a <br />
little (which is why you have to keep at it).<br />
<br />
An extension of this idea is experience for, say, casting <br />
spells. You get full experience value the first time you cast a new <br />
spell, but only a small "cast spell" value each time thereafter. The <br />
idea works for any ability that is action based, rather than intrinsic<br />
or "always-on".<br />
<br />
For added realism (ha :), it may be worth investigating a <br />
"decay" function for skills and abilities that go unused for long <br />
periods of time, with the time before decay increasing the higher the <br />
level of skill.<br />
<br />
<br />
Like the design of any game system, this article is two parts <br />
experience and one part prejudice. I hope that, at least, mentioning <br />
these issues will prompt roguelike designers to devote more thought <br />
game mechanics issues, and to question some accepted standards.<br />
<br />
I do apologize if you were looking for code examples, but the entire <br />
issue of character development is so tightly bound to the specific <br />
system and other game mechanics to make even pseudo code examples <br />
just about worthless.<br />
<br />
Feel free to write me with questions, comments, etc. Please keep the <br />
flames constructive, thanks! :)<br />
<br />
-Matthias E. Giwer<br />
mgiwer@ij.net<br />
<br />
= Creating A Player - Brian Bucklew [bbucklew@inteletek.com]. =<br />
<br />
Section 1 : The Definition<br />
<br />
[Note : I will be using C++ Class definitions]<br />
<br />
So, let's pretend we have a nice endless dungeon filled with<br />
vile demonic beasts, heaps of gold, and piles of flaming swords of instant<br />
monster to magic item transmutation. Mabey we even have an engine to make<br />
the ubiquitous '@' saunter around in this great dungeon.<br />
Now, what we really need is some way to make that little '@' into<br />
a daring adventurer, with Herculean strength and an intelligence to<br />
rival Hawking (or perhaps the lack of the same...).<br />
First off, we need to have some basic statistics and attributes.<br />
perhaps we need a Name, a Race, and a Class... We also need some numbers<br />
to represent the Hero's strength, and intelligence as well as his other<br />
important attributes.<br />
Now, in any RL, a player's Statistics are going to go up and<br />
down during the course of play, whether it's from going up a level or<br />
getting hit by a Lecherous Walking Carrot Of Charisma Sapping. So we should<br />
really represent each score by two numbers, a current score and a base score:<br />
<br />
class Stat<br />
{<br />
public:<br />
int Base;<br />
int Current;<br />
}<br />
<br />
All of our calculations done in the game should be based off of the<br />
current score, but the base score will allow us to revert to the Player's<br />
origional score or hit-point total after a magical-effect or damage wares<br />
off.<br />
<br />
Having the basic stat class, let's go ahead and derive a class to<br />
contain a basic RL character:<br />
<br />
class Player<br />
{<br />
public:<br />
char Name[256]; // A String to hold the player's name<br />
int Race; // let's say, 0=Human 1=Elf 2=Frog...<br />
int Class; // hmm... 0=Fighter 1=Mage 2=Tourist... <br />
<br />
Stat Str; // How Strong<br />
Stat Int; // How Smart<br />
Stat Dex; // How Fast<br />
Stat Hlt; // How Healthy<br />
Stat Cha; // How Well-Liked<br />
<br />
Stat HP; // How much damage you can take<br />
Stat AR; // Your armor-rating<br />
Stat SP; // Spell-points... How many kobold you can toast<br />
};<br />
<br />
That should be a good starting point for developing a unique character<br />
representation for your RL...<br />
<br />
Section 2 : The Creation<br />
<br />
The actual creation of the character is accomplished by somehow<br />
assigning a score to each of the stats... There are two main ways<br />
to accomplish this; Random Rolling and Point Distribution.<br />
Random Rolling would display all of the statistics, and allow<br />
the player to hit a key to "Roll" (or randomly assign numbers, say between<br />
1 and 100) to each main statistic. The player would then continue rolling<br />
until they have a set of numbers that is agreeable to them.<br />
Point Distribution would give the player's a number of points, say<br />
100, and allow them to distribute those points to their attributes in any<br />
way they wish; Thus allowing the player to design a character that they want<br />
to play.<br />
<br />
Usually, the player's chosen race affects the statistics in some way.<br />
For instance if our player picked:<br />
<br />
A Human - No change; Humans should be pretty standard fare.<br />
An Elf - +2 Dex, -2 Str; Elfs are quick, but weaker than humans<br />
A Frog - +2 Int, -2 Cha; Frogs are obviously intelligent, but ugly...<br />
<br />
Classes are generally restricted by attributes... <br />
<br />
Fighters - No basics; Everyone can pick up a stick and hit something...<br />
Mage - At least a 12 Int; A Mage has to read, at least...<br />
Tourist - At least a 12 Dex; You have to move fast, only 36 days left of<br />
vacation...<br />
<br />
The player might be given some basic equipment based on his class, and<br />
that's about it... That '@' has everything it needs to thump some Kobolds!<br />
<br />
The Author:<br />
Brian Bucklew, 18<br />
bbucklew@inteletek.com<br />
Current RL Project : Dungeon or "This game needs a new name"... :)<br />
Projected Beta Release : Early 98<br />
<br />
= Pretty Pictures - Darren Hebden [rogue@skoardy.demon.co.uk].txt =<br />
<br />
Some thoughts on Graphics in Roguelike Games.<br />
by Darren Hebden [rogue@skoardy.demon.co.uk]<br />
<br />
<br />
Traditionally, if you suggested graphics to a roguelike-<br />
stalwart, you would have found yourself out on your ear for speaking <br />
such heresy. Many would argue that being text-based is a defining <br />
feature of the roguelike genre. Others want more and look upon <br />
graphics as a natural progression. <br />
<br />
Many people (purveyors of quality knee-jerk reactions and 'The<br />
end is Nigh' flavoured rantings) warn of the old-style being phased <br />
out or graphic-based roguelikes lacking the same depth of text-based.<br />
Personally, I like to believe that both can exist quite happily and<br />
that the addition of graphics in roguelike games is a bonus, not a <br />
replacement. It is a new feature and it's use within the roguelikes<br />
is still being explored. <br />
<br />
This document talks a little about the uses of graphics in <br />
roguelikes, the different styles and some graphic techniques. Not <br />
being an expert on all systems (or the one I own, come to that), I'll <br />
try to make my article non-machine-specific. If you know a little <br />
about the packages you own, you should be able understand my texts.<br />
<br />
----//---- <br />
<br />
# Why Graphics.<br />
<br />
PROS.<br />
1) It's a "draw".<br />
The visual style attracts the eye to games that many of the <br />
uneducated heathens (sorry, I mean -- people who haven't encountered<br />
roguelike games before) would ignore and pass over because of their<br />
archaic text-editor style appearance. <br />
<br />
2) It's expected.<br />
Unfortunately, the expectations of todays game player have been<br />
adversely influenced by big budget, multi-cd, flashy productions. I<br />
don't exactly find this a pleasant situation but ignoring it or <br />
"taking a stand" won't help you or your game. <br />
<br />
3) So what's a 'Furgikan-bug'?<br />
Although a great deal of people are up on Tolkien lore and AD&D <br />
monster theory 101, but an unknown creature shown as a 'F' character <br />
on-screen may leave several of your players scratching their heads. A<br />
well-drawn image, however, is instantly recognisable and gives a <br />
better impression of the creatures appearance.<br />
<br />
CONS.<br />
1) Graphics kill the imagination.<br />
The original roguelike style counts on the players imagination <br />
to transform a simple red 'D' into the terrifying bulk of Fire Dragon<br />
flesh. No matter how detailed your graphics are, they may not be able<br />
to live up to the visions swirling around an over-active imagination.<br />
<br />
2) Bigger programs.<br />
The storage of large amounts of graphics data all adds to the <br />
overall archive size for your game. It's very difficult to produce a<br />
competent roguelike game with a small selection of graphics without<br />
compromising the colour-depth or tile size. Whichever way you even<br />
things out, graphics mean an increased game footprint.<br />
<br />
3) Bad graphics drag a game down.<br />
Good graphics can really add to the atmosphere of a game but in<br />
the same way, a bad set of graphics can seriously hamper a game which<br />
is technically competent and full of depth. Will you be able to supply<br />
good graphics for your game or would the game be better served staying<br />
with a text only display? Don't treat graphics like the current<br />
band-wagon to climb aboard.<br />
<br />
----//---- <br />
<br />
# Graphic Styles.<br />
<br />
Although all through this document I speak of older roguelikes<br />
being text based, simple texts characters _are_ a form of graphics. A<br />
'g' from a gremlin may be missing a few limbs and that mad glint in<br />
his eye but people soon become lost within the game world and accept<br />
that a horde of crazed 'g's bearing down on a weakened adventurer is<br />
not a good sign.<br />
<br />
There are several different styles that you can use when representing <br />
your dungeon on-screen. <br />
<br />
1) Flat Tiles.<br />
The most typical use of graphics in roguelikes is a one-for-one <br />
replacement of the ascii-characters themselves. A wall character is <br />
replaced with a brick pattern, a water character by a lump of blue. <br />
<br />
A little work is needed re-assigning what is displayed or how <br />
they are arranged on screen but often, this method restricts the <br />
artist in getting the best from the tile size and colour depth <br />
available. Due to the forced nature of the way the tiles may be <br />
arranged, the artist could be unable to introduce some details that <br />
would improve the overall look.<br />
<br />
This style doesn't _have_ to suffer from badly arranged tiles if <br />
the artist uses the way the tiles are placed to his benefit and the <br />
programmer is willing to make slight alterations to get the best out <br />
of the tiles provided. The perfect solution is to be programmer and <br />
artist :-)<br />
<br />
Badly drawn example... XXXXX<br />
XXXXX<br />
XXXXX<br />
XXXXX <br />
XXXXX<br />
<br />
<br />
2) Pseudo-3D Flat Tiles.<br />
The next style is very similar to the first but instead of flat <br />
patterns for tiles, the impression of depth is given by drawing front <br />
edges on lower half of the tile for the walls. It's a cheap trick but <br />
is quite effective. The illusion is only spoiled by the fact that the <br />
player cannot walk behind the tiles as they occupy the same space as a <br />
normal wall tile. A little 'walk-behind' effect can be gained if the <br />
tiles are overlapped. It okay but you also begin to lose a little of <br />
the floorspace of the tile above.<br />
<br />
All in all, a popular choice and for tiles that need a little <br />
more work when it comes to designing them to fit together. It means <br />
more graphics but generally, it's worth it.<br />
<br />
Badly drawn example... XXXXX<br />
XXXXX<br />
XXXXX<br />
||||| <br />
|||||<br />
<br />
<br />
3) Isometric Tiles.<br />
These tiles create the impression that the level is viewed from <br />
an angle of 45 degrees to the left/right. As they go, this style gives <br />
a very good illusion of depth (apart from the total lack of <br />
perspective, ofcourse). <br />
<br />
A problem with this style is that these tiles really need to <br />
overlap. I've tried some experiments with not overlapping them and <br />
they looked very bizarre. The overlap causes a bit of lost floorspace <br />
of the tiles drawn above the walls but this can be reduced by having <br />
shorter walls. <br />
<br />
As with the overlapping from the previous style, don't go over the top <br />
with the shortened walls though or you'll have levels looking like a <br />
stunted hedge-maze.<br />
<br />
A solution would be to make any wall that overlaps a floorspace <br />
semi-transparent. This effect can be achieved by either some rather <br />
clever palette mixing tricks on the programmers side of things (which <br />
is rather a bit of overkill for a roguelike) or by a chess-board style <br />
hashing of the pixels over the overlapped area -- one pixel of the <br />
wall, one of the floor, etc. It is a bit of a cop-out but quite <br />
effective. <br />
<br />
Badly drawn example... X<br />
XXX <br />
XXXXX<br />
|XXX|<br />
||X||<br />
|||<br />
|<br />
<br />
<br />
4) Tunnel Vision (or That-Style-From-Dungeon-Master).<br />
The player is presented with a full perspective view of a<br />
corridor/tunnel of the dungeon. Items in the distance are smaller and<br />
tunnels lead off from the original at right angles. Movement is <br />
generally made in steps and switching the direction viewed usually<br />
snaps round ninety degrees.<br />
<br />
This style allows for more detail on the wall/floor tiles as the<br />
tiles closest to the player are quite large on screen. I've yet to <br />
see this used in a roguelike game although it has been suggested <br />
quite a few times. Other games have used this style and in some<br />
ways, you could argue that Dungeon Master, Eye of the Beholder, etc.<br />
are in essence roguelike.<br />
<br />
One reason for it not being implemented is that the player can<br />
only see in one direction at a time. Usual roguelikes have forces<br />
coming at the player from all sides. This may put several players off<br />
due to the confusing nature of this 'realistic' feature. Other <br />
windows containing the left/right/back views may help this situation.<br />
<br />
Badly drawn example... .........<br />
|.......|<br />
||.....||<br />
||| |||<br />
||| |||<br />
||.....||<br />
|.......|<br />
.........<br />
<br />
<br />
5) 3D Texture Mapped.<br />
The last style I'm going to cover is texture mapping. So far <br />
(without making a massive leap with the definition of the genre), no <br />
roguelike game has ever used texture mapped 3D graphics. I'm sure if <br />
you visualise a game like Quake, or whatever the current splurge of <br />
the month is, you'll realise what I'm getting at here.<br />
<br />
One problem with texture mapping is that to get a good <br />
definition on the walls, floors, etc. the textures need to be of a <br />
fair size otherwise, close inspection of a wall reveals a horrible <br />
level of pixelisation. 3D accelerator cards (and a certain console) <br />
can provide techniques to smooth the textures but now we're getting <br />
into silly-land. Roguelike game with texture-mapped polygons needing a <br />
3D accelerator card? Hmm. One day maybe...? ;-)<br />
<br />
Anyway, it's really up to you as to what looks right and at what <br />
point it stops looking like a wall pattern and more like a bunch of <br />
large square pixels. Working towards high quality textures means <br />
bigger textures and even more space taken up by the graphics. <br />
<br />
Obviously, programming such a view for just a roguelike game<br />
is no small fear either when compared to the original text-mode (or<br />
even the other styles mentioned in this document). How you present <br />
your 3D environment is up to you. Possible options are the fully<br />
submersing environments of Quake/Mario64. Or you could go for an<br />
isometric display such as Bullfrog's Dungeon Keeper. <br />
<br />
Badly drawn example... Yeah, right.<br />
<br />
----//---- <br />
<br />
# Issues<br />
<br />
Some problems you might want to take into consideration when working<br />
on your graphics...<br />
<br />
# Colour Depth.<br />
<br />
Colour depth is essentially how many colours you're allowed to <br />
create your wondrous and vivid roguelike graphics. Basically there is <br />
two camps. The programmers want the less number of colours possible <br />
and the artists generally want the most. The exception to the <br />
programmers is when the programmer in question doesn't care how much <br />
space the game takes or already has the code to handle higher colour <br />
depths. The exception with artist is when you find an artist who knows <br />
they can get the same effect with less colours.<br />
<br />
A set of tiles that only use a palette of 16 colours but have <br />
been stored as in a graphic format that utilises 65,000 colours uses <br />
up more memory than exactly the same tile set in a format that only <br />
allows for only 16 colours needed. If your tiles only take up a small <br />
range of colours, that 16bit (or 24bit) mode could be a waste of time. <br />
And if you can get beautiful tiles with 16 colours, programmers will <br />
love you. :)<br />
<br />
Again, it's a balance. Try some test tiles first. If you've got<br />
a list of the tiles needed, experiment with some fairly mis-matched <br />
sets and see how they stand up to the lower colour depths. If you're <br />
not happy with how they are working out, move up to the next depth. <br />
Remember though, an artist may have to compromise the graphics he/she <br />
creates to work within limits. Do the best you can with the tools <br />
available and the boundaries you are set.<br />
<br />
<br />
# Tile Size & Screen Size.<br />
<br />
In a perfect world, all players would have limitless hard-drive <br />
space, screen-resolutions that stretch into the ten-thousands and <br />
download the several hundred meg your game takes up in a second. <br />
Problem is, it doesn't work like that. Once again, file-size is <br />
affected by the choice you make over tile sizes. Deciding to expand <br />
your tiles from 16x16 pixels to 32x32 pixels will increase the file <br />
space each tiles takes up by 4. If the programming has decided they <br />
want tiles for each of the five-hundred different flavours of gnome <br />
they've implemented, we're talking of a big increase.<br />
<br />
Can you do everything you want with 16x16? Can you get all the <br />
detail you need and is the detail really necessary? In some cases, a <br />
good artist can 'imply' detail in a very small space. Do you really <br />
need to see the texture on the knight's chain mail or would a light <br />
grey mesh give the same impression?<br />
<br />
Another point to take into consideration is the screen size. A <br />
small screen size and a large tile size could cause trouble and <br />
restrict the amount of 'dungeon' you can see at one time. Small tiles <br />
on a huge screen could mean the player has trouble making out the <br />
tiles and misses out important details. Again - balance.<br />
<br />
See what the programmer wants. How many tiles do they want <br />
onscreen. Make sure that they understand how big that would allow you <br />
to make the tiles. A sample screen knocked up in five minutes is <br />
usually a good visual aid for both you and the programmer. Does it <br />
look right?<br />
<br />
If there is a lot of other information needed onscreen, the <br />
amount of screen left over to the level window may be cut down. Make <br />
sure you take all of that into consideration.<br />
<br />
<br />
# Resizing or Reducing Colours.<br />
<br />
Okay. You've created all your tiles. Five hundred gnomes of all <br />
shapes, sizes and colours. All in 64x64 pixel, 24bit colour tiles. The <br />
programmer gets in touch and tells you that they can't use them. They <br />
need 16x16, 16 colour. Bugger...<br />
<br />
Well, you've got three choices - call it a day, move to Tibet <br />
and take up the serene life of a monk or restart from scratch or start <br />
reducing tile size and colour depth. In the extreme case stated above, <br />
the reduction is going to pretty much murder your graphics and perhaps <br />
restarting is the only way to go. In other situations, when you only <br />
need to reduce the colour depth or just resize, you might just get <br />
away with it.<br />
<br />
One thing to remember when reducing colours, it always helps to <br />
choose a good utility/art package. The best way to test this is to use <br />
it with other graphics first. Choose a picture (maybe a scan of some <br />
sort) with a fair spread of colours and detail. Reduce the colours. If <br />
you're coming down from 24bit to 16bit, chances are you won't notice <br />
the reduction but down to anything less and the package has to create <br />
it's own palette of used colours.<br />
<br />
Most often, it's a best-fit and most-used kind of technique. <br />
Some packages offer different methods for reduction and some use a <br />
dithering algorithms to fool the eye. Sometimes it even works. <br />
Remember though, you may be reducing the colours of some fairly small <br />
tiles and when they begin to repeat in the game, the pattern these <br />
dithered tiles create may become very noticeable. The key to reduction <br />
is getting a good palette. Again, this depends on the tool you use.<br />
<br />
One thing I have noticed is once your package has reduce the <br />
colours, it tends to organise the colours in the palette in a manner <br />
which I find a little 'random'. Personally, I like my colours divided <br />
up into nice hue sets but after reduction, most packages generate <br />
light-to-dark range or that bizarre mac-style organisation that I <br />
dislike so much :) It's a little gripe but remember that if you're <br />
drawing more tiles after the reduction, finding the exact colour <br />
you're after may become a pain in the ass.<br />
<br />
Resizing is another matter. Most resizing does cause your tiles <br />
to lose all their detail and essentially makes touching-up afterwards <br />
a must. Some packages anti-alias or blur the tiles to cover the loss <br />
of detail. This is all very nice within the tile but you've got tiles <br />
with areas that are supposed to be transparent (for overlaying onto <br />
floor tiles, etc.) then the program tends to blur the edges of the <br />
shapes and destroy the clean edge you need. A good package will allow <br />
you turn this off. <br />
<br />
<br />
# 1001 Monsters.<br />
<br />
Not just monsters but potions, swords, shields, helmets, <br />
scrolls, spell-books, traps, walls, floor, stairs, food... well, you <br />
get the idea. When you think of all the tiles you may be called on to <br />
draw, you start begin longing for those simple ascii-characters. When <br />
drawing your tiles, it's always a good start to have some sort of idea <br />
of how many monsters, etc. will be required. If you need several <br />
different types of mold (green mold, yellow mold, red mold, blah-blah-<br />
blah), you would probably be able to get away with the same graphic<br />
but with changes to the colour. It saves time and allows you <br />
concentrate on making the basic mold design stand out from your other <br />
creatures.<br />
<br />
It is also useful to find a theme within creatures. If you need <br />
several ranks of orc, maybe changing their size and armour might help. <br />
If you have a set of monsters that have a specific trait (nether <br />
beasts, lava beasts), it'll help player recognition if you style those <br />
creatures similarly. <br />
<br />
<br />
# 3D packages.<br />
<br />
All styles can enjoy the benefits that using a 3D package can <br />
give. For the 2D bitmap tiles, building your objects and monsters with <br />
a 3D package means that size or colour depth isn't really an issue any <br />
more. The object you create can be rendered from any angle, at any <br />
size and with varying amounts of colour (if the package you're using <br />
is any good in the first place). And because the output is from the 3D <br />
package itself, outputting a smaller render will generally give a <br />
better result than trying to reduce the size of the tile with another <br />
graphics utility. <br />
<br />
Ofcourse, the amount of work required initially is massively <br />
increased as you need to model all the objects you wish to show. The <br />
benefit comes from the flexibility afterwards. For the user wishing to <br />
create modeled creatures for a Quake-style roguelike, a 3D package is <br />
essential. I'm sure there are people out there who can quite happily <br />
create some very good models with a pencil and graph paper but with<br />
so many cheap and shareware modelers on the market, save yourself the <br />
bother.<br />
<br />
<br />
# Size matters? <br />
<br />
Okay, first you're asked to draw a mouse and then you're asked <br />
for a poison breathing dragon. Do your work in scale? Draw a mouse <br />
that takes up a tile then draw a dragon that fills half the screen? <br />
'Course not. If you're drawing a dragon that takes up a tile but a <br />
mouse in scale would be hard pushed to fill a pixel. It takes some <br />
getting used to be it's usually a good idea to throw scale out of the <br />
window. Just pretend that mouse is really, really, really close. :)<br />
<br />
<br />
# Conclusion.<br />
<br />
As you've probably gathered by now, how you go about creating <br />
your graphics depends largely on the games needs. If you have been set <br />
limits either by the programmer or the hardware you're aiming for, <br />
always experiment to get the best you can from the tools you have <br />
available. If you're given an open-ended project with no definite <br />
requirements, planning will save you a lot of work in the long run. <br />
Decide which colour depth and tile size is best for the game and stick <br />
with it.<br />
<br />
Whatever style you choose, its all a question of whether your <br />
roguelike needs these graphics. Do they honestly add something to the <br />
game? Ignore those who automatically scream 'no!' or have built up <br />
some kind of barrier to considering the option. Graphics are just <br />
another feature to add to your game. Like everything you add, whether <br />
it works or not is up to you.<br />
<br />
= Object Representation - Sean Middleditch [sean.middleditch@iname.com]. =<br />
<br />
Representing objects in a roguelike. A difficult thing to do, in fact. When<br />
I started War of the Runes, I wasn't sure exactly how to go about doing it.<br />
Would everything be hard coded into the game? Would objects be malleable?<br />
What kinds of different objects need to be represented?<br />
<br />
Well, for starts, I knew I didn't want anything to be hard coded. One thing<br />
about War of the Runes is that EVERYTHING would need to be able to be changed.<br />
So objects need to be stored in external files, with all descriptions of the<br />
object need to be stored; from description, to behavior, to properties. And<br />
this also means all objects needed to be malleable. the state of an object can<br />
change at any time through any number of ways. And what kinds of objects were<br />
there? There's weapons and armor, food and drink, doors, chests, bags, rings,<br />
books, anything that can exist in a real world.<br />
<br />
So what is the best way to represent objects in a roguelike? Well, first we<br />
need to start with an object class:<br />
<br />
class Object {<br />
public:<br />
<br />
What kind of data do we need for objects? For starts, we need to know what<br />
the object is. We can do this with a name and a description;<br />
<br />
char *Name, *Desc;<br />
<br />
That's fairly self-explanatory. Information about where the object is would<br />
be useful, too:<br />
<br />
int X, Y;<br />
<br />
There are lots of different objects in the roguelike universe. Armor,<br />
weapons, books, rings, potions, lawn-chairs, etc. Each object can only be<br />
of one type.<br />
<br />
int ObjType;<br />
<br />
This field will be set to a value we define with #define's.<br />
<br />
#OBJ_WEAPON 1<br />
#OBJ_ARMOR 2<br />
#OBJ_POTION 3<br />
<br />
You get the idea. Every different type of object in the game would need a<br />
separate number. This will help in a LOT of areas. For example, characters<br />
can only equip items of type 2 (armor).<br />
<br />
Since I'm sure some of you may be a bit confused (I know I'm not the best of<br />
teachers) why don't we start defining an example item before we continue? A<br />
longsword.<br />
<br />
We'd set the Name field to point to "long sword". Simple enough. The Desc<br />
field would be "a long, sharp, metal stick". Well, you may want to use<br />
something other than that.<br />
<br />
The X,Y coordinates can be set to whatever... let's say 2,10.<br />
<br />
What about the object type? 1 (OBJ_WEAPON) of course!<br />
<br />
Now what? What does a longsword do? The game knows it's a weapon, but the<br />
game needs more information than that.<br />
<br />
Let's make a class to define what an object does.<br />
<br />
class ObjArg {<br />
public:<br />
<br />
Each ObjArg will define one aspect of an object. We'll need a way to store<br />
what each ObjArg defines.<br />
<br />
int ArgType;<br />
<br />
We'll give this meaning through the use of more defines.<br />
<br />
#define OARG_ATTACK 1<br />
#define OARG_DEFEND 2<br />
#define OARG_HEAL 3<br />
<br />
Now we know what an ObjArg defines. Now we need to store the actual<br />
definition. We'll do this by storing an array of 5 integers.<br />
<br />
int Args[5];<br />
<br />
And that's all there is to the ObjArg class. The meaning of the Args<br />
array's field will depend on the value of ArgType.<br />
<br />
Now, we want every object to be pretty versatile, so we'll make it so<br />
every object has 5 of the ObjArg classes.<br />
<br />
} Defines[5];<br />
<br />
And that's all we need for a basic Object class<br />
<br />
};<br />
<br />
So how does the ObjArg class work? Well, for our longsword, we'll need<br />
only one. It's ArgType will be set OARG_WEAPON. Now what about the<br />
Args array? Let's say for ArgType 1 (weapon), the first field of Args<br />
is the number of damage dice, the second field is sides per die, the<br />
third field is damage modifier, and the fourth field is the modifier<br />
to the character's skill. The fifth field will be unused.<br />
<br />
So, if we wanted long sword's to cause 1 to 8 damage, with no<br />
additional modifiers to damage or attack skill. So...<br />
<br />
Args[0] = 1<br />
Args[1] = 8<br />
Args[2] = 0<br />
Args[3] = 0<br />
<br />
Now if the character equips the long sword and attacks, we'll first<br />
check to see what kind of object is in the character's hand. We see<br />
the ObjType field is set to 1 (weapon). OK, so he/she can attack with<br />
that object. Now we'll look through the Defines array until we find an<br />
ObjArg entry whose ArgType is set to 1 (attack). The game see that<br />
Defines[0].ArgType = 2, so we'll use that ObjArg to look up the weapon's<br />
statistics. The game checks Defines[0].Args[3] = 0, so there's no skill<br />
modifier. The game does whatever combat system and determines the<br />
character hit. It check the damage (Args fields 0, 1, 2) and sees that<br />
the long sword does 1d8+0 damage. The game rolls the damage, hurts the<br />
target, etc.<br />
<br />
Well, that's all you need for simple objects. Although, you could do a<br />
LOT more, using the sample code I've given here as a base. For example,<br />
some ObjArgs are in effect whenever an item is equipped (the long sword's<br />
attack field, or armor's defend field). Some objects, like potions,<br />
don't effect unless a character uses the object (or in the case of objects<br />
with ObjType = 3, the character quaffs the potion). Only then will their<br />
ObjArg fields (like healing, in the case of a potion of healing) take<br />
effect. So you might want to store how many times an object can be used,<br />
and how many times it has been used.<br />
<br />
The complete code for the Object class is:<br />
<br />
#define OBJ_WEAPON 1<br />
#define OBJ_ARMOR 2<br />
#define OBJ_POTION 3<br />
<br />
#define OARG_ATTACK 1<br />
#define OARG_DEFEND 2<br />
#define OARG_HEAL 3<br />
<br />
class Object {<br />
public:<br />
<br />
char *Name, *Desc;<br />
<br />
int X, Y;<br />
<br />
int ObjType;<br />
<br />
class ObjArg {<br />
public:<br />
<br />
int ArgType;<br />
<br />
int Args[5];<br />
} Defines[5];<br />
};<br />
<br />
If you have any questions, feel free to e-mail me at<br />
sean.middleditch@iname.com<br />
<br />
The End<br />
<br />
= Inventory Abstraction - Kenneth Power [uncle_wiggly@bigfoot.com]. =<br />
<br />
An Inventory tracks Items in Storage. Items are anything you deem <br />
trackable: gloves, clubs, food, coins, flowers. Storage is anything<br />
defined as able to hold items: chests, sacks, hands, buildings.<br />
<br />
A basic Inventory does not care about extraneous fluff, such as <br />
container limitations. Keeping inventory implementation basic enables <br />
code reuse as discussed later.<br />
<br />
Throughout this paper, psuedo code is used to model examples. The <br />
examples use the following sample item definition:<br />
<br />
define Item:<br />
variable Name<br />
<br />
<br />
Tracking items<br />
There are two basic ways to track items. First is with a simple list, <br />
rather like writing a list of groceries. Lists usually are FIFO (First <br />
in First out) or LIFO (Last in First out). Other ways may exist. Indeed <br />
in some languages, there are very exotic forms of lists. A trouble with <br />
lists is the retrieval of information from the middle of the list. The <br />
list is examined from either end until the information is located.<br />
<br />
Our example simple list:<br />
<br />
list define Inventory<br />
<br />
Second is through a more complex scheme wherein more than the item is <br />
tracked. Also tracked is information about the item. This is so items <br />
may be grouped. Grouping has its pro's and con's like anything else. <br />
Use of grouping, for example, allows easier display of items (in my own <br />
opinion of course). In a way, grouping is a more esoteric list form, <br />
using such things as dictionaries, maps and other terms. <br />
<br />
In this example, the items are tracked by their name. Example:<br />
<br />
list define Inventory:<br />
list define itemNames<br />
keyedList define qtys<br />
<br />
<br />
Add items<br />
What use is an Inventory if you are not able to add items to it? Thus,<br />
the first function we define is the add() function. <br />
<br />
In basic form, add() only wants to place the passed item to the list:<br />
<br />
List define Inventory:<br />
define add(item):<br />
insert item<br />
<br />
With the complex form, add() is more detailed. Questions are raised: <br />
is the item already in inventory - this might affect or tracking <br />
feature-? Did I/you make an adjustment to the tracking feature if <br />
necessary? Note how this is done in the example: <br />
<br />
list define Inventory:<br />
list define itemNames<br />
keyedList define qtys<br />
define add(item):<br />
if item is in me.itemNames #do I exist?<br />
then me.qtys.key(item.name) = +1<br />
if item is not in me.itemNames #I don't exist<br />
then me.qtys.key.add(item.name)<br />
me.itemNames.add(item.name)<br />
me.qtys.key(item.name) = +1 <br />
<br />
<br />
Remove items<br />
The remove() function is really the opposite of add(). Find the item <br />
passed and remove it from the list. Let's examin it with our two <br />
pseudo codes.<br />
<br />
Of course, this example doesn't take into consideration language <br />
dependent behavior (C - did you fix your pointers?). Thus the <br />
abstraction is the same for add():<br />
<br />
List define Inventory:<br />
define remove(item):<br />
delete item<br />
<br />
Here, as in the complex add() function, more work needs accomplished. <br />
We not only find the item, but we make certain our tracking feature <br />
is adjusted accordingly.<br />
<br />
list define Inventory:<br />
list define itemNames<br />
keyedList define qtys<br />
define remove(item):<br />
if item is in me.itemNames<br />
then me.qtys.key(item.name) = -1<br />
if me.qtys.key(item.name) == 0<br />
then me.qtys.delete(item.name)<br />
if item is not in me.itemNames<br />
then error<br />
<br />
At the completion, our example would show the proper quantity for the <br />
item. Plus, if we have no more item in inventory, no quantity or <br />
listing will exist.<br />
<br />
<br />
Display items (opt.)<br />
This is listed as optional, because you may not code Inventory display <br />
as part of your Inventory. It may be in your UI code. However, during <br />
testing, having a simple Inventory Display feature is very useful.<br />
<br />
Like always, the simplest way is the list method. Merely iterate the <br />
list, printing each item: <br />
<br />
List define Inventory:<br />
define display():<br />
For each item in Inventory:<br />
print item.name<br />
<br />
Because of our tracking feature, we need print item and qty. Otherwise <br />
uncertainty will exist. The only added feature of the complex over <br />
simple is the header printed "Item Qty". <br />
<br />
List define Inventory:<br />
define display():<br />
print "Item Qty"<br />
for each item in me.itemNames:<br />
print item, me.qtys.key(item.name)<br />
<br />
<br />
Possible benefits<br />
For developers using OO style languages (C++, SmallTalk, Java, etc), <br />
having a simple Inventory Object lets you easily include it in other <br />
areas of the game. Containers (combinations of Items and Inventory), <br />
Buildings (Structure and Inventory), and more can be made. Of course <br />
non-OO languages(C, Pascal, Basic) can use Inventory as functions in <br />
other parts of the game. The point is: once you define what a basic <br />
inventory will be in your game, find how to use it in more areas.<br />
<br />
An Example<br />
Here is an example inventory, using the Python language. I find Python <br />
to be a grat language for prototyping. It is easy to spot errors, fix <br />
them, etc. Then you may easily recode in any other language.<br />
<br />
The Item Object - <br />
class Item:<br />
def __init__(self, name): #object constructor<br />
self.name = name<br />
The Inventory Object -<br />
class Inventory:<br />
def __init__(self):<br />
self. NameList = [] #a list of item names<br />
self.qtys = {} #a dictionary of item quantities<br />
self.contents = [] #a list of actual items<br />
def add(self, itemList = []):<br />
for item in itemList:<br />
#Check item is self<br />
if item is self:<br />
print 'Cannot store', item,' in itself!'<br />
if item in self.contents:<br />
print 'You already have this item!'<br />
else:<br />
#Check if item is in nameList<br />
if item.name in self.NameList:<br />
#merely insert<br />
self.qtys[item.name] = self.qtys[item.name] + 1<br />
#otherwise add to nameList<br />
else:<br />
self.qtys[item.name] = 1<br />
self.nameList.append(item.name)<br />
self.contents.append(item)<br />
def remove(self, item):<br />
#does item exist?<br />
If item not in self.contents:<br />
print item.name, 'is not in your inventory'<br />
else:<br />
self.qtys[item.name] = self.qtys[item.name] - 1<br />
if self.qtys[item.name] == 0:<br />
del self.qtys[item.name]<br />
self.NameList.remove(item.name)<br />
self.contents.remove(item)<br />
def display(self):<br />
#let's show everything!<br />
Print "Item\tQty"<br />
for item in self.NameList:<br />
print item,"\t", self.qtys[item]<br />
<br />
<br />
More Info<br />
For information about Python, visit: http://www.python.org<br />
Please send all comments, queries, and error notifications to the author.<br />
Written by: Ken Power email: uncle_wiggly@bigfoot.com<br />
Version: 1.0 Date: Oct. 25, 1999<br />
<br />
= Creating Inventories - Erno Tuomainen [ernomat@evitech.fi]. =<br />
<br />
----------------------------------------------------------------------------<br />
CREATING INVENTORIES - WHAT TOOLS ARE AVAILABLE<br />
(C) 1997 Erno Tuomainen<br />
ernomat@evitech.fi<br />
16th of November 1997<br />
----------------------------------------------------------------------------<br />
<br />
I know that many of you wonder about this problem. Atleast I did so when<br />
starting my Roguelike project (Legend of Saladir). In this article I<br />
intend to give you some tools for making those inventories, it's not<br />
intended to be a complete tutorial for making player inventories, maybe<br />
later I can offer you some more routines/ideas related to this subject.<br />
<br />
I assume that the reader of this article is not a total beginner (hey,<br />
you are starting to make your own game! :) and has a basic knowledge of<br />
C-language along with knowledge of pointers. And please, forgive me my<br />
bad english!<br />
<br />
Without any more hassle, lets begin defining a basic item structure for<br />
all examples in this article. This is just an example, the item defined<br />
is not really useful in real development :)<br />
<br />
typedef struct ITEMTYPE<br />
{<br />
int itemtype;<br />
int weight;<br />
unsigned int attributes;<br />
} Titem;<br />
<br />
So this is just a data structure which contains all the information<br />
needed for a particular item. Every item in the game has a similar<br />
(exactly!) structure.<br />
<br />
There are basically two methods of creating the inventory list for<br />
player/monster.<br />
<br />
1. Fixed size array<br />
-------------------<br />
<br />
You allocate an array of for example 100 items. Obviously this has one<br />
big disadvantage, you can't carry more than 100 items if the programmer<br />
doesn't change the code and secondly this array always takes<br />
100*sizeof(Titem) bytes of memory even if you were carrying just one<br />
item. <br />
<br />
Player-information structure would look like this:<br />
<br />
typedef struct PLAYERTYPE<br />
{<br />
char name[100]; /* normal player information fields */<br />
int age;<br />
<br />
Titem inv[100]; /* inventory array containing 100 items (See Titem definition) */<br />
} Player;<br />
<br />
So this is a structure which keeps all information about our player. You<br />
will have similar structures for your monsters/NPC's too, they might be<br />
a bit different but you can use the same methods for your monsters too.<br />
<br />
So the size is constant. The good point is that additions and deletions<br />
to this list are easy, you can index it directly. However, you can't<br />
easily insert/delete items to/from the middle of the list. It requires<br />
rebuilding the array from the point where you are inserting. This is<br />
slow.<br />
<br />
Another good point is that when you are going to save this structure,<br />
you just store this whole block into the file.<br />
<br />
This kind of approach has it's own good uses, but I have a better method<br />
for the purpose we are talking about.<br />
<br />
2. Dynamic memory allocation with linked lists<br />
----------------------------------------------<br />
<br />
So what is this? Ok, you can guess from the name. Each time you need a<br />
new item added to the inventory you allocate space for it and link it to<br />
the inventory you already have for your player/monster.<br />
<br />
This is a bit more complicated but it's not too hard when you go and<br />
think about it! When adding to the middle of the list, all you need to<br />
do is to go to the right place and move some pointers.<br />
<br />
Now, keeping the above player structure mostly the same, but modifying<br />
only the inventory part we will get:<br />
<br />
typedef struct PLAYERTYPE<br />
{<br />
char name[100]; /* normal player information fields */<br />
int age;<br />
<br />
InvList *inv; /* pointer to the start of inventory list */<br />
} Player;<br />
<br />
What is the third field "InvList *" in the structure, I hear you ask.<br />
<br />
"InvList" is also a structure, it defines ONE node for the inventory<br />
list. Node is one segment of the dynamic linked list. Look at this<br />
picture:<br />
<br />
+-------+ +-------+--+<br />
| start |----->| node 1| >---\ +-------+------+<br />
+-------+ +-------+--+ \-->| node 2| NULL |<br />
+-------+------+<br />
<br />
This example resembles a linked list with TWO nodes, the first block<br />
named 'start' contains a pointer to the node 1, telling that the first<br />
node of the list is there. And again, you see that in 'node 1' there is<br />
a extra field which contains a pointer to the NEXT node or 0 (NULL) if<br />
the list ends there.<br />
<br />
So the above "Player" structure contains just a POINTER to the players<br />
inventory list. It's a memory address holding the first node of the list<br />
if any (or NULL if inventory is empty!)<br />
<br />
At this point, compare this method to the array method I showed you<br />
earlier. If items are stored in array they will be stored in sequential<br />
order in memory ( 1-2-3-4-5-6-..) as one big block next to each other.<br />
In the case of linked lists, the list consists of nodes, which can be<br />
all around in the memory, the order of the list is preserved with the<br />
pointers linking each node to another. This list is called as "one way<br />
linked-list" or "single linked list" meaning that you can traverse only<br />
to one direction along the list. There is also a list which contains a<br />
"previous" and "next" link. This is a "dual linked" or "two way linked"<br />
list. But I won't speak about it this time.<br />
<br />
Now we have structures for the ITEM and the PLAYER. We must define the<br />
structure for InvList defining a one node of the list.<br />
<br />
typedef struct node<br />
{<br />
Titem item;<br />
struct node *next;<br />
} InvList;<br />
<br />
or like this:<br />
<br />
/* define a pointer to the list node */<br />
/* so we can use "Ipointer" instead of "struct node *" */<br />
typedef struct node *Ipointer;<br />
<br />
typedef struct node<br />
{<br />
Titem item;<br />
Ipointer next;<br />
} InvList;<br />
<br />
I will use the first method.<br />
<br />
The first field in the struct is the actual item stored in this node,<br />
and the "next" field contains an address to the NEXT node if there is<br />
such a node. (NULL telling that list is terminated here)<br />
<br />
So basically this is a very simple idea, it requires a bit more work to<br />
maintain this kind of inventory, but it offers some advantage which are<br />
really good for Roguelike games. You can use this kind of list in many<br />
places. For example, I use it in these situations:<br />
<br />
List of monsters in the level<br />
List of items in the level<br />
List of items carried by the player<br />
List of items carried by monsters<br />
<br />
So in my game, only limitation in the above situations is the amount of<br />
memory available. There can be for example 1000 items in a level.<br />
<br />
This practise can be used in MANY other situations, in other programs<br />
too. It's all depends in your imagination and how you can make this<br />
thing useful in certain situations.<br />
<br />
I must point however that this "linked list" method will make you some<br />
problems later on. Think about savegames. You must create a routine<br />
which saves each node from the list and when loading you must build the<br />
list again. Not a big deal, but it brings you again a bit more work to<br />
do :)<br />
<br />
Now that we have the idea coverered, let's start writing some code for<br />
the list.<br />
<br />
----------------------------------------------------------------------------<br />
WHAT FUNCTIONS DOES THIS KIND OF LIST NEED<br />
----------------------------------------------------------------------------<br />
<br />
First off, you need to initialize this list, you'll need node addition,<br />
node deletion and the routine for deleting the whole list. Let's create<br />
the actual code for these functions.<br />
<br />
1) Initialization of the list<br />
<br />
void initialize_list(Player *player)<br />
{<br />
player->inv=NULL;<br />
}<br />
<br />
This routine takes a pointer to the player structure and initializes the<br />
list pointer to NULL, telling that list does not exists yet. (so player<br />
has no items in inventory!)<br />
<br />
Please note that you should not call this routine if you have items<br />
stored in the list. You will destroy the pointer to your list, thus you<br />
will have allocated memory which can't be freed because you lost the<br />
pointer.<br />
<br />
2) Node addition<br />
<br />
This routine adds a node to the list. I use the method where the last<br />
added node will be put to the BEGINNING of the list (thus to the field<br />
Player->inv) and this new node will point to the to the previous value<br />
of Player->inv. Like this:<br />
<br />
int add_node(Player *player, Titem newitem)<br />
{<br />
InvList *newnode;<br />
/* allocate memory for the new node */<br />
newnode=(InvList *)malloc(sizeof(InvList));<br />
<br />
/* if newnode == 0 then the memory is out or something is messed up */<br />
if(!newnode)<br />
return 0;<br />
<br />
/* now place the new data item to the item-field in space we allocated */<br />
/* remember, "newnode->item" is similar to "newitem", both are defined */<br />
/* by "Titem" */<br />
newnode->item=newitem;<br />
<br />
/* if player inventory does not yet exists */<br />
if(player->inv==NULL) {<br />
newnode->next=0;<br />
player->inv=newnode;<br />
}<br />
else {<br />
/* point the "next" field of "newnode" to the old player->inv */<br />
newnode->next=player->inv;<br />
/* point the player->inv field to the node we just created */<br />
player->inv=newnode;<br />
}<br />
return 1;<br />
}<br />
<br />
The function returns 0 if the addition failed, otherwise 1.<br />
<br />
3) Node deletion<br />
<br />
This routine really depends on the fact how you want to delete the item<br />
from the list. I will create a routine which removes item with an index.<br />
For example, you might want to delete the fifth item from the list.<br />
<br />
Here is an example, it's not the optimal routine, should be easy to<br />
understand<br />
<br />
int delete_node(Player *player, int index)<br />
{<br />
InvList *node, *tmp;<br />
int count;<br />
<br />
/* again check first if the inventory exists */<br />
if(!player->inv)<br />
return 0;<br />
<br />
node=player->inv;<br />
<br />
/* if you are trying to delete the first node */<br />
if(index==0) {<br />
player->inv=node->next;<br />
free(node);<br />
<br />
/* we are done so return with success */<br />
return 1;<br />
}<br />
<br />
count=0;<br />
while(node) {<br />
/* remember the previous node */<br />
tmp=node;<br />
node=node->next;<br />
<br />
/* increase the item count in list */<br />
count++;<br />
if(count==index) break;<br />
}<br />
<br />
/* if trying to delete item over list boundaries */<br />
if(monesko>count) return 0;<br />
<br />
tmp->next=node->next;<br />
free(node);<br />
return 1;<br />
}<br />
<br />
4) Freeing the whole list at once<br />
<br />
Here is a useful routine for freeing the whole list at once. Notice how<br />
I traverse on the list.<br />
<br />
void free_list(Player *player)<br />
{<br />
InvList *tmp, *freethis;<br />
<br />
/* put the start of inventory to temporary variable */<br />
tmp=player->inv;<br />
<br />
/* do until we reach NULL */<br />
while(tmp) {<br />
freethis=tmp;<br />
<br />
/* assign "tmp" with the next node, if there isn't a next node<br />
"tmp" will contain NULL */<br />
tmp=tmp->next;<br />
/* free the current node */<br />
free(freethis);<br />
}<br />
player->inv=NULL;<br />
}<br />
<br />
The similar approach can be used for example when displaying the<br />
contents of the list.<br />
<br />
----------------------------------------------------------------------------<br />
SOMETHING EXTRA<br />
----------------------------------------------------------------------------<br />
<br />
<br />
Linked list is just one of the advanced data types (often called as<br />
Abstract Data Types, ADT), there are many other types of ADTs which can<br />
be useful in game programming. For example, Queue and Stack. Each of<br />
them have many uses, and again many ways to implement them. Some<br />
explanations.<br />
<br />
Stack<br />
-----<br />
<br />
Stack is a special case of a list. New items inserted to the stack will<br />
always go to the end of the list and when you take something out it will<br />
be taken from the end. So this type of list is called LAST IN FIRST OUT<br />
(LIFO). Stack has many uses.<br />
<br />
+-+----+<br />
|3|data| top/end of the stack (last added item)<br />
+-+----+<br />
|2|data|<br />
+-+----+<br />
|1|data|<br />
+-+----+<br />
|0|data| start of the stack<br />
+-+----+<br />
<br />
So items will "pile up" in the stack. You'll get the most recent item<br />
when you get something from the stack.<br />
<br />
One example from computer world. We want to check if a string is a<br />
palindrome: (string read forwards equals string read backwards)<br />
<br />
create 3 empty character stacks<br />
<br />
state1:<br />
for each_char_in_string do<br />
put_into_stack1(current char from string)<br />
put_into_stack2(current char from string)<br />
count=count+1<br />
end_do<br />
<br />
state2:<br />
while stack_2_has_something do<br />
put_into_stack3(take_from_stack2())<br />
end_do<br />
<br />
state3:<br />
while stack_1_has_something do<br />
if take_from_stack1() equals take_from_stack3()<br />
palindrome=true,<br />
else<br />
palindrome=false<br />
end do<br />
<br />
for example for word "automatic" it would go like this:<br />
<br />
after state1<br />
stack 1 contains: automatic<br />
stack 2 contains: automatic<br />
after state2<br />
stack 1 contains: automatic<br />
stack 3 contains: citamotua<br />
in state3 we take from both stacks and compare them:<br />
? a==c ?<br />
? u==i ?<br />
and so on...<br />
<br />
Queue<br />
-----<br />
<br />
Again, queue is a special case of a list. Items placed into the queue<br />
will go to the end and items taken from the queue will be taken from the<br />
start.<br />
<br />
first last<br />
+------+------+------+------+------+------+ +------+<br />
<--| data | data | data | data | data | data | <-- add | new |<br />
+------+------+------+------+------+------+ +------+<br />
<br />
Good example taken from the Real Life(tm) could be a BANK QUEUE. You<br />
come to the bank and the desk you go has a long long and long queue<br />
(it's friday and the bank is going to close soon :), you will have to go<br />
to the end of the queue. When the bank clerk can, he/she takes a next<br />
customer from the first position of the queue.<br />
<br />
The end?<br />
--------<br />
This ends this part of the lesson. I've tried to provide you a method<br />
for creating dynamic inventories along with some knowledge of other<br />
advanced data types. It's up to you to decide how you make use of them.<br />
<br />
I thank you for reading this, and apologise for any errors in C-examples<br />
I provided, there might be some since this text was written on a fly<br />
without any aid of C-compiler :)<br />
<br />
If you have any questions, ideas for my game, or want to report a bug in<br />
my examples, please feel free to contact me via email.<br />
<br />
ernomat@evitech.fi<br />
<br />
Also go see the homepage of my Roguelike project:<br />
<br />
The Legend of Saladir<br />
http://www.evitech.fi/~ernomat/saladir/main.html<br />
<br />
This text is written specially for Darren Hebden's Roguelike News<br />
developers section. Visit Darren's great pages at<br />
<br />
"http://www2.krisalis.co.uk/wwwdheb/index.html"<br />
<br />
----------------------------------------------------------------------------<br />
(C) 1997 by Erno Tuomainen Sunday 16th of November 1997<br />
----------------------------------------------------------------------------<br />
Do not modify or publish without my approval.<br />
<br />
= Equipment Wear and Tear - Michael Heinich [mheinich@yahoo.com]. =<br />
<br />
Every piece of equipment should have a durability. One example of this <br />
system is demonstrated in a popular series of commercial hack and slash games<br />
with some Rogue-Like tendencies. Another example can be found in ADOM. Both <br />
of these implementations could be improved upon.<br />
<br />
In the commercial games, durability played a very important if limited role.<br />
If an item's durability reached 0, it was broke beyond repair. This was <br />
normally kept as a ratio of current:maximum durability. The game allowed a <br />
character class a repair skill to partially repair an item. The drawback was <br />
that the maximum durability was reduced. Or a member of the town was able to <br />
provide this service. Found items had a lower then maximum durability and <br />
equipment that was used, lost durability during the course of weilding or <br />
wearing them. Durability also effected the value of the item in question. An <br />
item in great shape was worth more then the same item in bad repair. While <br />
the measurement system was easy to understand and to manage, it could still <br />
be improved upon. <br />
<br />
One area is in the item's use. The equipement was either broke or not. A <br />
better method would be to reduce the effectivness of the item in question. <br />
Using a sword for example, as it becomes worn out, the sword may cause less <br />
damage because it has become dull with use. Or the sword may have an ever <br />
increasing change where it may break during an attack as it's durability <br />
decreases. An armor example would be that the protection a chain mail shirt <br />
provides may be reduced as it's durability worsens. <br />
<br />
ADOM does take some of these factors into consideration, but it can be <br />
confusing to figure out the multitude of stats offered (some would say that <br />
this is one of it's strengths)and it lacks adequate skills or town services <br />
for the repairing of items. Usually it is usually better to replace an item <br />
then to repair it. <br />
<br />
Here are some more ideas thrown out more or less at random that build on this <br />
concept. The use of durability can also open other possibilities for object <br />
descriptives and use. For example, a sword that is undamaged and is like <br />
brand new may have a desciption before identification of Shiny and Sharp, as <br />
the sword becomes used, the description may change to dull and nicked. <br />
Durability provides an interesting twist to potions or items made of glass. <br />
Potions may be in delicate containers. In Angband, potions sometimes break <br />
when they are subject to heat or cold attacks. But what if a potion is dropped <br />
or thrown. They should spill, spreading their contents over the floor, wall or<br />
monster. This could cause interesting effects if the Potion was healing or Acid. <br />
A Crystal Ball may not last too long under a heavy attack by giants or earth <br />
hounds. Just how sturdy is a Lantern full of Oil anyway? Why hasn't one of <br />
these broke after an attack, spilling flaming oil all over the user. Or throwing <br />
the lantern, to have it's flaming contents spill over the monster. This is much <br />
preffered to the Flask of Oil attack in Angband. Since it assumes that you have <br />
lit the Flask first somehow. <br />
<br />
The code to add statistics for wear and tear should not be to hard to add to your <br />
Roguelike. Specially if you are using an Object Oriented programming language. <br />
You can just add an extra two lines to the Class for starters.<br />
<br />
int CurrentWear, NoWear; // Measure how much wear and tear<br />
int Durability; // How durable is this item<br />
<br />
In your object definition for a sword you would add the value for NoWear an the <br />
value for Durability. During the Object creation you would assign the value of <br />
NoWear to CurrentWear.<br />
<br />
CurrentWear = NoWear; // set CurrentWear value to NoWear<br />
<br />
Then when ever the item is used or after a certin number of uses, you would <br />
subtract from the value.<br />
<br />
if (NumOfUses == 10) {<br />
CurrentWear--;<br />
if (possiblebreak(Sword.CurrentWear)) Sword.Status = BROKE;<br />
NumOfUses=0;<br />
}<br />
<br />
I hope these meanderings showed you a new diminsion for your Game. The code examples <br />
were way oversimplified but will hopefully point you in the right direction. <br />
<br />
Happy Coding!<br />
<br />
= Fractal Landscapes - Mike Anderson [mike@mikera.net]. =<br />
<br />
30th October 1999<br />
<br />
There's something special about fractals. Maybe it's the way that<br />
infinitely complex shapes appear out of the simplest mathematical <br />
formulae.....<br />
<br />
Certainly beautiful, but why would you want to use them in your game?<br />
The answer, quite simply, is that they are perfect for generating<br />
realistic-looking landscapes. For example, real coastlines frequently<br />
exhibit fractal-like properties and fractal heightfields are often a<br />
good first approximation to the contours of mountainous terrain.<br />
<br />
Here I'm going to present a basic fractal algorithm that was<br />
originally designed for generating random islands, seas and coastlines.<br />
With a few minor alterations, it could easily be adapted to producing<br />
all kinds of natural landscape patterns. My algorithm is vaguely based <br />
on the familiar "plasma" type of fractal heightfield, but modified to <br />
work with tiled maps.<br />
<br />
I've included the source for a simple Java coastline generator applet<br />
at the end of this article. If you are impatient and want to see the <br />
thing working right away, just go to:<br />
<br />
http://www.mikera.net/code/coastline.html<br />
<br />
<br />
The Fractal Algorithm<br />
=====================<br />
<br />
One of the distinctive properties of fractal images is self-similarity.<br />
That is, a zoomed in version will look similar to the whole image. This<br />
algorithm achieves this effect by starting with a coarse map, and then <br />
enhancing it by applying increasing levels of random detail.<br />
<br />
Let's say that you are considering a square area of your map with the<br />
corners labelled a, b, c and d :<br />
<br />
a * b<br />
<br />
* * *<br />
<br />
c * d<br />
<br />
Each map square can have a different colour. I used green for land and<br />
blue for sea in the example applet.<br />
<br />
The algorithm will then determine the map colours for the intermediate<br />
points marked "*". It does this by randomly choosing a colour from one<br />
of the adjacent corner squares. The "*" in the centre could take the<br />
colour of either a, b, c or d.<br />
<br />
Thus a possible final result might be:<br />
<br />
a a b<br />
<br />
c b d<br />
<br />
c c d<br />
<br />
<br />
We have now defined smaller squares on the map. The algorithm can then<br />
be applied iteratively on a smaller scale. This process continues until<br />
the desired level of detail is achieved.<br />
<br />
a*a*b<br />
*****<br />
c*b*d<br />
*****<br />
c*c*d<br />
<br />
Note that for convenience, it is helpful to have a map size that is a<br />
power of two so that it can be repeatedly subdivided.<br />
<br />
<br />
Example<br />
=======<br />
<br />
Below shows the iterations for a 16*16 grid.<br />
<br />
For viewing convenience, the larger tiles have been completely filled<br />
with the colour from the top-left corner, though this is not needed for<br />
the algorithm to work.<br />
<br />
In addition, the map is considered to be toroidal, i.e. the points on<br />
the left edge are considered to be adjacent to those on the right edge,<br />
and similarly for top and bottom.<br />
<br />
<br />
Step 1:<br />
a-------b#######<br />
--------########<br />
--------########<br />
--------########<br />
--------########<br />
--------########<br />
--------########<br />
--------########<br />
c#######d-------<br />
########--------<br />
########--------<br />
########--------<br />
########--------<br />
########--------<br />
########--------<br />
########--------<br />
<br />
(a, b, c and d mark the points that are coloured at the start. This<br />
can be done randomly, or they can be pre-set to create land masses)<br />
<br />
<br />
Step 2:<br />
--------########<br />
--------########<br />
--------########<br />
--------########<br />
########----####<br />
########----####<br />
########----####<br />
########----####<br />
----####--------<br />
----####--------<br />
----####--------<br />
----####--------<br />
############----<br />
############----<br />
############----<br />
############----<br />
<br />
<br />
Step 3:<br />
------########--<br />
------########--<br />
--##----########<br />
--##----########<br />
########----####<br />
########----####<br />
######--------##<br />
######--------##<br />
----####--------<br />
----####--------<br />
----##----------<br />
----##----------<br />
##########------<br />
##########------<br />
##--########----<br />
##--########----<br />
<br />
<br />
Step 4:<br />
-----########---<br />
------########--<br />
-##-----########<br />
--##----#--#####<br />
########----####<br />
########-----###<br />
######--------##<br />
#-####--------#-<br />
----####--------<br />
---####---------<br />
---###----------<br />
-#--#--#--------<br />
##########-----#<br />
#########-#-----<br />
##-#########----<br />
#----######-----<br />
<br />
<br />
Et voila - one random continent ready to be populated with thriving<br />
cities, dangerous mountain ranges and deep forests.<br />
<br />
<br />
The Code<br />
========<br />
<br />
Here's a quick Java implementation of the fractal coastline algorithm.<br />
It generates a new landscape each time the applet is repainted.<br />
<br />
The makeFractal(step) method does all the actual work. This method<br />
calls itself to handle finer detail levels.<br />
<br />
<br />
========= CoastApp.java ==========<br />
package kult.quest;<br />
<br />
import java.awt.*;<br />
import java.applet.*;<br />
import java.awt.event.*;<br />
<br />
public class CoastApp extends Applet {<br />
<br />
// map size: must be a power of 2<br />
public static final int size=128;<br />
<br />
// allocate map storage<br />
public int[] map= new int[size*size];<br />
<br />
public void paint(Graphics g) {<br />
super.paint(g);<br />
<br />
// initial pattern (0=sea, 1=land)<br />
setCell(0,0,0);<br />
setCell(size/2,0,0);<br />
setCell(0,size/2,0);<br />
setCell(size/2,size/2,1);<br />
<br />
makeFractal(size/4);<br />
<br />
// draw the map<br />
for (int y=0; y<size; y++) for (int x=0; x<size; x++) {<br />
g.setColor( (getCell(x,y)==0) ? Color.blue : Color.green );<br />
g.fillRect(x*2,y*2,2,2);<br />
}<br />
}<br />
<br />
public void setCell(int x, int y, int c) {<br />
map[x+size*y]=c;<br />
}<br />
<br />
public int getCell(int x, int y) {<br />
return map[x+size*y];<br />
}<br />
<br />
// this routine builds the landscape....<br />
// step = detail square width<br />
public void makeFractal(int step) {<br />
for (int y=0; y<size; y+=step) {<br />
for (int x=0; x<size; x+=step) {<br />
// The inner loop calculates (cx,cy)<br />
// this is the point from which to copy map colour<br />
<br />
// add random offsets<br />
int cx=x+ ((Math.random()<0.5) ? 0 : step);<br />
int cy=y+ ((Math.random()<0.5) ? 0 : step);<br />
<br />
// truncate to nearest multiple of step*2<br />
// since step*2 is the previous detail level calculated<br />
cx=(cx/(step*2))*step*2;<br />
cy=(cy/(step*2))*step*2;<br />
<br />
// wrap around to reference world as torus<br />
// also guarantees getCell() and setCell() are within bounds<br />
cx=cx%size;<br />
cy=cy%size;<br />
<br />
// copy from (cx,cy) to (x,y)<br />
setCell(x,y,getCell(cx,cy));<br />
}<br />
}<br />
<br />
// recursively calculate finer detail levels<br />
if (step>1) makeFractal(step/2);<br />
}<br />
<br />
// applet initialisation<br />
public void init() {<br />
super.init();<br />
<br />
// repaint on mouse clicks<br />
addMouseListener(new MouseAdapter()<br />
public void mouseClicked( MouseEvent e ) {<br />
repaint();<br />
}<br />
});<br />
}<br />
<br />
// main function allows applet to run as an application<br />
public static void main(String[] args) {<br />
<br />
// create a frame<br />
Frame f = new Frame("Fractal Coastlines");<br />
f.addWindowListener(new WindowAdapter() {<br />
public void windowClosing(WindowEvent e) {<br />
System.exit(0);<br />
}<br />
});<br />
<br />
// set up frame and add applet<br />
f.setSize(300,300);<br />
f.setLayout(new BorderLayout());<br />
CoastApp q=new CoastApp();<br />
q.init();<br />
f.add(q);<br />
<br />
// go live....<br />
f.show();<br />
}<br />
}<br />
<br />
<br />
<br />
Conclusion<br />
==========<br />
<br />
Well, I hope I've given you a quick way to get some good-looking<br />
fractal landscapes. It is easy to extend this by adding different land <br />
types (forests, deserts etc). You could also enhance the method to <br />
include a height map by taking averages of adjacent points and adding <br />
random offsets.<br />
<br />
In fact, I've implemented a fractal algorithm to generate the World<br />
Maps for Tyrant, my very own roguelike. You can see it in action at:<br />
<br />
http://www.mikera.net/tyrant/<br />
<br />
This uses essentially the same method as the one described above,<br />
except that it uses a little bit of coding magic to make the landscapes <br />
look more realistic and textured. While it's still far from perfect, it<br />
does at least show there's scope for a lot of imaginative use of this <br />
technique.<br />
<br />
Happy Coding.<br />
<br />
Mike.<br />
<br />
<br />
Any questions or comments:<br />
mike@mikera.net<br />
<br />
= Terrain Generator - Mixi Lauronen [mplauron@paju.oulu.fi].txt =<br />
<br />
I have experimented with the following algorithm:<br />
<br />
1) Decide the range of land height values (I think 0-255 is conveninent)<br />
<br />
2) Initialize the land area with a value of 0. (Arbitrarily, you can<br />
initialize it with the average of the height minimum and maximum)<br />
<br />
3) Randomly set a rectangle of random size with a random value of (0-255)<br />
on the map, adding the value to every coordinate inside the rectangle's<br />
area. Arbitrarily the value can be anything between (-x to x). If the<br />
result is less than the minimum height or more than maximum height,<br />
readjust the value.<br />
<br />
4) Repeat as many times as needed.<br />
<br />
5) Apply a smoothing routine to every coordinate, thus simulating the<br />
effect of erosion. I use a simple method of setting the value of a land<br />
block to the average of (block+southern block+northern block+eastern<br />
block+western block).<br />
<br />
6) Set the water level. Anything under that will be water.<br />
<br />
Haven't implemented a river algorithm yet. Otherwise it seems to work<br />
fine, although it is a little bit slow (especially the smoothing routine).<br />
Of course the building blocks could be circles, ovals or single pixels,<br />
too.<br />
<br />
= Metaballs Dungeon.txt =<br />
<br />
The Metaballs Dungeon<br />
----------------------<br />
The idea of the metaballs dungeon is to generate two dimensional<br />
meatballs to construct a cave-like dungeon that looks natural and rough<br />
but still constructed by... goblin hands!<br />
If anyone here has ever worked with a 3d raytracer you may know what i<br />
am talking about. Basically the idea is that in many 3-D raytracing<br />
applications you can place these metaballs in your scene. Each meta<br />
ball has x,y,z coordinate variables and a t--threshhold. If you have<br />
one metaball then the edge of the ball is mearly a distance away from<br />
the center equal to the threshhold. In case you havent already guessed<br />
this, we are thinking about doing this in 2d (x,y,t). So lets look at<br />
how that would look.<br />
<br />
####<br />
#....#<br />
#......#<br />
#......#<br />
#......#<br />
#....#<br />
####<br />
(a better looking circle then above)<br />
<br />
Now this is because we only have one ball. If we place another right<br />
next too the first, then in our 2-D scenerio we will say that for every<br />
square we look to see if there is a ball or are balls nearby. Nearby is<br />
defigned like this<br />
<br />
If the square in question's distance to a ball's center is less then<br />
the ball's threshhold then that ball is "nearby".<br />
<br />
Now if we have a vector of balls (x,y,t) that have contructed (I will<br />
explain later) then we want to find out what our betaballs dungeon<br />
looks like. We would do the following.<br />
<br />
(slow version, could be optimized!! a lot!)<br />
For every square on our grid, we compile a list of the "nearby" balls.<br />
We then add the threshhold of every nearby ball to a temporary integer<br />
and then subtract the distance to every ball from this integer. If this<br />
number is positive then we have a floor tile. if not we have a wall<br />
tile. Its that simple. This algorthim could be optimized and the math<br />
is probably a little off. There are algorithms you can find through a<br />
google search that will probably be better/faster and offer you much<br />
more control. My simple example does work and has been tested on<br />
QBasic. I will probably implement this for some levels in my upcomming<br />
game CHAZM!<br />
<br />
A sample might look like this. A nice smooth melted merge between<br />
balls. You could also experiment with using ellipes and rounded<br />
rectangles. There are algorithms for those out their too.<br />
################<br />
#########....###<br />
##....##......##<br />
#.............##<br />
#.............##<br />
#......##.....##<br />
##....####...###<br />
################<br />
(This was handdrawn as a representation only...)<br />
If you cant visualize what this would look like with many rooms/balls<br />
then take a look here:<br />
<br />
http://foresightsagas.com/software/chazm/metaballs_cave_example.htm<br />
<br />
Laying out the Rooms<br />
---------------------<br />
You could lay out the rooms in any way you want but personally i would<br />
advocate for a recursive flow.<br />
<br />
call branch 2-4 times on randome angles at the center...<br />
<br />
void branch(x,y,a){<br />
do{<br />
a += randombetweenr(-.2 radians, +.2radiant);<br />
step x and y forward 8-12 squares forward in the direction of angle<br />
a<br />
then add room at location<br />
if (randombetween(0,6) == 2) branch(x,y,a);<br />
if (randombetween(0,6) == 3) return;<br />
}<br />
}<br />
<br />
thus you get a branching and twisting maze of caverns that go out quite<br />
far. You could also add other end conditions like hitting the edge of<br />
the screen or getting a cirtain distance from the original center....<br />
If you have any questions you can ask me about this recursion.<br />
<br />
I think this would work out great as a caves level. Any thoughts or<br />
questions: email me at comments (AT) foresightsagas .com<br />
<br />
Thanks. And have fun making your RL.<br />
<br />
By Thomas Gilray<br />
foresightsagas.com</div>Stuhttp://roguebasin.com/index.php?title=User:Duerig/Archive9&diff=12845User:Duerig/Archive92008-05-02T13:19:50Z<p>Stu: make readable</p>
<hr />
<div>= Random Dungeon Algo in QBasic - Andrew Collins [andrewcollins@hotmail.com].txt =<br />
<br />
<pre><br />
DEFINT A-Z' speeds things up<br />
DECLARE SUB initdungeon () 'blanks out dungeon array<br />
DECLARE SUB displaydungeon () 'draws dungeon to the screen<br />
DECLARE SUB generate (recurdepth) 'main generation function<br />
<br />
'checks bounds for halls and rooms<br />
DECLARE FUNCTION CheckBounds (x1, x2, y1, y2, direction)<br />
DECLARE FUNCTION CheckBoundsHall (x1, x2, y1, y2, direction)<br />
<br />
'makes the halls and rooms<br />
DECLARE SUB makehall (x1, x2, y1, y2, direction)<br />
DECLARE SUB makeroom (x1, x2, y1, y2, direction, recurdepth)<br />
<br />
'random number between lowest and highest<br />
DECLARE FUNCTION Rand (Lowest, Highest)<br />
<br />
<br />
<br />
'map array<br />
DIM SHARED DungeonLayer(150, 150) AS INTEGER<br />
<br />
'what this does is makes a list of rooms that were created.<br />
'then if the generator hits a dead end it goes back to a random room<br />
'in the list and takes up generation from there.<br />
DIM SHARED RoomHolder(200, 4) AS INTEGER<br />
<br />
'max numbers of maps<br />
DIM SHARED maxx 'MaxX coord of Dungeon<br />
DIM SHARED maxy 'MaxY of Dungeon<br />
DIM recurdepth AS INTEGER<br />
<br />
'map and engine constants<br />
DIM SHARED wall AS INTEGER<br />
DIM SHARED floor AS INTEGER<br />
DIM SHARED door AS INTEGER<br />
DIM SHARED true AS INTEGER<br />
DIM SHARED false AS INTEGER<br />
DIM SHARED Permwall AS INTEGER<br />
DIM SHARED numofrooms AS INTEGER<br />
DIM SHARED maxnumofrooms AS INTEGER<br />
<br />
'these are the ascii numbers (like angband for the door and walls)<br />
door = 43<br />
Permwall = 178<br />
wall = 176<br />
floor = 46<br />
<br />
true = 1<br />
false = -1<br />
<br />
recurdepth = 0<br />
numofrooms = 0<br />
<br />
DIM x1 AS INTEGER' top right coordinates<br />
DIM y1 AS INTEGER' top left coordinates<br />
DIM x2 AS INTEGER' bottom right coordinates<br />
DIM y2 AS INTEGER' bottom left coordinates<br />
DIM direction AS INTEGER<br />
<br />
<br />
<br />
<br />
<br />
<br />
'these tie into the DungeonLayer array so the size will have to be<br />
'increased there to increase these numbers<br />
maxx = 150<br />
maxy = 150<br />
<br />
' maxnumofrooms is tied into RoomHolder<br />
' at 200 it bogs down and fails a lot try setting to 200 you'll see<br />
<br />
maxnumofrooms = 150<br />
<br />
RANDOMIZE TIMER<br />
<br />
DO<br />
'this times the generation<br />
T! = TIMER<br />
initdungeon<br />
generate (recurdepth)<br />
T2! = TIMER<br />
T3! = T2! - T!<br />
<br />
displaydungeon' I'm not adding this into the timer<br />
'seeing as it only displays the dungeon<br />
LOCATE 1, 21: COLOR 4: PRINT "Door color"<br />
LOCATE 2, 21: COLOR 8: PRINT "Wall color "<br />
LOCATE 3, 21: COLOR 15: PRINT "PermaWall color"<br />
LOCATE 6, 21: COLOR 15: PRINT "# of Rooms"; numofrooms<br />
LOCATE 9, 21: PRINT "One pixel ="<br />
LOCATE 10, 23: PRINT "one ascii tile"<br />
LOCATE 21, 1: PRINT "Time to make "; T3!; " Seconds."<br />
LOCATE 22, 1: PRINT "Press esc to quit"<br />
LOCATE 23, 1: PRINT "Any other key to generate again"<br />
SLEEP<br />
LOOP UNTIL INKEY$ = CHR$(27)<br />
END<br />
<br />
<br />
FUNCTION CheckBounds (x1, x2, y1, y2, direction)<br />
CheckBounds = 0<br />
'Makes sure room isn't out of bounds of Dungeon<br />
'Our dungeon is 1 to MaxX and 1 to MaxY<br />
<br />
IF (x1 - 1) < 1 THEN CheckBounds = false: EXIT FUNCTION<br />
IF (y1 - 1) < 1 THEN CheckBounds = false: EXIT FUNCTION<br />
IF (x2 + 1) > maxx THEN CheckBounds = false: EXIT FUNCTION<br />
IF (y2 + 1) > maxy THEN CheckBounds = false: EXIT FUNCTION<br />
<br />
FOR x = (x1 - 1) TO (x2 + 1)<br />
FOR y = (y1 - 1) TO (y2 + 1)<br />
IF DungeonLayer(x, y) = floor THEN CheckBounds = false: EXIT FUNCTION<br />
NEXT y<br />
NEXT x<br />
CheckBounds = true<br />
END FUNCTION<br />
<br />
FUNCTION CheckBoundsHall (x1, x2, y1, y2, direction)<br />
CheckBoundsHall = 0<br />
'Makes sure hall isn't out of bounds of Dungeon<br />
'Our dungeon is 1 to MaxX and 1 to MaxY<br />
<br />
IF (x1 - 1) < 1 THEN CheckBoundsHall = false: EXIT FUNCTION<br />
IF (y1 - 1) < 1 THEN CheckBoundsHall = false: EXIT FUNCTION<br />
IF (x2 + 1) > maxx THEN CheckBoundsHall = false: EXIT FUNCTION<br />
IF (y2 + 1) > maxy THEN CheckBoundsHall = false: EXIT FUNCTION<br />
<br />
IF direction = 0 OR direction = 2 THEN<br />
FOR x = x1 TO x2<br />
FOR y = (y1 - 1) TO (y2 + 1)<br />
IF DungeonLayer(x, y) = floor THEN CheckBoundsHall = false: EXIT FUNCTION<br />
NEXT y<br />
NEXT x<br />
END IF<br />
<br />
<br />
IF direction = 1 OR direction = 3 THEN<br />
FOR x = (x1 - 1) TO (x2 + 1)<br />
FOR y = y1 TO y2<br />
IF DungeonLayer(x, y) = floor THEN CheckBoundsHall = false: EXIT FUNCTION<br />
NEXT y<br />
NEXT x<br />
END IF<br />
<br />
CheckBoundsHall = true<br />
END FUNCTION<br />
<br />
SUB displaydungeon<br />
'this just draws the dungeon <br />
CLS<br />
SCREEN 13<br />
FOR x = 1 TO maxx<br />
FOR y = 1 TO maxy<br />
IF DungeonLayer(x, y) = wall THEN PSET (x, y), 8<br />
IF DungeonLayer(x, y) = Permwall THEN PSET (x, y), 15<br />
IF DungeonLayer(x, y) = door THEN PSET (x, y), 4<br />
IF DungeonLayer(x, y) = floor THEN PSET (x, y), 0<br />
NEXT y<br />
NEXT x<br />
END SUB<br />
<br />
SUB generate (recurdepth)<br />
<br />
'start with a random room<br />
x1 = Rand(2, (maxx - 1))<br />
y1 = Rand(2, (maxy - 1))<br />
x2 = x1 + Rand(2, 4)<br />
y2 = y1 + Rand(3, 7)<br />
<br />
<br />
<br />
direction = Rand(0, 3)<br />
IF CheckBounds(x1, x2, y1, y2, direction) = true THEN<br />
CALL makeroom(x1, x2, y1, y2, direction, recurdepth)<br />
END IF<br />
<br />
<br />
room = true<br />
<br />
DO<br />
'these are all to make sure we dont get into an infinite loop<br />
hallcount = 0<br />
hallcountmultp = 0<br />
roomcount = 0<br />
roomcountmultp = 0<br />
'ite mean iterations<br />
<br />
<br />
DO<br />
ite = ite + 1<br />
direction = Rand(0, 3)'the direction we want to draw towards<br />
'0 north(up) : 1 east(right) : 2 south(down) : 3 west(left)<br />
<br />
hall = false<br />
hallcount = hallcount + 1<br />
<br />
halllength = Rand(2, 7)'min and max length of halls<br />
<br />
'for all hall generation they are basically the same<br />
IF direction = 0 THEN<br />
'halls are only 1 square wide <br />
dy1 = Rand(y1, y2)<br />
dy2 = dy1<br />
'and as long as our halllength variable <br />
dx2 = x1 - 2<br />
dx1 = dx2 - halllength<br />
' we check to see if it's in bounds <br />
IF CheckBoundsHall(dx1, dx2, dy1, dy2, direction) = true THEN<br />
' if it is we actually put it there <br />
CALL makehall(dx1, dx2, dy1, dy2, direction)<br />
' draw a door if it hits a room (this can be change to randomly place any type <br />
' of feature)<br />
IF room = true THEN<br />
DungeonLayer(dx2 + 1, dy1) = door<br />
ELSE<br />
'make it a floor tile if it doesn't hit a room <br />
DungeonLayer(dx2 + 1, dy1) = floor<br />
END IF<br />
'these are saved to pass to the room creation section below <br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
'sets hall to true so we can move on <br />
hall = true<br />
END IF<br />
<br />
END IF<br />
IF direction = 1 THEN<br />
dy1 = y2 + 2<br />
dy2 = dy1 + halllength<br />
dx1 = Rand(x1, x2)<br />
dx2 = dx1<br />
IF CheckBoundsHall(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makehall(dx1, dx2, dy1, dy2, direction)<br />
IF room = true THEN<br />
DungeonLayer(dx1, dy1 - 1) = door<br />
ELSE<br />
DungeonLayer(dx1, dy1 - 1) = floor<br />
END IF<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
hall = true<br />
END IF<br />
<br />
END IF<br />
<br />
IF direction = 2 THEN<br />
dy1 = Rand(y1, y2)<br />
dy2 = dy1<br />
dx1 = x2 + 2<br />
dx2 = dx1 + halllength<br />
IF CheckBoundsHall(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makehall(dx1, dx2, dy1, dy2, direction)<br />
IF room = true THEN<br />
DungeonLayer(dx1 - 1, dy1) = door<br />
ELSE<br />
DungeonLayer(dx1 - 1, dy1) = floor<br />
END IF<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
hall = true<br />
END IF<br />
END IF<br />
<br />
IF direction = 3 THEN<br />
dy1 = (y1 - halllength) - 2<br />
dy2 = dy1 + halllength<br />
dx1 = Rand(x1, x2)<br />
dx2 = dx1<br />
IF CheckBoundsHall(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makehall(dx1, dx2, dy1, dy2, direction)<br />
IF room = true THEN<br />
DungeonLayer(dx2, dy2 + 1) = door<br />
ELSE<br />
DungeonLayer(dx2, dy2 + 1) = floor<br />
END IF<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
hall = true<br />
END IF<br />
END IF<br />
<br />
<br />
'if we cant make a hall after 10 tries then we....<br />
IF hallcount > 10 AND hall = false THEN<br />
'pick a random room from our list<br />
RDepth = Rand(1, recurdepth)<br />
'make old room the dimensions of our current room<br />
x1 = RoomHolder(RDepth, 0)<br />
x2 = RoomHolder(RDepth, 1)<br />
y1 = RoomHolder(RDepth, 2)<br />
y2 = RoomHolder(RDepth, 3)<br />
'reset hall count<br />
hallcount = 0<br />
'increment our hallmult counter and go again<br />
hallcountmultp = hallcountmultp + 1<br />
END IF<br />
<br />
'if we tried to make a hall more than 1000 times (hallcount * hallcountmultp)<br />
'and no hall was made then we failed<br />
IF hallcountmultp > 100 THEN<br />
PRINT "FAILED at "; recurdepth; " Rooms": SLEEP<br />
numofrooms = recurdepth: EXIT SUB<br />
END IF<br />
<br />
LOOP UNTIL hall = true<br />
<br />
<br />
<br />
'************ room creation below<br />
<br />
<br />
room = false<br />
<br />
<br />
IF direction = 0 THEN<br />
'holder is a dummy variable <br />
holder = Rand(3, 7)<br />
dx2 = x1 - 2<br />
dx1 = dx2 - Rand(2, 4)<br />
dy1 = Rand((y1 - holder), y2)<br />
dy2 = dy1 + holder<br />
'check to see if our room is in bounds <br />
IF CheckBounds(dx1, dx2, dy1, dy2, direction) = true THEN<br />
'if it is, set it in stone(so to speak) <br />
CALL makeroom(dx1, dx2, dy1, dy2, direction, recurdepth)<br />
'put a door here cause this is where our hall will begin<br />
DungeonLayer(x1 - 1, y1) = door<br />
'put our end room coordiantes into these variables so we can send them<br />
'to our hall creation section above<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
'set to true so we can end <br />
room = true<br />
END IF<br />
<br />
END IF<br />
<br />
IF direction = 1 THEN<br />
holder = Rand(2, 4)<br />
dx1 = Rand((x1 - holder), x2)<br />
dx2 = dx1 + holder<br />
dy1 = y2 + 2<br />
dy2 = dy1 + Rand(3, 7)<br />
IF CheckBounds(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makeroom(dx1, dx2, dy1, dy2, direction, recurdepth)<br />
DungeonLayer(x2, y2 + 1) = door<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
room = true<br />
END IF<br />
END IF<br />
<br />
IF direction = 2 THEN<br />
holder = Rand(3, 7)<br />
dx1 = x2 + 2<br />
dx2 = dx1 + Rand(2, 4)<br />
dy1 = Rand(y1 - holder, y2)<br />
dy2 = dy1 + holder<br />
IF CheckBounds(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makeroom(dx1, dx2, dy1, dy2, direction, recurdepth)<br />
DungeonLayer(x2 + 1, y2) = door<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
room = true<br />
END IF<br />
END IF<br />
<br />
IF direction = 3 THEN<br />
holder = Rand(2, 4)<br />
dx1 = Rand((x1 - holder), x2)<br />
dx2 = dx1 + holder<br />
dy2 = y1 - 2<br />
dy1 = dy2 - Rand(3, 7)<br />
IF CheckBounds(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makeroom(dx1, dx2, dy1, dy2, direction, recurdepth)<br />
DungeonLayer(x2, y1 - 1) = door<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
room = true<br />
END IF<br />
END IF<br />
<br />
'do 4000 total loops,if it is more than 4000 then fail<br />
IF ite > 4000 THEN<br />
PRINT "FAILED at"; recurdepth; "Rooms": SLEEP<br />
numofrooms = recurdepth: EXIT SUB<br />
END IF<br />
LOOP UNTIL recurdepth = maxnumofrooms<br />
numofrooms = recurdepth<br />
END SUB<br />
<br />
SUB initdungeon<br />
'fill our dungeon with rock<br />
FOR x = 1 TO maxx<br />
FOR y = 1 TO maxy<br />
DungeonLayer(x, y) = wall<br />
NEXT y<br />
NEXT x<br />
' make the edges permawall <br />
FOR y = 1 TO maxy<br />
DungeonLayer(maxx, y) = Permwall<br />
DungeonLayer(1, y) = Permwall<br />
NEXT y<br />
FOR x = 1 TO maxx<br />
DungeonLayer(x, maxy) = Permwall<br />
DungeonLayer(x, 1) = Permwall<br />
NEXT x<br />
END SUB<br />
<br />
SUB makehall (x1, x2, y1, y2, direction)<br />
'draw our dungeon always from upper left to lower right <br />
FOR x = x1 TO x2<br />
FOR y = y1 TO y2<br />
DungeonLayer(x, y) = floor<br />
NEXT y<br />
NEXT x<br />
END SUB<br />
<br />
SUB makeroom (x1, x2, y1, y2, direction, recurdepth)<br />
'draw our dungeon always from upper left to lower right <br />
FOR x = x1 TO x2<br />
FOR y = y1 TO y2<br />
DungeonLayer(x, y) = floor<br />
NEXT y<br />
NEXT x<br />
recurdepth = recurdepth + 1<br />
' this holds our rooms so we can choose one at random if we get stuck<br />
' we never save halls or it would be a horrendous mess<br />
RoomHolder(recurdepth, 0) = x1<br />
RoomHolder(recurdepth, 1) = x2<br />
RoomHolder(recurdepth, 2) = y1<br />
RoomHolder(recurdepth, 3) = y2<br />
END SUB<br />
<br />
FUNCTION Rand (Lowest, Highest)<br />
DIM a AS INTEGER<br />
DIM b AS INTEGER<br />
DIM c AS INTEGER<br />
<br />
a = Lowest<br />
b = Highest<br />
IF a > b THEN<br />
c = a - b<br />
ELSEIF b > a THEN<br />
c = b - a<br />
ELSE<br />
Rand = a: EXIT FUNCTION<br />
END IF<br />
Rand = INT(RND(1) * (c + 1)) + a<br />
<br />
END FUNCTION<br />
<br />
</pre><br />
<br />
= Nest of Ants - Jakub Debski [jakub@mks.com.pl].txt =<br />
<br />
I was wondering how to create a nice looking nest for the ants, and here is my idea:<br />
<br />
Let's say, that we have some sticky dust. It goes through air and catch all the static objects. So, let's see, if we have one static object at the beginning, and a lot of randomly moving objects of the same type:<br />
<br />
dust: *<br />
move vector: -<br />
<br />
*- <br />
/ * -*<br />
*<br />
|<br />
*<br />
<br />
then these objects will catch the first one and group into larger<br />
one:<br />
<br />
**<br />
*<br />
*****<br />
* *<br />
* **<br />
*<br />
<br />
That's all. We have nice looking corridors with all the places<br />
reachabale. Algorithm is very simple and gives nice results:<br />
<br />
# Allocate 2 dimensional array for 0,1 values of the nest size.<br />
# In the centre add single object<br />
# Create new sticky object on the ellipse which is around the nest, having centre in the centre of the nest<br />
# Add random move vector to the object<br />
# Move object a bit. If it crosses the border of our territory, then appears on the other side.<br />
# Look around the object and if there is something to catch then stop. If size of the nest is enough, then stop, else go to 3.<br />
# Goto 5<br />
<br />
My two advices are to add guard for moving object, f.e. for 1000 steps,<br />
because depending on vector it's possible, that object won't catch any<br />
other. The second advice it to add some "rooms" at the end of corridors (on<br />
cell, which has only one neighbour:<br />
<br />
piece of nest:<br />
<br />
* <br />
*****<br />
**<br />
<br />
+ - the cell with one neighbour, means end of corridor<br />
<br />
*<br />
****+<br />
**<br />
<br />
add there 3x3 room<br />
<br />
* +++<br />
***+++<br />
** +++<br />
<br />
source code:<br />
<br />
<pre><br />
#define NEST_SIZE_X 80<br />
#define NEST_SIZE_Y 50<br />
<br />
int main(void)<br />
{<br />
init_graph(); // not neccecary, for draw_char(x,y,char)<br />
srand(get_ticks_count()); // for (rand())<br />
<br />
bool c[NEST_SIZE_X][NEST_SIZE_Y];<br />
int x,y;<br />
for (x=0;x<NEST_SIZE_X;x++)<br />
for (y=0;y<NEST_SIZE_Y;y++)<br />
{<br />
c[x][y]=0;<br />
draw_char(x,y,'#');<br />
}<br />
<br />
// in the centre we put one object<br />
c[NEST_SIZE_X/2][NEST_SIZE_Y/2]=1; // in the array<br />
draw_char(NEST_SIZE_X/2,NEST_SIZE_Y/2,'.'); // and on the screen for test<br />
myrefresh();<br />
<br />
float x1,y1; // position of object<br />
float k; // angle<br />
float dx, dy; // move vector<br />
int px, py;<br />
<br />
for (int object=0;object<NEST_SIZE_X*NEST_SIZE_Y/3;object++)<br />
{<br />
// degree<br />
k = (rand()%360)*3.1419532/180;<br />
// position on ellipse by degree<br />
x1 = NEST_SIZE_X/2+(NEST_SIZE_X/2)*sin(k);<br />
y1 = NEST_SIZE_Y/2+(NEST_SIZE_Y/2)*cos(k);<br />
// draw_char(x1,y1,'*');<br />
<br />
// object will move not too horizontal and not too vertival<br />
do {<br />
dx=rand()%100;<br />
dy=rand()%100;<br />
} while ((abs(dx)<10 && abs(dy)<10));<br />
dx-=50;<br />
dy-=50;<br />
dx/=100; // by little steps<br />
dy/=100; // by little steps<br />
<br />
int counter=0;<br />
while (1)<br />
{<br />
// didn't catch anything after 1000 steps (just to avoid infinite loops)<br />
if (counter++>1000)<br />
{<br />
object--;<br />
break;<br />
}<br />
// move object by small step<br />
x1+=dx;<br />
y1+=dy;<br />
<br />
// change float to int<br />
<br />
px=x1;<br />
py=y1;<br />
<br />
// go through the border to the other side<br />
<br />
if (px<0)<br />
{<br />
px=NEST_SIZE_X-1;<br />
x1=px;<br />
}<br />
if (px>NEST_SIZE_X-1)<br />
{<br />
px=0;<br />
x1=px;<br />
}<br />
if (py<0)<br />
{<br />
py=NEST_SIZE_Y-1;<br />
y1=py;<br />
}<br />
if (py>NEST_SIZE_Y-1)<br />
{<br />
py=0;<br />
y1=py;<br />
}<br />
<br />
// if object has something to catch, then catch it<br />
<br />
if ((px>0 && c[px-1][py]==1) ||<br />
(py>0 && c[px][py-1]==1) ||<br />
(px<NEST_SIZE_X-1 && c[px+1][py]==1) ||<br />
(py<NEST_SIZE_Y-1 && c[px][py+1]==1))<br />
{<br />
c[px][py]=1;<br />
draw_char(px,py,'.');<br />
myrefresh();<br />
break; // go to creation of new object<br />
}<br />
} // end of while(1)<br />
} // end of for<br />
<br />
// add halls at the end of corridors<br />
int neighbours;<br />
for (x=1;x<NEST_SIZE_X-1;x++)<br />
for (y=1;y<NEST_SIZE_Y-1;y++)<br />
{<br />
if ((x>NEST_SIZE_X/2-10 && x<NEST_SIZE_X/2+10 && y>NEST_SIZE_Y/2-5 && y<NEST_SIZE_Y/2+5) || c[x][y]==0)<br />
continue;<br />
<br />
neighbours=0;<br />
if (c[x-1][y-1]!=0)<br />
neighbours++;<br />
if (c[x][y-1]!=0)<br />
neighbours++;<br />
if (c[x+1][y-1]!=0)<br />
neighbours++;<br />
if (c[x-1][y]!=0)<br />
neighbours++;<br />
if (c[x+1][y]!=0)<br />
neighbours++;<br />
if (c[x-1][y+1]!=0)<br />
neighbours++;<br />
if (c[x][y+1]!=0)<br />
neighbours++;<br />
if (c[x-1][y+1]!=0)<br />
neighbours++;<br />
<br />
if (neighbours==1)<br />
{<br />
for (px=-1;px<=1;px++)<br />
for (py=-1;py<=1;py++)<br />
{<br />
c[x+px][y+py]=1;<br />
draw_char(x+px,y+py,',');<br />
myrefresh();<br />
}<br />
}<br />
}<br />
<br />
return 0;<br />
<br />
}<br />
</pre><br />
<br />
some samples<br />
<br />
<pre><br />
80x25<br />
#####################............................###############.###..##########<br />
###############,,,###.#########.#.######.##..###################.###.###########<br />
###############,,,......#######...######.....########.#####...#......##.########<br />
###############,,,###.#..#.##.##..##,,,#..#.######,,,.#####.#...###.....########<br />
################..###......#...##..#,,,#....######,,,.#####.##.##......#########<br />
#####################.###......###.#,,,..##,,,.###,,,##.###.......###.....######<br />
########################..#,,,.........#.#.,,,..####.....##.####.#.######.######<br />
#########################.#,,,########.....,,,..####..####.....#...#############<br />
#####################,,,###,,,...#######.####.#.#.##.#####.###.###..############<br />
#####################,,,########.#######.####...#.#....###.####,,,##############<br />
#################,,,.,,,#.#.#.##..####.......................##,,,##############<br />
#################,,,...........#.....###.##.##.#.#####..##..###,,,#####.########<br />
#################,,,##.#,,,###...##...........##....#########..#..#.....########<br />
##############,,,#######,,,######.#..###.###.#####...###.#.##.##....#.#..#######<br />
##############,,,,,,####,,,###.......##...##.####...........#....#.#############<br />
##############,,,,,,#######...#####.####..######...#.###.##......####....#######<br />
############..#.#,,,#######............##...#####.##...#..#..##...###.#.########<br />
###########.#...##.###....##...##...##,,,.#..########.###..####..........#######<br />
#####,,,.##...#...............#.......,,,.##.########...##..####.##....#########<br />
#####,,,....#...###.#..#.#..#.#,,,.#.#,,,############..###.....#.##.,,,#########<br />
#####,,,#,,,..###...####.######,,,##.###############..####.#....####,,,#########<br />
#########,,,.####...####..#####,,,##.###############..#######...####,,,#########<br />
#########,,,..##...#.....#######,,,#.##############...########..################<br />
##########..#.##.#..####..######,,,....############...########.#################<br />
##########.#######.#############,,,..#.#######################.#################<br />
<br />
80x40<br />
<br />
##########################.......................#....##......##################<br />
##############,,,#####,,,#....,,,.###...####.######...###.##..##################<br />
##############,,,.....,,,###.#,,,.###..#####.#..###.#####.######################<br />
##############,,,....#,,,#####,,,.####..####.....##..####.####.#################<br />
#################,,,.####,,,.####.##...#####.#.####.##.##.##...#################<br />
#################,,,.####,,,.#.##.#.##.###...#.###..#..##....##.....############<br />
#################,,,.####,,,......#..#..##..#..###.#..###.#####.,,,#############<br />
################.......#########.....#..##..#..##..#..###.#.....,,,#############<br />
################.###.#.########...##.#.###.##.##..........#....#,,,#############<br />
################.##....##,,,##,,,###.#.###....##..##........####..##############<br />
###############..####..##,,,##,,,##.....##.###.....##.##.#.###.#.....###########<br />
##############....####.##,,,.#,,,##...#.##.##..##,,,#..#.........#...###########<br />
##############.......#.###...##..###.##....##...#,,,#.###.#.#.#####..###########<br />
#################......####.####.####,,,.#.#..#.#,,,#####.....#,,,##.###########<br />
##################.###.#.##.####.###.,,,.#....#.......###.,,,..,,,##############<br />
###################......##.#.##..#..,,,..##.#####..#.###.,,,##,,,##############<br />
############........####................#.########.##..###,,,###################<br />
##########.#.#####.####....##.#.##.##.#...########..###,,,######################<br />
####,,,............##,,,..##########.##..##.##########.,,,######################<br />
####,,,...#####...###,,,.#####.#####....#.......#####..,,,######################<br />
####,,,.#.###...#####,,,.####...#####.#...##.##.....#.,,,#######################<br />
######.######..########.######...######....########...,,,#..####################<br />
############..#########.######.#..####...#.####.#####.,,,#..####################<br />
#######################..###,,,#....#...####.##.#######.##.,,,##################<br />
########################.###,,,.##..............#.#####.#..,,,#..###############<br />
##################.......###,,,....#.#..####.##...#.......#,,,...###############<br />
##################.,,,....##.####.##....###...##......##..#.#.....###.,,,#######<br />
##############,,,##,,,.#..........#...#.###.#.##.####..##.....,,,.....,,,#######<br />
##############,,,..,,,#..#.#.####.#.#.#.###.#..#...##..##.#.#.,,,.#...,,,#######<br />
#############.,,,#.####.####.##...#####..##..#.##....###,,,.#.,,,###############<br />
############.............#...##....##....###..####.#.###,,,.#....###############<br />
####,,,.#.######.#########..#####.###.##..##...###..####,,,..###################<br />
####,,,...#...######.#.....#####..###.#...##.#####....##########################<br />
,,,.,,,#....#.####.....##...###...##...##.##...###.##..#########################<br />
,,,.#...............##.###..###.,,,#.####.##....##...#..########################<br />
,,,....##.##..#.#.#....##..###..,,,######.##.##.####..##########################<br />
#########.#,,,..#....#.#...###.#,,,####...##..#####,,,##########################<br />
#########.#,,,##......##..####..#######..###.#####.,,,##########################<br />
#########.#,,,#..#.##......#############.###.####..,,,##########################<br />
########..#####..#.#####..##############.###........############################<br />
<br />
80x50<br />
<br />
######################.##..#.....#........######################################<br />
#####################.......#.,,,##.#.##########################################<br />
########################..#.#.,,,##...##########################################<br />
###########################...,,,....######################,,,##################<br />
##########################..#.#####...#####################,,,.#################<br />
############################....##.....#######.############,,,##...#############<br />
#####################,,,####.#...#...######,,,.#############...#..##############<br />
#####################,,,######......#,,,###,,,.############..#.#.##..###########<br />
#####################,,,###,,,.#.....,,,###,,,..###########..#.#......##########<br />
################,,,####...#,,,###...#,,,...###.########,,,..##....##############<br />
################,,,######..,,,#####.###...####..#######,,,.......#.#############<br />
################,,,#.,,,#..##.......##..###.##.########,,,#.######.,,,#####.####<br />
##################...,,,..#####,,,..##.##....#..###,,,#####........,,,####..####<br />
###################..,,,..#####,,,........###...###,,,######.,,,##.,,,#####.####<br />
###################.......#####,,,...#.#,,,##.#,,,#,,,######.,,,###########...##<br />
####################.####.....##.###.#..,,,##..,,,...######..,,,.##.#######..###<br />
###########,,,#####,,,,,,,,,#.##........,,,#..#,,,#..##...##..##....######..####<br />
#########..,,,##.##,,,,,,,,,#...######.,,,###.,,,###.#.##.##.###.##,,,####.##...<br />
#########..,,,.....,,,,,,,,,....#####..,,,##..,,,.##...##..#.#.....,,,####.....#<br />
########.#....#.#.....#.####,,,.#####..,,,###.,,,.#...####.#......#,,,#.....#.##<br />
######......#.....###.#.###.,,,...###..#...##..##..#.#.,,,...##.#.......#.###..#<br />
######..#########.##..#..#..,,,#..##......###..##.##.#.,,,..###...#######..#####<br />
#######.###..####........##.###..####.#.#..##..##.##.#.,,,.##.###..........##,,,<br />
######,,,#........##..#...#.###...#.#####.###.....#..#.##.......#####,,,.#...,,,<br />
######,,,####...#.###..#..#...........#...#....##.##...#..#.##.######,,,.####,,,<br />
######,,,..#..#######.###.....#####..................#...############,,,#,,,###.<br />
##########...##############.#####.#.###.#.....##..##..#..#####.#....#####,,,.##.<br />
###########.########..#.....#####.#..##.#.##.####...#.####.........######,,,....<br />
##########..######......####.........##.####....###.#.......#...##.###.#...##.#.<br />
###########.######.##..#####...#,,,.#...####.##....##.##.##...#..#.......#.##...<br />
##########..#####,,,...####...##,,,.##..###..###.#.#####.###....####.#.######..#<br />
##########.######,,,#..#####..##,,,###...##.###.....####..###.#.....##..####,,,#<br />
#################,,,...#......###.###...########.##..####..#...########.####,,,#<br />
################......##.##.,,,##..........#####.###..###..##....######...##,,,#<br />
################..###.#,,,##,,,##.##.#....######..########.##.##.#######.#######<br />
#################.....#,,,##,,,...####.#...#####.##.######.##,,,...#############<br />
#################.###.#,,,###..####.....#.#####......#####...,,,.#.#############<br />
######################,,,#..#..###..#..##..###..#.##########.,,,.#...###########<br />
######################,,,.....###..###.##.#######.##################..##########<br />
######################,,,##..####..###.##.,,,####.......##.##..#################<br />
#######################.....####..#.....#.,,,####.##..#.......##################<br />
######################..#.#.#########.#.##,,,####...#..#.#.#..,,,###############<br />
###########################.#.#######.#..########.,,,###.####.,,,..#############<br />
####################,,,###.......###..##..#######.,,,###..####,,,...############<br />
####################,,,###..#,,,....#.#######,,,#.,,,###...####....#############<br />
####################,,,.....#,,,##.....######,,,....######.##...#..#############<br />
#####################.##,,,.#,,,....##....###,,,##....####........##############<br />
########################,,,.,,,#.#.####....####.....#..#...##..#..##############<br />
########################,,,.,,,....####..#.####.#.........##..#....#############<br />
############################,,,.....#......######..##.....####..################<br />
</pre><br />
<br />
regards<br />
Jakub<br />
<br />
= Passable Cave Building Algorithm - Josh Tippets [vertexnormal@email.com].txt =<br />
<br />
Here is an algorithm I have used to generate a passable cave:<br />
<br />
First of all, I need a couple of support functions, which I call Blobbers. Basically, these functions use various methods to create "blobs" within the grid of the level array.<br />
<br />
The first Blobber I call ProbBlob, which has the prototype:<br />
<br />
void ProbBlob(int X, int Y, int Reps, int Value, float Up, float Down, float Left, float Right);<br />
<br />
* (X,Y)=Location within map grid at which to start.<br />
* Reps=Number of times to iterate. Determines the size of the blob.<br />
* Value=Grid-type value to fill in the blob with. FLOOR_TYPE,WALL_TYPE, etc.<br />
* Up,Down,Left,Right=Values in the range [0,1], which all must add up to 1.0<br />
<br />
These values are used to setup a probability table that determines which direction the blobber will move next.<br />
<br />
By giving ProbBlob the values of 0.25, 0.25, 0.25, 0.25, I generate a blob with an equal probability of moving in any given direction. By playing with these numbers, I can cause the blob to trend in a general direction.<br />
<br />
ProbBlob basically iterates through a loop Reps number of times, each time writing Value to the current location. After writing Value, I use the probability table generated from Up,Down,Left and Right to determine a direction to move. I move one cell in the chosen direction, write Value, and choose again until the loop terminates.<br />
<br />
Reps roughly determines the size of the blob. I say roughly, because a lot of the repetitions may actually re-visit a cell already blobbed, in effect being wasted, but you get the idea.<br />
<br />
The second helper function I need is called BlobToward:<br />
<br />
void BlobToward(int X1, int Y1, int X2, int Y2, float *Up, float *Down, float *Left, float *Right);<br />
<br />
This function doesn't actually draw a blob. Rather, it uses the given start and end coordinates to generate the directional values Up, Down, Left, and Right, which are later fed to the ProbBlob function.<br />
<br />
This function finds the difference between X1 and X2, and the difference between Y1 and Y2, and uses the results to compute probabilities which will cause the blob to progress generally from (X1,Y1) toward (X2,Y2). This is good for drawing random cave tunnels; you can specify a start and an end, generate the probabilities, then feed the numbers to the blobber.<br />
<br />
Another possible blobber function is one which functions almost exactly like ProbBlob, but which doesn't exit until some location is reached. If done this way, it is sometimes best to continually re-calculate Up, Down, Left, and Right, in the event that the blob runs past the destination position without actually hitting it. If the probabilities are not recomputed, the blob will tend to keep going past the destination, and might never actually hit it. Re-computing the probs routinely will ensure that the blob is always directed toward the destination.<br />
<br />
Given these functions and a grid filled with WALL_TYPE, I am given a number of options. One I commonly use is to call ProbBlob with (0.25,0.25,0.25,0.25) and generate a large blob in the very center of the map. Then I loop an arbitrary number of times, each time randomly selecting (X1,Y1) and (X2,Y2) coordinates, which I feed to BlobToward. Taking the results of BlobToward, I call ProbBlob again with the generated probabilities, using randomly determined Reps. By passing FLOOR_TYPE to ProbBlob, the generated blob is written as a floor type of cell.<br />
<br />
The result of this algorithm tends to be a large central cave complex with many arms radiating outward and terminating in dead ends.<br />
<br />
Alternately, you could partition the level grid into maybe nine blocks, 3x3, and use ProbBlob to generate a regular blob within each block. BlobToward could then be used to connect the various regular blobs into something resembling an interconnected series of rooms.<br />
<br />
I'm sure there are hundreds of ways these methods could be used, in conjunction with other ideas. This might give you a place to start. Good luck, and keep us all posted on how it goes.<br />
<br />
Josh Tippetts<br />
vertexnor...@email.com<br />
OGRESlash- www.me.icobb.com/rpg/vertexnormal/</div>Stuhttp://roguebasin.com/index.php?title=User:Duerig/Archive9&diff=12844User:Duerig/Archive92008-05-02T13:16:57Z<p>Stu: make it more wiki readable</p>
<hr />
<div>= Random Dungeon Algo in QBasic - Andrew Collins [andrewcollins@hotmail.com].txt =<br />
<br />
<pre><br />
DEFINT A-Z' speeds things up<br />
DECLARE SUB initdungeon () 'blanks out dungeon array<br />
DECLARE SUB displaydungeon () 'draws dungeon to the screen<br />
DECLARE SUB generate (recurdepth) 'main generation function<br />
<br />
'checks bounds for halls and rooms<br />
DECLARE FUNCTION CheckBounds (x1, x2, y1, y2, direction)<br />
DECLARE FUNCTION CheckBoundsHall (x1, x2, y1, y2, direction)<br />
<br />
'makes the halls and rooms<br />
DECLARE SUB makehall (x1, x2, y1, y2, direction)<br />
DECLARE SUB makeroom (x1, x2, y1, y2, direction, recurdepth)<br />
<br />
'random number between lowest and highest<br />
DECLARE FUNCTION Rand (Lowest, Highest)<br />
<br />
<br />
<br />
'map array<br />
DIM SHARED DungeonLayer(150, 150) AS INTEGER<br />
<br />
'what this does is makes a list of rooms that were created.<br />
'then if the generator hits a dead end it goes back to a random room<br />
'in the list and takes up generation from there.<br />
DIM SHARED RoomHolder(200, 4) AS INTEGER<br />
<br />
'max numbers of maps<br />
DIM SHARED maxx 'MaxX coord of Dungeon<br />
DIM SHARED maxy 'MaxY of Dungeon<br />
DIM recurdepth AS INTEGER<br />
<br />
'map and engine constants<br />
DIM SHARED wall AS INTEGER<br />
DIM SHARED floor AS INTEGER<br />
DIM SHARED door AS INTEGER<br />
DIM SHARED true AS INTEGER<br />
DIM SHARED false AS INTEGER<br />
DIM SHARED Permwall AS INTEGER<br />
DIM SHARED numofrooms AS INTEGER<br />
DIM SHARED maxnumofrooms AS INTEGER<br />
<br />
'these are the ascii numbers (like angband for the door and walls)<br />
door = 43<br />
Permwall = 178<br />
wall = 176<br />
floor = 46<br />
<br />
true = 1<br />
false = -1<br />
<br />
recurdepth = 0<br />
numofrooms = 0<br />
<br />
DIM x1 AS INTEGER' top right coordinates<br />
DIM y1 AS INTEGER' top left coordinates<br />
DIM x2 AS INTEGER' bottom right coordinates<br />
DIM y2 AS INTEGER' bottom left coordinates<br />
DIM direction AS INTEGER<br />
<br />
<br />
<br />
<br />
<br />
<br />
'these tie into the DungeonLayer array so the size will have to be<br />
'increased there to increase these numbers<br />
maxx = 150<br />
maxy = 150<br />
<br />
' maxnumofrooms is tied into RoomHolder<br />
' at 200 it bogs down and fails a lot try setting to 200 you'll see<br />
<br />
maxnumofrooms = 150<br />
<br />
RANDOMIZE TIMER<br />
<br />
DO<br />
'this times the generation<br />
T! = TIMER<br />
initdungeon<br />
generate (recurdepth)<br />
T2! = TIMER<br />
T3! = T2! - T!<br />
<br />
displaydungeon' I'm not adding this into the timer<br />
'seeing as it only displays the dungeon<br />
LOCATE 1, 21: COLOR 4: PRINT "Door color"<br />
LOCATE 2, 21: COLOR 8: PRINT "Wall color "<br />
LOCATE 3, 21: COLOR 15: PRINT "PermaWall color"<br />
LOCATE 6, 21: COLOR 15: PRINT "# of Rooms"; numofrooms<br />
LOCATE 9, 21: PRINT "One pixel ="<br />
LOCATE 10, 23: PRINT "one ascii tile"<br />
LOCATE 21, 1: PRINT "Time to make "; T3!; " Seconds."<br />
LOCATE 22, 1: PRINT "Press esc to quit"<br />
LOCATE 23, 1: PRINT "Any other key to generate again"<br />
SLEEP<br />
LOOP UNTIL INKEY$ = CHR$(27)<br />
END<br />
<br />
<br />
FUNCTION CheckBounds (x1, x2, y1, y2, direction)<br />
CheckBounds = 0<br />
'Makes sure room isn't out of bounds of Dungeon<br />
'Our dungeon is 1 to MaxX and 1 to MaxY<br />
<br />
IF (x1 - 1) < 1 THEN CheckBounds = false: EXIT FUNCTION<br />
IF (y1 - 1) < 1 THEN CheckBounds = false: EXIT FUNCTION<br />
IF (x2 + 1) > maxx THEN CheckBounds = false: EXIT FUNCTION<br />
IF (y2 + 1) > maxy THEN CheckBounds = false: EXIT FUNCTION<br />
<br />
FOR x = (x1 - 1) TO (x2 + 1)<br />
FOR y = (y1 - 1) TO (y2 + 1)<br />
IF DungeonLayer(x, y) = floor THEN CheckBounds = false: EXIT FUNCTION<br />
NEXT y<br />
NEXT x<br />
CheckBounds = true<br />
END FUNCTION<br />
<br />
FUNCTION CheckBoundsHall (x1, x2, y1, y2, direction)<br />
CheckBoundsHall = 0<br />
'Makes sure hall isn't out of bounds of Dungeon<br />
'Our dungeon is 1 to MaxX and 1 to MaxY<br />
<br />
IF (x1 - 1) < 1 THEN CheckBoundsHall = false: EXIT FUNCTION<br />
IF (y1 - 1) < 1 THEN CheckBoundsHall = false: EXIT FUNCTION<br />
IF (x2 + 1) > maxx THEN CheckBoundsHall = false: EXIT FUNCTION<br />
IF (y2 + 1) > maxy THEN CheckBoundsHall = false: EXIT FUNCTION<br />
<br />
IF direction = 0 OR direction = 2 THEN<br />
FOR x = x1 TO x2<br />
FOR y = (y1 - 1) TO (y2 + 1)<br />
IF DungeonLayer(x, y) = floor THEN CheckBoundsHall = false: EXIT FUNCTION<br />
NEXT y<br />
NEXT x<br />
END IF<br />
<br />
<br />
IF direction = 1 OR direction = 3 THEN<br />
FOR x = (x1 - 1) TO (x2 + 1)<br />
FOR y = y1 TO y2<br />
IF DungeonLayer(x, y) = floor THEN CheckBoundsHall = false: EXIT FUNCTION<br />
NEXT y<br />
NEXT x<br />
END IF<br />
<br />
CheckBoundsHall = true<br />
END FUNCTION<br />
<br />
SUB displaydungeon<br />
'this just draws the dungeon <br />
CLS<br />
SCREEN 13<br />
FOR x = 1 TO maxx<br />
FOR y = 1 TO maxy<br />
IF DungeonLayer(x, y) = wall THEN PSET (x, y), 8<br />
IF DungeonLayer(x, y) = Permwall THEN PSET (x, y), 15<br />
IF DungeonLayer(x, y) = door THEN PSET (x, y), 4<br />
IF DungeonLayer(x, y) = floor THEN PSET (x, y), 0<br />
NEXT y<br />
NEXT x<br />
END SUB<br />
<br />
SUB generate (recurdepth)<br />
<br />
'start with a random room<br />
x1 = Rand(2, (maxx - 1))<br />
y1 = Rand(2, (maxy - 1))<br />
x2 = x1 + Rand(2, 4)<br />
y2 = y1 + Rand(3, 7)<br />
<br />
<br />
<br />
direction = Rand(0, 3)<br />
IF CheckBounds(x1, x2, y1, y2, direction) = true THEN<br />
CALL makeroom(x1, x2, y1, y2, direction, recurdepth)<br />
END IF<br />
<br />
<br />
room = true<br />
<br />
DO<br />
'these are all to make sure we dont get into an infinite loop<br />
hallcount = 0<br />
hallcountmultp = 0<br />
roomcount = 0<br />
roomcountmultp = 0<br />
'ite mean iterations<br />
<br />
<br />
DO<br />
ite = ite + 1<br />
direction = Rand(0, 3)'the direction we want to draw towards<br />
'0 north(up) : 1 east(right) : 2 south(down) : 3 west(left)<br />
<br />
hall = false<br />
hallcount = hallcount + 1<br />
<br />
halllength = Rand(2, 7)'min and max length of halls<br />
<br />
'for all hall generation they are basically the same<br />
IF direction = 0 THEN<br />
'halls are only 1 square wide <br />
dy1 = Rand(y1, y2)<br />
dy2 = dy1<br />
'and as long as our halllength variable <br />
dx2 = x1 - 2<br />
dx1 = dx2 - halllength<br />
' we check to see if it's in bounds <br />
IF CheckBoundsHall(dx1, dx2, dy1, dy2, direction) = true THEN<br />
' if it is we actually put it there <br />
CALL makehall(dx1, dx2, dy1, dy2, direction)<br />
' draw a door if it hits a room (this can be change to randomly place any type <br />
' of feature)<br />
IF room = true THEN<br />
DungeonLayer(dx2 + 1, dy1) = door<br />
ELSE<br />
'make it a floor tile if it doesn't hit a room <br />
DungeonLayer(dx2 + 1, dy1) = floor<br />
END IF<br />
'these are saved to pass to the room creation section below <br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
'sets hall to true so we can move on <br />
hall = true<br />
END IF<br />
<br />
END IF<br />
IF direction = 1 THEN<br />
dy1 = y2 + 2<br />
dy2 = dy1 + halllength<br />
dx1 = Rand(x1, x2)<br />
dx2 = dx1<br />
IF CheckBoundsHall(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makehall(dx1, dx2, dy1, dy2, direction)<br />
IF room = true THEN<br />
DungeonLayer(dx1, dy1 - 1) = door<br />
ELSE<br />
DungeonLayer(dx1, dy1 - 1) = floor<br />
END IF<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
hall = true<br />
END IF<br />
<br />
END IF<br />
<br />
IF direction = 2 THEN<br />
dy1 = Rand(y1, y2)<br />
dy2 = dy1<br />
dx1 = x2 + 2<br />
dx2 = dx1 + halllength<br />
IF CheckBoundsHall(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makehall(dx1, dx2, dy1, dy2, direction)<br />
IF room = true THEN<br />
DungeonLayer(dx1 - 1, dy1) = door<br />
ELSE<br />
DungeonLayer(dx1 - 1, dy1) = floor<br />
END IF<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
hall = true<br />
END IF<br />
END IF<br />
<br />
IF direction = 3 THEN<br />
dy1 = (y1 - halllength) - 2<br />
dy2 = dy1 + halllength<br />
dx1 = Rand(x1, x2)<br />
dx2 = dx1<br />
IF CheckBoundsHall(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makehall(dx1, dx2, dy1, dy2, direction)<br />
IF room = true THEN<br />
DungeonLayer(dx2, dy2 + 1) = door<br />
ELSE<br />
DungeonLayer(dx2, dy2 + 1) = floor<br />
END IF<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
hall = true<br />
END IF<br />
END IF<br />
<br />
<br />
'if we cant make a hall after 10 tries then we....<br />
IF hallcount > 10 AND hall = false THEN<br />
'pick a random room from our list<br />
RDepth = Rand(1, recurdepth)<br />
'make old room the dimensions of our current room<br />
x1 = RoomHolder(RDepth, 0)<br />
x2 = RoomHolder(RDepth, 1)<br />
y1 = RoomHolder(RDepth, 2)<br />
y2 = RoomHolder(RDepth, 3)<br />
'reset hall count<br />
hallcount = 0<br />
'increment our hallmult counter and go again<br />
hallcountmultp = hallcountmultp + 1<br />
END IF<br />
<br />
'if we tried to make a hall more than 1000 times (hallcount * hallcountmultp)<br />
'and no hall was made then we failed<br />
IF hallcountmultp > 100 THEN<br />
PRINT "FAILED at "; recurdepth; " Rooms": SLEEP<br />
numofrooms = recurdepth: EXIT SUB<br />
END IF<br />
<br />
LOOP UNTIL hall = true<br />
<br />
<br />
<br />
'************ room creation below<br />
<br />
<br />
room = false<br />
<br />
<br />
IF direction = 0 THEN<br />
'holder is a dummy variable <br />
holder = Rand(3, 7)<br />
dx2 = x1 - 2<br />
dx1 = dx2 - Rand(2, 4)<br />
dy1 = Rand((y1 - holder), y2)<br />
dy2 = dy1 + holder<br />
'check to see if our room is in bounds <br />
IF CheckBounds(dx1, dx2, dy1, dy2, direction) = true THEN<br />
'if it is, set it in stone(so to speak) <br />
CALL makeroom(dx1, dx2, dy1, dy2, direction, recurdepth)<br />
'put a door here cause this is where our hall will begin<br />
DungeonLayer(x1 - 1, y1) = door<br />
'put our end room coordiantes into these variables so we can send them<br />
'to our hall creation section above<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
'set to true so we can end <br />
room = true<br />
END IF<br />
<br />
END IF<br />
<br />
IF direction = 1 THEN<br />
holder = Rand(2, 4)<br />
dx1 = Rand((x1 - holder), x2)<br />
dx2 = dx1 + holder<br />
dy1 = y2 + 2<br />
dy2 = dy1 + Rand(3, 7)<br />
IF CheckBounds(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makeroom(dx1, dx2, dy1, dy2, direction, recurdepth)<br />
DungeonLayer(x2, y2 + 1) = door<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
room = true<br />
END IF<br />
END IF<br />
<br />
IF direction = 2 THEN<br />
holder = Rand(3, 7)<br />
dx1 = x2 + 2<br />
dx2 = dx1 + Rand(2, 4)<br />
dy1 = Rand(y1 - holder, y2)<br />
dy2 = dy1 + holder<br />
IF CheckBounds(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makeroom(dx1, dx2, dy1, dy2, direction, recurdepth)<br />
DungeonLayer(x2 + 1, y2) = door<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
room = true<br />
END IF<br />
END IF<br />
<br />
IF direction = 3 THEN<br />
holder = Rand(2, 4)<br />
dx1 = Rand((x1 - holder), x2)<br />
dx2 = dx1 + holder<br />
dy2 = y1 - 2<br />
dy1 = dy2 - Rand(3, 7)<br />
IF CheckBounds(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makeroom(dx1, dx2, dy1, dy2, direction, recurdepth)<br />
DungeonLayer(x2, y1 - 1) = door<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
room = true<br />
END IF<br />
END IF<br />
<br />
'do 4000 total loops,if it is more than 4000 then fail<br />
IF ite > 4000 THEN<br />
PRINT "FAILED at"; recurdepth; "Rooms": SLEEP<br />
numofrooms = recurdepth: EXIT SUB<br />
END IF<br />
LOOP UNTIL recurdepth = maxnumofrooms<br />
numofrooms = recurdepth<br />
END SUB<br />
<br />
SUB initdungeon<br />
'fill our dungeon with rock<br />
FOR x = 1 TO maxx<br />
FOR y = 1 TO maxy<br />
DungeonLayer(x, y) = wall<br />
NEXT y<br />
NEXT x<br />
' make the edges permawall <br />
FOR y = 1 TO maxy<br />
DungeonLayer(maxx, y) = Permwall<br />
DungeonLayer(1, y) = Permwall<br />
NEXT y<br />
FOR x = 1 TO maxx<br />
DungeonLayer(x, maxy) = Permwall<br />
DungeonLayer(x, 1) = Permwall<br />
NEXT x<br />
END SUB<br />
<br />
SUB makehall (x1, x2, y1, y2, direction)<br />
'draw our dungeon always from upper left to lower right <br />
FOR x = x1 TO x2<br />
FOR y = y1 TO y2<br />
DungeonLayer(x, y) = floor<br />
NEXT y<br />
NEXT x<br />
END SUB<br />
<br />
SUB makeroom (x1, x2, y1, y2, direction, recurdepth)<br />
'draw our dungeon always from upper left to lower right <br />
FOR x = x1 TO x2<br />
FOR y = y1 TO y2<br />
DungeonLayer(x, y) = floor<br />
NEXT y<br />
NEXT x<br />
recurdepth = recurdepth + 1<br />
' this holds our rooms so we can choose one at random if we get stuck<br />
' we never save halls or it would be a horrendous mess<br />
RoomHolder(recurdepth, 0) = x1<br />
RoomHolder(recurdepth, 1) = x2<br />
RoomHolder(recurdepth, 2) = y1<br />
RoomHolder(recurdepth, 3) = y2<br />
END SUB<br />
<br />
FUNCTION Rand (Lowest, Highest)<br />
DIM a AS INTEGER<br />
DIM b AS INTEGER<br />
DIM c AS INTEGER<br />
<br />
a = Lowest<br />
b = Highest<br />
IF a > b THEN<br />
c = a - b<br />
ELSEIF b > a THEN<br />
c = b - a<br />
ELSE<br />
Rand = a: EXIT FUNCTION<br />
END IF<br />
Rand = INT(RND(1) * (c + 1)) + a<br />
<br />
END FUNCTION<br />
<br />
</pre><br />
<br />
= Nest of Ants - Jakub Debski [jakub@mks.com.pl].txt =<br />
<br />
I was wondering how to create a nice looking nest for the ants,<br />
and here is my idea:<br />
<br />
Let's say, that we have some sticky dust. It goes through air<br />
and catch all the static objects. So, let's see, if we have<br />
one static object at the beginning, and a lot of randomly moving<br />
objects of the same type:<br />
<br />
dust: *<br />
move vector: -<br />
<br />
*-<br />
<br />
/ * -*<br />
*<br />
<br />
|<br />
*<br />
<br />
then these objects will catch the first one and group into larger<br />
one:<br />
<br />
**<br />
*<br />
*****<br />
* *<br />
* **<br />
*<br />
<br />
That's all. We have nice looking corridors with all the places<br />
reachabale. Algorithm is very simple and gives nice results:<br />
<br />
1. Allocate 2 dimensional array for 0,1 values of the nest size.<br />
2. In the centre add single object<br />
3. Create new sticky object on the ellipse which is around the nest,<br />
having centre in the centre of the nest<br />
4. Add random move vector to the object<br />
5. Move object a bit. If it crosses the border of our territory, then<br />
appears on the other side.<br />
6. Look around the object and if there is something to catch then stop. If<br />
size of the nest is enough, then stop, else go to 3.<br />
7. Goto 5<br />
<br />
My two advices are to add guard for moving object, f.e. for 1000 steps,<br />
because depending on vector it's possible, that object won't catch any<br />
other. The second advice it to add some "rooms" at the end of corridors (on<br />
cell, which has only one neighbour:<br />
<br />
piece of nest:<br />
<br />
*<br />
*****<br />
**<br />
<br />
+ - the cell with one neighbour, means end of corridor<br />
<br />
*<br />
****+<br />
**<br />
<br />
add there 3x3 room<br />
<br />
* +++<br />
***+++<br />
** +++<br />
<br />
source code:<br />
<br />
#define NEST_SIZE_X 80<br />
#define NEST_SIZE_Y 50<br />
<br />
int main(void)<br />
{<br />
init_graph(); // not neccecary, for draw_char(x,y,char)<br />
srand(get_ticks_count()); // for (rand())<br />
<br />
bool c[NEST_SIZE_X][NEST_SIZE_Y];<br />
int x,y;<br />
for (x=0;x<NEST_SIZE_X;x++)<br />
for (y=0;y<NEST_SIZE_Y;y++)<br />
{<br />
c[x][y]=0;<br />
draw_char(x,y,'#');<br />
}<br />
<br />
// in the centre we put one object<br />
c[NEST_SIZE_X/2][NEST_SIZE_Y/2]=1; // in the array<br />
draw_char(NEST_SIZE_X/2,NEST_SIZE_Y/2,'.'); // and on the screen for test<br />
myrefresh();<br />
<br />
float x1,y1; // position of object<br />
float k; // angle<br />
float dx, dy; // move vector<br />
int px, py;<br />
<br />
for (int object=0;object<NEST_SIZE_X*NEST_SIZE_Y/3;object++)<br />
{<br />
// degree<br />
k = (rand()%360)*3.1419532/180;<br />
// position on ellipse by degree<br />
x1 = NEST_SIZE_X/2+(NEST_SIZE_X/2)*sin(k);<br />
y1 = NEST_SIZE_Y/2+(NEST_SIZE_Y/2)*cos(k);<br />
// draw_char(x1,y1,'*');<br />
<br />
// object will move not too horizontal and not too vertival<br />
do {<br />
dx=rand()%100;<br />
dy=rand()%100;<br />
} while ((abs(dx)<10 && abs(dy)<10));<br />
dx-=50;<br />
dy-=50;<br />
dx/=100; // by little steps<br />
dy/=100; // by little steps<br />
<br />
int counter=0;<br />
while (1)<br />
{<br />
// didn't catch anything after 1000 steps (just to avoid infinite<br />
loops)<br />
if (counter++>1000)<br />
{<br />
object--;<br />
break;<br />
}<br />
// move object by small step<br />
x1+=dx;<br />
y1+=dy;<br />
<br />
// change float to int<br />
<br />
px=x1;<br />
py=y1;<br />
<br />
// go through the border to the other side<br />
<br />
if (px<0)<br />
{<br />
px=NEST_SIZE_X-1;<br />
x1=px;<br />
}<br />
if (px>NEST_SIZE_X-1)<br />
{<br />
px=0;<br />
x1=px;<br />
}<br />
if (py<0)<br />
{<br />
py=NEST_SIZE_Y-1;<br />
y1=py;<br />
}<br />
if (py>NEST_SIZE_Y-1)<br />
{<br />
py=0;<br />
y1=py;<br />
}<br />
<br />
// if object has something to catch, then catch it<br />
<br />
if ((px>0 && c[px-1][py]==1) ||<br />
(py>0 && c[px][py-1]==1) ||<br />
(px<NEST_SIZE_X-1 && c[px+1][py]==1) ||<br />
(py<NEST_SIZE_Y-1 && c[px][py+1]==1))<br />
{<br />
c[px][py]=1;<br />
draw_char(px,py,'.');<br />
myrefresh();<br />
break; // go to creation of new object<br />
}<br />
} // end of while(1)<br />
} // end of for<br />
<br />
// add halls at the end of corridors<br />
int neighbours;<br />
for (x=1;x<NEST_SIZE_X-1;x++)<br />
for (y=1;y<NEST_SIZE_Y-1;y++)<br />
{<br />
if ((x>NEST_SIZE_X/2-10 && x<NEST_SIZE_X/2+10 && y>NEST_SIZE_Y/2-5 &&<br />
y<NEST_SIZE_Y/2+5) || c[x][y]==0)<br />
continue;<br />
<br />
neighbours=0;<br />
if (c[x-1][y-1]!=0)<br />
neighbours++;<br />
if (c[x][y-1]!=0)<br />
neighbours++;<br />
if (c[x+1][y-1]!=0)<br />
neighbours++;<br />
if (c[x-1][y]!=0)<br />
neighbours++;<br />
if (c[x+1][y]!=0)<br />
neighbours++;<br />
if (c[x-1][y+1]!=0)<br />
neighbours++;<br />
if (c[x][y+1]!=0)<br />
neighbours++;<br />
if (c[x-1][y+1]!=0)<br />
neighbours++;<br />
<br />
if (neighbours==1)<br />
{<br />
for (px=-1;px<=1;px++)<br />
for (py=-1;py<=1;py++)<br />
{<br />
c[x+px][y+py]=1;<br />
draw_char(x+px,y+py,',');<br />
myrefresh();<br />
}<br />
}<br />
}<br />
<br />
return 0;<br />
<br />
}<br />
<br />
some samples<br />
<br />
<pre><br />
80x25<br />
#####################............................###############.###..##########<br />
###############,,,###.#########.#.######.##..###################.###.###########<br />
###############,,,......#######...######.....########.#####...#......##.########<br />
###############,,,###.#..#.##.##..##,,,#..#.######,,,.#####.#...###.....########<br />
################..###......#...##..#,,,#....######,,,.#####.##.##......#########<br />
#####################.###......###.#,,,..##,,,.###,,,##.###.......###.....######<br />
########################..#,,,.........#.#.,,,..####.....##.####.#.######.######<br />
#########################.#,,,########.....,,,..####..####.....#...#############<br />
#####################,,,###,,,...#######.####.#.#.##.#####.###.###..############<br />
#####################,,,########.#######.####...#.#....###.####,,,##############<br />
#################,,,.,,,#.#.#.##..####.......................##,,,##############<br />
#################,,,...........#.....###.##.##.#.#####..##..###,,,#####.########<br />
#################,,,##.#,,,###...##...........##....#########..#..#.....########<br />
##############,,,#######,,,######.#..###.###.#####...###.#.##.##....#.#..#######<br />
##############,,,,,,####,,,###.......##...##.####...........#....#.#############<br />
##############,,,,,,#######...#####.####..######...#.###.##......####....#######<br />
############..#.#,,,#######............##...#####.##...#..#..##...###.#.########<br />
###########.#...##.###....##...##...##,,,.#..########.###..####..........#######<br />
#####,,,.##...#...............#.......,,,.##.########...##..####.##....#########<br />
#####,,,....#...###.#..#.#..#.#,,,.#.#,,,############..###.....#.##.,,,#########<br />
#####,,,#,,,..###...####.######,,,##.###############..####.#....####,,,#########<br />
#########,,,.####...####..#####,,,##.###############..#######...####,,,#########<br />
#########,,,..##...#.....#######,,,#.##############...########..################<br />
##########..#.##.#..####..######,,,....############...########.#################<br />
##########.#######.#############,,,..#.#######################.#################<br />
<br />
80x40<br />
<br />
##########################.......................#....##......##################<br />
##############,,,#####,,,#....,,,.###...####.######...###.##..##################<br />
##############,,,.....,,,###.#,,,.###..#####.#..###.#####.######################<br />
##############,,,....#,,,#####,,,.####..####.....##..####.####.#################<br />
#################,,,.####,,,.####.##...#####.#.####.##.##.##...#################<br />
#################,,,.####,,,.#.##.#.##.###...#.###..#..##....##.....############<br />
#################,,,.####,,,......#..#..##..#..###.#..###.#####.,,,#############<br />
################.......#########.....#..##..#..##..#..###.#.....,,,#############<br />
################.###.#.########...##.#.###.##.##..........#....#,,,#############<br />
################.##....##,,,##,,,###.#.###....##..##........####..##############<br />
###############..####..##,,,##,,,##.....##.###.....##.##.#.###.#.....###########<br />
##############....####.##,,,.#,,,##...#.##.##..##,,,#..#.........#...###########<br />
##############.......#.###...##..###.##....##...#,,,#.###.#.#.#####..###########<br />
#################......####.####.####,,,.#.#..#.#,,,#####.....#,,,##.###########<br />
##################.###.#.##.####.###.,,,.#....#.......###.,,,..,,,##############<br />
###################......##.#.##..#..,,,..##.#####..#.###.,,,##,,,##############<br />
############........####................#.########.##..###,,,###################<br />
##########.#.#####.####....##.#.##.##.#...########..###,,,######################<br />
####,,,............##,,,..##########.##..##.##########.,,,######################<br />
####,,,...#####...###,,,.#####.#####....#.......#####..,,,######################<br />
####,,,.#.###...#####,,,.####...#####.#...##.##.....#.,,,#######################<br />
######.######..########.######...######....########...,,,#..####################<br />
############..#########.######.#..####...#.####.#####.,,,#..####################<br />
#######################..###,,,#....#...####.##.#######.##.,,,##################<br />
########################.###,,,.##..............#.#####.#..,,,#..###############<br />
##################.......###,,,....#.#..####.##...#.......#,,,...###############<br />
##################.,,,....##.####.##....###...##......##..#.#.....###.,,,#######<br />
##############,,,##,,,.#..........#...#.###.#.##.####..##.....,,,.....,,,#######<br />
##############,,,..,,,#..#.#.####.#.#.#.###.#..#...##..##.#.#.,,,.#...,,,#######<br />
#############.,,,#.####.####.##...#####..##..#.##....###,,,.#.,,,###############<br />
############.............#...##....##....###..####.#.###,,,.#....###############<br />
####,,,.#.######.#########..#####.###.##..##...###..####,,,..###################<br />
####,,,...#...######.#.....#####..###.#...##.#####....##########################<br />
,,,.,,,#....#.####.....##...###...##...##.##...###.##..#########################<br />
,,,.#...............##.###..###.,,,#.####.##....##...#..########################<br />
,,,....##.##..#.#.#....##..###..,,,######.##.##.####..##########################<br />
#########.#,,,..#....#.#...###.#,,,####...##..#####,,,##########################<br />
#########.#,,,##......##..####..#######..###.#####.,,,##########################<br />
#########.#,,,#..#.##......#############.###.####..,,,##########################<br />
########..#####..#.#####..##############.###........############################<br />
<br />
80x50<br />
<br />
######################.##..#.....#........######################################<br />
#####################.......#.,,,##.#.##########################################<br />
########################..#.#.,,,##...##########################################<br />
###########################...,,,....######################,,,##################<br />
##########################..#.#####...#####################,,,.#################<br />
############################....##.....#######.############,,,##...#############<br />
#####################,,,####.#...#...######,,,.#############...#..##############<br />
#####################,,,######......#,,,###,,,.############..#.#.##..###########<br />
#####################,,,###,,,.#.....,,,###,,,..###########..#.#......##########<br />
################,,,####...#,,,###...#,,,...###.########,,,..##....##############<br />
################,,,######..,,,#####.###...####..#######,,,.......#.#############<br />
################,,,#.,,,#..##.......##..###.##.########,,,#.######.,,,#####.####<br />
##################...,,,..#####,,,..##.##....#..###,,,#####........,,,####..####<br />
###################..,,,..#####,,,........###...###,,,######.,,,##.,,,#####.####<br />
###################.......#####,,,...#.#,,,##.#,,,#,,,######.,,,###########...##<br />
####################.####.....##.###.#..,,,##..,,,...######..,,,.##.#######..###<br />
###########,,,#####,,,,,,,,,#.##........,,,#..#,,,#..##...##..##....######..####<br />
#########..,,,##.##,,,,,,,,,#...######.,,,###.,,,###.#.##.##.###.##,,,####.##...<br />
#########..,,,.....,,,,,,,,,....#####..,,,##..,,,.##...##..#.#.....,,,####.....#<br />
########.#....#.#.....#.####,,,.#####..,,,###.,,,.#...####.#......#,,,#.....#.##<br />
######......#.....###.#.###.,,,...###..#...##..##..#.#.,,,...##.#.......#.###..#<br />
######..#########.##..#..#..,,,#..##......###..##.##.#.,,,..###...#######..#####<br />
#######.###..####........##.###..####.#.#..##..##.##.#.,,,.##.###..........##,,,<br />
######,,,#........##..#...#.###...#.#####.###.....#..#.##.......#####,,,.#...,,,<br />
######,,,####...#.###..#..#...........#...#....##.##...#..#.##.######,,,.####,,,<br />
######,,,..#..#######.###.....#####..................#...############,,,#,,,###.<br />
##########...##############.#####.#.###.#.....##..##..#..#####.#....#####,,,.##.<br />
###########.########..#.....#####.#..##.#.##.####...#.####.........######,,,....<br />
##########..######......####.........##.####....###.#.......#...##.###.#...##.#.<br />
###########.######.##..#####...#,,,.#...####.##....##.##.##...#..#.......#.##...<br />
##########..#####,,,...####...##,,,.##..###..###.#.#####.###....####.#.######..#<br />
##########.######,,,#..#####..##,,,###...##.###.....####..###.#.....##..####,,,#<br />
#################,,,...#......###.###...########.##..####..#...########.####,,,#<br />
################......##.##.,,,##..........#####.###..###..##....######...##,,,#<br />
################..###.#,,,##,,,##.##.#....######..########.##.##.#######.#######<br />
#################.....#,,,##,,,...####.#...#####.##.######.##,,,...#############<br />
#################.###.#,,,###..####.....#.#####......#####...,,,.#.#############<br />
######################,,,#..#..###..#..##..###..#.##########.,,,.#...###########<br />
######################,,,.....###..###.##.#######.##################..##########<br />
######################,,,##..####..###.##.,,,####.......##.##..#################<br />
#######################.....####..#.....#.,,,####.##..#.......##################<br />
######################..#.#.#########.#.##,,,####...#..#.#.#..,,,###############<br />
###########################.#.#######.#..########.,,,###.####.,,,..#############<br />
####################,,,###.......###..##..#######.,,,###..####,,,...############<br />
####################,,,###..#,,,....#.#######,,,#.,,,###...####....#############<br />
####################,,,.....#,,,##.....######,,,....######.##...#..#############<br />
#####################.##,,,.#,,,....##....###,,,##....####........##############<br />
########################,,,.,,,#.#.####....####.....#..#...##..#..##############<br />
########################,,,.,,,....####..#.####.#.........##..#....#############<br />
############################,,,.....#......######..##.....####..################<br />
</pre><br />
<br />
regards<br />
Jakub<br />
<br />
= Passable Cave Building Algorithm - Josh Tippets [vertexnormal@email.com].txt =<br />
<br />
Here is an algorithm I have used to generate a passable cave:<br />
<br />
First of all, I need a couple of support functions, which I call Blobbers. Basically, these functions use various methods to create "blobs" within the grid of the level array.<br />
<br />
The first Blobber I call ProbBlob, which has the prototype:<br />
<br />
void ProbBlob(int X, int Y, int Reps, int Value, float Up, float Down, float Left, float Right);<br />
<br />
* (X,Y)=Location within map grid at which to start.<br />
* Reps=Number of times to iterate. Determines the size of the blob.<br />
* Value=Grid-type value to fill in the blob with. FLOOR_TYPE,WALL_TYPE, etc.<br />
* Up,Down,Left,Right=Values in the range [0,1], which all must add up to 1.0<br />
<br />
These values are used to setup a probability table that determines which direction the blobber will move next.<br />
<br />
By giving ProbBlob the values of 0.25, 0.25, 0.25, 0.25, I generate a blob with an equal probability of moving in any given direction. By playing with these numbers, I can cause the blob to trend in a general direction.<br />
<br />
ProbBlob basically iterates through a loop Reps number of times, each time writing Value to the current location. After writing Value, I use the probability table generated from Up,Down,Left and Right to determine a direction to move. I move one cell in the chosen direction, write Value, and choose again until the loop terminates.<br />
<br />
Reps roughly determines the size of the blob. I say roughly, because a lot of the repetitions may actually re-visit a cell already blobbed, in effect being wasted, but you get the idea.<br />
<br />
The second helper function I need is called BlobToward:<br />
<br />
void BlobToward(int X1, int Y1, int X2, int Y2, float *Up, float *Down, float *Left, float *Right);<br />
<br />
This function doesn't actually draw a blob. Rather, it uses the given start and end coordinates to generate the directional values Up, Down, Left, and Right, which are later fed to the ProbBlob function.<br />
<br />
This function finds the difference between X1 and X2, and the difference between Y1 and Y2, and uses the results to compute probabilities which will cause the blob to progress generally from (X1,Y1) toward (X2,Y2). This is good for drawing random cave tunnels; you can specify a start and an end, generate the probabilities, then feed the numbers to the blobber.<br />
<br />
Another possible blobber function is one which functions almost exactly like ProbBlob, but which doesn't exit until some location is reached. If done this way, it is sometimes best to continually re-calculate Up, Down, Left, and Right, in the event that the blob runs past the destination position without actually hitting it. If the probabilities are not recomputed, the blob will tend to keep going past the destination, and might never actually hit it. Re-computing the probs routinely will ensure that the blob is always directed toward the destination.<br />
<br />
Given these functions and a grid filled with WALL_TYPE, I am given a number of options. One I commonly use is to call ProbBlob with (0.25,0.25,0.25,0.25) and generate a large blob in the very center of the map. Then I loop an arbitrary number of times, each time randomly selecting (X1,Y1) and (X2,Y2) coordinates, which I feed to BlobToward. Taking the results of BlobToward, I call ProbBlob again with the generated probabilities, using randomly determined Reps. By passing FLOOR_TYPE to ProbBlob, the generated blob is written as a floor type of cell.<br />
<br />
The result of this algorithm tends to be a large central cave complex with many arms radiating outward and terminating in dead ends.<br />
<br />
Alternately, you could partition the level grid into maybe nine blocks, 3x3, and use ProbBlob to generate a regular blob within each block. BlobToward could then be used to connect the various regular blobs into something resembling an interconnected series of rooms.<br />
<br />
I'm sure there are hundreds of ways these methods could be used, in conjunction with other ideas. This might give you a place to start. Good luck, and keep us all posted on how it goes.<br />
<br />
Josh Tippetts<br />
vertexnor...@email.com<br />
OGRESlash- www.me.icobb.com/rpg/vertexnormal/</div>Stuhttp://roguebasin.com/index.php?title=User:Duerig/Archive9&diff=12843User:Duerig/Archive92008-05-02T13:13:08Z<p>Stu: added code tags</p>
<hr />
<div>= Random Dungeon Algo in QBasic - Andrew Collins [andrewcollins@hotmail.com].txt =<br />
<br />
<pre><br />
DEFINT A-Z' speeds things up<br />
DECLARE SUB initdungeon () 'blanks out dungeon array<br />
DECLARE SUB displaydungeon () 'draws dungeon to the screen<br />
DECLARE SUB generate (recurdepth) 'main generation function<br />
<br />
'checks bounds for halls and rooms<br />
DECLARE FUNCTION CheckBounds (x1, x2, y1, y2, direction)<br />
DECLARE FUNCTION CheckBoundsHall (x1, x2, y1, y2, direction)<br />
<br />
'makes the halls and rooms<br />
DECLARE SUB makehall (x1, x2, y1, y2, direction)<br />
DECLARE SUB makeroom (x1, x2, y1, y2, direction, recurdepth)<br />
<br />
'random number between lowest and highest<br />
DECLARE FUNCTION Rand (Lowest, Highest)<br />
<br />
<br />
<br />
'map array<br />
DIM SHARED DungeonLayer(150, 150) AS INTEGER<br />
<br />
'what this does is makes a list of rooms that were created.<br />
'then if the generator hits a dead end it goes back to a random room<br />
'in the list and takes up generation from there.<br />
DIM SHARED RoomHolder(200, 4) AS INTEGER<br />
<br />
'max numbers of maps<br />
DIM SHARED maxx 'MaxX coord of Dungeon<br />
DIM SHARED maxy 'MaxY of Dungeon<br />
DIM recurdepth AS INTEGER<br />
<br />
'map and engine constants<br />
DIM SHARED wall AS INTEGER<br />
DIM SHARED floor AS INTEGER<br />
DIM SHARED door AS INTEGER<br />
DIM SHARED true AS INTEGER<br />
DIM SHARED false AS INTEGER<br />
DIM SHARED Permwall AS INTEGER<br />
DIM SHARED numofrooms AS INTEGER<br />
DIM SHARED maxnumofrooms AS INTEGER<br />
<br />
'these are the ascii numbers (like angband for the door and walls)<br />
door = 43<br />
Permwall = 178<br />
wall = 176<br />
floor = 46<br />
<br />
true = 1<br />
false = -1<br />
<br />
recurdepth = 0<br />
numofrooms = 0<br />
<br />
DIM x1 AS INTEGER' top right coordinates<br />
DIM y1 AS INTEGER' top left coordinates<br />
DIM x2 AS INTEGER' bottom right coordinates<br />
DIM y2 AS INTEGER' bottom left coordinates<br />
DIM direction AS INTEGER<br />
<br />
<br />
<br />
<br />
<br />
<br />
'these tie into the DungeonLayer array so the size will have to be<br />
'increased there to increase these numbers<br />
maxx = 150<br />
maxy = 150<br />
<br />
' maxnumofrooms is tied into RoomHolder<br />
' at 200 it bogs down and fails a lot try setting to 200 you'll see<br />
<br />
maxnumofrooms = 150<br />
<br />
RANDOMIZE TIMER<br />
<br />
DO<br />
'this times the generation<br />
T! = TIMER<br />
initdungeon<br />
generate (recurdepth)<br />
T2! = TIMER<br />
T3! = T2! - T!<br />
<br />
displaydungeon' I'm not adding this into the timer<br />
'seeing as it only displays the dungeon<br />
LOCATE 1, 21: COLOR 4: PRINT "Door color"<br />
LOCATE 2, 21: COLOR 8: PRINT "Wall color "<br />
LOCATE 3, 21: COLOR 15: PRINT "PermaWall color"<br />
LOCATE 6, 21: COLOR 15: PRINT "# of Rooms"; numofrooms<br />
LOCATE 9, 21: PRINT "One pixel ="<br />
LOCATE 10, 23: PRINT "one ascii tile"<br />
LOCATE 21, 1: PRINT "Time to make "; T3!; " Seconds."<br />
LOCATE 22, 1: PRINT "Press esc to quit"<br />
LOCATE 23, 1: PRINT "Any other key to generate again"<br />
SLEEP<br />
LOOP UNTIL INKEY$ = CHR$(27)<br />
END<br />
<br />
<br />
FUNCTION CheckBounds (x1, x2, y1, y2, direction)<br />
CheckBounds = 0<br />
'Makes sure room isn't out of bounds of Dungeon<br />
'Our dungeon is 1 to MaxX and 1 to MaxY<br />
<br />
IF (x1 - 1) < 1 THEN CheckBounds = false: EXIT FUNCTION<br />
IF (y1 - 1) < 1 THEN CheckBounds = false: EXIT FUNCTION<br />
IF (x2 + 1) > maxx THEN CheckBounds = false: EXIT FUNCTION<br />
IF (y2 + 1) > maxy THEN CheckBounds = false: EXIT FUNCTION<br />
<br />
FOR x = (x1 - 1) TO (x2 + 1)<br />
FOR y = (y1 - 1) TO (y2 + 1)<br />
IF DungeonLayer(x, y) = floor THEN CheckBounds = false: EXIT FUNCTION<br />
NEXT y<br />
NEXT x<br />
CheckBounds = true<br />
END FUNCTION<br />
<br />
FUNCTION CheckBoundsHall (x1, x2, y1, y2, direction)<br />
CheckBoundsHall = 0<br />
'Makes sure hall isn't out of bounds of Dungeon<br />
'Our dungeon is 1 to MaxX and 1 to MaxY<br />
<br />
IF (x1 - 1) < 1 THEN CheckBoundsHall = false: EXIT FUNCTION<br />
IF (y1 - 1) < 1 THEN CheckBoundsHall = false: EXIT FUNCTION<br />
IF (x2 + 1) > maxx THEN CheckBoundsHall = false: EXIT FUNCTION<br />
IF (y2 + 1) > maxy THEN CheckBoundsHall = false: EXIT FUNCTION<br />
<br />
IF direction = 0 OR direction = 2 THEN<br />
FOR x = x1 TO x2<br />
FOR y = (y1 - 1) TO (y2 + 1)<br />
IF DungeonLayer(x, y) = floor THEN CheckBoundsHall = false: EXIT FUNCTION<br />
NEXT y<br />
NEXT x<br />
END IF<br />
<br />
<br />
IF direction = 1 OR direction = 3 THEN<br />
FOR x = (x1 - 1) TO (x2 + 1)<br />
FOR y = y1 TO y2<br />
IF DungeonLayer(x, y) = floor THEN CheckBoundsHall = false: EXIT FUNCTION<br />
NEXT y<br />
NEXT x<br />
END IF<br />
<br />
CheckBoundsHall = true<br />
END FUNCTION<br />
<br />
SUB displaydungeon<br />
'this just draws the dungeon <br />
CLS<br />
SCREEN 13<br />
FOR x = 1 TO maxx<br />
FOR y = 1 TO maxy<br />
IF DungeonLayer(x, y) = wall THEN PSET (x, y), 8<br />
IF DungeonLayer(x, y) = Permwall THEN PSET (x, y), 15<br />
IF DungeonLayer(x, y) = door THEN PSET (x, y), 4<br />
IF DungeonLayer(x, y) = floor THEN PSET (x, y), 0<br />
NEXT y<br />
NEXT x<br />
END SUB<br />
<br />
SUB generate (recurdepth)<br />
<br />
'start with a random room<br />
x1 = Rand(2, (maxx - 1))<br />
y1 = Rand(2, (maxy - 1))<br />
x2 = x1 + Rand(2, 4)<br />
y2 = y1 + Rand(3, 7)<br />
<br />
<br />
<br />
direction = Rand(0, 3)<br />
IF CheckBounds(x1, x2, y1, y2, direction) = true THEN<br />
CALL makeroom(x1, x2, y1, y2, direction, recurdepth)<br />
END IF<br />
<br />
<br />
room = true<br />
<br />
DO<br />
'these are all to make sure we dont get into an infinite loop<br />
hallcount = 0<br />
hallcountmultp = 0<br />
roomcount = 0<br />
roomcountmultp = 0<br />
'ite mean iterations<br />
<br />
<br />
DO<br />
ite = ite + 1<br />
direction = Rand(0, 3)'the direction we want to draw towards<br />
'0 north(up) : 1 east(right) : 2 south(down) : 3 west(left)<br />
<br />
hall = false<br />
hallcount = hallcount + 1<br />
<br />
halllength = Rand(2, 7)'min and max length of halls<br />
<br />
'for all hall generation they are basically the same<br />
IF direction = 0 THEN<br />
'halls are only 1 square wide <br />
dy1 = Rand(y1, y2)<br />
dy2 = dy1<br />
'and as long as our halllength variable <br />
dx2 = x1 - 2<br />
dx1 = dx2 - halllength<br />
' we check to see if it's in bounds <br />
IF CheckBoundsHall(dx1, dx2, dy1, dy2, direction) = true THEN<br />
' if it is we actually put it there <br />
CALL makehall(dx1, dx2, dy1, dy2, direction)<br />
' draw a door if it hits a room (this can be change to randomly place any type <br />
' of feature)<br />
IF room = true THEN<br />
DungeonLayer(dx2 + 1, dy1) = door<br />
ELSE<br />
'make it a floor tile if it doesn't hit a room <br />
DungeonLayer(dx2 + 1, dy1) = floor<br />
END IF<br />
'these are saved to pass to the room creation section below <br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
'sets hall to true so we can move on <br />
hall = true<br />
END IF<br />
<br />
END IF<br />
IF direction = 1 THEN<br />
dy1 = y2 + 2<br />
dy2 = dy1 + halllength<br />
dx1 = Rand(x1, x2)<br />
dx2 = dx1<br />
IF CheckBoundsHall(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makehall(dx1, dx2, dy1, dy2, direction)<br />
IF room = true THEN<br />
DungeonLayer(dx1, dy1 - 1) = door<br />
ELSE<br />
DungeonLayer(dx1, dy1 - 1) = floor<br />
END IF<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
hall = true<br />
END IF<br />
<br />
END IF<br />
<br />
IF direction = 2 THEN<br />
dy1 = Rand(y1, y2)<br />
dy2 = dy1<br />
dx1 = x2 + 2<br />
dx2 = dx1 + halllength<br />
IF CheckBoundsHall(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makehall(dx1, dx2, dy1, dy2, direction)<br />
IF room = true THEN<br />
DungeonLayer(dx1 - 1, dy1) = door<br />
ELSE<br />
DungeonLayer(dx1 - 1, dy1) = floor<br />
END IF<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
hall = true<br />
END IF<br />
END IF<br />
<br />
IF direction = 3 THEN<br />
dy1 = (y1 - halllength) - 2<br />
dy2 = dy1 + halllength<br />
dx1 = Rand(x1, x2)<br />
dx2 = dx1<br />
IF CheckBoundsHall(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makehall(dx1, dx2, dy1, dy2, direction)<br />
IF room = true THEN<br />
DungeonLayer(dx2, dy2 + 1) = door<br />
ELSE<br />
DungeonLayer(dx2, dy2 + 1) = floor<br />
END IF<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
hall = true<br />
END IF<br />
END IF<br />
<br />
<br />
'if we cant make a hall after 10 tries then we....<br />
IF hallcount > 10 AND hall = false THEN<br />
'pick a random room from our list<br />
RDepth = Rand(1, recurdepth)<br />
'make old room the dimensions of our current room<br />
x1 = RoomHolder(RDepth, 0)<br />
x2 = RoomHolder(RDepth, 1)<br />
y1 = RoomHolder(RDepth, 2)<br />
y2 = RoomHolder(RDepth, 3)<br />
'reset hall count<br />
hallcount = 0<br />
'increment our hallmult counter and go again<br />
hallcountmultp = hallcountmultp + 1<br />
END IF<br />
<br />
'if we tried to make a hall more than 1000 times (hallcount * hallcountmultp)<br />
'and no hall was made then we failed<br />
IF hallcountmultp > 100 THEN<br />
PRINT "FAILED at "; recurdepth; " Rooms": SLEEP<br />
numofrooms = recurdepth: EXIT SUB<br />
END IF<br />
<br />
LOOP UNTIL hall = true<br />
<br />
<br />
<br />
'************ room creation below<br />
<br />
<br />
room = false<br />
<br />
<br />
IF direction = 0 THEN<br />
'holder is a dummy variable <br />
holder = Rand(3, 7)<br />
dx2 = x1 - 2<br />
dx1 = dx2 - Rand(2, 4)<br />
dy1 = Rand((y1 - holder), y2)<br />
dy2 = dy1 + holder<br />
'check to see if our room is in bounds <br />
IF CheckBounds(dx1, dx2, dy1, dy2, direction) = true THEN<br />
'if it is, set it in stone(so to speak) <br />
CALL makeroom(dx1, dx2, dy1, dy2, direction, recurdepth)<br />
'put a door here cause this is where our hall will begin<br />
DungeonLayer(x1 - 1, y1) = door<br />
'put our end room coordiantes into these variables so we can send them<br />
'to our hall creation section above<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
'set to true so we can end <br />
room = true<br />
END IF<br />
<br />
END IF<br />
<br />
IF direction = 1 THEN<br />
holder = Rand(2, 4)<br />
dx1 = Rand((x1 - holder), x2)<br />
dx2 = dx1 + holder<br />
dy1 = y2 + 2<br />
dy2 = dy1 + Rand(3, 7)<br />
IF CheckBounds(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makeroom(dx1, dx2, dy1, dy2, direction, recurdepth)<br />
DungeonLayer(x2, y2 + 1) = door<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
room = true<br />
END IF<br />
END IF<br />
<br />
IF direction = 2 THEN<br />
holder = Rand(3, 7)<br />
dx1 = x2 + 2<br />
dx2 = dx1 + Rand(2, 4)<br />
dy1 = Rand(y1 - holder, y2)<br />
dy2 = dy1 + holder<br />
IF CheckBounds(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makeroom(dx1, dx2, dy1, dy2, direction, recurdepth)<br />
DungeonLayer(x2 + 1, y2) = door<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
room = true<br />
END IF<br />
END IF<br />
<br />
IF direction = 3 THEN<br />
holder = Rand(2, 4)<br />
dx1 = Rand((x1 - holder), x2)<br />
dx2 = dx1 + holder<br />
dy2 = y1 - 2<br />
dy1 = dy2 - Rand(3, 7)<br />
IF CheckBounds(dx1, dx2, dy1, dy2, direction) = true THEN<br />
CALL makeroom(dx1, dx2, dy1, dy2, direction, recurdepth)<br />
DungeonLayer(x2, y1 - 1) = door<br />
x1 = dx1<br />
x2 = dx2<br />
y1 = dy1<br />
y2 = dy2<br />
room = true<br />
END IF<br />
END IF<br />
<br />
'do 4000 total loops,if it is more than 4000 then fail<br />
IF ite > 4000 THEN<br />
PRINT "FAILED at"; recurdepth; "Rooms": SLEEP<br />
numofrooms = recurdepth: EXIT SUB<br />
END IF<br />
LOOP UNTIL recurdepth = maxnumofrooms<br />
numofrooms = recurdepth<br />
END SUB<br />
<br />
SUB initdungeon<br />
'fill our dungeon with rock<br />
FOR x = 1 TO maxx<br />
FOR y = 1 TO maxy<br />
DungeonLayer(x, y) = wall<br />
NEXT y<br />
NEXT x<br />
' make the edges permawall <br />
FOR y = 1 TO maxy<br />
DungeonLayer(maxx, y) = Permwall<br />
DungeonLayer(1, y) = Permwall<br />
NEXT y<br />
FOR x = 1 TO maxx<br />
DungeonLayer(x, maxy) = Permwall<br />
DungeonLayer(x, 1) = Permwall<br />
NEXT x<br />
END SUB<br />
<br />
SUB makehall (x1, x2, y1, y2, direction)<br />
'draw our dungeon always from upper left to lower right <br />
FOR x = x1 TO x2<br />
FOR y = y1 TO y2<br />
DungeonLayer(x, y) = floor<br />
NEXT y<br />
NEXT x<br />
END SUB<br />
<br />
SUB makeroom (x1, x2, y1, y2, direction, recurdepth)<br />
'draw our dungeon always from upper left to lower right <br />
FOR x = x1 TO x2<br />
FOR y = y1 TO y2<br />
DungeonLayer(x, y) = floor<br />
NEXT y<br />
NEXT x<br />
recurdepth = recurdepth + 1<br />
' this holds our rooms so we can choose one at random if we get stuck<br />
' we never save halls or it would be a horrendous mess<br />
RoomHolder(recurdepth, 0) = x1<br />
RoomHolder(recurdepth, 1) = x2<br />
RoomHolder(recurdepth, 2) = y1<br />
RoomHolder(recurdepth, 3) = y2<br />
END SUB<br />
<br />
FUNCTION Rand (Lowest, Highest)<br />
DIM a AS INTEGER<br />
DIM b AS INTEGER<br />
DIM c AS INTEGER<br />
<br />
a = Lowest<br />
b = Highest<br />
IF a > b THEN<br />
c = a - b<br />
ELSEIF b > a THEN<br />
c = b - a<br />
ELSE<br />
Rand = a: EXIT FUNCTION<br />
END IF<br />
Rand = INT(RND(1) * (c + 1)) + a<br />
<br />
END FUNCTION<br />
<br />
</pre><br />
<br />
= Nest of Ants - Jakub Debski [jakub@mks.com.pl].txt =<br />
<br />
I was wondering how to create a nice looking nest for the ants,<br />
and here is my idea:<br />
<br />
Let's say, that we have some sticky dust. It goes through air<br />
and catch all the static objects. So, let's see, if we have<br />
one static object at the beginning, and a lot of randomly moving<br />
objects of the same type:<br />
<br />
dust: *<br />
move vector: -<br />
<br />
*-<br />
<br />
/ * -*<br />
*<br />
<br />
|<br />
*<br />
<br />
then these objects will catch the first one and group into larger<br />
one:<br />
<br />
**<br />
*<br />
*****<br />
* *<br />
* **<br />
*<br />
<br />
That's all. We have nice looking corridors with all the places<br />
reachabale. Algorithm is very simple and gives nice results:<br />
<br />
1. Allocate 2 dimensional array for 0,1 values of the nest size.<br />
2. In the centre add single object<br />
3. Create new sticky object on the ellipse which is around the nest,<br />
having centre in the centre of the nest<br />
4. Add random move vector to the object<br />
5. Move object a bit. If it crosses the border of our territory, then<br />
appears on the other side.<br />
6. Look around the object and if there is something to catch then stop. If<br />
size of the nest is enough, then stop, else go to 3.<br />
7. Goto 5<br />
<br />
My two advices are to add guard for moving object, f.e. for 1000 steps,<br />
because depending on vector it's possible, that object won't catch any<br />
other. The second advice it to add some "rooms" at the end of corridors (on<br />
cell, which has only one neighbour:<br />
<br />
piece of nest:<br />
<br />
*<br />
*****<br />
**<br />
<br />
+ - the cell with one neighbour, means end of corridor<br />
<br />
*<br />
****+<br />
**<br />
<br />
add there 3x3 room<br />
<br />
* +++<br />
***+++<br />
** +++<br />
<br />
source code:<br />
<br />
#define NEST_SIZE_X 80<br />
#define NEST_SIZE_Y 50<br />
<br />
int main(void)<br />
{<br />
init_graph(); // not neccecary, for draw_char(x,y,char)<br />
srand(get_ticks_count()); // for (rand())<br />
<br />
bool c[NEST_SIZE_X][NEST_SIZE_Y];<br />
int x,y;<br />
for (x=0;x<NEST_SIZE_X;x++)<br />
for (y=0;y<NEST_SIZE_Y;y++)<br />
{<br />
c[x][y]=0;<br />
draw_char(x,y,'#');<br />
}<br />
<br />
// in the centre we put one object<br />
c[NEST_SIZE_X/2][NEST_SIZE_Y/2]=1; // in the array<br />
draw_char(NEST_SIZE_X/2,NEST_SIZE_Y/2,'.'); // and on the screen for test<br />
myrefresh();<br />
<br />
float x1,y1; // position of object<br />
float k; // angle<br />
float dx, dy; // move vector<br />
int px, py;<br />
<br />
for (int object=0;object<NEST_SIZE_X*NEST_SIZE_Y/3;object++)<br />
{<br />
// degree<br />
k = (rand()%360)*3.1419532/180;<br />
// position on ellipse by degree<br />
x1 = NEST_SIZE_X/2+(NEST_SIZE_X/2)*sin(k);<br />
y1 = NEST_SIZE_Y/2+(NEST_SIZE_Y/2)*cos(k);<br />
// draw_char(x1,y1,'*');<br />
<br />
// object will move not too horizontal and not too vertival<br />
do {<br />
dx=rand()%100;<br />
dy=rand()%100;<br />
} while ((abs(dx)<10 && abs(dy)<10));<br />
dx-=50;<br />
dy-=50;<br />
dx/=100; // by little steps<br />
dy/=100; // by little steps<br />
<br />
int counter=0;<br />
while (1)<br />
{<br />
// didn't catch anything after 1000 steps (just to avoid infinite<br />
loops)<br />
if (counter++>1000)<br />
{<br />
object--;<br />
break;<br />
}<br />
// move object by small step<br />
x1+=dx;<br />
y1+=dy;<br />
<br />
// change float to int<br />
<br />
px=x1;<br />
py=y1;<br />
<br />
// go through the border to the other side<br />
<br />
if (px<0)<br />
{<br />
px=NEST_SIZE_X-1;<br />
x1=px;<br />
}<br />
if (px>NEST_SIZE_X-1)<br />
{<br />
px=0;<br />
x1=px;<br />
}<br />
if (py<0)<br />
{<br />
py=NEST_SIZE_Y-1;<br />
y1=py;<br />
}<br />
if (py>NEST_SIZE_Y-1)<br />
{<br />
py=0;<br />
y1=py;<br />
}<br />
<br />
// if object has something to catch, then catch it<br />
<br />
if ((px>0 && c[px-1][py]==1) ||<br />
(py>0 && c[px][py-1]==1) ||<br />
(px<NEST_SIZE_X-1 && c[px+1][py]==1) ||<br />
(py<NEST_SIZE_Y-1 && c[px][py+1]==1))<br />
{<br />
c[px][py]=1;<br />
draw_char(px,py,'.');<br />
myrefresh();<br />
break; // go to creation of new object<br />
}<br />
} // end of while(1)<br />
} // end of for<br />
<br />
// add halls at the end of corridors<br />
int neighbours;<br />
for (x=1;x<NEST_SIZE_X-1;x++)<br />
for (y=1;y<NEST_SIZE_Y-1;y++)<br />
{<br />
if ((x>NEST_SIZE_X/2-10 && x<NEST_SIZE_X/2+10 && y>NEST_SIZE_Y/2-5 &&<br />
y<NEST_SIZE_Y/2+5) || c[x][y]==0)<br />
continue;<br />
<br />
neighbours=0;<br />
if (c[x-1][y-1]!=0)<br />
neighbours++;<br />
if (c[x][y-1]!=0)<br />
neighbours++;<br />
if (c[x+1][y-1]!=0)<br />
neighbours++;<br />
if (c[x-1][y]!=0)<br />
neighbours++;<br />
if (c[x+1][y]!=0)<br />
neighbours++;<br />
if (c[x-1][y+1]!=0)<br />
neighbours++;<br />
if (c[x][y+1]!=0)<br />
neighbours++;<br />
if (c[x-1][y+1]!=0)<br />
neighbours++;<br />
<br />
if (neighbours==1)<br />
{<br />
for (px=-1;px<=1;px++)<br />
for (py=-1;py<=1;py++)<br />
{<br />
c[x+px][y+py]=1;<br />
draw_char(x+px,y+py,',');<br />
myrefresh();<br />
}<br />
}<br />
}<br />
<br />
return 0;<br />
<br />
}<br />
<br />
some samples<br />
<br />
<pre><br />
80x25<br />
#####################............................###############.###..##########<br />
###############,,,###.#########.#.######.##..###################.###.###########<br />
###############,,,......#######...######.....########.#####...#......##.########<br />
###############,,,###.#..#.##.##..##,,,#..#.######,,,.#####.#...###.....########<br />
################..###......#...##..#,,,#....######,,,.#####.##.##......#########<br />
#####################.###......###.#,,,..##,,,.###,,,##.###.......###.....######<br />
########################..#,,,.........#.#.,,,..####.....##.####.#.######.######<br />
#########################.#,,,########.....,,,..####..####.....#...#############<br />
#####################,,,###,,,...#######.####.#.#.##.#####.###.###..############<br />
#####################,,,########.#######.####...#.#....###.####,,,##############<br />
#################,,,.,,,#.#.#.##..####.......................##,,,##############<br />
#################,,,...........#.....###.##.##.#.#####..##..###,,,#####.########<br />
#################,,,##.#,,,###...##...........##....#########..#..#.....########<br />
##############,,,#######,,,######.#..###.###.#####...###.#.##.##....#.#..#######<br />
##############,,,,,,####,,,###.......##...##.####...........#....#.#############<br />
##############,,,,,,#######...#####.####..######...#.###.##......####....#######<br />
############..#.#,,,#######............##...#####.##...#..#..##...###.#.########<br />
###########.#...##.###....##...##...##,,,.#..########.###..####..........#######<br />
#####,,,.##...#...............#.......,,,.##.########...##..####.##....#########<br />
#####,,,....#...###.#..#.#..#.#,,,.#.#,,,############..###.....#.##.,,,#########<br />
#####,,,#,,,..###...####.######,,,##.###############..####.#....####,,,#########<br />
#########,,,.####...####..#####,,,##.###############..#######...####,,,#########<br />
#########,,,..##...#.....#######,,,#.##############...########..################<br />
##########..#.##.#..####..######,,,....############...########.#################<br />
##########.#######.#############,,,..#.#######################.#################<br />
<br />
80x40<br />
<br />
##########################.......................#....##......##################<br />
##############,,,#####,,,#....,,,.###...####.######...###.##..##################<br />
##############,,,.....,,,###.#,,,.###..#####.#..###.#####.######################<br />
##############,,,....#,,,#####,,,.####..####.....##..####.####.#################<br />
#################,,,.####,,,.####.##...#####.#.####.##.##.##...#################<br />
#################,,,.####,,,.#.##.#.##.###...#.###..#..##....##.....############<br />
#################,,,.####,,,......#..#..##..#..###.#..###.#####.,,,#############<br />
################.......#########.....#..##..#..##..#..###.#.....,,,#############<br />
################.###.#.########...##.#.###.##.##..........#....#,,,#############<br />
################.##....##,,,##,,,###.#.###....##..##........####..##############<br />
###############..####..##,,,##,,,##.....##.###.....##.##.#.###.#.....###########<br />
##############....####.##,,,.#,,,##...#.##.##..##,,,#..#.........#...###########<br />
##############.......#.###...##..###.##....##...#,,,#.###.#.#.#####..###########<br />
#################......####.####.####,,,.#.#..#.#,,,#####.....#,,,##.###########<br />
##################.###.#.##.####.###.,,,.#....#.......###.,,,..,,,##############<br />
###################......##.#.##..#..,,,..##.#####..#.###.,,,##,,,##############<br />
############........####................#.########.##..###,,,###################<br />
##########.#.#####.####....##.#.##.##.#...########..###,,,######################<br />
####,,,............##,,,..##########.##..##.##########.,,,######################<br />
####,,,...#####...###,,,.#####.#####....#.......#####..,,,######################<br />
####,,,.#.###...#####,,,.####...#####.#...##.##.....#.,,,#######################<br />
######.######..########.######...######....########...,,,#..####################<br />
############..#########.######.#..####...#.####.#####.,,,#..####################<br />
#######################..###,,,#....#...####.##.#######.##.,,,##################<br />
########################.###,,,.##..............#.#####.#..,,,#..###############<br />
##################.......###,,,....#.#..####.##...#.......#,,,...###############<br />
##################.,,,....##.####.##....###...##......##..#.#.....###.,,,#######<br />
##############,,,##,,,.#..........#...#.###.#.##.####..##.....,,,.....,,,#######<br />
##############,,,..,,,#..#.#.####.#.#.#.###.#..#...##..##.#.#.,,,.#...,,,#######<br />
#############.,,,#.####.####.##...#####..##..#.##....###,,,.#.,,,###############<br />
############.............#...##....##....###..####.#.###,,,.#....###############<br />
####,,,.#.######.#########..#####.###.##..##...###..####,,,..###################<br />
####,,,...#...######.#.....#####..###.#...##.#####....##########################<br />
,,,.,,,#....#.####.....##...###...##...##.##...###.##..#########################<br />
,,,.#...............##.###..###.,,,#.####.##....##...#..########################<br />
,,,....##.##..#.#.#....##..###..,,,######.##.##.####..##########################<br />
#########.#,,,..#....#.#...###.#,,,####...##..#####,,,##########################<br />
#########.#,,,##......##..####..#######..###.#####.,,,##########################<br />
#########.#,,,#..#.##......#############.###.####..,,,##########################<br />
########..#####..#.#####..##############.###........############################<br />
<br />
80x50<br />
<br />
######################.##..#.....#........######################################<br />
#####################.......#.,,,##.#.##########################################<br />
########################..#.#.,,,##...##########################################<br />
###########################...,,,....######################,,,##################<br />
##########################..#.#####...#####################,,,.#################<br />
############################....##.....#######.############,,,##...#############<br />
#####################,,,####.#...#...######,,,.#############...#..##############<br />
#####################,,,######......#,,,###,,,.############..#.#.##..###########<br />
#####################,,,###,,,.#.....,,,###,,,..###########..#.#......##########<br />
################,,,####...#,,,###...#,,,...###.########,,,..##....##############<br />
################,,,######..,,,#####.###...####..#######,,,.......#.#############<br />
################,,,#.,,,#..##.......##..###.##.########,,,#.######.,,,#####.####<br />
##################...,,,..#####,,,..##.##....#..###,,,#####........,,,####..####<br />
###################..,,,..#####,,,........###...###,,,######.,,,##.,,,#####.####<br />
###################.......#####,,,...#.#,,,##.#,,,#,,,######.,,,###########...##<br />
####################.####.....##.###.#..,,,##..,,,...######..,,,.##.#######..###<br />
###########,,,#####,,,,,,,,,#.##........,,,#..#,,,#..##...##..##....######..####<br />
#########..,,,##.##,,,,,,,,,#...######.,,,###.,,,###.#.##.##.###.##,,,####.##...<br />
#########..,,,.....,,,,,,,,,....#####..,,,##..,,,.##...##..#.#.....,,,####.....#<br />
########.#....#.#.....#.####,,,.#####..,,,###.,,,.#...####.#......#,,,#.....#.##<br />
######......#.....###.#.###.,,,...###..#...##..##..#.#.,,,...##.#.......#.###..#<br />
######..#########.##..#..#..,,,#..##......###..##.##.#.,,,..###...#######..#####<br />
#######.###..####........##.###..####.#.#..##..##.##.#.,,,.##.###..........##,,,<br />
######,,,#........##..#...#.###...#.#####.###.....#..#.##.......#####,,,.#...,,,<br />
######,,,####...#.###..#..#...........#...#....##.##...#..#.##.######,,,.####,,,<br />
######,,,..#..#######.###.....#####..................#...############,,,#,,,###.<br />
##########...##############.#####.#.###.#.....##..##..#..#####.#....#####,,,.##.<br />
###########.########..#.....#####.#..##.#.##.####...#.####.........######,,,....<br />
##########..######......####.........##.####....###.#.......#...##.###.#...##.#.<br />
###########.######.##..#####...#,,,.#...####.##....##.##.##...#..#.......#.##...<br />
##########..#####,,,...####...##,,,.##..###..###.#.#####.###....####.#.######..#<br />
##########.######,,,#..#####..##,,,###...##.###.....####..###.#.....##..####,,,#<br />
#################,,,...#......###.###...########.##..####..#...########.####,,,#<br />
################......##.##.,,,##..........#####.###..###..##....######...##,,,#<br />
################..###.#,,,##,,,##.##.#....######..########.##.##.#######.#######<br />
#################.....#,,,##,,,...####.#...#####.##.######.##,,,...#############<br />
#################.###.#,,,###..####.....#.#####......#####...,,,.#.#############<br />
######################,,,#..#..###..#..##..###..#.##########.,,,.#...###########<br />
######################,,,.....###..###.##.#######.##################..##########<br />
######################,,,##..####..###.##.,,,####.......##.##..#################<br />
#######################.....####..#.....#.,,,####.##..#.......##################<br />
######################..#.#.#########.#.##,,,####...#..#.#.#..,,,###############<br />
###########################.#.#######.#..########.,,,###.####.,,,..#############<br />
####################,,,###.......###..##..#######.,,,###..####,,,...############<br />
####################,,,###..#,,,....#.#######,,,#.,,,###...####....#############<br />
####################,,,.....#,,,##.....######,,,....######.##...#..#############<br />
#####################.##,,,.#,,,....##....###,,,##....####........##############<br />
########################,,,.,,,#.#.####....####.....#..#...##..#..##############<br />
########################,,,.,,,....####..#.####.#.........##..#....#############<br />
############################,,,.....#......######..##.....####..################<br />
</pre><br />
<br />
regards<br />
Jakub<br />
<br />
= Passable Cave Building Algorithm - Josh Tippets [vertexnormal@email.com].txt =<br />
<br />
Here is an algorithm I have used to generate a passable cave:<br />
<br />
First of all, I need a couple of support functions, which I call<br />
Blobbers. Basically, these functions use various methods to create<br />
"blobs" within the grid of the level array.<br />
The first Blobber I call ProbBlob, which has the prototype:<br />
<br />
void ProbBlob(int X, int Y, int Reps, int Value, float Up, float Down,<br />
float Left, float Right);<br />
<br />
(X,Y)=Location within map grid at which to start.<br />
Reps=Number of times to iterate. Determines the size of the blob.<br />
Value=Grid-type value to fill in the blob with. FLOOR_TYPE,<br />
WALL_TYPE, etc.<br />
Up,Down,Left,Right=Values in the range [0,1], which all must add up<br />
to 1.0<br />
These values are used to setup a probability table that determines<br />
which<br />
direction the blobber will move next.<br />
<br />
By giving ProbBlob the values of 0.25, 0.25, 0.25, 0.25, I generate<br />
a blob with an equal probability of moving in any given direction. By<br />
playing with these numbers, I can cause the blob to trend in a general<br />
direction.<br />
ProbBlob basically iterates through a loop Reps number of times,<br />
each time writing Value to the current location. After writing Value,<br />
I use the probability table generated from Up,Down,Left and Right to<br />
determine a direction to move. I move one cell in the chosen<br />
direction, write Value, and choose again until the loop terminates.<br />
Reps roughly determines the size of the blob. I say roughly, because<br />
a lot of the repetitions may actually re-visit a cell already blobbed,<br />
in effect being wasted, but you get the idea.<br />
<br />
The second helper function I need is called BlobToward:<br />
<br />
void BlobToward(int X1, int Y1, int X2, int Y2, float *Up, float<br />
*Down,<br />
float *Left, float *Right);<br />
<br />
This function doesn't actually draw a blob. Rather, it uses the<br />
given start and end coordinates to generate the directional values Up,<br />
Down, Left, and Right, which are later fed to the ProbBlob function.<br />
This function finds the difference between X1 and X2, and the<br />
difference between Y1 and Y2, and uses the results to compute<br />
probabilities which will cause the blob to progress generally from<br />
(X1,Y1) toward (X2,Y2). This is good for drawing random cave tunnels;<br />
you can specify a start and an end, generate the probabilities, then<br />
feed the numbers to the blobber.<br />
<br />
Another possible blobber function is one which functions almost<br />
exactly like ProbBlob, but which doesn't exit until some location is<br />
reached. If done this way, it is sometimes best to continually<br />
re-calculate Up, Down, Left, and Right, in the event that the blob<br />
runs past the destination position without actually hitting it. If the<br />
probabilities are not recomputed, the blob will tend to keep going<br />
past the destination, and might never actually hit it. Re-computing<br />
the probs routinely will ensure that the blob is always directed<br />
toward the destination.<br />
<br />
Given these functions and a grid filled with WALL_TYPE, I am given a<br />
number of options. One I commonly use is to call ProbBlob with<br />
(0.25,0.25,0.25,0.25) and generate a large blob in the very center of<br />
the map. Then I loop an arbitrary number of times, each time randomly<br />
selecting (X1,Y1) and (X2,Y2) coordinates, which I feed to BlobToward.<br />
Taking the results of BlobToward, I call ProbBlob again with the<br />
generated probabilities, using randomly determined Reps. By passing<br />
FLOOR_TYPE to ProbBlob, the generated blob is written as a floor type<br />
of cell.<br />
The result of this algorithm tends to be a large central cave<br />
complex with many arms radiating outward and terminating in dead ends.<br />
Alternately, you could partition the level grid into maybe nine<br />
blocks, 3x3, and use ProbBlob to generate a regular blob within each<br />
block. BlobToward could then be used to connect the various regular<br />
blobs into something resembling an interconnected series of rooms.<br />
I'm sure there are hundreds of ways these methods could be used, in<br />
conjunction with other ideas. This might give you a place to start.<br />
Good luck, and keep us all posted on how it goes.<br />
<br />
Josh Tippetts<br />
vertexnor...@email.com<br />
OGRESlash- www.me.icobb.com/rpg/vertexnormal/</div>Stuhttp://roguebasin.com/index.php?title=User_talk:Duerig&diff=12820User talk:Duerig2008-05-01T18:11:42Z<p>Stu: </p>
<hr />
<div>I'd rather see articles automatically included in this site requiring explicit removal.<br />
Some people dissappear off the net, if we cant track them down they cant agree to add their content.<br />
<br />
I'd rather remove it when asked to than loose it forever...<br />
[[User:Stu|Stu]] 20:11, 1 May 2008 (CEST)</div>Stuhttp://roguebasin.com/index.php?title=Cracks_and_Crevices&diff=12783Cracks and Crevices2008-04-25T16:07:18Z<p>Stu: update external links</p>
<hr />
<div>{{game-alpha| name = Cracks and Crevices<br />
|developer = [[Stu George]]<br />
|theme = Fantasy<br />
|influences = Underdark<br />
|released = 24.02.07<br />
|updated = 18.02.08<br />
|licensing = GPL<br />
|language = C<br />
|platforms = Windows, Linux<br />
|interface = [[Graphical ascii tiles]], [[Keyboard]]<br />
|length = short<br />
|site = http://bloodycactus.com:3085/projects/show/sdlrl<br />
}}<br />
<br />
''Cracks and Crevices'' is a graphical ascii roguelike game written by Stu, using [[SDL]]. It takes ideas from my other roguelikes like [[UnderDark]] and [[SRL]].<br />
<br />
The originaly idea was to keep things simple in order to create an actual working game instead of a huge mountain of ideas that never get implemented or see the light of day.<br />
<br />
Its designed to not be so hardcore as [[NetHack]] and [[Crawl]] but not be as easy as [[Larn]]. It does provide help for the beginner and cue's when the game starts.<br />
<br />
== Story ==<br />
''Cracks and Crevices'' is about life in the small village of ''Danforths Outcrop'', hewn into the rock at an opening to a large crevice. The game starts with you, a young person of the village on the verge of your adulthood test, which is to survive two days in the labyrinth of the crevice before you will be allowed back into town. Only the strong survive to increase the strength of the village, and if you survive you will be allowed back into town, there you can explore or re-enter the labyrinth or take up some quests offered by the town clerk.<br />
<br />
<br />
== Features ==<br />
* Semi realtime gameplay<br />
* Facing FOV<br />
* Stackable spell / weapon system<br />
* Magic System based on MP that regerates over time or by wielding/wearing mage type items<br />
* Weapons, Potions, Spell books, mushrooms, rings, armor, shields, etc<br />
* No preset classes or skill systems. Development of @'s class is up to the player.<br />
* Customer key configuration<br />
* Message Logs<br />
* Character dumps<br />
* Save / Load<br />
* Permadeath<br />
* Working towns (shops, inns, banks, etc)<br />
* Special NPC's<br />
<br />
<br />
== Time and Modes ==<br />
''Cracks and Crevices'' uses semi-realtime to set the game play. There is an Easy / Medium / Hard mode of play.<br />
<br />
=== Easy ===<br />
* Easy mode gives you 3 seconds to make a move before you loose your current turn and all the monsters get to move. <br />
* More Money to start the game with<br />
* Circular FOV<br />
<br />
=== Medium ===<br />
* 1.5 seconds per move<br />
* Facing directional cone FOV<br />
<br />
=== Hard ===<br />
* 1 second per move<br />
* Facing directional cone FOV<br />
<br />
== Class System ==<br />
There is no preset class system or skill system in the game. It is left up to the player to choose the direction of development, if they want to focus on pure melee fighter type or mage type or something in between. There is no restriction on wielding swords and casting spells at the same time. There are pros and cons to each and heavy armor may not be the best choice for a spellcaster...<br />
<br />
<br />
== Current Status ==<br />
0.4 has many changes<br />
* BIG Rewrote mainloop code (fixed some subtle round bugs).<br />
* Rounds now work properly for all NPC's and the PC<br />
* Timers work correctly<br />
* Rewrote attribute code<br />
* Gold drops on floor now<br />
* Monsters die correctly!<br />
* Initial quest time shortened to make it more attainable.<br />
* Messages are now counted and displayed as Msg (x) if repeated to stop cluttering the display.<br />
* Remove character dump when starting a new game<br />
* Dont save character dump when saving game<br />
* Stopped monsters and drops from appearing in the message window (doh!)<br />
* Stopped saving from doing an explicit call to exit instead of falling through the game loop like quit does, which revealed some mem leaks that were plugged.<br />
* Gold drops were dropping underneath the player not monster!<br />
* Spells in spellbooks<br />
* Start spell when buying first spellbook<br />
* Attack/Target Cycling/Cast Spell commands<br />
* Implemented 99% of the spell attributes<br />
* Casting spells now works! (no whizzbang animation. it just works)<br />
* auto pickup working<br />
* Pickup key words<br />
* Fixed : When selling item, unequip it automatically<br />
* Added circular fov for easy games<br />
* Bumpbed facing fov for medium + hard games<br />
* Added leveling up<br />
* Added ctrl-c as break all from program<br />
* Added ESC as means to close out most all dialogues<br />
* Made some defaults sane (no mixing cursor + keypad)<br />
<br />
==External Links==<br />
* [http://redmine.bloodycactus.com:3085/projects/list_files/sdlrl Downloads]<br />
* [http://redmine.bloodycactus.com:3085/projects/sdlrl/issues Buglist]</div>Stu