Re: Building your first Roguelike

At Sat, 18 Mar 2006 20:37:50 +0000 (UTC),
Crypt wrote:

On 2006-03-18 19:35:16, Radomir 'The Sheep' Dopieralski
<thesheep@ sheep.prv.pl> wrote:
At 18 Mar 2006 10:24:37 -0800, Slash wrote:
Radomir 'The Sheep' Dopieralski wrote:
At Sat, 18 Mar 2006 14:31:52 +0000 (UTC), Crypt wrote:
On 2006-03-18 00:43:46, "Will Shattuck" wrote:

You could start by creating World class
containing an ArrayList grid[][]=new
ArrayList[100][100]

I think this is a very bad advice...

Perhaps for this, his very first roguelike, it will be good experience
to try to make something, get to certain advancement level and then
just crash the project because of the obvious issues that will arise
for being a design-less project... then he will be able to take all he
learned and apply it into a project with real hopes to be something
stable and interesting.

Perhaps. Over-planning may do no good.
But the advice stays bad...

Why ?

I'm sorry, I should have made myself clear right away.
I'll try to explain why I think such an advice is bad.

First of all, I think it's bad code. Java uses objects and object
references. This advice suggest basically to create 10 000 lists
of references. Even an empty list will take up some memory. You
end up with lots of your memory wasted for such a simple thing as
map. Not only that -- as you work on your game, you usually make
it more complicated, adding attributes to various objects. Every
change to the map objects results in a change in memory usage
multiplied by 10 000. You no longer can afford sloppiness -- every
non-optimal choice will grow 10 000 times and bite you back.
Making it 20x20 instead of 100x100 only changes the magnitude, but
doesn't solve the problem.

This, in my opinion, bad code is actually pretty common, and is
usually corrected or worked around eventually at later stages of
development. That's why I don't think it's a grave mistake in your
own code. You will sort it out somehow eventually, or do a rewrite
or anything -- that's what the testing, profiling, correcting,
refactoring, etc., are for. You are learning while coding, and that
does you good. This kind of code can stay unchanged even in the
release versions of roguelikes -- when it's not critical, the game
is small, the computer it runs on has lots of ram, the way you
access the map plays good with the page swapping mechanism of your
operating system, etc. It can occassionally bite when you try
to extend something or to run the game on a worse machine, or to
port it to a different operating system -- but that's rare.

Still, I don't think it's a good advice to follow. It's not
something horrible, but it's not pretty either.
Anyways, I beginning to regret I posted that comment, because
now it feels like I'm just ranting about insignificant details.
Sorry about that.

Because you think i spoke about coding before planning ?

No, not at all. It's good to code before you start planning --
so that you have something to base your plans on. Just don't
get attached to the code you wrote before planning ;)

I didn't tell him to code at first. I just spoke about code.
1. we don't know what is his programming skill.
2. in case he doesn't know how to build a map, make a character moving on it,
etc, some basic coding helps are useful and can help him to test some ideas,
select ones, reject others.

It's always good to give some helping tips, even if they are obvious.
Even if you do know how the Breshenham algorithm works, it's easier
to implement it when you look at some code, for example.
The bad things happen when the sample snippets actually suggest you
suboptimal approach. When there's a flaw in certain implementation,
it should be mentioned, so that you don't get in trouble with copy+paste.

Of course he should plan before coding...:
- Model (what it should look like, what would be possible, etc) (no code)
- General code architecture. (uml)
- RPG resolution system. (no code)

That's one possible approach. There are many of them. The cycle
stays basically the same: plan, code, test, plan, code, test,...
With smaller or larger steps, with existing or new code. With
small projects, it's better to test often. With large ones, it's
sometimes beneficial to plan large parts. There is no golden
rule, but you should know different methodologies and apply them
as needed.

I'm really sorry about the remark and the uneasyness it caused.
Most of what I wrote here is either my personal opinion or well
known and general fact. No real content. I'm sorry.

--
Radomir `The Sheep' Dopieralski
.

Relevant Pages

  • Random Map Progress
    ... I asked for some advice a few months back about how to generate a ... "random" map for a game I was writing. ...
    (comp.lang.php)
  • >>>> MAP GAMES <<<<
    ... addictive games with united states map, game maps ds, marauders map ... game, think tanks game maps, british legends game map, map game third ... grade, your child learns map game, sin game maps, middle east online ... 50 us states map game, make game maps, arcanum game maps, europe map ...
    (de.rec.buecher)
  • How to write a roguelike game? :)
    ... This is a rough route map for the creators of roguelikes. ... Step 1 -- Decide to write a game ... Don't start by asking around about the definition of roguelike game -- you don't ... still fun to play for you -- you succeeded. ...
    (rec.games.roguelike.development)
  • Re: Todays battle report
    ... 'Stealers win if the flamer dies/runs out of ... The Nid player built this map as you moved, ... A game that only engages people as long as they're waiting ... Advanced missions convinced me that WD and CJ were worth the price. ...
    (rec.games.miniatures.warhammer)
  • Re: Quick review: Brothers In Arms - Hells Highway
    ... I never even finished the second game because the difficulty of it just ruined the fun for me. ... With this third game, which I've been playing on Veteran, it's very easy to just pick off the enemy soldiers using your M1 rifle. ... But not too realistic since in a few fights seem to be designed to have you easily take out *all* the enemy positions with the bazooka team. ... What I keep running into with the map, is that it doesn't offer enough detail. ...
    (comp.sys.ibm.pc.games.action)
Loading