Posted to rec.games.design by Stefan Matthias Aust.
Hi!

Last week, I posted an article to comp.lang.smalltalk about
game-programming in Dolphin Smalltalk in which I came to the
conclusion that Smalltalk is a promising alternative to other
programming languages and which ended with the idea of writing
a rogue-like role playing game in Smalltalk. 

Because of the response I received, I decided to give that
idea a try.

This posting shall be an open announcement and an appeal for
cooperation and participation. If you're interested, you're
welcome! I'll present my current ideas in this article, but
don't take my ideas as to be written in stone. This project
can only be successful, if it is supported by many people.

The game should be simple, but not too simple. We should try
to start with a small core which can be extended. I think, this
approach is essential to prevent the failure of this project,
because otherwise after some time interest will vanish if no
progress can be seen. 

There are three important milestones we have to reach:

1. creating an extendable base game system (the rules)
2. developing an object oriented design for such a game 
3. implementing the game in Smalltalk

Even if I'd put the main emphasize on the design process and the
implementation language Smalltalk, I'd wish that people with other
programming backgrounds take part, too. (That's the reason why I
crossposted this to rec.games.design and rec.games.programmer)

I'd like to propose SmallHack as project title (unless someone
provides a better name). The name shall suggest a relation to
rogue-like games as Hack or Moria. And of course, should hint to
the implementation language Smalltalk.


                       SmallHack - The Background

The player's hero starts in the forgotten city of "Delhagen." The city
is old, lost and abandoned by all gods and most good people. The
overwhelming forces of evil assemble to summon "Kothuga", their dark
lord, the oldest god of darkness. The last hope of the surviving
citizen is to call for "Shada'za", the queen of the dragon gods. But
her temple lost, destroyed by the priest of the new human gods, her
magical statue broken into five pieces and scattered over the city.

The player's task is to find the five parts of the dragon queen's
artefact, which are hidden by the creatures of evil deep into the
dungeons below "Delhagen", then find the location of the old dragon
temple, and pray for help. If Shada'za shall call their dragons to
chase the darkness from this world, she'll name her payment. The game
is won if this final quest succeeds. 


                           The Abstract Game

The game shall combine the above sketched fixed story line together
with randomly generated locations. Each time you play, the city is newly
created. The same is true for the dungeons and the hidden pieces.

The city consists of a number of city locations:

    * tavern (to enlist new characters)
    * shop (to buy and sell items)
    * temple (to receive a healing)
    * ruin (entry to dungeons)
    * graveyard (entry to dungeons)
    * marketplace (to talk with people)
    * town council (to talk to authority)
    * city gate (to leave the city)
    * and so on

Some locations are always present, some aren't. The game shall be
designed that more locations can be added easily later on.

Outside the city, we can add a number of "outside locations" to travel
to other cities, villages or other places of interest. But I'd say
that's left for a later version of this game.

A dungeon consists of a number of dungeon locations:

    * rooms, halls, corridors (the basic building blocks)
    * and so on (I lost my fantasy)
    
I use dungeon as a generic name for everything, the hero can wander in
which isn't a city or an outside location. You can call them dungeons,
cellars, lairs, sewers, .... 

Locations are populated by creatures, most of them hostile to our hero.
They may also contain items, (hidden) treasures, traps or riddles. All
locations are connected with other locations, some connections may offer
restricted access (say, you've to carry a golden key). 

The hero can pick up items, use or drop them. Items can be sold or
bought. They can be traded for "tokens" of information, which are
abstract knowledge items, too. Common items are weapons, armor, magic
scrolls and potions, chests, rings, books, and so on. 


                          Resolving Conflicts

This is a game of heroic struggle of (relative) good against pure evil.
Fighting monsters is hero-business. Therefore, combat is an important
part of this game. The hero and his/her companions stand against the
enemy as follows:

Each side has three range bands, to which creatures are allocated.
Characters in the first bands can fight each other at melee range. They
block the enemy against attacking creatures in the second band. This
band can only be reached by ranged attacks like bows, crossbows or
spells. People in the third band are normally out of reach. They can
be
seen, but not directly attacked. Creatures can advance or retreat one
band per turn (combat is handled in turns). A side can advance the other
party if not blocked, which reduces all bands of that side by one.
Creatures in band three can run away from combat.

Each creature (hero, companion or monster) has combat skills that are
used to determine whether an enemy can be hit. Actual damage is
dependent on the used weapon, the attacker's strength and the defenders
armor. Each creature can suffer a certain number of damage before it is
unable to fight and/or dies. The attack order is determined by the
creature's initiate value. 


                                 Magick

A fantasy game isn't complete without magic (I'll add a "k" because that
looks more arcane). Heroes (and monsters) can cast magic spells and
cause or suffer from magic effects. A Dragon can breath fire, an undead
skeleton can frighten to death, a troll can regenerate. Spells can
learned from arcane books (grimores) and cast during combat. Heroes who
cast magic are called magicians. Each magician has a magick skill that
measures his/her practice. They can cast magick as long as they carry a
device to focus the magic energy. Each spell has a difficulty level that
is compared against the magick skill to determine, whether the spell is
successfully.


                               Companions

To reach his/her great goal, our hero needs help: Companions. Most
people are cowards, but in the shadow of a real hero, they might become
heroes, too. Companions are computer-controlled creatures (mostly
humans) which follow the player's character on his/her task. In a later
version, this might be heroes controlled by other players. Companions
can be found at the tavern or found deep into the dungeons. Some demand
payment, others might follow voluntary. The player can control their
behavior to a great extend. He can't however take all their possession
or sacrifice them all in combat. (Perhaps from time to time, a companion
might offer to "hold the bridge" against the overwhelming opponent)

It depends on the hero's charisma (a base characteristic), whether a
companion will follow. Money sometimes help, though.


                              The Roadmap

The game system has to be fleshed out. I've kept this description vague
to ease a compromise system most people can agree with to shorten this
decission process.

The abstract game can be implemented without any special GUI (graphical
user interface) at all, I think. This is intentional. A first game
version can have a simple ascii interface, which can then be improved to
a rogue-like (or Ultima-like) tiled-graphics system or even to some
isometric 3D system as Diablo has. At the same time, sounds can be
added. The game design has to separate the world model from the
presentation and the interaction. 


                           Technical Details

The game design shall be extendable and modular, parted into different
stages which can be implemented separately. We'll use an component
oriented approach to analyze and design the system which shall result in
a number of component descriptions. These components are then
implemented with an object oriented language, using the specified
component interfaces are only interfaces. 

The game consists of a core engine subsystem, which represents the world
model. The engine will be extendable with new items, monsters and
locations. A presentation subsystem will be responsible for drawing a
graphical view of the world. Finally, a controlling subsystem will
handle all user interaction and will control both view and model. (An
MVP or MVC pattern.)

Definitions: A subsystem is defined as a number of relating components.
A component is some black-box thing which exposes one or more
interfaces. An interface describes a set of messages (name, type
signature and description) with defined behavior that can send to that
component. A component expose (through interfaces) a number of
properties, methods and events. Components are managed by a central
point to which new components can be added and which can be queried for
interfaces. 

The game design shall be done in an object oriented, behavior driven
manner. During design, no performance or language specific optimizations
are allowed. Use cases will describe the whole system. Components are
built after and are checked against these use cases.


                            Everything else

I'm sure, I've missed a lot of very important points here. Most topics
have to be detailed and all topics can certainly be discussed.  I'd like
to see my basic ideas in the final game, though. I can be very stubborn,
sorry :-)

bye