Re: Angband's future (was Re: Angband maintainer)

I realise I sounded rather neutral and opinionless in my original post;
I'm not, don't worry. :)

magnate wrote:
On Apr 11, 1:19 am, Andrew Sidwell <a...@xxxxxxxxxxx> wrote:

I plan to release every six months. More changes can be made because
the perceived "risk" of each change is small. It will feel like the
game is active, which should encourage more posts, and hopefully more
feedback on what to do next.

Ok, but don't force yourself to stick to the timetable at the expense
of quality improvements that would require an extra few months.

There's actually good reasons for six-month releases, and regular
releases in general.

Why regular releases: you can plan what changes to make now, and later.
If there is a change that requires more than six months, then it's not
a single change, it's a lot of other changes, and can be broken down.
If it can't, then it won't get finished anyway. Something like
rebalancing the dungeon in a big way would be the kind of work I'd set
aside a week of free time for, get dug into, and get out of quickly.
Fine-tuning is something that can happen for ages, but the bulk of a
change has to happen fast or it you lose track of what you were doing.

Why six-month releases: A yearly release would lose focus and would tend
towards being more conservative. Quicker than six months would mean
that everyone's always lagging behind.

(On a tangent: I would like to know why people still play 3.0.3.)


I plan to clean up the code a lot. Pete Mack has done lots of work on
this already. When the game has both a good-looking and cleanly written
graphics mode, and when it is easy to assign tiles and deal with new
monsters, I think we will find more people willing to play.

Um. I notice that support for tilesets is more common nowadays, and I
certainly don't criticise anyone who invests their own time in
improving graphics support - but I don't think graphics should become
a key feature of Angband. I personally love ascii graphics and would
not want graphics improvements at the expense of any existing
gameplay.

Steve Clark also wrote:
Please don't forget the ascii players.

Don't worry. I won't. I don't use graphics myself, but I understand
that to attract a wider audience, the game pretty much needs graphics.


Perhaps a better example of this principle is mouse support: again, I
don't mind if people want to add mouse support, and if people want to
play with a mouse. That's fine. But I don't want to use a mouse, and I
will be pissed off if my Angband experience worsens as a side effect
of the addition of mouse support (e.g. if menus are harder to
navigate, or something).

I'll try my best not to let that happen, but changes will require people
to retrain their muscle memory. I just hope that the tradeoff is worth
people's time.


I see my role as maintainer [1] as more of a gatekeeper; keeping code to
a certain level of quality, and moving the game in the right direction.
I'm quite happy (read: want) to have more people involved. Burnout and
slowdown don't happen so much when you have a group. Different people
have different interests, which is why Julian didn't get round to doing
much with the game: people wanted squelch but he didn't feel the need.
It'd be great, if he found the time, to make the changes he was going to
make before on the new code.

I think your role needs to do more than QA people's coding. Angband is
emphatically not a game designed by committee, and you should take the
sole decision on whether or not to include any particular patch
(though as Antoine suggested, you should be guided by previous
discussions, and introduce anything controversial as an option which
defaults to off).

I think I probably put the emphasis in the wrong place, there. My
points were:
* people are welcome to join in development if they can code reasonably
well and have more to contribute than just the one patch
* that as an individual, it is much better to work in a team, because
there is naturally more motivation which helps avoid burnout
* and also that I don't really *want* to be the sole coder.


And now a big question: What should Vanilla be? Conservative with
gameplay, or taking risks? Should we remove statgain? Add random
quests? A wilderness [3]? Just make changes to the UI? Clean up the code?

Taking these in reverse order -

Cleaning up code is irrelevant to me because I can't code, but it
can't ever be a bad thing. So yes, but not top priority as it benefits
a subset of the user base (hackers and variant developers).

Though I do start to wonder how many people on r.g.r.a don't have
aspirations to start a variant. :)

<feedback on wilderness/quests/statgain taken, will reply to in a later
post with other similar posts>


OPTIONS

On things others have mentioned: I totally agree that you should
introduce gameplay changes as options wherever possible. RR didn't
like option bloat and IMHO did not implement many changes because of
this. I think options are definitely the way to appeal to more people
- Eddie and Leon can enjoy the same game simply by allowing squelch as
an option.

From elsewhere on this thread: "Sangband has done a good job of
eliminating several truly-ridiculous options and replacing them with
good defaults. The suite of options is very intimidating when learning
the game so I think it's good to make sure those options really count."

JLE: "Also, to tell the truth, a lot of the options that would have been
necessary for "older machines" can pretty much be discarded wholesale
now, if they haven't already been."


I plan to turn on the following permanently:
* preserve
* maximise
* flow_by_sound
* flow_by_smell
* next_xp (toggled XP display)
* allow_quantity
* expand_look
* expand_list
* compress_savefiles
* show_labels

I plan to turn off the following permanently:
* view_reduce_lite
* hidden_player

Any other suggestions?



Someone mentioned randarts: I hope you will at last take this
opportunity to replace the old and broken ten-years-in-beta randart
code with the newer one. You could use the version [...] in Un
(especially [the] improvements to the monster rating code which would
come in handy in other areas), but you should also check out what Jeff
and Diego have done with it in NPP. (Or you could use the 'other' new
randart code which is in O, S and FA - but naturally IMO isn't quite
as good! Maybe take the best of each?).

I do intend to fix the randart code, but I don't know how soon. It'll
require a big chunk of time to set aside, examine the various verisons,
work out how to fit them together, and then actually do it. Then there
will be lots of playtesting afterwards.

I hope to make the randart generator good enough that we can cut down a
bit on the static artifacts, stop randarts replacing current artifacts,
and have them generated alongside each other.


I'm tired now, so I will reply to the rest of the posts made up to now
in the morning. :) Thanks for all the feedback! It's useful. My
original post was very neutral, but I do have opinions, don't worry.


Andrew Sidwell
--
http://entai.co.uk/projects/angband/opensource

My email address changes monthly, and is the first three letters of the
month (in English), followed by the last two digits of the current year,
@entai.co.uk.
.

Relevant Pages

  • Re: new here, my lang project...
    ... >>a graphics pane)? ... Or are they for the physics of resolving movement, ... a computer game. ... >>If there is a collision, then figure out a new movement based upon the ...
    (comp.object)
  • Re: new here, my lang project...
    ... > Probably 80% of the processor cycles go to graphics, ... Then you need the AI or game mechanics to be making up for lost ... would effectively result in other collisions. ... >> could probably be said physics is doing the heavy lifting and rendering ...
    (comp.object)
  • Re: Fate: How can they get away with it?
    ... Nice try, but since the Mona Lisa is art and NOTHING else, while a game ... HUGE and contain very complex gameplay. ... Diablo style graphics, so without REAL GAMEPLAY you'd have had nothing ...
    (comp.sys.ibm.pc.games.rpg)
  • Re: new here, my lang project...
    ... It is more of an immediate, short-term hassle. ... >>I'm kind of surprised a game like quake didn't have threading. ... That only works for primitive graphics, a dumb AI, and an RTS format ... > physics is doing the heavy lifting and rendering is just along for the ride. ...
    (comp.object)
  • Re: WTF Game Scores Mass Effect Vs. Uncharted
    ... more epic, has a lot more to do, great visual design... ... aspect of a game. ... had technically the best graphics ever made for a console. ... I didn't mean the visual design of the characters. ...
    (alt.games.video.xbox)