[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Global game design (Was: Re: [Adonthell-devel] Battle System)

From: Ricardo Colon
Subject: Re: Global game design (Was: Re: [Adonthell-devel] Battle System)
Date: Wed, 30 Jan 2002 14:18:58 -0500 (EST)

Another game that's good at creating a world where NPCs have their own
life is Shenmue for Dreamcast, which in some cases would be the ideal RPG even
though it's linear.

Shenmue is revolves around Ryo Hazuki, and the murder of his father(right
in front of Ryo's eyes). The murderer was a man named Lan Di. Your role in
the game is to investigate the matter and avenge your father(hopefully).

The game is a 3D RPG of sorts feels like an interactive movie. The
game's creator actually create a new classification for the game.
He describe the game systems as FREE (Full Reactive Eyes

Shenmue: Chapter I(they're planning on having 16 chapters) takes place in
Ryo's hometown, Yokosuka. The story takes place in 1986. You figure out
clues by speaking to everyone(i.e. voice not text, unless you'd rather have it 
the other way).
As you talk to more and more people, the story slowly unfolds.

It really feels as if you're place inside of a movie. It's always an
interesting game to watch, since it feels so cinematic. My dad, whose
never even played video games before liked watching me play and see the
story progress.

The best part about Shenmue is that you don't have to necessarily stick to
the plot. All of the NPCs work on their own schedule. Some NPCs like to
hangout at the park. Others walk around the shopping. Others stay home.
It really feels like you're living in a town with normal people that have
their own things to do.

Your character can also do more than just talking. You can go to the local
convenience store and buy some soda,potato chips,fried squid..whatever.
You can also call people to see what's up.

One cool feature is the game's sense of time. The stores in the shopping
district have their own house. Some are open all day. Others only at
night. Others are open all day.

The game does an amazing job of fully immersing yourself in its own world.
I've never seen any game like it. Personally, I don't think Shenmue could
have ever been a 2D title.

I don't necessarily think that this kind of detail would need to be added
to Adonthell.

I guess the question we'd need to ask ourselves is if we really want
players to be immersed in the NPCs world, and thus delay the resolution of
the main plot. In Shenmue, it's encouraged, but I'm not sure if this is
what we want.

Well, that's all I have to say.

                                                -- R:

On 30 Jan 2002, Alexandre Courbot wrote:

> > Ummm.. wasn't that what we were planning to do? Remember Alex started
> > redesigning the map-engine in a server/client way to accomodate exactly
> > such a feature. :)
> Yes. And the random ideas maturated quite well during these few weeks.
> Moreover I had a great example of game design that I think would
> perfectly fit to Adonthell. Hang on, it's gonna be... space. ;)
> I recently bought Terminus. As you probably don't know this game, it's a
> commercial title that has the particularity to be shipped for
> Linux/MacOS/Windows in the same box (otherwise, how could I play it,
> hehe). But it has another particularity, much more important: it's
> probably the best designed game I have ever seen. I'll have to come to
> some description of the game.
> Terminus (,
> is both a space
> simulator and a RPG game. You can either engage as a military, become a
> pirate or run as a mercenary. In the latter case (the most interesting)
> you'll have to manage your ship(s), gain money, talk to people, and so
> on. You travel in the whole solar system, which planets & satellites are
> also modelized. I insist that the game as a whole RPG system - but the
> most interesting is the way they implemented multiplayer mode &
> persistance.
> Most often in games, there are a number of key elements/characters, and
> a lot of less important stuffs. In Terminus, you'll often meet others
> ships and people. The interested thing is that:
> -A ship is never a "random" thing or ennemy because
> -Each ship belong to another NPC character (there is quite a lot of
> them)
> -Each characters go on their own business, depending on their alignment.
> When I say they go on their own business, if you and Random J. Pirate
> are at the two opposite ends of the solar system, you can still locate
> him on the radar and know what he is doing. NPC's hijack each others,
> make contracts, trade, travel, just like a real player. They do not
> depend on you AT ALL. You can sit down and look at how the world
> evolves. The game world still exist, with or without you. It's totally
> persistant.
> -In these conditions, you can guess that implementing multiplayer is
> quite easy. Such a design allows the game to be played both in single or
> multi player, with the same engine, without any change. To my eyes, it's
> the ideal in game design.
> How would it work for us? Let's take the map system. A map must be able,
> like Terminus, to run with characters doing their own business on a
> machine, without graphisms (they are only on the 'client' part), and the
> player would only have a special schedule that reacts to the player
> input, just as we do now.
> A classic map would just contain information for the game to run. No
> displaying, nothing. From this class would inheritate another map (or we
> could connect others data structures), with the same abilities of
> course, but also ways to render on screen.
> In single player mode, you'd then have the game that runs on this map
> with graphical capabilities, and the mapview would just render it. No
> network connections, no performance lost compared to a totally single
> player game.
> In multiplayer, the server would run a non-graphical capable map.
> Clients that connect to it are sent the map information they need to
> update their local copy of the map. That is, the client map is exactly
> the same as the single-player one (and has all the properties of the
> server one, as it inclues it), but instead of running the game, it gets
> updated by the information the server sents:
> ------------------                               --------------------
> |                |        Update information     |                  |
> | Client map     |  <--------------------------- |  Server map      |
> |(server copy)   |                               |    (runs)        |
> ------------------                               --------------------
> In this case, we need a way to serialize the necessary map data to send
> it to the client. There is also a network layer that is used, that isn't
> needed in single player mode. As you guessed it, a single player game
> can easily turn into a multiplayer one: clients connects to the player's
> machine, but will experience pings while the local player will not even
> use network, as he directly renders the master map.
> Uuuuuhhh, saying that I realize it's much like Quake III dedicated or
> not servers. Which makes me think it's the way to go! :)
> Another advantage is that the multiplayer constraints doesn't need to be
> considered immediatly. You can program the classes for single player
> only, then extend them with serializing and communicating capabilities
> to get a multiplayer stuff. Also, you can easily tune/change the
> communication protocols if they doesn't fit first.
> The result for single player games would be exactly the same as the
> stuff we had with Waste's Edge - NP characters were already not
> different from the player, and they were also doing their own stuff.
> This structure has the advantage of being much clearer and extensible,
> especially extensible to multiplayer games.
> Please tell what you think - I thought a lot about it and it seems to me
> that it would perfectly work. But until I start programming it a bit, we
> can't really know whether or not it's the best idea.
> Alex.
> --
> _______________________________________________
> Adonthell-devel mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]