Game Concept: Technical

[Threed]

Tile based is not necessarily bad. Using hexagonananalalal tiles, you get much more movement space and it seems more fluid. Alternatively, you can abndon the concept of "tiles" for guiding player movement and just use collision detection, little rectangles around special, impassible entites, to determine wheither a player is allowed to walk through them or not.

Uh... yes?
I thought of it as, "All flammable GameObjects have flag self.flammable = True. When you create fire, a Fire(range, temperature) message is sent to all GameObjects in range; if an object's flammable is True, it catches fire."

Alright; two means to the same end.

The problem is that you're going to have to add a self.flammable variable to every entity you create. =D Probably not that much, though, if you inherit from a base class... just toggle self.flammable whneverekrjlkjelkfjkljsdlkfjslkdfjslkdf

KAJUTA STAN.

What are you doing?! GO BACK TO THE CON RIGHT NOW.

There might be hot chicks dressed up as sexy fox vixens AND YOU'RE MISSING IT ALL RIGHT NOW.

[Kay]

Nice digression!

It's just finishing up. I've got some head-shot sketches I can use for my raccoon AI thing, and if I can catch an artist on the way out I'll try to get some kind of concept sketch of a Rennaissance courier. Unfortunately the vixens are more likely to be men. Some fun gaming sessions, anyway; I got to see two fellow writers, bought a (clean) otter bookmark, and talked to the rep from Sanguine, which is planning to publish my RPG book Real Soon Now.

Anyway: a gridless system can be done. The distance function in 2D is just
d^2 = sqrt( (x2-x1)^2 + (y2-y1)^2 )
I think, and
d^3 = cuberoot( (x2-x1)^2 + (y2-y1)^2 + (z2-z1)^2)
for 3D? The recent RPG "Phantom Brave" uses a gridless movement system.

More later. Closing Ceremonies.

[Kay]

No, I think the 2D distance function is:

d = sqrt( (x2-x1)^2 + (y2-y1)^2 )

"Kajuta Stan"?

I got a little sketch of a rabbit-man courier in a rainstorm; will scan and post when possible. The artist is looking for work, but that means $.

[Threed]

No, I think the 2D distance function is:

d = sqrt( (x2-x1)^2 + (y2-y1)^2 )

"Kajuta Stan"?

Stan of the Kajuta, of course.

Yes, its right.

[Kay]

I wrote some item code in lectures today. I did a Thing class with basic stats like XYZ and mass, then an Item class inheriting Thing and adding more stats like "script."

Code Select Expand

>> x = DefaultItem()
>> x.name
"Conch"
>> x.Use("look")
Response: You | see | smooth, blue, shiny thing.
>> x.Use("listen")
Response: You | hear | whoosh thing.

There's also a "Common" sentence format used for sensory input, which also makes the AIs better able to understand dialogue. It would work well with a building-block dialogue system that makes it easy for players to ask AIs reasonably complex questions. A typical command right now is "You | move | north!" (See "Level 3 AI.")

This part isn't relevent to our project, but I've got some basic journal-writing stuff going too:

2004 Nov 29, 0030:
Niss is an ai, raccan, female thing.
Kay is a lapan, male thing.
Tofu is an evil thing.
Guest is a thing.

I was daydreaming about flammability and thought it might be a good tech demo: Aqua the Fire Fox running through a burning building, blasting items with a water spell! (Or not.)

In any case, I'll keep working on the AI, objects, and world-sim on this end, trying to keep it all generic enough to work with any graphics engine that we use.

[Kay]

What do you think of tiles versus no tiles? Threed, you suggested hexagonal tiles, but that sounds hard to do mathematically, especially with an isometric display.

If we have tiles, we can have an array of Tile structures that each store the ID of a graphic to display on each graphics layer, and also a list of Objects (interactive things) in that spot.

Code Select Expand

World
\-Tile
 \-layer_1_graphic
  -layer_2_graphic (etc)
  -objects
   \-object_1
   \-object_2 (etc)

Then the world-drawing function says, for the x/y range Player can see, draw each tile along with its objects. When the AI wants to see whether something is in range, it can just scan the appropriate tiles' object lists. (It's a simple equation to find the right tile range. Good for showing movement ranges in tactical combat too.)

But if we go tile-less, the system might be more complicated and less efficient. I think it would mean still having background tiles (how else?) but with objects stored in an un-ordered list.

Code Select Expand

World
\-Tile array
\-List of objects in world
 \-Object 1
   \-X/Y location
   \-Type of object
   \-Other data
 \-Object 2 (etc.)

Then, to find out what's in range for an AI function, spell, etc., or even to find out which objects to draw, the program has to look at every single object's coordinates. Slow.

What else could you do to make a tile-less world practical? Create a frequently-updated, area-based lookup table of objects?

By the way, my own thinking about the gameplay is muddy. I had been picturing:
-Zelda-like movement (limited to whole-tile steps?) in a tile-based world
-Lifting/throwing/jumping; I seem fixated on this
-Non-Zelda-like combat: either tactical (see "Final Fantasy Tactics," "Disgaea: Hour of Darkness") or, more likely, highly stylized and emphasizing non-lethal battle. (Battles are rare and usually end with bribery, surrender or fleeing.)

Suule, you seem to have emphasized adventure-style gameplay -- finding the right object and deciding where to use it. I support having some of that, and using it as a way to limit where the player can go rather than giving them completely free reign over the game world. Checkpoints, rockslides, and mysterious doors can block paths.

I read that the creators of "Deus Ex" spent a lot of their time figuring out what kind of game it was.

"That little * Chrono, he said Gato, give up your Silver Points
I said Chrono, I ain't fightin' you, amigo, so put down your sword and let's smoke this joint."
--"Chrono Trigger: Team Gato," www.ocremix.org

[Threed]

The dissonace is having tile-based graphics with a freeform movement system!

@Finding nearby tiles and their items:

I think using a Binary Search would make this much more efficient, if the list of objects were sorted. But that requires sorting, resorting, and searching.

Having said that, the actual performance hit for iterating through an unsorted array is not very bad; most users wouldn't notice unless you had thousands upon thousands of objects all loaded at once.

Problem is, you're going to have to have some kind of coordinate system to lay down objects - what's the granularity? Is 1.1 similar to 1.01?

Hexagonalalalala isn't too bad; it actually adds, like, 4 more possible areas of movement - 8 potential moves, almost freeform movement, but not quite; however, what are the benefits of a freeform system like that? If this were an FPS you could argue that you might pull some "emergent behavior" like jumping between two very hard-to-get-at-rocks.

Zelda - at least on the SNES - was tiled based. It seemed like you could move in every direction, but attacking or throwing objects would only go in four directions; you had the illusion of freeform movement, but not the benefits, which I thought was weird.

You could take it to the extreme and divide everything up into bazillions of "tile" based quardinates, then each object has the potential to spawn multiple mini tiles, thus creating the illusion of freeform phatness, but I've never done that before, so its all theory. (Theoretically this allows for neat things like scrawny characters being able to fit where fatter characters wouldn't, or can't, because they occupy way more characters than the slimmer ones that just snuck between two big rocks).

Checkpoints, rockslides, and mysterious doors can block paths.

Not necessarily bad - I played Max Payne 2 three times in a row, mainly just to get the good ending, the one I so richly deserved, RIGHTEOUSLY DESERVED, but it was still a blast even on the third go round, but maybe I just liked shoot-diving into a crowd of gangstas and thugs to save the day.

Although I'd like to blow up the world some day, and leave my initals floating in outer space using the Earth-debris.

[Kay]

Uh, hexagonal would mean six-way. You mean octagonal?

Are you and Suule currently working on anything, graphics-wise? I've been staying away from that end of it.

I'm thinking tile-based is the way to go, even if it means random thrown crates always land right-side-up along a grid. And even if it means the player can only walk in increments of one tile (though maybe in more than 4 directions). This system is simpler than using a lookup table. The main benefit of having pixel-accurate placement of objects is action-oriented gameplay, and it doesn't sound like we want even as much real-time running-around-with-a-sword as Zelda, because that'd require action-oriented combat AI.

[Threed]

yah. that math shit boggles my cubes, mun.

Are you and Suule currently working on anything, graphics-wise? I've been staying away from that end of it.

"Not I," said the little bunny rabbit, sinking his fangs into your neck.

I'd say there's still junk to discuss, language, user interface, map file format, etc,, etc, other things deserving of kung-fu action.

Alternatively I could just start hacking away in a language I know best and then try to backport the code to whatever (trust me, it will be backporting).

[Kay]

(Cue Tom Jones' "Kung Fu Fighting")

-I don't know about you, but I've got law exams coming up, so I'm not going to work (much) on this until the 22nd or so.

-Shouldn't you have a "vorpal bunny" graphic, then? You too, Suule!

Some rambling on other topics:

-Language: I'm going to start looking at PyOGRE to see if I can figure it out. If at all possible I'd like to use Python as the main language, and invoke whatever voodoo (or even nVidia) you like from there.

-File formats: One way to store complicated data is Python's almighty Pickle module. I've had trouble trying to store an entire big object at once (like a whole AI) but success at storing each piece in a fixed order. With a fixed format or some clever alternation between Pickled objects and XML-like tags (saying "the next 42 lines are type X"), loading and saving shouldn't be a problem.
For my old graphical NISS, I made a map editor program and was able to save/load with it. I found that it was best to pickle the individual variables rather than the objects -- eg. ten "int"s rather than an object consisting of ten "int"s -- because that format was about 1/10 the size of storing raw objects!
For the item code I've been writing, I've managed to load and save data in plain text format, so that items can be edited in Notepad. I've got support for comment lines, too. For a real game it'd be unwise to have everything in the open, though.
If you mean "What should be stored in the map files?", I think:

Code Select Expand

-Floor graphic map: tile-based
-Possible second "floor" layer: for flat decorations like small rocks
-2D height map: what's the elevation of each patch of ground? (Walls are very high patches of ground against much lower surroundings. Note that this system is like "Doom II"'s in that different floors of a building have to be different maps.)
-Texture to apply to the sides of each floor patch, if it's not the same height as its surroundings. (Easiest if all four sides are the same.)
-2D map of objects (if there's a limit of one per tile and they're assumed to be on the ground) or unordered list.
-2D obstruction map: passable/impassable/trigger script?
-Possible 2D script map: run a script when someone steps here?

-As for the interface, I'm of the "Donkey Kong Country" school: keep nothing on the screen unless it's relevant. Given that this isn't an action game, there aren't any "meters" that need constant attention, so I'd devote the screen to showing the game world and maybe have a little "what's in your hands at the moment" display. We'd need a title screen with "New Game" and "Load" options; an in-game "System" screen, an "Inventory" or "Party" screen, and a "Conversation" screen.
I was thinking keyboard control -- hold down the right arrow to go East or Northeast -- but keyboard-and-mouse movement is easy enough and is important if we're to have buttons. Important for any modern PC game, really.
I guess that starting conversation with an NPC could pause the rest of the game, so that you won't be attacked while talking, but NPCs have to talk to each other in real-time, as the player won't appreciate having _their_ end of the game pause!

-What confuses me is the idea of party members. If the player creates a fox PC and we have all this tile-based movement and item-manipulation gameplay, the player is going to expect that they can leap Mario-style across pits with their whole party, even though they've got the big tough boar NPC carrying fifty pounds of armor.
I would rather have NPCs following the PC, and limit the game to the more sedate pace of an adventure/RPG, than make the PC a loner and throw in platform-jumping gameplay. I don't know how to do good action physics or combat AI beyond "charge at the PC and run when you're hurt," but I know how to tell a story and create interesting characters.

I want to explore a graphical world meeting characters who remember me, react to the character I've created and portrayed, have thoughts beyond their scripted dialogue, and give the impression that they're alive. I want to be convinced that my sidekick is following me because he likes me, and not because the story gods ordered him to. Secondarily, I'd like to choose from multiple character races, solve puzzles, walk around interacting with objects for fun, and uncover an interesting story. Other gameplay elements are less important to me. What's your main vision for this project?

Will cross-post this last comment to "Outline."

[Kay]

Check out the new "Combat Demo" topic. I've got a playable little text-based combat system whose code could be recycled for a real game.

[Kay]

Two other possible resources are PyUI here, a good-looking Python-based user interface package that works with various graphics engines...

...and this interesting list of RPG monsters we could use, here. It's got raccoons.

While on the second topic, it's worth mentioning the Console RPG Cliche List.

[Kay]

Last exam (Contracts) is on Wednesday afternoon -- more free time starting then.

I've begun setting up OGRE and PyOGRE, but the help files are less than helpful:

Implementation: pyogre use boost.python to make the binding. pyste to generate the c++ binding code (which use boost.python) from simple specification. Scons is used to build the project.

Any idea on where the OGRE and PyOGRE files need to go for me to run anything? Running TerrainDemo.py, for instance, tells me:

Traceback (most recent call last):
  File "C:\Python\pyogre\python\ogre\demo\terraindemo.py", line 1, in ?
    import localogre as ogre
  File "C:\Python\pyogre\python\ogre\demo\localogre.py", line 4, in ?
    from ogre import *
  File "../..\ogre\__init__.py", line 1, in ?
    from pyogre_ import *
ImportError: No module named pyogre_

And there's this matter of building OGRE and its third-party libraries, somehow, in Visual C++ to get it set up for PyOGRE to use it...? Suppose Visual C# would work?

On the SDL end, I know a bit about running non-isometric tiled graphics, but nothing useful about sprites.

[Kay]

I've got free time now. Any advice on getting OGRE and PyOGRE set up, anyone?

[Threed]

I've got free time now. Any advice on getting OGRE and PyOGRE set up, anyone?

http://www.ogre3d.org/phpBB2/viewtopic.php...ighlight=pyogre

Precompiled binaries of OGRE3D and PyOGRE bindings.

Sorry, incommunicado, life's been hectic, consulting is fun but hard work, also, its cold.

Love,

Threed.