Re: Umbrarum Regnum

Risto Saarelma wrote:

Of course the assumption here is that the designer can find an engine
coder who will actually be able to produce a sufficiently complete
engine that the game can be built on top of it. Currently T-Engine seems
to be the only stable generic engine. Incidentally, T-Engine also had
the prequisite of needing to be able to run an Angband variant, instead
of starting without any fixed game design. The success rate for engine
projects which start from scratch seems to be pretty close to zero.


I have observed that same thing. Engine projects which are not
driven by the development needs of a particular game *always*
fail, as far as I can see.

In this, they are much like new programming languages developed
without input from the process of writing an application in the
language. Such languages are many, but almost all such languages
are profoundly useless for actual programming.

I think that one difficulty is finding the *right* level of
abstraction for a roguelike engine. I mean, it's easy to trumpet
"you never have to write a line of code!" when you've got all
your monster descriptions, item descriptions, etc, stuck in
configuration files. But those configuration files themselves
represent a formal language with a rigid semantics, and you
*ARE* writing code when you edit those files.

And writing code is not a bad thing. After all, you're
specifying game rules and game content, and that's complicated.
At some point you have to specify behavior and interactions
and you have to do it precisely, with rigid semantics. and
that's the complexity normally associated with writing code.
If you're going to do that, I think you ought to have a proper
programming language to do it in.

So maybe the proper approach for these projects is less
"engine" and more "framework." The idea is that the
framework provides a main() routine and an event loop
and the infrastructure for handling events and time and
messages and so on, plus the content for a fairly
"generic" roguelike game in the form of code that
implements events and items, and an easily-understood,
simple API for how to add things and modify things, and
a *lot* of error-checking code that checks invariants
and catches errors fast whenever the framework gets
control. The variant writer is expected to write code
to that API, make programming errors that are caught by
the error-checking code, edit existing code to change
the way things work, etc. We can't really pretend it isn't
programming, so why not get the benefit of programming
languages?

I'm now on my third or fourth rewrite-from-scratch and I'm
doing things a new way. It seems a lot more "framework-like"
in that code that specifies "game content" is all very
uniform in its interface, like drop-in modules. The grotty
stuff that isn't really game content, like line-of-sight
calculations, message handling, error checking, and so on,
is all part of the framework. It seems more promising than
previous attempts, and much more like something it would be
easy to develop a variant from.

Bear





.

Relevant Pages

  • Re: ArmA2 1.04 patch released
    ... themselves well to multithreading. ... take advantage of all cores than a FPS game might. ... Making full use of MT throughout the engine would ... existing programming paradigm and start over. ...
    (comp.sys.ibm.pc.games.action)
  • Scid 3.6.25 (chess database, playing and training application)
    ... Removed Crafty engine, as tacgame.tcl does not need it any longer. ... Add a visual indicator to the game list if a comment was sent by the opponent. ... when deleting the last move of a variation by right clicking on board, ... A training base of over 1500 games has been released (not included in Scid package). ...
    (rec.games.chess.computer)
  • Re: Troll-o-Matic
    ... engine to start working with. ... turned into a game engine. ... CFFI wrappers for SDL, game programming, AI ...
    (comp.lang.lisp)
  • Re: fps modding
    ... >> to see the game data. ... > Visual Studio so all you really have to do is double click then compile. ... also building the engine in question with the same compiler). ... (why then are the load times so long?... ...
    (comp.games.development.programming.misc)
  • Re: C++ sucks for games
    ... The alternative, garbage collection, tends to corrupt memory too. ... Game programmers need efficient and deterministic garbage collection. ... The game programming industry has ... Most programs have two languages ...
    (comp.lang.lisp)