What do YOU want in a RPG?
Rainer Deyke
I've started designing a role playing game. Current features include:
1. Top down world based on 16x16 tiles (like Ultima 6)
2. 320x200 resolution with square pixels
3. Advanced character interaction. If you ask the right questions,
NPCs will give you valuable hints. If you ask the wrong questions
they may refuse to tell you something or may even attack you if
you insult them.
4. Advanced plot. Although there is a single main plot, it won't be a
typical "kill evil dude and save kingdom" type plot. I'm still
working out the details, but it will probably involve a lot of
internal conflict.
5. Depth. Dynamic, well rounded characters. A real, believable world
with a history, believable cultures (each with their own heroes,
practices, and prejudices), and laws of nature that include a
believable system of magic.
6. No classes, no levels - instead, different skills and attributes
that increase with practice.
My question[s]: What do YOU want? Are the above acceptable? Marketable?
What should I keep? What should I add? What should I change?
--
+-----------------------------------------------------------+
| Rainer Deyke (rai...@mdddhd.fc.hp.com) |
| "Is it me or is it shadows that are dancing on the walls? |
| Is this a dream or is it now? |
| Is this a vision or normality I see before my eyes?" |
| - Iron Maiden |
+-----------------------------------------------------------+
Nicholas Marrone
>
>I've started designing a role playing game. Current features include:
>
>1. Top down world based on 16x16 tiles (like Ultima 6)
>2. 320x200 resolution with square pixels
320x200 is not square pixels, 320x240 is square pixels, but to do that
you'd have to use Mode X. Also, 320x200 won't fit 16x16 tiles in evenly.
Are you going to have a text scrolling box at the bottom of the screen?
>4. Advanced plot. Although there is a single main plot, it won't be a
> typical "kill evil dude and save kingdom" type plot. I'm still
> working out the details, but it will probably involve a lot of
> internal conflict.
Good plot is DEFINATELY good.
>5. Depth. Dynamic, well rounded characters. A real, believable world
> with a history, believable cultures (each with their own heroes,
> practices, and prejudices), and laws of nature that include a
> believable system of magic.
>6. No classes, no levels - instead, different skills and attributes
> that increase with practice.
Sounds good to me. This system (#6) _and_ the level system work well.
Good luck!
Nick
Nicholas Marrone
Skywalker
> : >2. 320x200 resolution with square pixels
> : 320x200 is not square pixels, 320x240 is square pixels, but to do that
> : you'd have to use Mode X. Also, 320x200 won't fit 16x16 tiles in evenly.
> : Are you going to have a text scrolling box at the bottom of the screen?
> extensively and have found mode 13h to be better suited for the job.
> This means that will have to use 320x200. However, I can still get
> square pixels by writing some value to some port. This creates a small
> (20 pixel high) blank area at the top and bottom of the screen. Yes, I
> am planning on using the bottom area for text scrolling.
Pardon my ignorance, but wouldn't the blank area be BLANK, ie, inaccessable,
not there? How would you put text there?
BTW, where are you physicly?
-Joshua Gustafson (skyw...@kaster.cts.com)
Rainer Deyke
: rai...@deyke3.fc.hp.com (Rainer Deyke) wrote:
: >
: >I've started designing a role playing game. Current features include:
: >
: >1. Top down world based on 16x16 tiles (like Ultima 6)
: 320x200 is not square pixels, 320x240 is square pixels, but to do that
: you'd have to use Mode X. Also, 320x200 won't fit 16x16 tiles in evenly.
: Are you going to have a text scrolling box at the bottom of the screen?
320x200 can be square pixels. I have used both mode X and mode 13h
extensively and have found mode 13h to be better suited for the job.
This means that will have to use 320x200. However, I can still get
square pixels by writing some value to some port. This creates a small
(20 pixel high) blank area at the top and bottom of the screen. Yes, I
am planning on using the bottom area for text scrolling.
--
+---------------------------------------------------+
| Rainer Deyke (rai...@mdddhd.fc.hp.com) |
| "A plague rages in all our hearts" - Napalm Death |
+---------------------------------------------------+
Rainer Deyke
: Re: Re: What do YOU want in a RPG?
:
: > : >2. 320x200 resolution with square pixels
: > : 320x200 is not square pixels, 320x240 is square pixels, but to do that
: > : you'd have to use Mode X. Also, 320x200 won't fit 16x16 tiles in evenly.
: > : Are you going to have a text scrolling box at the bottom of the screen?
: > 320x200 can be square pixels. I have used both mode X and mode 13h
: > extensively and have found mode 13h to be better suited for the job.
: > This means that will have to use 320x200. However, I can still get
: > square pixels by writing some value to some port. This creates a small
: > (20 pixel high) blank area at the top and bottom of the screen. Yes, I
: > am planning on using the bottom area for text scrolling.
: Pardon my ignorance, but wouldn't the blank area be BLANK, ie, inaccessable,
: not there? How would you put text there?
What I meant was that the bottom area of the accessable screen will be
used for text scrolling. This is the area above the blank area.
: BTW, where are you physicly?
Fort Collins, Colorado, USA
Skywalker
> : > extensively and have found mode 13h to be better suited for the job.
> : > This means that will have to use 320x200. However, I can still get
> : > square pixels by writing some value to some port. This creates a small
> : > (20 pixel high) blank area at the top and bottom of the screen. Yes, I
> : > am planning on using the bottom area for text scrolling.
> : Pardon my ignorance, but wouldn't the blank area be BLANK, ie, inaccessable
> What I meant was that the bottom area of the accessable screen will be
> used for text scrolling. This is the area above the blank area.
OH, Ok. I get it now. :-)
-Joshua Gustafson (skyw...@kaster.cts.com)
DaveBixler
thinking about for awhile.
o Network aware, TCP/IP and Netware. A non-interactive adventure seems
dry
compared to even text based MUDs. Need to find a good way to do the
network stuff without worrying about the protocol.
o (Related to above), Multi-Player. If this is done on a multi-tasking
OS, you can
even create NPCs using different processes or threads. I once made a
mini-MUD on a Unix system where each NPC was a separate process.
Depending on the level of complexity of the NPC, other real players could
barely
tell that they were computer controlled.
o Graphical. The interface should be as graphical as possible without
being
obtrusive. Further, depending on your audience, you must be careful not
to
"pollute" the screen with useless pictures. I was always fond of the
Ultima(tm)
style of interface, and this would work well across networks. 3D is
obviously
nice, but you run into trouble when it comes to world sizes. The best
place to
be here is the middle of the road. Use enough graphics to make the games
interesting, but don't take away the chance for the user to use their
imagination.
I always think back to the reason why I orignally began playing D&D, and
it
wasn't fancy graphics. It was the chance to expand my mind using my
imagination to take me places which could never exist.
o If you're trying to target a large audience, you pretty much are
relagated to
DOS or Windows. Try using WinG and see what you come up with. The nice
thing about Windows is not having to worry about what sound card you're
using
or what resolution you're running in. Windows (more or less) hides this.
Hope this is useful.
--Dave
Alex Curylo
daveb...@aol.com (DaveBixler) writes:
> o Network aware, TCP/IP and Netware. A non-interactive adventure seems
> dry compared to even text based MUDs. Need to find a good way to do the
> network stuff without worrying about the protocol.
It's called "the Comm Toolbox".
> o (Related to above), Multi-Player. If this is done on a multi-tasking
> OS, you can even create NPCs using different processes or threads.
It's called "the Thread Manager".
> o Graphical. The interface should be as graphical as possible without
> being obtrusive.
It's called "the Macintosh Human Interface Guidelines".
> o If you're trying to target a large audience, you pretty much are
> relagated to DOS or Windows.
Oh! Sorry. I was wondering why you were talking as if all these
concepts were somehow novel or innovative. Hmmmm, I guess you're SOL
then, good luck with all the work it takes yourself to get up to the
level you'd start out from on the Mac, otherwise known as "The Ultimate
Game Programming Platform".
> --Dave
Alex Curylo first....@mindlink.bc.ca (604)451-5323, fax -1359
*** First Ascent: Mac programming, UP paragliders, indie CDs ***
Robert Cassidy
English) wrote:
> Actually, while you are correct that the Windows/DOS market is much
> larger, consider the fact that it is *easier* to program for the
> consistent virtual Mac platform then it is for the Wintel platform and
> that the cost of troubleshooting/debugging Mac software is probably far
> lower because you have a more consistent interface to deal with (the Mac
> clones must pass a compatibility suite from Apple to keep their license,
> BTW).
>
> Also, the market for Macintosh games is FAR larger than you might
> suspect, and the PowerMac is so much easier to program for that it is
> ludicrous.
There are very important lessons to be learned here. The PC world has
roughly 6x the entertainment sales and 10x the number of developers than
the Mac world. What that means is that even though there are more PC's to
buy, there are more competing products to take sales from you. The Mac has
much more opportunity to make money. Would you rather enter a saturated
market, or one that still has a shortage of suppliers? Hmmm.
Unless you are convinced that your idea is *so* much better that you will
rise above the army of competing developers to take the lions share of
that $700M market, then you will probably make more money on the Mac
community than the PC.
If only developers had any sense of economics...
--
Bob Cassidy
UC Irvine
Gavin Estey
eng...@primenet.com "Lawson English" writes:
>
> PC/MS-DOS Windows Macintosh Other Total
>
> Entertainment $403.6 $218.9 $93.6 $716.2
>
>
Nothing against macs but doesn't this mean that if you release a game that
works under DOS and Windows you will be aiming at a market nearly 7 times
bigger that the Mac market?
--
Gavin Estey
===============================================================
E-MAIL ga...@senator.demon.co.uk PHONE +44 (01276) 476503
S-MAIL 2 Lovells Close, Lightwater, Surrey, GU18 5RS, ENGLAND
===============================================================
Real programmers curse alot, but only at inanimate objects.
Robert Cassidy
> In article <3p738b$c...@news.primenet.com>
> eng...@primenet.com "Lawson English" writes:
>
> >
> > PC/MS-DOS Windows Macintosh Other Total
> >
> > Entertainment $403.6 $218.9 $93.6 $716.2
> >
> >
> Nothing against macs but doesn't this mean that if you release a game that
> works under DOS and Windows you will be aiming at a market nearly 7 times
> bigger that the Mac market?
Yes, but you're also releasing into a market that has 10x as many
competitors. If you were to write a non-combat FS, your only competition
would be MS FS 4.0. A helicopter simulator has no competition. There are
no decent driving games/simulators. The list goes on and on. Of that $93M,
5% is probably Myst. Each company can command a high percentage of the
market. No product could come up with 5% of the PC market ($35M in sales),
I'd be surprised to see 1%.
Also remember that Bandai is aiming for 500,000 Powerplayers in the first
year. Those are 100% entertainment machines - probably $20M in
entertainment sales (given 1 40$ title/machine) at the least - wouldn't be
surprised to see $40-$60M should they sell so many boxes - all of this
over what Macintosh brings in. Assuming standard growth, the Mac
entertainment marketshare could jump 20% or more in the next 1-2 years
bringing it to the 1:6 or 1:5 range.
Added to all of that is the fact that Mac games are typically easier to
write and much easier (cheaper) to support - profit margins are greater.
Deirdre
times as many titles. E.g. the competition is stiffer.
_Deirdre
Alex Curylo
> that the cost of troubleshooting/debugging Mac software is probably far
> lower because you have a more consistent interface to deal with (the Mac
Dramatically so. One of my ongoing contracts is National Geographic's
ZipZapMap! series (simple 2D sprite graphics, pretty much). The
developers, Promark, have 4 DOS/Windows programmers fulltime, and for
the Mac, well, I spend maybe 10 hours a month average. Mind you, they
do most of the program design too, but my beta cycle is about three
days and theirs is about six weeks. Mainly because once mine works with
Color QuickDraw and without Color QuickDraw, well, it works, except for
the odd System 7-only call I slip in carelessly. Theirs always needs a
long list of patches for this video card, that sound card, etc.
And it's just amazing what they have to do for themselves. We had a
conversation a couple weeks ago about the sound support libraries they
have to write for the new ZZM language-teaching game:
Brady: "What kind of sound library do you use? I like the way you got
the Mac version to do multi-channel sound."
Alex: "Uh, it's called the Sound Manager."
Brady: "We're going to write a DLL to manage all the different sounds
we need and index them by an ID. Can you do something like that
easily?"
Alex: "Uh, I am already, it's called the Resource Manager."
Brady: "And then we'll have an .SDB file to go with each .GDB file, and
we'll keep the appropriate .SDB open and have a sound index stored with
each piece in the .GDB, is that file management difficult for you?"
Alex: "Uh, no, I already have pretty much that available, it's called a
resource fork, if I add one GetResource() call to GetPiece() then I'm
done."
And they figured it would take six days to add this functionality to
the Windows product. Ho ho.
Lawson English
: In article <3p738b$c...@news.primenet.com>
: eng...@primenet.com "Lawson English" writes:
: >
: > PC/MS-DOS Windows Macintosh Other Total
: >
: > Entertainment $403.6 $218.9 $93.6 $716.2
: >
: >
: Nothing against macs but doesn't this mean that if you release a game that
: works under DOS and Windows you will be aiming at a market nearly 7 times
: bigger that the Mac market?
: --
True, but you can be certain that the sound I/O will work across all
models, and that if your test for QuickTime 2.0 and the MIDI instruments
file returns positive, you know that the machine will support MIDI music,
regardless of teh hardware that the user has installed.
You also know that you can test for multiple monitors and use 'em all if
it makes sense and write directly to the screen buffer, or draw
off-screen using your own custom routines and blitt it on-screen using
your own custom buffer or use the built-in blitter OR you can draw
directly into off-screen VRAM on an accelerator card and let the
accelerator take care of things for you.
The ability to do this dates back to 32-bit QUickDraw, which is about 6
years old now...
You can also test for the presence of a network and use the same API to
communicate with someone over a twisted wire cable or EtherNet or
microwave (been available in the twisted wire form since 1985).
You can also localize your interface to work for Japanese or Korean or
Chinese or whomever. Been able to do that since Apple invented TrueType.
In fact, that is why Microsoft licensed it from Apple (they were supposed
to furnish a PostScript clone in exchange, but didn't, I understand), but
MS has taken a lot longer to get true internationalization going.
What all this means is that the Mac gives one a much more consistent
hardware and software platform so that programmers can spend less time
debugging and more time programming or designing.
Doom graphics for the Mac are 640x480, so the graphics standards that the
Mac uses can translate into nicer games graphics also.
Bottom line is that there are more potential Windows/DOS customers, but
the overhead of programming a game on the Mac is much lower, and the
overhead of user support is MUCH lower.
--
-------------------------------------------------------------------------------
Lawson English __ __ ____ ___ ___ ____
eng...@primenet.com /__)/__) / / / / /_ /\ / /_ /
/ / \ / / / / /__ / \/ /___ /
-------------------------------------------------------------------------------
Alex Curylo
eng...@primenet.com (Lawson English) writes:
> In fact, that is why Microsoft licensed it from Apple (they were supposed
> to furnish a PostScript clone in exchange, but didn't, I understand), but
Oh no, they finished and shared TrueImage, as per contract, no problem
there.
Of course ... what kind of performance and compatibility would you
EXPECT from a Microsoft product? Suddenly Adobe didn't look all that
evil after all.
Byron K Guernsey
>:If you must know... Here's my list for an RPG, some of which I've been
>:thinking about for awhile.
>:
>:o Network aware, TCP/IP and Netware. A non-interactive adventure seems
>:dry
>:compared to even text based MUDs. Need to find a good way to do the
>:network stuff without worrying about the protocol.
>:o (Related to above), Multi-Player. If this is done on a multi-tasking
>:OS, you can
>:even create NPCs using different processes or threads. I once made a
>:mini-MUD on a Unix system where each NPC was a separate process.
>:Depending on the level of complexity of the NPC, other real players could
>:barely
>:tell that they were computer controlled.
>:o Graphical. The interface should be as graphical as possible without
>:being
>:obtrusive. Further, depending on your audience, you must be careful not
>:to
>:"pollute" the screen with useless pictures. I was always fond of the
>:Ultima(tm)
>:style of interface, and this would work well across networks. 3D is
>:obviously
>:nice, but you run into trouble when it comes to world sizes. The best
>:place to
>:be here is the middle of the road. Use enough graphics to make the games
>:interesting, but don't take away the chance for the user to use their
>:imagination.
>:I always think back to the reason why I orignally began playing D&D, and
>:it
>:wasn't fancy graphics. It was the chance to expand my mind using my
>:imagination to take me places which could never exist.
>:o If you're trying to target a large audience, you pretty much are
>:relagated to
>:DOS or Windows. Try using WinG and see what you come up with. The nice
>:thing about Windows is not having to worry about what sound card you're
>:using
>:or what resolution you're running in. Windows (more or less) hides this.
>:
>:Hope this is useful.
>:
>:--Dave
You've just described The Kingdom of Drakkar. Graphical/Multi-Player/PC/Windows/
literally 1000's of NPC's eating up all available runtime on massively fast system.
However, the Kingdom of Drakkar is only available through the MultiPlayer Games
Network. (1-800-get-game) If this comes across as an advertisement then please
forgive me...you simply described our product to a T so I thought you should be
aware that it already exists.
Byron
Kenneth C. Finney
rmca...@uci.edu (Robert Cassidy) wrote:
>In article <3p738b$c...@news.primenet.com>, eng...@primenet.com (Lawson
>English) wrote:
>
>There are very important lessons to be learned here. The PC world has
..
>Unless you are convinced that your idea is *so* much better that you will
>rise above the army of competing developers to take the lions share of
>that $700M market, then you will probably make more money on the Mac
>community than the PC.
>
>If only developers had any sense of economics...
>
SHHHHHH!!!!You aren't s'posed to tell anybody...
Scooter
-------------------------------------------------------
Keep cool, but do not freeze. - Kraft Mayonnaise Jar