 |
|
 |
|
Related Topics:
| 7DRL: Invader - Well, I've talked myself into a game for the 7DRL :-) Invader will be a sci-fi RL where the player is the planet's only hope of stopping a dread alien invasion ship. The base of will be their docked ship. ..
7DRL: TBA! :P - I'm going to throw my hat into the 7drl arena by taking on a project I've wanted to do for ages. I think it will get me past the mental block of actually getting started. My concept is based around the remains of a post world with gang..
7DRL : Commander - It is 13.40 in my time zone (GMT +100). Time to start my 7DRL project: I will do it in Free Pascal. Plans are quite big so there is real danger of failure. Good luck to all of 7DRL contest. -- Michal Bielinski
7DRL : Valley of Ge-Hinnom - Info : @ goes chase to Moloch, java, using my library, so if I fail at least I can post an updated library. T.
7DRL - Deserted... - Okay, Here's to learning new things :) I am beginning work on my 7DRL, Deserted. Everybody loves waking up on a desert island, right? C++, dev-cpp, minGW... no curses.. I'm just beginning to dip into that. So, everyone get ready for a
|
|
|
Next: YAVP: Hill Dwarf Priest
|
| Author |
Message |
External

Since: Dec 08, 2007 Posts: 4
|
(Msg. 16) Posted: Mon Dec 31, 2007 10:45 am
Post subject: Re: We are doomed.. [Login to view extended thread Info.] Archived from groups: rec>games>roguelike>development (more info?)
|
|
|
-> I cannot wait to try it. JADE is one of these mega-hyper-roguelike
projects,
> which usually never get anywhere, but given TB's track record.. maybe he
> will actually do it..
I'm reasonably sure he will. His dev style seems a lot like mine,
in that he works on something heavily privately and then releases
it only when it satisfies him.
> ADOM is already the most popular roguelike,
NetHack might contest that; Crawl is rising, too.
> Here is a copy of the JADE feature list, just to remind you:
> --------
> A complete world with continents, weather patterns, settlements, dungeons
> and strange places, either randomly generated at the start of each game or
> chosen from a number of preselected worlds
>
> [...] together with a guild system
> providing special benefits for guild membership.
>
> Complete freedom in what you want to do (e.g. explore dungeons, work as a
> caravan guardian, build your own castle, conquer cities, lead a life as a
> simple farmer, become a shopkeeper or whatever).
>
> Hidden plots.
>
> Monster inventories.
>
> The ability to transform into another being.
>
> A detailed system for morale values (on an Order...Balance...Chaos scale)
> and ethics (on a Good...Uncaring...Evil scale).
>
> Compressed save files.
There's a _lot_ of symmetry here with my planned design goals
for the "full" Return of the Forsaken version of Incursion, which I
will admit I find a bit intimidating. Still, I think this kind of
feature-
list has been fairly standard for those who aspire to "next-gen"
roguelikes for a while now, /especially/ since Dwarf Fortress has
shown that the whole random world gen thing is actually viable
in real life.
I wanted to post about the feature list symmetry, because it
seems that Incursion and ADOM are going in very similar
directions, and Incursion is a much younger game and will
take longer to "get there", so I'm going to get "scooped" and
end up looking like I'm ripping off ADOM.
Ah, well, Thomas has always been one of the great innovaters
in the RL community, and I wish him all the best in getting JADE
out to all his fans. I tend to believe it will have been worth the
wait!
> I guess for the rest of us that means we will have to take our projects and
> hide in shame
I will admit to feeling very intimidated by this, initially, but on
consideration that isn't really either a rational or a mature
response. It does look like newer games may get beaten
in the feature race by JADE, but really what does that matter
in the long run? Most players play several different games,
anyway.
I think there's definitely room for more than one "next-gen" RL;
in addition to my own ambitions, Dwarf Fortress is very clearly
moving in the same "sim-world freedom" direction, and I suspect
it is more mature in the world-sim area than ADOM 0.1 will be.
NetHack, Angband and Omega all co-existed in their time
without impinging on each other, after all -- I can't imagine that
the current generation will be any different.
> If TB really manages to make this a reality, he will move the roguelike
> genre to a whole new level.
If JADE really does everything listed above, then it surely
deserves a great deal of credit for blazing ahead on the trail
the rest of us ('us' being conventional fantasy RL devs) will
follow!
Definitely curious,
-- Julian Mensch >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Dec 31, 2007 Posts: 18
|
(Msg. 17) Posted: Mon Dec 31, 2007 8:02 pm
Post subject: Re: Debugging games [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
On 2007-12-31 17:18:42, Ray Dillinger <bear RemoveThis @sonic.net> wrote:
> Jeff Lait wrote:
>
> > On an unrelated note, I'm having a lot of fun watching POWDER in
> > stress test mode. Last night I found another rare crash bug after
> > 470,000 moves. Current run is up to 443,500 moves without crashing...
>
> On a related note, I thought your unrelated note was
> interesting enough to start its own thread.
>
> Do I understand correctly that you have a robot tester,
> or "borg", that you can run in your game for the express
> purpose of finding bugs?
>
> Cool!
>
> Now I'm imagining the feature set one wants for such a
> thing: Like starting at a random level with a random
> character after each crash (with some fraction exercising
> the initial character-generation code), etc.
>
> Do you proceed by feeding random characters into the
> keyboard buffer, or have you coded an AI in a serious
> attempt to win? Or some combination of the two, like
> "every fifth move random" or something?
>
> I made a standard debugging output where debug "trace"
> statements write sentences about what the game is doing.
> If the game crashes I can pop up TrDebug.txt and see
> what it was doing right before it crashed. That has
> helped a lot.
>
> What do other people do?
>
> Bear
>
I assert return values in functions prior to returning them. I have those
messages either thrown into the player message log, or stop the game execution
and display on screen.
I have caught several crashes this way.
Finding the bugs that don't crash the game are harder to pinpoint with this
method, so
I test by implememting a feature and playing the game for several minutes before
and after each coding session. This allows me to observe game behavior that
isn't what I want, so I can make changes.
Adding this automated testing sounds like a great idea, I'm adding it to my todo
list for development tools.
--
Elsairon >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Oct 18, 2007 Posts: 161
|
(Msg. 18) Posted: Mon Dec 31, 2007 8:02 pm
Post subject: Re: Debugging games [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
On 2007-12-31 17:18:42, Ray Dillinger <bear.TakeThisOut@sonic.net> wrote:
> Jeff Lait wrote:
>
> > On an unrelated note, I'm having a lot of fun watching POWDER in
> > stress test mode. Last night I found another rare crash bug after
> > 470,000 moves. Current run is up to 443,500 moves without crashing...
>
> On a related note, I thought your unrelated note was
> interesting enough to start its own thread.
>
> Do I understand correctly that you have a robot tester,
> or "borg", that you can run in your game for the express
> purpose of finding bugs?
>
> Cool!
>
> Now I'm imagining the feature set one wants for such a
> thing: Like starting at a random level with a random
> character after each crash (with some fraction exercising
> the initial character-generation code), etc.
>
> Do you proceed by feeding random characters into the
> keyboard buffer, or have you coded an AI in a serious
> attempt to win? Or some combination of the two, like
> "every fifth move random" or something?
>
> I made a standard debugging output where debug "trace"
> statements write sentences about what the game is doing.
> If the game crashes I can pop up TrDebug.txt and see
> what it was doing right before it crashed. That has
> helped a lot.
>
> What do other people do?
Mostly programming-by-contract so far, although if I could figure out how to
transform dataflow errors into compiler errors that would be next. In C++,
static assertions in conjunction with integral-type template parameters have
been slightly useful in this regard. (Unfortunately, the language standard is
ahead of the compilers.)
assert() is nice, but the fact the standard requires it to abort() is slightly
unnerving. I have a suite of auditing and invariant-testing macros for projects
that don't have to be purely standard C/C++ . (E.g., exit with error message in
debug mode but silently do the safe thing in release mode, and so on.) >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Jan 02, 2008 Posts: 1
|
(Msg. 19) Posted: Wed Jan 02, 2008 1:07 pm
Post subject: Random worldgen (Re: We are doomed..) [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
On Dec 31 2007, 1:45 pm, Julian Mensch <jmen... RemoveThis @shaw.ca> wrote:
> Still, I think this kind of feature-
> list has been fairly standard for those who aspire to "next-gen"
> roguelikes for a while now, /especially/ since Dwarf Fortress has
> shown that the whole random world gen thing is actually viable
> in real life.
I want to pick on one thing you've said here - although I find DF
really fascinating as a concept, when Fortress mode went from a few
spots with a guaranteed feature set (river/chasm/lava/pits) to full
world place-anywhere generation, you lost a *lot* of plot and high-
level game shape. Many DF players are happy about that, but some
aren't, and I'd submit that a wider audience would be less happy about
it. I suspect the equivalent in a current-gen roguelike would be being
given the choice of one a dozen dungeons at game start - some of which
go all the way down to the big baddy, and others of which are only
three levels deep and have some interesting terrain features but not
much else, or have as their "first level" the equivalent of a normal
15th-or-so level.
I've actually put some of my random-world generation ideas on hold
because of how poorly I thought DF worked out; some things that are
hardwired or carefully parameterized in standard roguelikes are
considerably weaker in DF, but making them better automatically
appears to be beyond the edges of academic research.
Tom >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Dec 27, 2007 Posts: 4
|
(Msg. 20) Posted: Wed Jan 02, 2008 1:59 pm
Post subject: Re: Random worldgen (Re: We are doomed..) [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
> I've actually put some of my random-world generation ideas on hold
> because of how poorly I thought DF worked out; some things that are
> hardwired or carefully parameterized in standard roguelikes are
> considerably weaker in DF, but making them better automatically
> appears to be beyond the edges of academic research.
>
The dev of DF said that playability would regress with z-levels being
introduced as well as choosing your site to the utmost. So, I agree
that it did poorly work out, but we are clearly seeing a stepping
stone to eventual regain of the playability. >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Apr 06, 2005 Posts: 1031
|
(Msg. 21) Posted: Wed Jan 02, 2008 5:13 pm
Post subject: Re: We are doomed.. [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
Quoting copx <copx.TakeThisOut@gazeta.pl>:
>ADOM is already the most popular roguelike,
It is? I thought it was gradually rotting away from lack of maintenance.
>Complete freedom in what you want to do (e.g. explore dungeons, work as a
>caravan guardian, build your own castle, conquer cities, lead a life as a
>simple farmer, become a shopkeeper or whatever).
I am often deeply suspicious of this kind of thing. It's better to do one
thing well by thinking about the mechanics and challenges of that. You
probably can do an interesting game about being a simple farmer, but you'd
have to do a lot of stuff specific to that. Being a simple farmer in a
game where you get to slot in and replace one cog in a vast simulationist
economy - probably not going to work.
>Monster inventories.
>The ability to transform into another being.
Amazing. What will this roguelike developers think of next?
--
David Damerell <damerell.TakeThisOut@chiark.greenend.org.uk> flcl?
Today is First Potmos, January. >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Feb 19, 2005 Posts: 1090
|
(Msg. 22) Posted: Sun Jan 06, 2008 12:09 am
Post subject: Re: We are doomed.. [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
copx wrote:
> Thomas Biskup seems to be serious about finally releasing JADE in 2008 (see
> www.adom.de).
>
> I cannot wait to try it. JADE is one of these mega-hyper-roguelike projects,
> which usually never get anywhere, but given TB's track record.. maybe he
> will actually do it..
>
> ADOM is already the most popular roguelike, and JADE is supposed to be at
> least a league above that, with a massive, living world and all that..
>
> I guess for the rest of us that means we will have to take our projects and
> hide in shame
>
> Here is a copy of the JADE feature list, just to remind you:
> --------
Will it have better graphics than ADOM? Say, graphics that are as good
as Angband's? As in actual graphics?
--
Peter Knutsen
sagatafl.org >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Dec 03, 2007 Posts: 41
|
(Msg. 23) Posted: Tue Jan 08, 2008 1:27 pm
Post subject: Re: We are doomed.. [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
On Jan 8, 11:27 am, Rachel Elizabeth Dillon <rac....TakeThisOut@akrasiac.org>
wrote:
> On 2008-01-08, Gerry Quinn <ger....TakeThisOut@indigo.ie> wrote:
>
> > In article <wAB*rg...@news.chiark.greenend.org.uk>,
> > damer....TakeThisOut@chiark.greenend.org.uk says...
> >> Quoting copx <c....TakeThisOut@gazeta.pl>:
> >> >ADOM is already the most popular roguelike,
SNIP
>
> > I think the guy's attitude is right. Finish a project, and go onto the
> > next. I find bizarre the attitude some people have that a roguelike is
> > 'alive' before it is finished, then 'dead' from the moment it's done.
>
> I'd agree with that. I'm told ADOM has some major crash bugs and, as a
> player, hearing that combined with "the developer hasn't touched it in
> N years" makes me more likely to check out a different game. But I think
> a game is dead when no one is playing it, not when no one is changing it.
For me, the key is letting players (specially power-users) add content
to the game; may be thatīs the only way to go if the game is to suceed
over time without being developed. A game may live through a community
of scenario developers or modders.
>
> -r.
--
Slash
http://slashie.net >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Nov 06, 2006 Posts: 838
|
(Msg. 24) Posted: Tue Jan 08, 2008 3:49 pm
Post subject: Re: We are doomed.. [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
In article <fl7984$m9q$1@inews.gazeta.pl>, copx.RemoveThis@gazeta.pl says...
> Thomas Biskup seems to be serious about finally releasing JADE in 2008 (see
> www.adom.de).
>
> I cannot wait to try it. JADE is one of these mega-hyper-roguelike projects,
> which usually never get anywhere, but given TB's track record.. maybe he
> will actually do it..
I won't be bothering, as it is ASCII based.
- Gerry Quinn >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Nov 14, 2007 Posts: 40
|
(Msg. 25) Posted: Tue Jan 08, 2008 3:49 pm
Post subject: Re: We are doomed.. [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
> > I cannot wait to try it. JADE is one of these mega-hyper-roguelike projects,
> > which usually never get anywhere, but given TB's track record.. maybe he
> > will actually do it..
>
> I won't be bothering, as it is ASCII based.
Because we all know that REAL roguelikes use graphics. =P
--
Gamer_2k4 >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Nov 06, 2006 Posts: 838
|
(Msg. 26) Posted: Tue Jan 08, 2008 4:01 pm
Post subject: Re: Debugging games [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
In article <477915fe$0$84175$742ec2ed@news.sonic.net>, bear.RemoveThis@sonic.net
says...
> I made a standard debugging output where debug "trace"
> statements write sentences about what the game is doing.
> If the game crashes I can pop up TrDebug.txt and see
> what it was doing right before it crashed. That has
> helped a lot.
I put in lots of asserts for unexpected input or conditions and examine
them when code breaks them in debug mode (occasionally I have to remove
the asserts, because I am allowing the code to deal with input I had
not originally expected it to deal with). That finds the majority of
bugs caused by logic errors in my code.
I also use defensive coding so that unexpected conditions should give
harmless results. Better a wand that doesn't fire than a wand that
crashes the game. Didn't get to many of those, though.
And then when I see a bug I scratch my head and try to figure out the
cause in the traditional fashion...
- Gerry Quinn
--
Lair of the Demon Ape
http://indigo.ie/~gerryq/lair/lair.htm >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Nov 06, 2006 Posts: 838
|
(Msg. 27) Posted: Tue Jan 08, 2008 4:07 pm
Post subject: Re: Debugging games [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
In article <flbtq8$2014$1@news.vol.cz>, zaimoni RemoveThis @zaimoni.com says...
> assert() is nice, but the fact the standard requires it to abort() is slightly
> unnerving. I have a suite of auditing and invariant-testing macros for projects
> that don't have to be purely standard C/C++ . (E.g., exit with error message in
> debug mode but silently do the safe thing in release mode, and so on.)
That's what the ASSERT macro in MSVC does, and I would not think of
using anything that worked otherwise. When I was referring to asserts
previously I was referring to ASSERT or equivalent, which I think is in
fact the normal meaning of "to assert" even if in their wisdom C++
standard writers have defined a new meaning for assert as a keyword.
- Gerry Quinn >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Nov 06, 2006 Posts: 838
|
(Msg. 28) Posted: Tue Jan 08, 2008 4:16 pm
Post subject: Re: We are doomed.. [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
In article <wAB*rgV3r@news.chiark.greenend.org.uk>,
damerell.TakeThisOut@chiark.greenend.org.uk says...
> Quoting copx <copx.TakeThisOut@gazeta.pl>:
> >ADOM is already the most popular roguelike,
>
> It is? I thought it was gradually rotting away from lack of maintenance.
How can that happen? I thought digital data was permanent.
I think the guy's attitude is right. Finish a project, and go onto the
next. I find bizarre the attitude some people have that a roguelike is
'alive' before it is finished, then 'dead' from the moment it's done.
- Gerry Quinn >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Oct 18, 2007 Posts: 49
|
(Msg. 29) Posted: Tue Jan 08, 2008 4:27 pm
Post subject: Re: We are doomed.. [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
On 2008-01-08, Gerry Quinn <gerryq RemoveThis @indigo.ie> wrote:
> In article <wAB*rgV3r@news.chiark.greenend.org.uk>,
> damerell RemoveThis @chiark.greenend.org.uk says...
>> Quoting copx <copx RemoveThis @gazeta.pl>:
>> >ADOM is already the most popular roguelike,
>>
>> It is? I thought it was gradually rotting away from lack of maintenance.
>
> How can that happen? I thought digital data was permanent.
Communities aren't permanent, though; active developer involvement and
active player involvement are often linked. ADOM seems to have staying
power but I do know people who have chosen to pick up another game
instead because it seems like a quiescent project, myself included.
> I think the guy's attitude is right. Finish a project, and go onto the
> next. I find bizarre the attitude some people have that a roguelike is
> 'alive' before it is finished, then 'dead' from the moment it's done.
I'd agree with that. I'm told ADOM has some major crash bugs and, as a
player, hearing that combined with "the developer hasn't touched it in
N years" makes me more likely to check out a different game. But I think
a game is dead when no one is playing it, not when no one is changing it.
-r. >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
External

Since: Oct 18, 2007 Posts: 161
|
(Msg. 30) Posted: Tue Jan 08, 2008 5:33 pm
Post subject: Re: Debugging games [Login to view extended thread Info.] Archived from groups: per prev. post (more info?)
|
|
|
On 2008-01-08 17:07:24, Gerry Quinn <gerryq.DeleteThis@indigo.ie> wrote:
> In article , zaimoni.DeleteThis@zaimoni.com says...
>
> > assert() is nice, but the fact the standard requires it to abort() is slightly
> > unnerving. I have a suite of auditing and invariant-testing macros for projects
> > that don't have to be purely standard C/C++ . (E.g., exit with error message in
> > debug mode but silently do the safe thing in release mode, and so on.)
>
> That's what the ASSERT macro in MSVC does, and I would not think of
> using anything that worked otherwise. When I was referring to asserts
> previously I was referring to ASSERT or equivalent, which I think is in
> fact the normal meaning of "to assert" even if in their wisdom C++
> standard writers have defined a new meaning for assert as a keyword.
C89 standard writers, which both C99 and C++97 use as reference. I doubt C++0x
is going to get away from this either.
abort() should be reserved for when you really *can't* clean up safely (which
should be almost-never). >> Stay informed about: We are doomed.. |
|
| Back to top |
|
 |  |
|
|
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|
 |
|
|