Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Notes about random modeling ideas (to reduce time managment & game/engine entropy)

30 views
Skip to first unread message

Jimmy Åberg

unread,
Mar 11, 2011, 6:08:45 AM3/11/11
to
:::START DISCLAIMER:::

Here is a very informal/sketchy post, that (partially) presents some
of my ideas regarding "language construction", "doman specific
languanges", "domain modellering", "logic reasoning", "reflexive game
logic", etc. I have many more ideas like this, but it is quite hard to
express them in a "linear" "formal" way, since much of my work still
is still in progress, and therefor, very informal and not yet
implemented... The purpose of this post is mainly:
1. To present my (partly informal) ideas, in hope of getting some help/
support from you, so I maybe can implement the ideas someday, and help
me save some time.
2. To spread my ideas to others.


My primary languange is Swedish, and I understand English very good,
but at the moment my English isn't as fluent as I wound wish it could
be.


Feel free to ask questions, about any parts in this post that you find
interesting and/or confusing,

:::END DISCLAIMER:::

...

Past history:
The last 3-4 years I have not found much time to do actual game
implementation. The most time is spent on programming workrelated
stuff. On my spare time I try study discrete math, and computer
science (parsing, languange construction). In 2005 was the last time I
did an actual game, and back then i used C++ and Allegro.

The since the last projects, after a certain time, i have built in "to
much entropy", based on "bad assumptions"/"bad reasoning"/"bad models"
that "to fast limit" my options. Its an issue of "maintainability of
features".


Current need:
This leads me to a need of good models, wich implicates a need of good
modeling languages, and most general purpose languages are to verbos,
to allow simple specificications.

I want a emergent system, kind of the game "incredible machine". So
interactions should be based on simple "laws" or "rules", so the
player creatively can reason and construct creative sollutions,
(rather than preprogrammed/scripted sollutions).


Current position:
I feel "kind of stuck" in some kind of "abstraction spin" in trying to
build my own modelling languagne. I try to learn about languange
construction to build my own Interpreter/"Virtual machine environment"/
DSL's. The purpose is to try to cleanly model my domain in my own
languange.


I primarily work in .NET (C#), has some skills in F#, have used fsyacc
and fslex to construct simple languages.
I tried Irony (google "Irony codeplex"), but I thought it was poorly
documented. Thought of switching to ANTRL.
The problem with both ANTRL, Irony, and such, is that i primarilly
want a system capabel of some king of "incremental parsing" or
"runtime parser constrution". I want the parsing logic, to be a part
of the "game ai", i.e. the "ai" should use the same commands as the
"general game system". I want a language that enables me to "construct
parsers at runtime". Irony enables runtime parser construction, but I
don't have the skills yet to implement this in Irony, and since its
poorly documented I kind of abandoned it.

A simple language to construct machines, such as:
"state machines",
"state machines with transactions based on probability (e.g.markow
chains)",
"state machines with multiple variables (fuzzy logic, neutral net,
etc)"
"recursive machines" that can construct "levels", "monsters" in a
recursive/treelike fashion etc.


The problem with (class-oriented) object oriented languages such as C+
+, Java, C#, is that much information is "lost in compilation", e.g.
"you write a lot of code" in the "development environment" that the
"execution environment" don't get access to, since the information is
"lost in translation".
Features such as "reflexion" partially solves this, but I don't think
reflexion alone is enought. I really want my "game agents" to be able
to reason about what kind of "enteties" that exist in the world (and
primarily, "reason about objects in the same room as the agent
itself") .

I try to construct a "Reflective languange", so the "game agents" can
reason about the models.
The game models also should be constructed in a "bottom up" fashion,
so the game easyly can be extended at any time, making the system very
modular.

The DSL should be able to suppory a "simple english grammar", that
basically is a language mix of "set theory", "discrete math" and
"recurrent controll stuctures".

"every orc is being"
"every being is damage-able"
"every sword causes damage"
"every sword is weapon"
"every weapon is item"
"every character starts-with 2 random-item"
"every random-item is any item"
"every food is consumable"
"every food produces"
"some being is hostile"

TOP DOWN GRAMMAR:
phrase = [proj quant adj obj]* //projection quantification adjective
object
proj = {cmd,ctrl,ai,prepos,link}
cmd = {'new','def','sym'}
ctrl = {'if','while','for'}
ai = {pred,fun,rel}
prepos = {'at','in','under','by',with','from','to'}
link = {'is','are'}

quant = {'every','some','any','the','one','none'}

adj = {dim,psy,phy,vis,sou}
dim = {'huge','large','small','tiny'}
psy = {'hostile','friendly','neutral,'angry','calm','frenzy'}
phy = {'healthy','diseased','hungry','poisioned','strong'}
vis = {tex,col}
tex = {'invisible'}
col = {'green','red','blue'}
sou = {'loud',''}

obj = {plant,being,act,event,interior,prop}
plant = {flower}
being = {insect,reptile,mammal,humanoid}
act = {'walk', 'attack', 'hide', 'pick'}
event = {'explosion'}
interior = {'floor','wall'}
prop = {'door','barrel'}


...

and to extend to above, we use a bottom-up grammar.
BOTTOM UP GRAMMAR:

"def every orc is humanoid"
"def every orc is greenskin"
"def some orc is green"
"def some orc is black"

or more compact:
"def every orc is {humanoid,greenskin}"
"def some orc is {black,green,strong}"
or (even) more compact:
"def {
every orc is {humanoid,greenskin}"
some orc is {black,green,strong}
}"

then we could write:
"new (black,strong) orc"
or:
"new (black,strong) orc at (0 2)"

or more compact:
"sym def §"
"sym is ="
"sym new $"
"sym at @"
"§every orc={humanoid,greenskin}"
"§some orc={black,green}"
"$(black,strong)orc@(0,2)"

...
STATE MACHINE EXAMPLE
"schema 1={w:walk,c:charge,a:attack,i:idle,s:sidestep,b:block,j:jump}"
"schema 2={p:pathfind,r:rest,f:flee}"
"script A(1)=(has target){wbca[BA]} " // script, apply schema 1, and
assert has target
"script B(1)=(has no-target){sbs2jbaA}" // script, apply schema 2,
and assert has no-target
"schema orc_action_tick_lenght={walk:12,charge:20,attack:8}"

script A = // walk, then block, then charge, then attack, then
randomize between restarting at A och B.
script B = // sidestep, block, sidestep*2, jump, block, attack,
restart at C...
... .etc....

....

Set intersection based on infered rule based logic:

"every orc know consumable"
"every apple is consumable"
"new apple at (12,12)"
"new (hungry) orc at (12,13)"
"fun look-food = visible&consumable" // & = set intersection
"fun hungry = if look-food(*) then eat(*)" // * = wildcard

visible = internal queue of visible objects, each being has this
queue. it is "feed/pushed" by objects in the room.
consumable = "set of consumable items, and since every apple is
consumable, and every orc know about consumable, it will find it"

Rule based exploration:

by specification "is" and "know" relations, then we can model "world
exploration". For example:
"
every
{
{orc,goblin} is greenskin
greenskin know color
greenskin know flower
greenskin like bloodflower
{fireflower,bloodflower} is {red,flower}
fireflower cause poison
bloodflower cause berzerk
}
some goblin
{
know fireflower
know bloodflower
}
"

This means orcs dont know what firelowers are/causes, but (some)
goblins does know what fireflower are/causes.
When a orc sees a "red flower" it (maybe) will think it is a
"bloodflower", since they like "bloodflowers", but only know it is a
"red" "flower" (since they know "color" and "flower", and since "every
red is color").

...

Inspiration:

Simple syntax, such as Lisp/Scheme.
The logic capabilites of Prolog,
The interpretability of Python/Smalltalk.
The library support of .NET.
etc.

Parser/language kits:
Irony.
ANTLR
fsyacc/fslex
IronPython

Yesterday, I thought of maybe start by some "javascript"/"ecmascript"
implementation in .NET, such as:
Machete - http://blogs.lessthandot.com/index.php/DesktopDev/MSTech/machete-a-scripting-runtime-for
JInt - http://jint.codeplex.com/
and then modding it to fit my needs...

Jimmy Åberg

unread,
Mar 11, 2011, 6:26:47 AM3/11/11
to
Is there anyway I can edit the typos in my prev post?

vsync

unread,
Mar 11, 2011, 7:04:38 AM3/11/11
to
Jimmy Åberg <jimmy...@gmail.com> writes:

> Is there anyway I can edit the typos in my prev post?

Yes, just supersede the article. Be aware that it has already
propagated around the world and been read by many people however.

--
vsync
http://quadium.net/~vsync/

My whole approach in broadcasting has always been "You are an
important person just the way you are. You can make healthy
decisions." ... I just feel that anything that allows a person to
be more active in the control of his or her life, in a healthy way,
is important.
-- Fred Rogers

Risto Saarelma

unread,
Mar 11, 2011, 7:05:10 AM3/11/11
to
On 2011-03-11, Jimmy Åberg <jimmy...@gmail.com> wrote:
> The DSL should be able to suppory a "simple english grammar", that
> basically is a language mix of "set theory", "discrete math" and
> "recurrent controll stuctures".
>
> "every orc is being"
> "every being is damage-able"
> "every sword causes damage"

Take a look at Inform 7.

Mario Lassnig

unread,
Mar 11, 2011, 7:07:14 AM3/11/11
to
On 3/11/11 1:05 PM, Risto Saarelma wrote:
> On 2011-03-11, Jimmy Åberg<jimmy...@gmail.com> wrote:
>> The DSL should be able to suppory a "simple english grammar", that
>> basically is a language mix of "set theory", "discrete math" and
>> "recurrent controll stuctures".

i.e. LISP

Jimmy Åberg

unread,
Mar 11, 2011, 8:05:45 AM3/11/11
to
On 11 mar, 13:07, Mario Lassnig <ma...@lassnig.net> wrote:
> On 3/11/11 1:05 PM, Risto Saarelma wrote:
>
> > On 2011-03-11, Jimmy Åberg<jimmy.ab...@gmail.com>  wrote:
> >> The DSL should be able to suppory a "simple english grammar", that
> >> basically is a language mix of "set theory", "discrete math" and
> >> "recurrent controll stuctures".
>
> i.e. LISP


So can you give me an brief example of how you would implement the
idea of "Rule based exploration" in Lisp? Regarding the follwing code:


"every
{
{orc,goblin} is greenskin
greenskin know color
greenskin know flower
greenskin like bloodflower
{fireflower,bloodflower} is {red,flower}
fireflower cause poison
bloodflower cause berzerk
}

some goblin
{
know fireflower
know bloodflower
}"

Would you write a parser, or would you try to represent this structure
in a similar structrure directly as Lisp code? Kind of like:
"(every (
((orc goblin) is greenskin),
(greenskin know color),
(greenskin know flower),
(greenskin like bloodflower),
((fireflower bloodflower) is (red flower)),
(fireflower cause poison),
(bloodflower cause berzerk)
))

Two points here:
1a. Is this valid Lisp Syntax?
1b. Would Lisp support both this two notations:
"(some goblin(
(know fireflower),
(know bloodflower)
))"

"(some
(goblin know fireflower),
(goblin know bloodflower)
)"

2. The readability is greatly reduced....
3. Does Lisp support "Runtime Interpretation"? I.e can i enter
commands throught a console.

...

Jimmy Åberg

unread,
Mar 11, 2011, 8:06:04 AM3/11/11
to
On 11 mar, 13:05, Risto Saarelma <rsaar...@gmail.com> wrote:

Thx for the tip.

Jimmy Åberg

unread,
Mar 11, 2011, 8:35:37 AM3/11/11
to
Another idea I have, is to write a "simple parser", that don't
"translates the 'string input' to an executable representation",
but instead translates/maps a "string/file input (of source language)
to a string/file output (to target language)".
I.e i write a "re-write parser" without compiler. Kind of what lex/
yacc does. Since the main issue is maintainability.

Krice

unread,
Mar 11, 2011, 8:55:07 AM3/11/11
to
On 11 maalis, 13:08, Jimmy Åberg <jimmy.ab...@gmail.com> wrote:
> I try to learn about languange construction to build my own
> Interpreter/"Virtual machine environment"/ DSL's.

Why build something like that on top of the game engine?
I don't even know why people use so much scripting, like it
was something that's required. I think designing a complex
game becomes much easier if you keep stuff modular and
restrict the actions to specific class/user defined type.

vsync

unread,
Mar 11, 2011, 3:28:18 PM3/11/11
to
Jimmy Åberg <jimmy...@gmail.com> writes:

> Would you write a parser, or would you try to represent this structure
> in a similar structrure directly as Lisp code? Kind of like:
>
> "(every (
> ((orc goblin) is greenskin),
> (greenskin know color),
> (greenskin know flower),
> (greenskin like bloodflower),
> ((fireflower bloodflower) is (red flower)),
> (fireflower cause poison),
> (bloodflower cause berzerk)
> ))

I would implement it as S-expressions for the fact that all your code
ends up following the same syntax and it's very easy to write your DSL
that way by taking advantage of Lisp's reader and compiler through
macros rather than having to write your own.

Now, I am a huge Lisp fan (and my entry's written in Lisp) but I would
encourage you to take a look at Prolog.

<URL: http://en.wikipedia.org/wiki/Prolog >
<URL: http://www.csupomona.edu/~jrfisher/www/prolog_tutorial/contents.html >

greenskin(orc).
greenskin(goblin).

knows(X, color) :-
greenskin(X).

knows(X, flower) :-
greenskin(X).

likes(X, bloodflower) :-
greenskin(X).

color(fireflower, red).
color(bloodflower, red).

causes(fireflower, poison).
causes(bloodflower, berserk).

Luckily you can embed Prolog in Lisp :)


> Two points here:
> 1a. Is this valid Lisp Syntax?

It is, by and large, although you don't need the commas. I'd also use
prefix notation. EVERY and SOME are actually used for something
slightly different but you can overload them for your use if needed.

I would write it more like

(every
(is (orc goblin) greenskin)
(knows greenskin (color flower))
(likes greenskin bloodflower)
(is (fireflower bloodflower) (red flower))
(causes fireflower poison)
(causes bloodflower berserk))

The advantage of expressing in tuples is you can take advantage of
things like Prolog, RDF, AllegroGraph that handle them quite well and
fast.

You could also instead take advantage of Common Lisp's object system:


; things about flowers

(defclass flower ()
())

(defclass fireflower (flower)
())

(defclass bloodflower (flower)
())

(defmethod flower-color ((flower fireflower))
'red)

(defmethod flower-color ((flower bloodflower))
'red)


; things about actors

(defclass actor ()
())

(defclass greenskin ()
())

(defclass orc (actor greenskin)
())

(defclass goblin (actor greenskin)
())

(defmethod actor-likes ((actor greenskin) (object bloodflower))
t)


; try it out

(actor-likes (make-instance 'orc)
(make-instance 'bloodflower))

=> T


> 1b. Would Lisp support both this two notations:
> "(some goblin(
> (know fireflower),
> (know bloodflower)
> ))"
>
> "(some
> (goblin know fireflower),
> (goblin know bloodflower)
> )"

You can have the reader read in any set of S-expressions you want and
assign whatever sub-syntax you want.


> 2. The readability is greatly reduced....

*takes off glove, slaps Jimmy*

No, in all seriousness you could implement it then add a plain language
parser on top.

Though be aware that McCarthy and crew (that originally made Lisp)
always meant to make a "more readable" M-expressions syntax, but once
they got going using S-expressions they never felt the need. YMMV


> 3. Does Lisp support "Runtime Interpretation"? I.e can i enter
> commands throught a console.

Yes.

Paul Donnelly

unread,
Mar 11, 2011, 4:37:28 PM3/11/11
to
It sounds like you want Lisp with embedded Prolog, which is easy, but
designing the whole system you have in mind will not be easy. If you're
looking to make a game, but are finding it difficult to design a good
architecture, you should just practice designing programs. Writing an
all-purpose game construction tool is an attractive idea, but it's not
the way to go if making games is your desire. And unless you've got some
experience designing games, you probably don't have a good idea what
such a tool should be like.

Jimmy Åberg <jimmy...@gmail.com> writes:

> Would you write a parser, or would you try to represent this structure
> in a similar structrure directly as Lisp code? Kind of like:
> "(every (
> ((orc goblin) is greenskin),
> (greenskin know color),
> (greenskin know flower),
> (greenskin like bloodflower),
> ((fireflower bloodflower) is (red flower)),
> (fireflower cause poison),
> (bloodflower cause berzerk)
> ))
>
> Two points here:
> 1a. Is this valid Lisp Syntax?

The nice thing about Lisp is that nearly anything can be valid Lisp
code. Go ahead an implement the EVERY macro.

> 1b. Would Lisp support both this two notations:
> "(some goblin(
> (know fireflower),
> (know bloodflower)
> ))"
>
> "(some
> (goblin know fireflower),
> (goblin know bloodflower)
> )"

Will you support those two notations with your Lisp program?

> 2. The readability is greatly reduced....

*Enhanced*

> 3. Does Lisp support "Runtime Interpretation"? I.e can i enter
> commands throught a console.

Yes, it's called the REPL, although any decent Lisp environment will let
you work in a file then send your new code over. It doesn't have
anything to do with interpretation though.

gabriel arthur petrie

unread,
Mar 11, 2011, 7:39:17 PM3/11/11
to
Jimmy Åberg <jimmy...@gmail.com> wrote:
> :::START DISCLAIMER:::

>
> , Irony, and such, is that i primarilly
> want a system capabel of some king of "incremental parsing" or
> "runtime parser constrution". I want the parsing logic, to be a part
> of the "game ai", i.e. the "ai" should use the same commands as the
> "general game system". I want a language that enables me to "construct
> parsers at runtime". Irony enables runtime parser construction, but I
> don't have the skills yet to implement this in Irony, and since its
> poorly documented I kind of abandoned it.
>
> A simple language to construct machines, such as:
> "state machines",
> "state machines with transactions based on probability (e.g.markow
> chains)",
> "state machines with multiple variables (fuzzy logic, neutral net,
> etc)"
> "recursive machines" that can construct "levels", "monsters" in a
> recursive/treelike fashion etc.
>

A very good idea. You are doing what a lot of us try to do, and stream
the game. You're doing somethinsg most streaming game designers never
touch, though, namely either modularity or procedural generation (you
are attempting a complex of both, procedurally generated modularity).
Its entirely achievable. I think you should step away from object
declaration in your language, and focus on representing evrry single
possible interaction between user, ai, control, and environment, as
individual machine code blocks. Two bytes for 65535 different commands
should suffice. You could easily write a macro mnemonic for it later.

--
blaaaahhhhhhhhhhhhhaaaaaaaaaahaaaahaaahah

Martin Read

unread,
Mar 12, 2011, 4:54:54 AM3/12/11
to
vsync <vs...@quadium.net> wrote:
>Yes, just supersede the article. Be aware that it has already
>propagated around the world and been read by many people however.

And also be aware that many news servers stopped honoring supersedes and
cancels over a decade ago.
--
\_\/_/ turbulence is certainty turbulence is friction between you and me
\ / every time we try to impose order we create chaos
\/ -- Killing Joke, "Mathematics of Chaos"

Jimmy Åberg

unread,
Mar 15, 2011, 3:46:00 PM3/15/11
to
(To All Lispers):

I have started to take up my studies of Lisp, due to two reasons:
1. The feedback I have got from this thread (so far), and
2. Last week I was visiting http://www.reddit.com/r/programming/ and
stumbled on this post about (great) features in Common Lisp:
http://abhishek.geek.nz/docs/features-of-common-lisp/

But I have some questions regarding on what development environment I
should use: I currently don't have either any Linux or Emacs skills,
so for the moment I have to pick some Windows environment. It would be
very nice if the environment also support for Lisp Prolog.

Any suggestions would be highly appreciated...

Jimmy Åberg

unread,
Mar 15, 2011, 3:51:05 PM3/15/11
to
By the way:
Thanks for all the great feedback so far guys, I haven't had the time
to reply, and I probably woun't have time to do it until the weekend
or so....

vsync

unread,
Mar 15, 2011, 6:30:24 PM3/15/11
to
Jimmy Åberg <jimmy...@gmail.com> writes:

I believe Lispbox <URL:http://common-lisp.net/project/lispbox/> comes
well recommended but I haven't used it.

I use SBCL + XEmacs + SLIME on Linux. I like SLIME for the IDE a lot.

LispWorks produces a commercial Lisp environment
<URL:http://www.lispworks.com/products/lispworks.html> including IDE. A
free personal edition is available but you will need to purchase a
license to be able to compile standalone apps for distribution.

Franz also produces a commercial Lisp environment
<URL:http://www.franz.com/products/allegro-common-lisp/acl_ide.lhtml>.
They also have a free personal information but they require even an
upgraded license to distribute apps, and their pricing seems to require
negotiating with some sales person.

There are many other free and/or open source Lisps which do not include
an IDE and maybe some that do. Other than SBCL I've only really used
CMUCL and CLISP. I've copied comp.lang.lisp so you can get wider input.

Eric Schulte

unread,
Mar 15, 2011, 6:58:47 PM3/15/11
to
vsync <vs...@quadium.net> writes:

> Jimmy Åberg <jimmy...@gmail.com> writes:
>
>> I have started to take up my studies of Lisp, due to two reasons:
>> 1. The feedback I have got from this thread (so far), and
>> 2. Last week I was visiting http://www.reddit.com/r/programming/ and
>> stumbled on this post about (great) features in Common Lisp:
>> http://abhishek.geek.nz/docs/features-of-common-lisp/
>>
>> But I have some questions regarding on what development environment I
>> should use: I currently don't have either any Linux or Emacs skills,
>> so for the moment I have to pick some Windows environment. It would be
>> very nice if the environment also support for Lisp Prolog.
>>
>> Any suggestions would be highly appreciated...
>

This screencast may be helpful
http://www.youtube.com/watch?v=43IiSvbyIZY

Ray

unread,
Mar 21, 2011, 12:24:29 PM3/21/11
to
Jimmy Åberg wrote:


Emacs is made for Lisp. It is a pain in the tookus to learn,
but seriously, in the long run, if you will write Lisp code,
it's the easiest and best way to go.

Bear

0 new messages