rpg-maker-design — Design talk for RPGMaker.

Re: [Rpg-maker-design] Language design

[Jon E. <je...@mi...>]

I like 'New <Type> called <Name>'.

I'm thinking about the 'is part of' thing. I partially agree, but I 
don't know if 'is part of' is any better than 'is in'.

Dan wrote:

> Overall, I think it looks good.  But then, I'm a programmer, and it's 
> a very easy language.
> My biggest complaint is with creating new objects:
>
>> Map Firstmap is in Game
>
> <Type> <Name> is in <Object>
>
> This can really be broken down into two parts:
> "<Type> <Name>": Create a new <Type> called <Name>
> "is in <Object>": This new <Type> is part of <Object>
>
> The first part, to me, isn't all that clear.   Would a random 
> non-coder looking at "Map Firstmap" realize that Firstmap is a Map?  
> Maybe, but maybe not.  I'm thinking something like
> "new <Type> called <Name>" would be clearer:
> "new Map called FirstMap".
> On the other hand, that could be adding too much typing.  We could 
> shorten it.
> "new Map: FirstMap"
> "Map called FirstMap"
> "FirstMap is a Map"
> "FirstMap is a new Map"
>
> Which one do people like best?
>
> As for the second part, I think the "in" could be confusing to those 
> who are just being introduced to Object Oriented stuff.  "is part of" 
> would probably make it much clearer, but that is, again, probably too 
> much typing.
>
>
> Related to both problems, we could make the scripting engine 
> auto-expand certain phrases or symbols when it sees them.  The user 
> could type 'ipo', and when it checks for syntax, it would replace that 
> with "is part of".  Or they could just type "is part of".
> Of course, if we end up with a GUI to create the script, it doesn't 
> really matter.
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Rpg-maker-design mailing list
> Rpg...@li...
> https://lists.sourceforge.net/lists/listinfo/rpg-maker-design
>

Re: [Rpg-maker-design] Language design

[Dan <di...@co...>]

Overall, I think it looks good.  But then, I'm a programmer, and it's a 
very easy language.
My biggest complaint is with creating new objects:

> Map Firstmap is in Game
<Type> <Name> is in <Object>

This can really be broken down into two parts:
"<Type> <Name>": Create a new <Type> called <Name>
"is in <Object>": This new <Type> is part of <Object>

The first part, to me, isn't all that clear.   Would a random non-coder 
looking at "Map Firstmap" realize that Firstmap is a Map?  Maybe, but 
maybe not.  I'm thinking something like
"new <Type> called <Name>" would be clearer:
"new Map called FirstMap".
On the other hand, that could be adding too much typing.  We could 
shorten it.
"new Map: FirstMap"
"Map called FirstMap"
"FirstMap is a Map"
"FirstMap is a new Map"

Which one do people like best?

As for the second part, I think the "in" could be confusing to those 
who are just being introduced to Object Oriented stuff.  "is part of" 
would probably make it much clearer, but that is, again, probably too 
much typing.


Related to both problems, we could make the scripting engine 
auto-expand certain phrases or symbols when it sees them.  The user 
could type 'ipo', and when it checks for syntax, it would replace that 
with "is part of".  Or they could just type "is part of".
Of course, if we end up with a GUI to create the script, it doesn't 
really matter.

[Rpg-maker-design] Language design

[Jon E. <je...@mi...>]

Alright, it's about time we got started on this. One thing I neglected 
to mention in the milestone plan mail I wrote (thanks Dan) is that we're 
going to need to design a language for all of the steps and then write 
the compiler for the language as it goes along. It's going to be really 
important that the non-programmer(s) involved give feedback on the 
language design. The whole idea is that it shouldn't be that difficult.

So for Alpha 0.1, the language will need to support the following:

Map name
Map layout (defining paths/obstructions)
Defining valid directions for the character to go

Here's a sample script supporting all of this. I really really really 
want feedback on it. I haven't slept and the chances of this being 
idiotic are not slim, though the basic language format was designed with 
help from a well-rested Dan.

Script statements end with a period.

The language is, by necessity, object-oriented, meaning everything that 
isn't an object is an attribute of that object. Objects are the actual 
"things" of the game. The only ones defined at the start of the script 
are "Game" itself and "Player". Others, like maps, are defined as their 
type, and then become objects of their own. For example, the first line 
of this script will define the name of the game. It begins with a 
declaration of the object we are using, followed by the attribute we are 
defining, the keyword 'is' and finally the name itself.

So, the way to define any attribute is:
<Object> <Attribute> is <Value>.

However, when defining several attributes of a single object, one can 
use commas, in the form of:
<Object> <Attribute 1> is <Value>, <Attribute 2> is <Value>, <Attribute 
3> is <Value>.

For example, the following script segment:

Game name is "Simple Test One".
Game author is "Jonathan Eisenstein".

Can also be written as:

Game name is "Simple Test One", author is "Jonathan Eisenstein".

Comments (further explanations of a part of the script) are C++ style, 
following \\, as in:
Game name is "Simple Test One", author is "Jonathan Eisenstein". \\ This 
is the first design of the language.

Anyway, here's the first script, demonstrating the requirements above. 
I've also added a simple NPC and a map type, even though this milestone 
does not call for it, to demonstrate how the language will look later.
--

Game name is "Simple Test One".
Game author is "Jonathan Eisenstein".

Map Firstmap is in Game. \\ Defining a new object called 'Firstmap' of 
type Map, located in the game.
Firstmap size is (10,10), type is Plains. \\ Firstmap is a grid 10 x 10 
squares across, and is of type Plains, which will be defined in a later 
milestone.

Scene Testgame is in Game. \\ Every game has at least one scene. An 
object can be part of the scene or the entire game.

Player is in Firstmap, name is "Jon", origin is (1,5), scene is 
Testgame. \\ Place the player (only one can exist) at point (1,5) on 
Firstmap at the beginning of the game.

Player movement is type4. \\ Player can move up, down, left and right. 
type2 is a platformer (left/right) and type8 includes up-left, etc.

Obstruction Wall is in Firstmap. \\ Defining a new object called 'wall' 
of type Obstruction, located in Firstmap.
Wall type is "Wall", placed from (3,2) to (3,7). \\ Type Wall will be 
defined in a later milestone. This places the wall between (3,2) and (3,7).

[Rpg-maker-design] Initial design discussion

[Jon E. <je...@mi...>]

Alright, so now that we've got the main developers on this list, I'm 
going to put up what I've come up with. If you're not one of the 
programmers, you can ignore the following, and rejoin us in the 
following paragraph.

My initial concept is to have this be a modular design. We have a core 
interpreter engine that'll be used at all times, but then there are 
other modules for use as needed by the individual authors. For instance, 
there will be several interface designs (well, at least two, as you'll 
see below) and several graphic modules, and several sound modules, 
and... that's pretty much it. This will not only ensure that a game can 
be customized to even the most minute details, but also make it 
potentially cross-compatible.

Now, for each of the component areas, we have several goals. These are 
ones I came up with from the top of my head late at night, so I'm sure I 
missed something. It's best to get any feature requests in at the 
earliest stage possible, so if you have an idea for something that 
should be implemented, talk about it with this list.

For the purposes of simplicity, I've grouped everything into 6 
components that can be worked on, for the most part,  independently. 
I'll go through each one with a brief description and list of features 
I've come up with.

1) Interpreter
This is where scripts get turned into games. Basically, there is only 
one goal here, and that's to design a simple language that scriptwriters 
can use to create powerful, full-featured games. Depending on how we go 
about this, it may be on-the-fly or a compiler.

2) Engine
The Engine is where we run the game itself once it's interpreted. Most 
feature ideas will be right here, including any gameplay features we 
want to be able to support. For instance:
-Characters
-Group combat
-Single combat
-Map movement
-Areas
-Random monsters
-NPCs
-Stat modification (levels)
-Cutscenes

3) Interface
The Interface is how the player interacts with the game itself. While 
intrinsically tied with graphics, this is not where graphical features 
will be worked on. Instead, the interface is more things like controls, 
how one loads a new script, choosing options, etc. In order to test our 
engine before getting a full graphical interface going, we're going to 
need to design a command-line program that can be used to run all 
features we support in the Engine.

4) Display
This is where things start to look nice. Once we get the engine working 
properly, we can start supporting things like... full-color maps. And 
animation. And all that cool stuff. Things we need to consider here:
-Supported image types
-Top-down 2D view
-Slightly-behind 3D view
-Wipes

5) Sound
A game's not a real game nowadays without some sound. Personally, I'm 
not going to worry about this one for a while, until we get through the 
other 4 components.
-Sound FX
-Music
-MP3 / Midi / OGG

6) Scripts
The engine can't run games without scripts. Once we get an interpreter 
working, we should be working on designing scripts that show off our 
features and demonstrate how to do certain things. Once we have an 
official release, we're also going to need a full script so there's a 
reason for people to download it.

And that's it for components. Which brings us to the final topic: Our 
short-term goals and milestones. Here's my plan, based only on the ideas 
above. This may change, obviously, with more discussion. Each alpha 
release will add more features and show them working. Essentially, each 
stage is a proof-of-concept.

Alpha 0.1: Command-line interface to character movement on 
partially-obstructed map
Alpha 0.2: Add other objects to grid with speech possible (3 statements)
Alpha 0.3: Add defined combat with one character vs 1 NPC (simple 
fight/run command)
Alpha 0.4: Add random monsters on different map types (add different map 
types!)
Alpha 0.5: Add team-based combat (simple turn-based)
Alpha 0.6: Add more options to combat (magic/powers/heal)
Alpha 0.7: Add areas (dungeons/towns/etc)
Alpha 0.8: Let characters level based on experience (levels only - not 
each stat)
Alpha 0.9: Modify party
Alpha Release 1.0: Text-based, multi-area game with random monsters and 
XP. MUD, essentially.

[Rpg-maker-design] This list

[Jon E. <je...@mi...>]

In case you're wondering, this is the private mailing list for the open 
RPG engine thingy we'll be designing. If you don't want to be involved, 
you can unsubscribe through the instructions you should have received.

Anyway, I got the project approved at sourceforge, which, for those who 
don't know what it is, is good. It means we can do collaborative work 
really easily. If you want to join the development group at sourceforge, 
the project name is rpg-maker. Because everything else I wanted to use 
was taken.

Anyway, good luck on finals.

Jon Eisenstein