[idea] New project coming - The Theatry. (may be long)
Vlad Grynchyshyn
I forged this idea for a long time (a year or so). Just for case it is fated
to die, I decided to send it here and check if it is worth enough to start
it. I know it looks a bit too much, but everything below does not means I
will do all of that if something is voted to do not do it - these are jut
ideas that I would like to know if they're good enough to start something
like below and what from below is really worth to do at all.
The idea is to create a sort of simplified modeling tool with simplified
programming language ("program" here will be called "scenario"), where you
can in addition to populating database about monsters and items create some
rules for interaction between them, interaction with user interface and user
actions, interaction with timeline and interaction between scenarios
themselves. So, instead of writing tonns of C++ code, scenario writer will
be able to create a sort of model of game - all the rules described in much
more convenient way.
The idea then extends to quite remarkable area - n-tire development -
separating of game engine from the code and user interface.
The idea is to represent the game in 4 tires:
- Database that describes items, monsters, levels, rules for levels
generating, rules for interactions, scenarios (quests and complex
interactions, such as smithing weapons or herbs growing), screens data
(rules about populating screens by data, for example, inventory list).
- Engine - very generic engine that is a host for game. You select game
database and engine runs it. Because game model database will be a sort of
well-documented standard, engine can be developed in a lot of very different
platforms and languages by anybody.
- Client data - separate part of the game database that describes data
specific for the game client. Sounds, graphics, additional messages, video
etc.
- The client itself - it is a wrapper written around the engine. ASCII,
Java, Windows applications are examples. The client is responsible for
representing the interface, provide user input into the engine, provide
design of screens and display data prepared by engine for screens.
A bit more about the last thing - connection between game engine and the
client.
There will be list of clients supported by game. For every client, you will
define additional data. For example, if you have item class - sword, for
graphical client you will have additional properties - image of how that
sword looks like on the ground, how it looks like in the inventory list, a
sound how it sounds when dropped on the floor etc. If you have 3-D client -
images will be different, so for another client you will have different set
of properties. The client-specific data will be stored in a separate
database files, so, for example, to play a game in ASCII client, you will
have to download only 2 data files - core game data and ASCII client data
(actually, no much - just characters of how every item class or every
monster is represented on map). Such things as map scrolling, scaling,
graphics around the map and controls, user input and selection from list of
items etc. are up to the client. The client, however, should have clear
description of every screen data and what is expected from the screen (for
example, "select metal item from list for smithing").
It all should follow the concept "define game rules, the rest is up to the
game-masters about how to organize game-playing". "Game rules" here is a
game model database. Game-master here is developer of the game client and
artists that populate data specific for that client. Engine stands
separately from that - it is just the a tool to run everything.
It is very comparable to how theater "works" from inside: there is scenario
writer that writes good play or operetta (game core rules, characters and
their roles etc.). There is a theater personnel that staging it
(game-masters - developers of client and graphics artists). There is a game
engine (theater scene, theater mechanisms). There is audience (game
players). That is why I called it "The Theatry". I wanted to call it "RPR
Theatry", but it seems covers a bit larger area than just RL or RPG.
(You can beat me for that name if it is too ugly, I would not protest to
name the approach and the system differently if some other name is better to
your opinion).
The goal of Theatry is separation of development of the game itself, engine
(based on some technical standards that describe data that should not be
very large), and client (design whatever you like to for game you have). And
also try such approach and see if universal client is possible (engine is
possible for sure), so games like RL could be developed without a single
line of C++ code and much quicker.
The most "probable" solution for above idea in obvious time is following:
Because my skills, I can very easy write an interface for Theatry - game
editor/construction kit/scenario editor. It will be Web-based interface
written using C# and hosted somewhere (luckily I already have place where to
put it). Using C#, I can also write a prototype of game engine, and simple
client application for it (with no design at all, just data, ASCII-based map
and user input). I will start from the most simple parts to create something
to start from, then extend/improve it in the process. I would not release
specifications for game database to write other engines (for example,
portable open-source C++ engine) till I develop the concept to the state
when such games as ADOM could be developed without a single line of C++ code
for the game model part, and also a bit extend the model to use graphics as
well. Possible also (to some limit as I see from existing game construction
kits) to create more or less universal clients that will host multiple
games.
Why Web interface? To allow something like source forge gives -
collaborative work of large number of people (not only developers) on the
game model development. The goal of interface development is also make it
user-friendly enough to allow use it by non-developers. You can skip below
example of how I see it should look like from scenario writer point of view.
---------------------
Example of how it should look like in the process of game model development.
Assume you define rules for smithing like in the ADOM game. You already
should have action for "Apply skill" defined. You define a rule of
interaction - "Apply skill for smithing". You define a scenario for this
rule - how smithing process would go. Scenario have conditions to start
(have an anvil, wield hammer, stand over the forge, be not blind etc.). You
also define message for case when conditions failed, like "You should have
an anvil, wield a hammer and stand over the forge to do smithing." Then
define first step of scenario when starting conditions are successful -
select an item to work on. This will include additional screen. You will
define a query for this screen that prepares data from your inventory that
includes only items suitable for smithing. This query will be just "select
all items made from metal or broken or rusty". The screen should return a
single selection - item to work on. Next step will be a selection of what to
do with that item. It is not user-based here (though could be, BTW) - when
item is rust, we will proceed to remove rust step in scenario, if item is
broken, we will proceed to fix item step etc. Assume we selected a sword
made of iron to work on. Next step displays one more screen to select an
ingot to use for smithing. Next step verifies that ingot matches to the
metal of item - it should be iron ingot. If check is not successful, user
gets appropriate message and scenario ends. If message is successful,
Smithing process starts. The process starts turns auto-running without
possibility of user interaction. (From this point, I'm not sure I match
exactly to the process in ADOM, though roughly it should looks like
following.) In the process, every turn step does some sort of RNG check
based on the Smithing skill and fails if returned number is too low. For
this We will define special kind of "repeating check" step where we define
to check special condition every turn, define limitation to number of turns,
define what to do if check is successful (continue smithing) and define what
to do when check failed (finish scenario with message "You failed to improve
%s"). When number of turns specified passed (could be based on formula as
well based on the Smithing kill, so more skilled character does quicker),
next step is RNG for improvement - it selects what exactly is improved for
sword - damage or to-hit value. Next step is RNG of how much is improved,
this is also based on Smithing skill, and also on the current level of
damage or to-hit value, so if to-hit value is very high already, probability
of improvement is much lower. If RNG returns 0, user gets message "You fail
to improve %s". If 1 is returned by RNG, next step is performing
improvement. You define adding of some generated value (1D3) to the improved
attribute (to-hit). Just assignment operation, but you can define more for
this step. This step is considered "Failed" if assignment did not actually
changed anything for some other reason or rule defined for that attribute.
Here it could be only because maximum for attribute. If "failed", player
gets message "Despite your best effort, %s does not improve.". If
successful, player gets message "You managed to improve %s".
All the messages above you can define for several languages at once, so
they're stored already with support for multi-language. Later translators
can get all messages as a single file (XML, for example) and translate them.
On place of %s you pass a parameter - an item that is being improved. When
converting to string (%s), it uses expression (or scenario) for representing
that item in form of string - "short sword of hunting (+2, 1D6+4)".
A bit more of examples (continue):
In process of smithing, when interaction is "locked", some monster can
approach or some event can happen (reach hungry/starving state for example),
so we should ask if break the process. We define global scenario with
starting condition "Currently locking from interaction because some process
and happened something that is dangerous." Define to check this condition
every turn. "happened something that is dangerous" may be sub-scenario with
multiple checks for monster approaching, attacking you, starving etc. If
conditions return "true", break the scenario that is currently locking user
input. The locking scenario should have breaking condition when stopped for
some reason from "outside" of it. In this case it is one additional step -
ask user if stop the scenario (Yes/No message). If stop and if we used ingot
in the smithing process, one more step happens that gets RNG to calculate if
ingot we are worked with damaged (wasted) or not.
(If character is paralyzed, there will be no asking and "breaking" step for
"being paralyzed" scenario would always fail.)
The significant part of all above is, "in background", providing context of
scenario. In case of smithing, it is item user works on, ingot, Smithing
skill etc. - everything user uses in formulas and RNG data, as well as
everything scenario changes in the process. There will be some
context-sensitive help about this, as well as some sort of intelli-sense
where user cans elect from a list of values/objects for this scenario only.
Attributes of object and scenarios will be accessed through "." or "->".
User will be able to use spaces in names if name is enclosed into "". There
will be no direct strings or names in the scenario - all messages will be
multi-lingual, so they will be edited and specified a bit separately. There
will be such thing as scenario attributes - scenario state (step, is it
running, instance number for multi-instance scenarios, objects used for
scenario, for example, "Object selected at step 3" or something like that),
and scenario actions (such as break scenario, switch it to specific state,
push scenario to instantly move through several steps till specific step
omitting timeline rules etc.) There will be also different user interface
for different kinds of scenarios:
- check scenario (check really large number of conditions and do something
dependent on them or just verify them)
- chat scenario (mostly defines messages, message cases to ask user for
etc.)
- process scenario (like for smithing)
There will be a way to see and edit scenario in form of the program (I did
not decided what programming language I will use as a prototype, probably
2 - VB and C#), so programmers will be able to do not get bored by user
interface for editing rules and write all that as program. Everything will
be stored in the XML files, so global search will be possible. The read data
model file for game engine will be compiled into the binary file from XML
files.
--------------------
There are a few problems though that I already foresee:
- Need to create more or less universal dungeon generation routine that is
not specific to a game. Possibly it should be based on the client-specific
data, so there is a (circular) back connection: game core - client data ->
game core again for map generation. So seems maps and map generation should
also be client-specific, or have generic part of it and client-specific - it
still needs to be worked out more.
- I have little skill in graphics, specially 3-D graphics for games. It is
possible I cannot see something that can overcomplicate the separation of
the client from the game model using the way I described. If this is a case,
please point me to obstacles in this area and I'll think how to overcome
them.
- Because large number of possible different scenarios that do checks and
calculations every turn, it is possible that there may be performance
impact. I plan to create a sort of compiler from user-friendly
representation of game data and rules (XML) to the slightly re-organized
data and optimized for running by game engine (binary file). There is a
possibility I will create C++ (or Pascal) code generator for game rules.
Compiling a code from such generator will create a module (DLL for Windows)
usable by game engine. But I will mess with the generator only if there is
really need in very high performance.
- I need to analyze some modeling tools with basic programming of rules of
interaction between objects and running the model. If somebody knows any
such tool available for review/trial, I would appreciate the links. I need
them to get as much as possible of ideas of how to organize user-friendly
interface for creating model and rules. I already have experience in
creating user-friendly interface for really complex models, but it is very
basic, very specific (database-oriented) and it is my personal experience. I
just want to see how others do for it :-)
- Huge timescale, if I do all this alone. I need really a LOT of feedbacks
and reviews in the process of development of first version to work
effectively. Discovering every ugly/inconvenient/boring/time-consuming thing
in the user interface of such large game-editor may take a lot of time. I
would appreciate any help you can give.
Estimated project start - July 20 (my vacation). If it all worth a start at
all, I will establish web site for this project, if anybody else is
interested to participate.
z.e.r.o
>
> [MEGA CUT POWER!]
>
I like you idea. Basically a sort of roguelike generalist engine.
It is a really big and vast project, btw and there are someone that
already moved deeply into that way, so your efforts may be mingled (he
is searching for collaborators, indeed). I checked the code and I found
it really well written and engeneered (the guy is the same of the Java
port of Angband). Take a look:
http://roguelike-eng.sourceforge.net/
--
Matteo Anelli
-------------
zerosoft - http://www.zerosoft.it
the.brain - http://www.zerosoft.it/the.brain
Hansjoerg Malthaner
> Vlad Grynchyshyn ha scritto:
>
> >
>
>> [MEGA CUT POWER!]
>>
>
> I like you idea. Basically a sort of roguelike generalist engine.
>
> It is a really big and vast project, btw and there are someone that
> already moved deeply into that way, so your efforts may be mingled (he
> is searching for collaborators, indeed). I checked the code and I found
> it really well written and engeneered (the guy is the same of the Java
> port of Angband). Take a look:
>
> http://roguelike-eng.sourceforge.net/
You can also take a look at:
http://h-world.simugraph.com/index.html
it's built with similar ideas in mind.
Docs:
http://h-world.simugraph.com/docs.html
c.u.
Hajo
Vlad Grynchyshyn
news:Cshzc.329820$hc5.14...@news3.tin.it...
> Vlad Grynchyshyn ha scritto:
>
> >
> > [MEGA CUT POWER!]
> >
>
> I like you idea. Basically a sort of roguelike generalist engine.
>
> It is a really big and vast project, btw and there are someone that
> already moved deeply into that way, so your efforts may be mingled (he
> is searching for collaborators, indeed). I checked the code and I found
> it really well written and engeneered (the guy is the same of the Java
> port of Angband). Take a look:
>
> http://roguelike-eng.sourceforge.net/
>
I saw it. Idea is similar, but not exactly what I had in mind. The
difference is in a lot of points. In particular, take a look to the
document:
http://roguelike-eng.sourceforge.net/manuals/SimpleGame.htm
Section "Stepping On A Trap Hurts The Player"
In my concept, it should be MUCH more simplified to allow define this kind
of thing by non-developer (scenario writer) by using the "scenario" concept
that describes all rules.
Also, I find the user interface is, indeed, really complicated and not that
user-friendly, it requires a lot of learning.
The goal in my project is allowing virtually any programming languages for
any engine and client to use the game model while the game itself remains
the same (the same items, monsters, behaviors and rules). In "The Java
Roguelike Engine Project" it is too much tied to the java itself.
Vlad Grynchyshyn
news:2j5mpoF...@uni-berlin.de...
Still reviewing it. From first look, it is very promising project, maybe the
most of all I saw. It is also looks like more programmer-oriented though.
Hansjoerg Malthaner
> "Hansjoerg Malthaner" <hansjoerg...@nurfuerspam.de> wrote in message
> news:2j5mpoF...@uni-berlin.de...
>
>>z.e.r.o schrieb:
[...]
>>>I like you idea. Basically a sort of roguelike generalist engine.
[...]
>>You can also take a look at:
>>
>>http://h-world.simugraph.com/index.html
>>
>>it's built with similar ideas in mind.
>>
>>Docs:
>>
>>http://h-world.simugraph.com/docs.html
>
> Still reviewing it. From first look, it is very promising project, maybe the
> most of all I saw. It is also looks like more programmer-oriented though.
That's right. At some point customizeability needs the user to express
functionality and behaviour of their extensions, and this is probably is
done best done by using a scripting language (= programming scripts)
At the current stage it isn't user friendly at all [1]. ABCGi has given
a lot of feedback and some improvements already have been made, but
there is still a long way to go.
I'm glad that ABCGi actually tries to build a game with the H-World
Engine. By reading his feedback I can learn all the things that I forgot
to implement yet.
I think what's currently missing most is a document that describes how
the data, scripts, engine and other stuff works together.
Once you're done with the review, will you share the results with me?
Knowong the weaknesses I can try to offer better solution in future
releases :)
c.u.
Hajo
[1]: Someone said: "Unix is user friendly. But not idiot friendly."
So opinions on what's user friendly can vary widly ;^)
The Sheep
> Vlad Grynchyshyn schrieb:
>> "Hansjoerg Malthaner" <hansjoerg...@nurfuerspam.de> wrote in message
>> news:2j5mpoF...@uni-berlin.de...
>> most of all I saw. It is also looks like more programmer-oriented though.
>
> That's right. At some point customizeability needs the user to express
> functionality and behaviour of their extensions, and this is probably is
> done best done by using a scripting language (= programming scripts)
Someone could make a `game generator' with GUI and lots of script templates
enabled with simple comboboxes and radio buttons. Plus some builtin
image viewer with `point & click' offset calculation and you've got a
`rpg click and play'. ^^)))
--
Radomir `The Sheep' Dopieralski
Whatever you're looking for, you always find it
in the last place you check. Coincidence?
Hansjoerg Malthaner
> Dnia Mon, 14 Jun 2004 16:21:31 +0200, Hansjoerg Malthaner napisal(a):
>
>>Vlad Grynchyshyn schrieb:
>>
>>>"Hansjoerg Malthaner" <hansjoerg...@nurfuerspam.de> wrote in message
>>>news:2j5mpoF...@uni-berlin.de...
>>>Still reviewing it. From first look, it is very promising project, maybe the
>>>most of all I saw. It is also looks like more programmer-oriented though.
>>
>>That's right. At some point customizeability needs the user to express
>>functionality and behaviour of their extensions, and this is probably is
>>done best done by using a scripting language (= programming scripts)
>
> Someone could make a `game generator' with GUI and lots of script templates
> enabled with simple comboboxes and radio buttons. Plus some builtin
> image viewer with `point & click' offset calculation and you've got a
> `rpg click and play'. ^^)))
Once in a while I think about a 'drag and drop' program generator, where
I can assemble loops and switches by drag and drop gestures, and coding
would be merely parametrising the building blocks. I'd like to have a
graphical view of the program structure, too.
I know this has been tried, but only with limited success. I still think
the idea has potential :)
c.u.
Hajo
Kornel Kisielewicz
> Vlad Grynchyshyn ha scritto:
>
> >
>> [MEGA CUT POWER!]
>>
>
> I like you idea. Basically a sort of roguelike generalist engine.
>
> It is a really big and vast project, btw and there are someone that
> already moved deeply into that way, so your efforts may be mingled (he
> is searching for collaborators, indeed). I checked the code and I
> found it really well written and engeneered (the guy is the same of
> the Java port of Angband). Take a look:
>
> http://roguelike-eng.sourceforge.net/
Hey, I didn't get the original post, may someone repost it?
Kostatus
I'm going to snip a lot, be warned.
...
> The idea is to create a sort of simplified modeling tool with simplified
> programming language ("program" here will be called "scenario"), where
> you can in addition to populating database about monsters and items
> create some rules for interaction between them, interaction with user
> interface and user actions, interaction with timeline and interaction
> between scenarios themselves. So, instead of writing tonns of C++ code,
> scenario writer will be able to create a sort of model of game - all the
> rules described in much more convenient way.
This is a nice idea, but I have to say that I would never use something
like that, I would rather write my own from scratch. Also this seems like
quite a hard and long project, but you seem to know what you're talking
about :)
...
> It all should follow the concept "define game rules, the rest is up to
> the game-masters about how to organize game-playing". "Game rules" here
> is a game model database. Game-master here is developer of the game
> client and artists that populate data specific for that client. Engine
> stands separately from that - it is just the a tool to run everything.
Suggestion - create a GUI-based IDE for creating these.
...
> (You can beat me for that name if it is too ugly, I would not protest to
> name the approach and the system differently if some other name is
> better to your opinion).
IMHO the name is good.
...
> The most "probable" solution for above idea in obvious time is
> following: Because my skills, I can very easy write an interface for
> Theatry - game editor/construction kit/scenario editor. It will be
> Web-based interface written using C# and hosted somewhere (luckily I
> already have place where to put it).
Hmm... web-based... Does that mean that people would have to go to your
site to use it with no downloadable option?
...
>
> Why Web interface? To allow something like source forge gives -
> collaborative work of large number of people (not only developers) on
> the game model development. The goal of interface development is also
> make it user-friendly enough to allow use it by non-developers. You can
> skip below example of how I see it should look like from scenario writer
> point of view.
>
>
[snip long example on how the development process would work]
You'll probably have to provide a good tutorial for this.
...
> There will be a way to see and edit scenario in form of the program (I
> did not decided what programming language I will use as a prototype,
> probably 2 - VB and C#), so programmers will be able to do not get bored
> by user interface for editing rules and write all that as program.
> Everything will be stored in the XML files, so global search will be
> possible. The read data model file for game engine will be compiled into
> the binary file from XML files.
Also a good idea, giving XML files to the player IMO is a bad idea. But
the developer should still be able to use the advantages XML.
>
> --------------------
>
>
> There are a few problems though that I already foresee:
> - Need to create more or less universal dungeon generation routine that
> is not specific to a game. Possibly it should be based on the
> client-specific data, so there is a (circular) back connection: game
> core - client data -> game core again for map generation. So seems maps
> and map generation should also be client-specific, or have generic part
> of it and client-specific - it still needs to be worked out more.
You could include several methods of map generations, and also allow the
player to create his own methods using C++ by compiling DLLs which your
engine would use (although I'm not sure if other operating systems have
equivelants of DLLs).
...
> - Huge timescale, if I do all this alone. I
> need really a LOT of feedbacks and reviews in the process of development
> of first version to work effectively. Discovering every
> ugly/inconvenient/boring/time-consuming thing in the user interface of
> such large game-editor may take a lot of time. I would appreciate any
> help you can give.
I'm sure people here would be happy to help, just post your releases here.
>
>
> Estimated project start - July 20 (my vacation). If it all worth a start
> at all, I will establish web site for this project, if anybody else is
> interested to participate.
>
>
>
--
Kostatus
kostatus001 at ihug co nz
http://www.woodsoftorbin.on.to/
or http://on.to/woodsoftorbin/
Vlad Grynchyshyn
Hey, you're ahead of my ideas! I have a LOT of ideas, but sent just what I
thought the most promising.
The try you mentioned was for universal programming and indeed, it failed
because it is more time-consuming to program in that way.
For game construction, I think, it may be VERY different.
Just think what is needed in the game. When you program the logic of
different game scenarios (actions, interactions, quest scenarios), you often
do not need all programming language constructions. Most of algorithms
(sight of view, lighting etc.) should be available as utility functions. All
you need is build a sort of scenario that consists of steps, formulas and
simple loops that are all in most cases standard. Very good place for using
programming by using visual blocks. It was one of the variants I had in mind
for organizing user interface for designing (constructing by blocks and
formulas) scenarios and rules for game without actual programming.
Another approach was exactly as in previous post - a lot of dialogs with
convenient selections, defaults for quick input and instant help everywhere,
plus "advanced" buttons to add a lot more options for rare cases. While this
one looks too "Windows-like", it is far easier to implement for Web
interface than blocks programming.
Anyway, if programming by visual blocks is indeed good for game
constructing, I'll do this even for Web, and yes, it will support NN browser
:-)
Vlad Grynchyshyn
news:Xns95097CF20...@203.109.252.31...
> On Mon, 14 Jun 2004 10:49:11 GMT, Vlad Grynchyshyn wrote:
>
> > The idea is to create a sort of simplified modeling tool with simplified
> > programming language ("program" here will be called "scenario"), where
> > you can in addition to populating database about monsters and items
> > create some rules for interaction between them, interaction with user
> > interface and user actions, interaction with timeline and interaction
> > between scenarios themselves. So, instead of writing tonns of C++ code,
> > scenario writer will be able to create a sort of model of game - all the
> > rules described in much more convenient way.
>
> This is a nice idea, but I have to say that I would never use something
> like that, I would rather write my own from scratch. Also this seems like
> quite a hard and long project, but you seem to know what you're talking
> about :)
>
Curious, why you would like to write your own from scratch?
Well, I'll try to "guess" - you're programmer. My idea is to provide a
system for scenario writers mostly that do not know programming very well.
> > It all should follow the concept "define game rules, the rest is up to
> > the game-masters about how to organize game-playing". "Game rules" here
> > is a game model database. Game-master here is developer of the game
> > client and artists that populate data specific for that client. Engine
> > stands separately from that - it is just the a tool to run everything.
>
> Suggestion - create a GUI-based IDE for creating these.
That is exactly what I'm going to make.
> > The most "probable" solution for above idea in obvious time is
> > following: Because my skills, I can very easy write an interface for
> > Theatry - game editor/construction kit/scenario editor. It will be
> > Web-based interface written using C# and hosted somewhere (luckily I
> > already have place where to put it).
>
> Hmm... web-based... Does that mean that people would have to go to your
> site to use it with no downloadable option?
> ....
> > Why Web interface? To allow something like source forge gives -
> > collaborative work of large number of people (not only developers) on
> > the game model development. The goal of interface development is also
> > make it user-friendly enough to allow use it by non-developers. You can
> > skip below example of how I see it should look like from scenario writer
> > point of view.
>
There will be downloadable options. Web-based is to allow collaboration of
several people on development of the same game, like sourse forge.
Question then: would desktop IDE be more useful???
> You'll probably have to provide a good tutorial for this.
Of course yes. Not only that - basic simple game (or a few different game
templates) to start
> > There are a few problems though that I already foresee:
> > - Need to create more or less universal dungeon generation routine that
> > is not specific to a game. Possibly it should be based on the
> > client-specific data, so there is a (circular) back connection: game
> > core - client data -> game core again for map generation. So seems maps
> > and map generation should also be client-specific, or have generic part
> > of it and client-specific - it still needs to be worked out more.
>
> You could include several methods of map generations, and also allow the
> player to create his own methods using C++ by compiling DLLs which your
> engine would use (although I'm not sure if other operating systems have
> equivelants of DLLs).
Well, plug-in-like framework is good idea too, but, as you said, it is hard
to organize it for different platforms, unless you think more about the
tires which I propose to split the system to. Client-specific data is
ANYTHING that you can define for object. If your client have some special
map generation algorithm, in addition to what is in the engine, just define
that using client-specific data. That is what puzzles me as I already
described - that map-generation and maps themselves should be also available
as client-specific data, not only as a core data.
Vlad Grynchyshyn
news:cako9t$8np$1...@inews.gazeta.pl...
> z.e.r.o wrote:
>
> Hey, I didn't get the original post, may someone repost it?
>
Try:
http://groups.google.com/groups?threadm=Xns95097CF202E1DKostatus%40203.109.252.31
(BTW, how you guys create a tiny URL out of link google groups post?)
Kostatus
...
>> This is a nice idea, but I have to say that I would never use something
>> like that, I would rather write my own from scratch. Also this seems
>> like quite a hard and long project, but you seem to know what you're
>> talking about :)
>>
>
> Curious, why you would like to write your own from scratch?
> Well, I'll try to "guess" - you're programmer. My idea is to provide a
> system for scenario writers mostly that do not know programming very
> well.
Correct. I don't really care if I will be able to complete a great new
innovative roguelike and see it rise to fame glory (although I wouldn't mind
that, who would), my goal is to _enjoy_ the process of making it and
hopefully learn something from it. Also, writing from scratch gives me full
control over what I want to do every step of the way.
But it _is_ a good idea to provide a tool for creative non-programmers to
create a good game.
...
>>
>> Hmm... web-based... Does that mean that people would have to go to your
>> site to use it with no downloadable option?
>> ....
>> > Why Web interface? To allow something like source forge gives -
>> > collaborative work of large number of people (not only developers) on
>> > the game model development. The goal of interface development is also
>> > make it user-friendly enough to allow use it by non-developers. You
>> > can skip below example of how I see it should look like from scenario
>> > writer point of view.
>>
>
> There will be downloadable options. Web-based is to allow collaboration
> of several people on development of the same game, like sourse forge.
>
> Question then: would desktop IDE be more useful???
This maybe just me, but I prefer having something fully downloaded when I use
it; doing something over the internet is always slower than doing something
on your hard drive, especially when you're like me on 56K (On a side note,
ADSL is 5 times more expensive in New Zealand than in UK for the same service
:( THIEVES!)
...
Vlad Grynchyshyn
Well, looks like you do not know what is browser client-side web
application. It loads all data to client and rarely connects to the
internet. If you provide enough browser cache for image icons and java
script files, in such applications you usually need connection to open
application, load data. Then work without connection at all. Then connect
just to save results of work. This is "ideal" case when nobody else is
working with these data. IN multi-user environment, you will have to keep
connection to allow application check if the item you going to modify is not
already modified by another developer and thus refresh or tell it is
currently in editing progress. No much traffic for that, actually.
Also, Web application gives one more advantage - scalability. I plan to have
support of Netscape browser, that opens wide possibilities for Linux users
to use it.
I'll plan desktop version anyway. Web version is what I plan to start from
because I know it better than .NET desktop development :-) And also it
requires no installation on client so I can expect more reviews from start -
desktop requires to install .NET framework and Windows and quite high
requirements to machine.
Thomas Seufert
> any engine and client to use the game model while the game itself remains
> the same (the same items, monsters, behaviors and rules). In "The Java
> Roguelike Engine Project" it is too much tied to the java itself.
[Disclaimer: JRLE is my project]
It's a valid point. In attempting a project to aid other game
developers, I have found it absolutely necessary to strictly define
the project scope(or else it becomes infinite and the project fails).
Your project idea sounds more ambitious in one sense in that it aims
to encapsulate all RL behavior into (essentially) a scripting language
which a GUI client can write scripts for. My project focuses on
giving developers the ability to do whatever they want by writing Java
plug-ins. I settled on this approach after finding that the
architecture I'd chosen for a Java attempt at Angband to be too
restrictive and confusing -- implementing something like allowing
large creatures would have required massive effort.
IMO, This approach has some pros and cons:
Pro:
Flexibility -- developers can code whatever they want; if they find a
portion of the architecture too restrictive, they can ignore or extend
it.
Ease of Implementation -- In my experience, simplicity is the opposite
of power. Writing visual programming environments seems like it would
be very difficult to do well.
Con:
Complexity -- Although many tasks (changing item names, adding
monsters) might be simple, the target audience is game developers, ie
fairly sophisticated programmers.
Java-centric -- Hence the name ;) Plug-ins must be written in Java.
I wish you luck with your project!
Kornel Kisielewicz
>...
I'll repost here to your original post, for I haven't got it on my NG ;).
<snip almost everything>
Ok, let me say, that I'm deeply sceptical about your chances to create at
least a part of what you wrote -- there are many places that you seem to
overlook basic pitfalls, etc... having tried something similar I can only
say, that writing a master-go-playing program is probably easier then a
truly generic AND user-friendly roguelike/cRPG platform (and the former is
worth about 2M$). But people here start to criticize me, that I'm to
critical and sceptic, so I won't go into this further ;).
The reason I'm replying to your post is something that hit me in the last
part:
> maps and map generation should also be client-specific, or have
> generic part of it and client-specific - it still needs to be worked
> out more. - I have little skill in graphics, specially 3-D graphics
> for games. It is possible I cannot see something that can
> overcomplicate the separation of the client from the game model using
> the way I described. If this is a case, please point me to obstacles
> in this area and I'll think how to overcome them.
3D graphics is not just 2D with a height. A game thwt supposed to resonably
run in 3D needs a lot more then just 3D models and z-axis data. You need
textures, movement data, etc -- these can of course be provided with the
data. But the more complicated thing is that the GameWorld needs to have
preprepared data for the 3D environment which can be a pain-in-the-ass in a
random dungeon. You have to remember that doing a map for eg. Quake III may
take just a few hours, but rendering it to a reasonable format may take even
a few days -- you can't leave that to run-time! Of course you may drop some
features so the game will have Doom I-class 3D graphics on todays compuers,
but that will be never considered valid 3D by gamers. Also note that 3D
objects have two sides -- that 2D # that represents a wal will look and
behave differently from different sides. Moreover dynamical 3D architecture
(architecture is dynamical in most roguelikes --> tunneling etc) is beyond
the scope of most traditional 3D rendering techniques used in games.
And that is just a tip of an iceberg.
My advice -> If you want any reasonable chance of completeing anything
related to this project, then forget about 3D. You may still provide a old
DungeonMaster style client, etc, but true 3D DEMANDS a dedicated engine.
> - Because large number of possible different scenarios that do checks
> and calculations every turn, it is possible that there may be
> performance impact.
Something that you absolutely may not have in a 3D engine.
> Estimated project start - July 20 (my vacation). If it all worth a
> start at all, I will establish web site for this project, if anybody
> else is interested to participate.
Good luck. I'll be watching this idea carefully, though not with much hope.
[ hey guys, don't look at me like that! someone had to play the sceptic
part, right? ]
Good luck, anyway ;)
regards,
Kornel Kisielewicz
Vlad Grynchyshyn
> Vlad Grynchyshyn wrote:
> >...
>
> I'll repost here to your original post, for I haven't got it on my NG ;).
>
> <snip almost everything>
>
> Ok, let me say, that I'm deeply sceptical about your chances to create at
> least a part of what you wrote -- there are many places that you seem to
> overlook basic pitfalls, etc... having tried something similar I can only
> say, that writing a master-go-playing program is probably easier then a
> truly generic AND user-friendly roguelike/cRPG platform (and the former is
> worth about 2M$). But people here start to criticize me, that I'm to
> critical and sceptic, so I won't go into this further ;).
Hej, I posted this EXACTLY to get critics :-)))
So you can blame me like mad, maybe I'll learn something out of it. What I
want to do this month before project really starts is analysis - all cons,
and also all disadvantages and obstacles. Also, learn from other existing
tools around. So I will predict and try to find solution to all obstacles
before real coding. Later on it would be much harder to make changes into
concept when a lot of code is already developed.
So ANY critics welcome.
Well, I agree that this is a large scale project. I wonder why I cannot make
at least part of it? I aware about all things related to such large projects
because I worked on 3 really large-scale projects, and a lot of small
projects. The last one was a web-based client-side application with large
number of features and user-friendiness requirement, where I did a lot of
really new stuff. Because this experience, I want to try it in the area of
games development. I know I may fail, but at least I would not waste my
experience by putting it on the shelf for another chance of working on the
project like that one.
Well, as a 3D, I meant not graphics like in Quake III (Might & Magic
versions 6 and higher is example of such games). My system is more RL
oriented. Baldurs gate, Evil Island (Allods 3), Revenant to count few - that
is what I'm oriented to. This kind of 3D graphics seems do not have very
high requirements to preformance. Or am I wrong?
> > - Because large number of possible different scenarios that do checks
> > and calculations every turn, it is possible that there may be
> > performance impact.
>
> Something that you absolutely may not have in a 3D engine.
Why? Any game, even real-time, should have such things as checking for
victory conditions, checking for special cases etc. The question is how to
implement it the best way. This is he main problem of modelling, as far as I
know - performance related to the operations.
I also plan to improve this a bit to define the "scope" and "context" of
scenario and rules, so it do run code for scenario only in the context of
some object action, interaction. Also run code not every turn but, say,
every day, every 1000 turns etc. So it will be not every turn for all
scenarios, but a bit more sophisticated.
> > Estimated project start - July 20 (my vacation). If it all worth a
> > start at all, I will establish web site for this project, if anybody
> > else is interested to participate.
>
> Good luck. I'll be watching this idea carefully, though not with much
hope.
> [ hey guys, don't look at me like that! someone had to play the sceptic
> part, right? ]
>
> Good luck, anyway ;)
Thanks. Your feedback, BTW, may be the most valuable ;) And please, do not
be afraid about killing this idea from start. The purpose of this post is
exactly to check if it is worth to start at all and, if there are any
obstacles, find a solution to overcome them.
Kornel Kisielewicz
> "Kornel Kisielewicz" <charon...@magma-net.pl> wrote in message
> news:cao6s5$6p1$1...@inews.gazeta.pl...
>> Vlad Grynchyshyn wrote:
>>> ...
>> create at least a part of what you wrote -- there are many places
>> that you seem to overlook basic pitfalls, etc... having tried
>> something similar I can only say, that writing a master-go-playing
>> program is probably easier then a truly generic AND user-friendly
>> roguelike/cRPG platform (and the former is worth about 2M$). But
>> people here start to criticize me, that I'm to critical and sceptic,
>> so I won't go into this further ;).
>
> Hej, I posted this EXACTLY to get critics :-)))
Yeah, just wait for Amy Wang to come back ;) *evil grin*
> So you can blame me like mad, maybe I'll learn something out of it.
> What I want to do this month before project really starts is analysis
> - all cons, and also all disadvantages and obstacles.
My main advice to all project developers was always the same -> "start
small". In your case I would advise to create a simple roguelike so you know
what kind of obstacles arise while creating one. You will be surprised on
how much such a game is complex.
> So ANY critics welcome.
You don't know what you are asking for ;).
> Well, I agree that this is a large scale project. I wonder why I
> cannot make at least part of it?
A part is worthless if no one will make other parts :(.
> such large projects because I worked on 3 really large-scale
> projects, and a lot of small projects.
What about roguelikes? Have you worked on any roguelikes? A roguelike itself
(not even an engine) may be considerd a large-scale project. Moreover in the
case of this project it's not the programming skills that count the most
it's the design and analisis skills that count. In those large-scale
projects you worked in, in how many were you the lead designer?
>> And that is just a tip of an iceberg.
>>
>> My advice -> If you want any reasonable chance of completeing
>> anything related to this project, then forget about 3D. You may
>> still provide a old DungeonMaster style client, etc, but true 3D
>> DEMANDS a dedicated engine.
>
> Well, as a 3D, I meant not graphics like in Quake III (Might & Magic
> versions 6 and higher is example of such games). My system is more RL
> oriented. Baldurs gate, Evil Island (Allods 3), Revenant to count few
> - that is what I'm oriented to. This kind of 3De w graphics seems do not
> have very high requirements to preformance. Or am I wrong?
Out of those I played only Baldurs Gate, and Baldurs Gate is 2D.
>> Something that you absolutely may not have in a 3D engine.
>
> Why? Any game, even real-time, should have such things as checking for
> victory conditions, checking for special cases etc. The question is
> how to implement it the best way. This is he main problem of
> modelling, as far as I know - performance related to the operations.
> I also plan to improve this a bit to define the "scope" and "context"
> of scenario and rules, so it do run code for scenario only in the
> context of some object action, interaction. Also run code not every
> turn but, say, every day, every 1000 turns etc. So it will be not
> every turn for all scenarios, but a bit more sophisticated.
The point is you may not waste more then a few miliseconds every second on
non-3D related calculations -> the graphics will eat the reast, and if you
spend more you will get fps's in the range of 1-10. So all non-graphic
calculations need to be a separate thread, and have to be optimized to run
as regular and as little as possible.
> Thanks. Your feedback, BTW, may be the most valuable ;) And please,
> do not be afraid about killing this idea from start.
Oh yeah? *pulls out a double shotgun* You asked for it. *BANG! BANG* ;)
regards,
Kornel Kisielewicz
Hansjoerg Malthaner
> Vlad Grynchyshyn wrote:
>>such large projects because I worked on 3 really large-scale
>>projects, and a lot of small projects.
>
>
> What about roguelikes? Have you worked on any roguelikes? A roguelike itself
> (not even an engine) may be considerd a large-scale project. Moreover in the
> case of this project it's not the programming skills that count the most
> it's the design and analisis skills that count. In those large-scale
> projects you worked in, in how many were you the lead designer?
Kornel, don't hit him too hard. I think he really means large projects
if he says large projects. He just described the planned architecture
for his project to me, and this is how I'm used to build big
client-server applications.
>>Thanks. Your feedback, BTW, may be the most valuable ;) And please,
>> do not be afraid about killing this idea from start.
>
> Oh yeah? *pulls out a double shotgun* You asked for it. *BANG! BANG* ;)
>
> regards,
> Kornel Kisielewicz
c.u.
Hajo
Kornel Kisielewicz
> Kornel Kisielewicz schrieb:
>> What about roguelikes? Have you worked on any roguelikes? A
>> roguelike itself (not even an engine) may be considerd a large-scale
>> project. Moreover in the case of this project it's not the
>> programming skills that count the most it's the design and analisis
>> skills that count. In those large-scale projects you worked in, in
>> how many were you the lead designer?
>
> Kornel, don't hit him too hard.
He asked for it ;). And seriously though - I'm not saying that he hasn't got
any chances - I just ask him questions he should think about.
> I think he really means large projects
> if he says large projects. He just described the planned architecture
> for his project to me, and this is how I'm used to build big
> client-server applications.
Yes, I too believe he has experience in that field. But we both know that
game development, and crpg/roguelike development are in many ways different
then developing buisiness applications.
regards,
Kornel Kisielewicz
Vlad Grynchyshyn
> Vlad Grynchyshyn wrote:
> > "Kornel Kisielewicz" <charon...@magma-net.pl> wrote in message
> > news:cao6s5$6p1$1...@inews.gazeta.pl...
> >> Vlad Grynchyshyn wrote:
> > So ANY critics welcome.
>
> You don't know what you are asking for ;).
I know :-))))
> > Well, I agree that this is a large scale project. I wonder why I
> > cannot make at least part of it?
>
> A part is worthless if no one will make other parts :(.
I know. I'll make all parts from start but limited to the Windows platform
only.
> > such large projects because I worked on 3 really large-scale
> > projects, and a lot of small projects.
>
> What about roguelikes? Have you worked on any roguelikes? A roguelike
itself
> (not even an engine) may be considerd a large-scale project. Moreover in
the
> case of this project it's not the programming skills that count the most
> it's the design and analisis skills that count. In those large-scale
> projects you worked in, in how many were you the lead designer?
I understand very well what it means, despite I did not made one (yet). I
watcehd progress of some RL development, however. I did some feedbacks for
ADOM as well, one thing was also implemented, BTW, that seems is not yet
discovered (at least I do not know about it if discovered :-) )
> >> And that is just a tip of an iceberg.
> >>
> >> My advice -> If you want any reasonable chance of completeing
> >> anything related to this project, then forget about 3D. You may
> >> still provide a old DungeonMaster style client, etc, but true 3D
> >> DEMANDS a dedicated engine.
> >
> > Well, as a 3D, I meant not graphics like in Quake III (Might & Magic
> > versions 6 and higher is example of such games). My system is more RL
> > oriented. Baldurs gate, Evil Island (Allods 3), Revenant to count few
> > - that is what I'm oriented to. This kind of 3De w graphics seems do not
> > have very high requirements to preformance. Or am I wrong?
>
> Out of those I played only Baldurs Gate, and Baldurs Gate is 2D.
Let's say 2.5D :-)
3D graphics is different from 3D engine. 3D means 3 dimentions, and I meant
it for graphics only, not for actions, first person view etc. So 3D cube is
3D cube, but it can be layered as image for 2D game.
> > Thanks. Your feedback, BTW, may be the most valuable ;) And please,
> > do not be afraid about killing this idea from start.
>
> Oh yeah? *pulls out a double shotgun* You asked for it. *BANG! BANG* ;)
*jumps on the floor throwing rocks back* Yep! Repeat till you run out of
ammo :-)
Vlad Grynchyshyn
> Hansjoerg Malthaner wrote:
> > Kornel Kisielewicz schrieb:
> >> What about roguelikes? Have you worked on any roguelikes? A
> >> roguelike itself (not even an engine) may be considerd a large-scale
> >> project. Moreover in the case of this project it's not the
> >> programming skills that count the most it's the design and analisis
> >> skills that count. In those large-scale projects you worked in, in
> >> how many were you the lead designer?
> >
> > Kornel, don't hit him too hard.
>
> He asked for it ;). And seriously though - I'm not saying that he hasn't
got
> any chances - I just ask him questions he should think about.
I can very well resist any kind of critics, because I know tit teaches a
lot. I'm not very fragile to that :-)
> > I think he really means large projects
> > if he says large projects. He just described the planned architecture
> > for his project to me, and this is how I'm used to build big
> > client-server applications.
>
> Yes, I too believe he has experience in that field. But we both know that
> game development, and crpg/roguelike development are in many ways
different
> then developing buisiness applications.
I know that. And business application in many cases have a lot of similar
requirements, BTW.
Kornel Kisielewicz
>> A part is worthless if no one will make other parts :(.
>
> I know. I'll make all parts from start but limited to the Windows
> platform only.
What are the reasons not to make it multi-platform? (it's just a question,
I'm not a port-it-everywhere crusader)
>> What about roguelikes? Have you worked on any roguelikes? A
>> roguelike itself (not even an engine) may be considerd a large-scale
>> project. Moreover in the case of this project it's not the
>> programming skills that count the most it's the design and analisis
>> skills that count. In those large-scale projects you worked in, in
>> how many were you the lead designer?
>
> I understand very well what it means, despite I did not made one
> (yet).
So do one ;). Or at least try to do -- the experience you get while trying
to make a traditional roguelike is worth a lot more then any advice anyone
here can give you. And the time invested will pay back tenfold, you have my
word on it :).
> I watcehd progress of some RL development, however.
"So did everyone else" -- and not many people have learned from it ;(.
>>> Well, as a 3D, I meant not graphics like in Quake III (Might & Magic
>>> versions 6 and higher is example of such games). My system is more
>>> RL oriented. Baldurs gate, Evil Island (Allods 3), Revenant to
>>> count few - that is what I'm oriented to. This kind of 3De w
>>> graphics seems do not have very high requirements to preformance.
>>> Or am I wrong?
>>
>> Out of those I played only Baldurs Gate, and Baldurs Gate is 2D.
>
> Let's say 2.5D :-)
No, 2D ;).
> 3D graphics is different from 3D engine. 3D means 3 dimentions, and I
> meant it for graphics only, not for actions, first person view etc.
> So 3D cube is 3D cube, but it can be layered as image for 2D game.
3D objects pre-rendered to 2D sprites make 2D games. If not you would have
to say that almost all games today are 3D.
>> Oh yeah? *pulls out a double shotgun* You asked for it. *BANG! BANG*
>> ;)
>
> *jumps on the floor throwing rocks back* Yep! Repeat till you run out
> of ammo :-)
Well in that case... *sigh*
*pulls out the BFG-9000*
;)
regards,
Kornel Kisielewicz
Kornel Kisielewicz
>> He asked for it ;). And seriously though - I'm not saying that he
>> hasn't got any chances - I just ask him questions he should think
>> about.
>
> I can very well resist any kind of critics, because I know tit
> teaches a lot. I'm not very fragile to that :-)
Resistance to critics is a double-edged sword -> it is bunker wall that
shields you from the rest of the world -> it can save your life, but
inproperly used it can take everything you could learn away. ;).
regards,
Kornel Kisielewicz
Diwil
> > meant it for graphics only, not for actions, first person view etc.
> > So 3D cube is 3D cube, but it can be layered as image for 2D game.
>
> 3D objects pre-rendered to 2D sprites make 2D games. If not you would have
> to say that almost all games today are 3D.
There's nothing that would stop a Roguelike to have 3D graphics engine - you
might have the dungeon and objects represented as 3D models, but the game
engine running exactly the same - if written correctly and smart enough, the
graphics engine will be just as simple to use (excluding the complex 3D
math!) as a 2D graphics engine. Such as, lets say we have a Goblin at a
specific part of the map. An ASCII engine would just draw the 'g' to that
spot on the screen. A 2D engine would draw the sprite for a goblin. And a 3D
engine would place a 3D model for a goblin to that spot, maybe rotating it
so it'd face to the last direction it was walking to (hey, easy to
implement).
I actually plan to make 3D graphics myself later on for my roguelike, since
I wrote the graphical / input handler completely separete from the so called
business logic. The engine runs with every action the player does, but it
knows absolutely nothing about the presence of the player (excluding the
messages it gets from the input handler), or the screen. The graphics
handler just poll the engine for data, such as map's information, lighting
information and creatures and their locations. Then it processes the
information as it wishes... As far as I checked, it could easily be turned
into an IF, if you'd just be up for writing an engine for handling the
messages you'd get from every cell (IF games are usually separated as
rooms), or a way to treat rooms as a single object to "stand on".
Unless made real-time, the 3D approach would work just as good as any. It's
just a matter of deciding how the game world is displayed, not necessarily
involving any changes to the actual game.
- Claus "Diwil" Kruuskopf
R. Alan Monroe
>3D graphics is not just 2D with a height. A game thwt supposed to resonably
>run in 3D needs a lot more then just 3D models and z-axis data. You need
>textures, movement data, etc -- these can of course be provided with the
>data. But the more complicated thing is that the GameWorld needs to have
>preprepared data for the 3D environment which can be a pain-in-the-ass in a
>random dungeon. You have to remember that doing a map for eg. Quake III may
>take just a few hours, but rendering it to a reasonable format may take even
>a few days -- you can't leave that to run-time! Of course you may drop some
Ever seen http://www.cubeengine.com/ ?
Possibly it could probably be adapted to a roguelike. Just an idea.
Alan
Michael Blackney
>
> Ever seen http://www.cubeengine.com/ ?
> Possibly it could probably be adapted to a roguelike. Just an idea.
Thanks a lot for the link. I've been looking for a while for a decent
3d engine that allows a decent level of in-engine landscape editing.
--
michaelblackney at hotmail dot com
http://aburatan.sourceforge.net/
Latest version 0.95 2-5-4
Vlad Grynchyshyn
As resistance I meant "mood" to continue work - that is what was discussed
in "The slow world of Roguelike development" thread I followed :-) Of
course I'm not a tough-skin to critics, so I learn a lot from them, despite
it does not hurts my "mood".
Vlad Grynchyshyn
news:870Ac.464$594...@read3.inet.fi...
> > > 3D graphics is different from 3D engine. 3D means 3 dimentions, and I
> > > meant it for graphics only, not for actions, first person view etc.
> > > So 3D cube is 3D cube, but it can be layered as image for 2D game.
> >
> > 3D objects pre-rendered to 2D sprites make 2D games. If not you would
have
> > to say that almost all games today are 3D.
>
> There's nothing that would stop a Roguelike to have 3D graphics engine -
you
> might have the dungeon and objects represented as 3D models, but the game
> engine running exactly the same - if written correctly and smart enough,
the
> graphics engine will be just as simple to use (excluding the complex 3D
> math!) as a 2D graphics engine. Such as, lets say we have a Goblin at a
> specific part of the map. An ASCII engine would just draw the 'g' to that
> spot on the screen. A 2D engine would draw the sprite for a goblin. And a
3D
> engine would place a 3D model for a goblin to that spot, maybe rotating it
> so it'd face to the last direction it was walking to (hey, easy to
> implement).
>
The problem to that, as already pointed out, not in puttong object there and
representing it by graphics. As in Quake III, it is easy. The problem is in
the difference for 3D graphics from the "internals" point of veiw. The thing
you're talking about reqreuis also some sort of lighting (if monster have
light source) that dynamically represented on the walls. THus there is a
sort of "environment" around the moster. And THAT is a problem - interaction
between several opbjects in some environment that causes visual effects.
That is what takes several days for Quacke III, as pointed out. To implement
this, you cannot just go through all cases, check and if that is a case,
update the pixels on screen. Need to make it more sophisticated to make it
have good enough performance to do not slow down game.
I know it could be made, but it goes to the level of algorthmic and graphics
processing science complexity - far behind an ordinary project. I can dive
into all this, but then forget about everything else. Mabe in the far future
it will be made, but not in my close plans.
> I actually plan to make 3D graphics myself later on for my roguelike,
since
> I wrote the graphical / input handler completely separete from the so
called
> business logic. The engine runs with every action the player does, but it
> knows absolutely nothing about the presence of the player (excluding the
> messages it gets from the input handler), or the screen. The graphics
> handler just poll the engine for data, such as map's information, lighting
> information and creatures and their locations. Then it processes the
> information as it wishes... As far as I checked, it could easily be turned
> into an IF, if you'd just be up for writing an engine for handling the
> messages you'd get from every cell (IF games are usually separated as
> rooms), or a way to treat rooms as a single object to "stand on".
>
> Unless made real-time, the 3D approach would work just as good as any.
It's
> just a matter of deciding how the game world is displayed, not necessarily
> involving any changes to the actual game.
There is no point in making 3D not real-time, IMO. Real-time, actually,
speeds up the game a lot and gives new possibilities to game-playing. It
adds playability a lot. Try Might & Magic versions 6 and higher - I like it
really a lot. 3D without real-time does not worth effort to make it 3D at
all, I think.
Vlad Grynchyshyn
> Vlad Grynchyshyn wrote:
> > "Kornel Kisielewicz" <charon...@magma-net.pl> wrote in message
> > news:capjhd$ibc$1...@inews.gazeta.pl...
> >> A part is worthless if no one will make other parts :(.
> >
> > I know. I'll make all parts from start but limited to the Windows
> > platform only.
>
> What are the reasons not to make it multi-platform? (it's just a question,
> I'm not a port-it-everywhere crusader)
Simplicity. It would be much easier for me becaus I would concentrate on the
data structures development (that is the main thing here) instead of
spending time and attention on multi-platform issues, harder programming in
C++ etc. I certainly CAN develop in C++, but C# is easier and also .NET
provides a lot of utility stuff I already convenient with. When moving to
C++ and make it multi-platfiorm, I'll have to learn a lot. When I do that, I
would like to have ready specifications for data structures, so it would not
drive me crazy to think about everything at the same moment. In large
projects it is hard to hold everything about every detail in a single head.
So I split to modules, stages of development etc. Of course it will be, at
some moment, multi-platform. Not from start.
> >> What about roguelikes? Have you worked on any roguelikes? A
> >> roguelike itself (not even an engine) may be considerd a large-scale
> >> project. Moreover in the case of this project it's not the
> >> programming skills that count the most it's the design and analisis
> >> skills that count. In those large-scale projects you worked in, in
> >> how many were you the lead designer?
> >
> > I understand very well what it means, despite I did not made one
> > (yet).
>
> So do one ;). Or at least try to do -- the experience you get while trying
> to make a traditional roguelike is worth a lot more then any advice anyone
> here can give you. And the time invested will pay back tenfold, you have
my
> word on it :).
Well, I wanted to. But then I'll end up the same way as others - years of
development. The point here is try something completely new. I'm mostly
inspires by "The slow world of Roguelike development" thread. My idea is to
try to speed it up. And if I'm not tied to the "standard" development of
roguelike, only in such case it may succeed. Otherwise I'll create another
construction kit using which is still the same slow roguelike development.
As about the game development in general - I made games in the past. Small
home computers (russian ones, that I even do not know how to translate to
English) - sokoban, unlucky frog. Delphi - Sokoban. So I have basic
knowledge of how RL game may work inside.
And I do not want to go further and develop RL game because I would never
create a system like I described.
> > I watcehd progress of some RL development, however.
>
> "So did everyone else" -- and not many people have learned from it ;(.
Because they tried to learn different things. In my case I look to the
process in general to try to simplify and speed it up.
I know this all may look strange, but if somebody comes and looks to your
program and code from "outside", you often get a lot of new feedbacks and
ideas you did not thought about at all. The same here - I'm trying to look
at it from "outside" and see how it could be improved.
> >>> Well, as a 3D, I meant not graphics like in Quake III (Might & Magic
> >>> versions 6 and higher is example of such games). My system is more
> >>> RL oriented. Baldurs gate, Evil Island (Allods 3), Revenant to
> >>> count few - that is what I'm oriented to. This kind of 3De w
> >>> graphics seems do not have very high requirements to preformance.
> >>> Or am I wrong?
> >>
> >> Out of those I played only Baldurs Gate, and Baldurs Gate is 2D.
> >
> > Let's say 2.5D :-)
>
> No, 2D ;).
Well, if there is map terrain that is not plain (terrain height, hills,
moubntains etc.), ability to change point of view (from zenith to horizon
and between smoothly) - is it 3D? Or 3D is just "first person view" like in
Doom?
> > 3D graphics is different from 3D engine. 3D means 3 dimentions, and I
> > meant it for graphics only, not for actions, first person view etc.
> > So 3D cube is 3D cube, but it can be layered as image for 2D game.
>
> 3D objects pre-rendered to 2D sprites make 2D games. If not you would have
> to say that almost all games today are 3D.
See above.
> >> Oh yeah? *pulls out a double shotgun* You asked for it. *BANG! BANG*
> >> ;)
> >
> > *jumps on the floor throwing rocks back* Yep! Repeat till you run out
> > of ammo :-)
>
> Well in that case... *sigh*
> *pulls out the BFG-9000*
>
> ;)
Well, that would not work! *shielding by tower eternium shield*
Vlad Grynchyshyn
news:l54Ac.46403$Oa7....@fe1.columbus.rr.com...
Thanks for a link.
Diwil
graphics
> processing science complexity - far behind an ordinary project. I can dive
> into all this, but then forget about everything else. Mabe in the far
future
> it will be made, but not in my close plans.
Not if you wouldn't make the game engine itself to "think in 3D". The
graphics would easily be presented in 3D, just as if they'd be 2D sprites.
The lighting problems would be solved using a vertex-shading shadow
algorithm for the world light, and so far in my game the only dynamic light
source is that of a player's - I might add the monsters having light sources
later which you can see from a mile away, but that could also be fixed using
a simple clipping to the player's shadows.
Most Roguelikes are in a 2D environment without height alternations, and you
could just make a 3D representation of that world, without the height
mappings and such that Quake or other games offer. I didn't mean making the
Roguelike 3D, just the graphics of it. The only problem you'd encounter
would probably be the light calculations, but most sites already have loads
of tutorials for clipping shadows. Think Diablo, just turn-based and a map
that you could freely spin around and zoom, and you get what I'm thinking
of.
But then again, you could easily add heights to even the 2D version, in
ASCII that'd be a problem to represent, in 2D it'd be a bit more simple (if
using isometric tiles) and in 3D it'd be the most simple... But in my case,
the engine will always remain the same, turn-based, but the way graphics are
processed depends entirely on the UI handler. And as far as I've checked,
making it from 2D to 3D changes nothing but the way the graphical
sub-routines would work... But, since most people program entirely
different, it might not work in the world or system you have in mind.
- Claus "Diwil" Kruuskopf
Hansjoerg Malthaner
> Well, if there is map terrain that is not plain (terrain height, hills,
> moubntains etc.), ability to change point of view (from zenith to horizon
> and between smoothly) - is it 3D? Or 3D is just "first person view" like in
> Doom?
I'd say it is 3D once it makes use of the third dimension. I.e. if the
game has an idea of things on top of other things, several layers of
ground, flying, submerging and such.
A hill IMO isn't enough. It's basically still a 2D grid. But a bridge
starts to require real 3D structures, you can walk over it and through
under it.
This isn't linked to the view of the game IMO. It still could have a 2D
view (although that might be a bit awkward to play).
c.u.
Hajo
Vlad Grynchyshyn
Yes, I *have* in mind to support real-time and 3D. What I want to say is
that I would not implement client and test it from the start. I know I may
overlook something, so any help here may be very valuable. At least I'll try
to build a system in such way that it would not be hard to create 3D client
for it later on. This may change if I find a good free 3D engine
ready-to-use.
Vlad Grynchyshyn
> Vlad Grynchyshyn schrieb:
>
> > Well, if there is map terrain that is not plain (terrain height, hills,
> > moubntains etc.), ability to change point of view (from zenith to
horizon
> > and between smoothly) - is it 3D? Or 3D is just "first person view" like
in
> > Doom?
>
> I'd say it is 3D once it makes use of the third dimension. I.e. if the
> game has an idea of things on top of other things, several layers of
> ground, flying, submerging and such.
>
> A hill IMO isn't enough. It's basically still a 2D grid. But a bridge
> starts to require real 3D structures, you can walk over it and through
> under it.
That is also what I meant as 3D. Evil Islands and Baldurs Gate 2 have it.
> This isn't linked to the view of the game IMO. It still could have a 2D
> view (although that might be a bit awkward to play).
Well, not that awkward, if you can change point of view like in Evil
Islands.
Link to Evil Islands: http://www.evil-islands.com/usa/
Kornel Kisielewicz
>>> 3D graphics is different from 3D engine. 3D means 3 dimentions, and
>>> I meant it for graphics only, not for actions, first person view
>>> etc. So 3D cube is 3D cube, but it can be layered as image for 2D
>>> game.
>>
>> 3D objects pre-rendered to 2D sprites make 2D games. If not you
>> would have to say that almost all games today are 3D.
>
> There's nothing that would stop a Roguelike to have 3D graphics
> engine - you might have the dungeon and objects represented as 3D
> models, but the game engine running exactly the same - if written
> correctly and smart enough, the graphics engine will be just as
> simple to use (excluding the complex 3D math!) as a 2D graphics
> engine. Such as, lets say we have a Goblin at a specific part of the
> map. An ASCII engine would just draw the 'g' to that spot on the
> screen. A 2D engine would draw the sprite for a goblin. And a 3D
> engine would place a 3D model for a goblin to that spot, maybe
> rotating it so it'd face to the last direction it was walking to
> (hey, easy to implement).
What's the use of a 3D model if you are turn-based? Why not use a sprite
instead?
> I actually plan to make 3D graphics myself later on for my roguelike,
> since I wrote the graphical / input handler completely separete from
> the so called business logic.
You will be only able to get non-realtime stills. That's *not* a 3D graphics
engine by normal standards.
> Unless made real-time, the 3D approach would work just as good as
> any. It's just a matter of deciding how the game world is displayed,
> not necessarily involving any changes to the actual game.
And *unless made real-time* is the key point in this sentence. There is no
point in fighting with 3D if you don't plan real-time. It's a lot easier to
make a 2D game then.
regards,
Kornel Kisielewicz
Diwil
> point in fighting with 3D if you don't plan real-time. It's a lot easier
to
> make a 2D game then.
I achnowledge that, but why use graphics at all, aside from ASCII?
Basically, it's just to make the game look prettier and more "acceptable" in
today's standards. I think there'd be plenty of new potential players for a
Roguelike, if it'd look more like Unreal2 than any ASCII-based game.
My point in making the game have ASCII, 2D and 3D renderers is just to make
it reach more people - the oldschool players play in ASCII and the rest
might play with 2D graphics or 3D, depending on their taste (and hardware,
since 2D graphics might work on older comps just as well, when 3D might
not). There'd be no real impact on gameplay (except if you'd program the GUI
to have quick-buttons for several commands) - just as there's no impact when
using 2D graphics.
- Claus "Diwil" Kruuskopf
Kornel Kisielewicz
Good :)
regardsm
Kornel Kisielewicz
Kornel Kisielewicz
> "Diwil" <claus.k...@pp.inet.fi> wrote in message
> news:870Ac.464$594...@read3.inet.fi...
>>>> 3D graphics is different from 3D engine. 3D means 3 dimentions,
>>>> and I meant it for graphics only, not for actions, first person
>>>> view etc. So 3D cube is 3D cube, but it can be layered as image
>>>> for 2D game.
>>>
>>> 3D objects pre-rendered to 2D sprites make 2D games. If not you
>>> would have to say that almost all games today are 3D.
>>
>> There's nothing that would stop a Roguelike to have 3D graphics
>> engine - you might have the dungeon and objects represented as 3D
>> models, but the game engine running exactly the same - if written
>> correctly and smart enough, the graphics engine will be just as
>> simple to use (excluding the complex 3D math!) as a 2D graphics
>> engine. Such as, lets say we have a Goblin at a specific part of the
>> map. An ASCII engine would just draw the 'g' to that spot on the
>> screen. A 2D engine would draw the sprite for a goblin. And a 3D
>> engine would place a 3D model for a goblin to that spot, maybe
>> rotating it so it'd face to the last direction it was walking to
>> (hey, easy to implement).
>>
>
> The problem to that, as already pointed out, not in puttong object
> there and representing it by graphics. As in Quake III, it is easy.
EASY? ROTFL ;).
People who tend to learn just the basics of 3D graphics via engines like
OpenGL tend to think writing an OpenGL-based-3D-engine is easy. How wrong
they are...
> The problem is in the difference for 3D graphics from the "internals"
> point of veiw. The thing you're talking about reqreuis also some sort
> of lighting (if monster have light source)
Which requires a whole lightning mechanism (a lot of work) unless you want
"stills".
> I know it could be made, but it goes to the level of algorthmic and
> graphics processing science complexity - far behind an ordinary
> project.
AND it needs to be thought about while writing the engine. It's not
something you can leave for the future.
>> Unless made real-time, the 3D approach would work just as good as
>> any. It's just a matter of deciding how the game world is displayed,
>> not necessarily involving any changes to the actual game.
>
> There is no point in making 3D not real-time, IMO.
Exactly.
> actually, speeds up the game a lot and gives new possibilities to
> game-playing. It adds playability a lot. Try Might & Magic versions 6
> and higher - I like it really a lot. 3D without real-time does not
> worth effort to make it 3D at all, I think.
And writing a real-time game is a pain in the ass, that is beyond the scope
of this project.
regards,
Kornel Kisielewicz
Kornel Kisielewicz
>> And *unless made real-time* is the key point in this sentence. There
>> is no point in fighting with 3D if you don't plan real-time. It's a
>> lot easier to make a 2D game then.
>
> I achnowledge that, but why use graphics at all, aside from ASCII?
> Basically, it's just to make the game look prettier and more
> "acceptable" in today's standards. I think there'd be plenty of new
> potential players for a Roguelike, if it'd look more like Unreal2
> than any ASCII-based game.
True. But for making it look like Unreal2 you need a Unreal2-sized team of
professionals.
regards,
Kornel Kisielewicz
Kornel Kisielewicz
>> I know it could be made, but it goes to the level of algorthmic and
>> graphics processing science complexity - far behind an ordinary
>> project. I can dive into all this, but then forget about everything
>> else. Mabe in the far future it will be made, but not in my close
>> plans.
>
> Not if you wouldn't make the game engine itself to "think in 3D". The
> graphics would easily be presented in 3D, just as if they'd be 2D
> sprites.
No.
> The lighting problems would be solved using a vertex-shading
> shadow algorithm for the world light, and so far in my game the only
> dynamic light source is that of a player's - I might add the monsters
> having light sources later which you can see from a mile away, but
> that could also be fixed using a simple clipping to the player's
> shadows.
You seem not to fully comprehend what you are talking about here. The
structure of a 3D enabled game is way different then a 2D one.
> didn't mean making the Roguelike 3D, just the graphics of it. The
> only problem you'd encounter would probably be the light
> calculations, but most sites already have loads of tutorials for
> clipping shadows.
The basic problem is 3D real-time rendering, and all the revelant needed
data for that.
regards,
Kornel Kisielewicz
Diwil
professionals.
Thank you captain obvious, but I was merely setting an example. Making a
very good 3D engine isn't too hard, considering the tutorials found at the
Horn of Plenty, which is also known as the Internet. And modeling and such?
Not that hard, trust me on that. Before getting into real programming I used
to make a load of stuff for Quake and other 3D games...
Most 3D engines' biggest problem is the world's physics and such, not the
graphical effects. And in Roguelike, the 3D world wouldn't need to be
processed in any way, it'd be there just for the shows, so... Making a
roguelike look like Unreal 2? I dunno if it'd take that much work. With a
skilled team of 4 members or so, I'd say a month.
- Claus "Diwil" Kruuskopf
SZDev - Slash
"Diwil" <claus.k...@pp.inet.fi> escribió en el mensaje
news:870Ac.464$594...@read3.inet.fi...
I'm also using a layered interface model. Right now i'm working in the main
game engine and a Testing Console UI, and when the engine reaches a stable
point I will work on a IF UI, which will just divide the map in which the
player stands in big squares and calculate a description for the big square
the player stands in, I think it would work well for simple maps altough off
course the descriptions wouldn't be as cool as in a human made IF.
> Unless made real-time, the 3D approach would work just as good as any.
It's
> just a matter of deciding how the game world is displayed, not necessarily
> involving any changes to the actual game.
>
> - Claus "Diwil" Kruuskopf
>
>
--
---------------------------------------
Santiago Zapata
L:Java E++ T- R+ !P D+ G++ F:ADoM RL* RLA-
W:G Q++ AI+ GFX- SFX- RN++++ PO--- Hp- Re+ S+ c-- ?OS *KG
---------------------------------------
SZDev - Slash
"Diwil" <claus.k...@pp.inet.fi> escribió en el mensaje
news:UyiAc.284$Ik5...@read3.inet.fi...
If this is true then I will summon you when I'm ready to make a 3D UI for my
game.
--
---------------------------------------
Santiago Zapata
L:Java E++ T- R+ !P D+ G++ F:ADoM RL* RLA-
W:G Q++ AI+ GFX- SFX- RN++++ PO--- Hp- Re+ S+ c-- ?OS *KG
---------------------------------------
> - Claus "Diwil" Kruuskopf
>
>
Diwil
my game.
If the project's interesting enough and I actually have spare time, bring it
on. ;D
- Claus "Diwil" Kruuskopf
Kornel Kisielewicz
>> True. But for making it look like Unreal2 you need a Unreal2-sized
>> team of professionals.
>
> Thank you captain obvious, but I was merely setting an example.
> Making a very good 3D engine isn't too hard, considering the
> tutorials found at the Horn of Plenty, which is also known as the
> Internet. And modeling and such? Not that hard, trust me on that.
> Before getting into real programming I used to make a load of stuff
> for Quake and other 3D games...
ROTFL! May I repost this?
[ps asides from other funny stuff here - did you think that you need to
ANIMATE those models also? Have you ever done that?]
> Most 3D engines' biggest problem is the world's physics and such, not
> the graphical effects. And in Roguelike, the 3D world wouldn't need
> to be processed in any way, it'd be there just for the shows, so...
It wouldn't? Well of course, if you have a square-turn-based map ;).
> Making a roguelike look like Unreal 2? I dunno if it'd take that much
> work. With a skilled team of 4 members or so, I'd say a month.
A month you say? So tell me what features it would have? Real-time? Animated
models? Collision-detection? Support for random map-generation? Portals?
BSP-tree based pathfinding? Dynamic lighting? Etc?
regards,
Kornel Kisielewicz
* rolling on the floor laughing*
Diwil
ANIMATE those models also? Have you ever done that?]
Yeah, I've animated plenty of models before, but then again think of a
Roguelike - how much animation would you possibly need, unless you'd turn
the game into real-time, which would make it an entirely different deal.
> > Making a roguelike look like Unreal 2? I dunno if it'd take that much
> > work. With a skilled team of 4 members or so, I'd say a month.
>
> A month you say? So tell me what features it would have? Real-time?
Animated
> models? Collision-detection? Support for random map-generation? Portals?
> BSP-tree based pathfinding? Dynamic lighting? Etc?
As I said, "look like Unreal2". I meant the graphical side. I haven't meant
anything else, except for the graphics to be 3D, during the entire thread.
But since this talk's going nowhere as everybody's missing each other's
points here, I'll just back out. The original question was that could a
Roguelike be presented in 3D? Yes, it would, if you'd only mean the
graphics. Making the game actually 3D, and work in 3D, would be an entirely
different matter.
Enjoy the floor. ;)
- Claus "Diwil" Kruuskopf
SZDev - Slash
"Kornel Kisielewicz" <charon...@magma-net.pl> escribió en el mensaje
news:cashq0$bqn$1...@inews.gazeta.pl...
May be he meant a 3D Chess-like thinguie with no model animation, square by
square movement, etc. (no sarcasm) which would not be too bad for me, I
would probably like it...
> regards,
> Kornel Kisielewicz
> * rolling on the floor laughing*
>
>
Diwil
by
> square movement, etc. (no sarcasm) which would not be too bad for me, I
> would probably like it...
...Finally somebody who understood what I meant. *sigh* Animations would be
possible to make still, but basically just what you said - tile-by-tile
movement, only represented as 3D models instead of 2D sprites.
- Claus "Diwil" Kruuskopf
SZDev - Slash
"Diwil" <claus.k...@pp.inet.fi> escribió en el mensaje
news:m7kAc.320$Ik5...@read3.inet.fi...
I'd love to see this, specially looking the world from the PC perspective
just for the show and being able to rotate the camera, zoom in and out
etc.etc.
You must know however that it would be a huge modeling task, considering the
number of races of an average RL.
>
> - Claus "Diwil" Kruuskopf
SZDev - Slash
"Vlad Grynchyshyn" <vg...@yahoo.com> escribió en el mensaje
news:2j5e58F...@uni-berlin.de...
> Hi!
>
> I forged this idea for a long time (a year or so). Just for case it is
fated
> to die, I decided to send it here and check if it is worth enough to start
> it. I know it looks a bit too much, but everything below does not means I
> will do all of that if something is voted to do not do it - these are jut
> ideas that I would like to know if they're good enough to start something
> like below and what from below is really worth to do at all.
>
>
> The idea is to create a sort of simplified modeling tool with simplified
> programming language ("program" here will be called "scenario"), where you
> can in addition to populating database about monsters and items create
some
> rules for interaction between them, interaction with user interface and
user
> actions, interaction with timeline and interaction between scenarios
> themselves. So, instead of writing tonns of C++ code, scenario writer will
> be able to create a sort of model of game - all the rules described in
much
> more convenient way.
>
> The idea then extends to quite remarkable area - n-tire development -
> separating of game engine from the code and user interface.
>
> The idea is to represent the game in 4 tires:
> - Database that describes items, monsters, levels, rules for levels
> generating, rules for interactions, scenarios (quests and complex
> interactions, such as smithing weapons or herbs growing), screens data
> (rules about populating screens by data, for example, inventory list).
>
> - Engine - very generic engine that is a host for game. You select game
> database and engine runs it. Because game model database will be a sort of
> well-documented standard, engine can be developed in a lot of very
different
> platforms and languages by anybody.
>
> - Client data - separate part of the game database that describes data
> specific for the game client. Sounds, graphics, additional messages, video
> etc.
>
> - The client itself - it is a wrapper written around the engine. ASCII,
> Java, Windows applications are examples. The client is responsible for
> representing the interface, provide user input into the engine, provide
> design of screens and display data prepared by engine for screens.
>
> A bit more about the last thing - connection between game engine and the
> client.
> There will be list of clients supported by game. For every client, you
will
> define additional data. For example, if you have item class - sword, for
> graphical client you will have additional properties - image of how that
> sword looks like on the ground, how it looks like in the inventory list, a
> sound how it sounds when dropped on the floor etc. If you have 3-D
client -
> images will be different, so for another client you will have different
set
> of properties. The client-specific data will be stored in a separate
> database files, so, for example, to play a game in ASCII client, you will
> have to download only 2 data files - core game data and ASCII client data
> (actually, no much - just characters of how every item class or every
> monster is represented on map). Such things as map scrolling, scaling,
> graphics around the map and controls, user input and selection from list
of
> items etc. are up to the client. The client, however, should have clear
> description of every screen data and what is expected from the screen (for
> example, "select metal item from list for smithing").
>
I use a similar model, but in your "Client" part I split it in a
UserInterface and a System Interface.
For example, I could design a UserInterface called SpriteUI, it takes the
data from the game and displays it in a grid using flat images, (which would
be covered as your "additional data"). However it doesn't show anything for
itself; it has to use a SystemInterface capable of displaying Sprites, which
may be for example a "Swing Sprite Interface" or a "SDL Interface" or
anything, which can be reused in any other project where tiles must be
shown.
The UserInterface depends on a family of SystemInterfaces, but they are
developed independently.
:: very huge snippage ::
Kornel Kisielewicz
>> [ps asides from other funny stuff here - did you think that you need
>> to
> ANIMATE those models also? Have you ever done that?]
>
> Yeah, I've animated plenty of models before, but then again think of a
> Roguelike - how much animation would you possibly need, unless you'd
> turn the game into real-time, which would make it an entirely
> different deal.
It is real-time we're talking about.
>>> Making a roguelike look like Unreal 2? I dunno if it'd take that
>>> much work. With a skilled team of 4 members or so, I'd say a month.
>>
>> A month you say? So tell me what features it would have? Real-time?
>> Animated models? Collision-detection? Support for random
>> map-generation? Portals? BSP-tree based pathfinding? Dynamic
>> lighting? Etc?
>
> As I said, "look like Unreal2". I meant the graphical side. I haven't
> meant anything else, except for the graphics to be 3D, during the
> entire thread.
> But since this talk's going nowhere as everybody's missing each
> other's points here, I'll just back out.
Yes we are missing each other. The author of the original request wanted a
real-time engine. He even said (and I double him here) that a still-image 3D
is basicaly useless. Heck, and even if you wan't just still images think
about dynamical lighting and the like -- that's not child's play y'know
(although if you're satisfied with 5fps it could be done not as hard).
regards
Kornel Kisielewicz
Kornel Kisielewicz
> "Diwil" <claus.k...@pp.inet.fi> escribió en el mensaje
> news:m7kAc.320$Ik5...@read3.inet.fi...
> considering the number of races of an average RL.
Oh, that's no problem for him, for he did thousands of models ;)
regards,
Kornel Kisielewicz
Diwil
*sigh* You honestly childish enough to embark to some sort of flamewar with
me, just because we completely missed each other's points? I know modeling
for a roguelike would be a devious task, and depending on the complexity
required for the monsters it might take from a few hours to a few days, plus
the skinning etc.
Just because I talk of past experience and what I know of modeling to Quake
and Half-Life, doesen't necessarily make me have a deus-complex, now does
it? And I really have enough of childish fuckers trying to annoy me online,
so drop the act before you start. Dont become one of the assholes, mm'kay?
- Claus "Diwil" Kruuskopf
Diwil
from a few hours to a few days...
...Per model. Damnit.
- Claus "Diwil" Kruuskopf
Kornel Kisielewicz
>>> Making a roguelike look like Unreal 2? I dunno if it'd take that
>>> much work. With a skilled team of 4 members or so, I'd say a month.
>>
>> A month you say? So tell me what features it would have? Real-time?
>> Animated models? Collision-detection? Support for random
>> map-generation? Portals? BSP-tree based pathfinding? Dynamic
>> lighting? Etc?
>
> As I said, "look like Unreal2". I meant the graphical side. I haven't
> meant anything else, except for the graphics to be 3D, during the
> entire thread.
As a matter of explanation for my sudden explosion of laughter -- if after
spending two threee nights on caffeine and nicotine, trying to optimize the
softshadow algorithm so it has a decent framerate on g-cards slower than
R8k, killing oneself over every f'kin line of code, a guy comes up and sais
that writing a Unreal2 like graphics engine is easy... one can lose his
temper (no matter what his intention was). Sorry ;)
regards,
Kornel Kisielewicz
Diwil
> spending two threee nights on caffeine and nicotine, trying to optimize
the
> softshadow algorithm so it has a decent framerate on g-cards slower than
> R8k, killing oneself over every f'kin line of code, a guy comes up and
sais
> that writing a Unreal2 like graphics engine is easy... one can lose his
> temper (no matter what his intention was). Sorry ;)
I know the feeling better than you think. Good luck with the softshadow
algorithm. ;)
- Claus "Diwil" Kruuskopf
Kornel Kisielewicz
*sigh* You are lucky, not many of other group regulars read this thread for
you would probably get plonked. Ok, my annoyment I explained a few messages
above, so I wont go into that. What I will try to explain to you is why you
got such a reaction. One of the regular type of newcomers we get here at
RGRD are the people that come here and say "this is easy, I could do that in
a few days" etc. This kind of newbies is generaly amusing, but in large
numbers quite annoying. The reason that I replied to your "graphics dreams"
is that I work on graphics for a group, and what you talked about was
ridiculous. And don't tell me that there we missed our points, for it's your
fault, not mine. Vlad wrote as a reply to YOUR post:
Vlad Grynchyshyn wrote:
There is no point in making 3D not real-time, IMO. Real-time, actually,
speeds up the game a lot and gives new possibilities to game-playing. It
adds playability a lot. Try Might & Magic versions 6 and higher - I like it
really a lot. 3D without real-time does not worth effort to make it 3D at
all, I think.
Oh, and read the netiquette. That's something we don't particulary enforce
here, but it's considered rude to break it nevertheless.
regards,
Kornel Kisielewicz
Diwil
for
> you would probably get plonked. Ok, my annoyment I explained a few
messages
> above, so I wont go into that. What I will try to explain to you is why
you
> got such a reaction. One of the regular type of newcomers we get here at
> RGRD are the people that come here and say "this is easy, I could do that
in
> a few days" etc.
Ok, so you're a regular and I respect that.
I'll just back off and wont interfere with your kingdom, but just read the
posts and not suggest anything, as I see you and the others can do such a
better task at everything. Cheers!
- Diwil
Kornel Kisielewicz
You didn't get the point did you? *sigh*
Whatever. Cheers!
regards,
Kornel Kisielewicz
Arthur J. O'Dwyer
I would like something like that, too, *if* it were done well.
We're talking Warcraft 3-quality landscapes and better-than-Warcraft
3-quality models, though; otherwise I wouldn't consider it worth
while.
This is yet another old idea, BTW; see for instance
Message-ID: Pine.LNX.4.55L-032....@unix46.andrew.cmu.edu
in May 2003. Sorry, I don't know what Google did with the first
half of that thread...
-Arthur
Kornel Kisielewicz
>>>> A part is worthless if no one will make other parts :(.
>>>
>>> I know. I'll make all parts from start but limited to the Windows
>>> platform only.
>>
>> What are the reasons not to make it multi-platform? (it's just a
>> question, I'm not a port-it-everywhere crusader)
>
> Simplicity. It would be much easier for me becaus I would concentrate
> on the data structures development (that is the main thing here)
> instead of spending time and attention on multi-platform issues,
> harder programming in C++ etc.
Well, seems reasonable. But if I would go for simplicity I'd choose Ruby ;)
> I certainly CAN develop in C++, but C#
> is easier and also .NET provides a lot of utility stuff I already
> convenient with. When moving to C++ and make it multi-platfiorm, I'll
> have to learn a lot. When I do that, I would like to have ready
> specifications for data structures, so it would not drive me crazy to
> think about everything at the same moment. In large projects it is
> hard to hold everything about every detail in a single head. So I
> split to modules, stages of development etc. Of course it will be, at
> some moment, multi-platform. Not from start.
Agreed.
>>> I understand very well what it means, despite I did not made one
>>> (yet).
>>
>> So do one ;). Or at least try to do -- the experience you get while
>> trying to make a traditional roguelike is worth a lot more then any
>> advice anyone here can give you. And the time invested will pay back
>> tenfold, you have my word on it :).
>
> Well, I wanted to. But then I'll end up the same way as others -
> years of development.
A skeleton roguelike is 1week development. A simple roguelike is 3 weeks
development. A fun simple roguelike is 2-3 months of development (give or
take a year for random time-eaters). Each of these would help you a lot. Try
at least the first one.
> The point here is try something completely new.
That's almost everyone's point :D
> I'm mostly inspires by "The slow world of Roguelike development"
> thread. My idea is to try to speed it up. And if I'm not tied to the
> "standard" development of roguelike, only in such case it may
> succeed.
No. If you don't prepare a good background (and trying a skeleton realy
helps) your engine will land on the pile of many other generic engines that
were created over the past years. The main problem of those engines was
usualy the fact that the designers didn't know what is needed in the last
stages of roguelike programming, cause they never developed even a very
simplistic one.
> As about the game development in general - I made games in the past.
> Small home computers (russian ones, that I even do not know how to
> translate to English) - sokoban, unlucky frog. Delphi - Sokoban.
That's a completely different type of games. cRPG developing experience
might be usefull. All other game-developing experience is useless modulo the
general programming experience gained.
> So I
> have basic knowledge of how RL game may work inside.
No ;). One of the main problems of roguelike engines is the handling of
large amounts of complex data which isn't the case in small games.
> And I do not want to go further and develop RL game because I would
> never create a system like I described.
I tell you 1-3 weeks is hell worth it. (and no, by 1-3 weeks I don't mean 12
hour development day ;)
>>> Let's say 2.5D :-)
>>
>> No, 2D ;).
>
> Well, if there is map terrain that is not plain (terrain height,
> hills, moubntains etc.), ability to change point of view (from zenith
> to horizon and between smoothly) - is it 3D? Or 3D is just "first
> person view" like in Doom?
First person, third person, 3d rts, any that allows you free camera
movement.
>> Well in that case... *sigh*
>> *pulls out the BFG-9000*
>>
>> ;)
>
> Well, that would not work! *shielding by tower eternium shield*
[ever saw a BFG in Doom? A shield is useless ;)]
Elethiomel
> Vlad Grynchyshyn wrote:
> There is no point in making 3D not real-time, IMO. Real-time, actually,
> speeds up the game a lot and gives new possibilities to game-playing. It
> adds playability a lot. Try Might & Magic versions 6 and higher - I like it
> really a lot. 3D without real-time does not worth effort to make it 3D at
> all, I think.
Since you seem to agree with this, Kornel, I shall reply here rather
than farther up the thread.
I disagree with you both. A game can have turn based mechanics and still
make good use of 3D models. I, for one, liked the concept of the Temple
of Elemental Evil game, where this was partly used. True, there wasn't a
complete lighting engine, as the maps were predrawn, but there were 3D
models used. There was animation, but in combat the game was not realtime.
The Silent Storm series is a better example though, in combat there you
have a fully rotatable and zoomable map, 3D multy-story structures,
etc... and it's turn based. In my opinion, the result is very nice indeed.
Massive Assault is another example of a turn based game with 3D models
and 3D terrain (I really like this one too. Its mechanics are great...
it's like Diplomacy or Chess, there's no randomness in unit interaction.
No RNG to blame but the world-seeding one. Which is great for
multiplayer, IMO).
I'm not saying "these games are good roguelike models" but rather that
"these games are examples of commercial games using 3D that are also
turn based" to give examples of why I feel that you and Vlad aren't
seeing all the possibilities.
Yes, modelling for a roguelike would be a hellish task, way above and
beyond that of creating a comprehensive tileset. I don't see the engine
as as much of a problem - there are free engines out there you could use
if you wanted to, like the cube engine -- but I've never done any 3D
programming, so there are probably hurdles I don't see. Anyway, even
though modelling would as I said be a major task, someone might be up to
doing it.
Try not to dismiss the idea of a non-realtime 3D roguelike just because
3D != turn based.
Kornel Kisielewicz
> Kornel Kisielewicz wrote:
>
>> Vlad Grynchyshyn wrote:
>> There is no point in making 3D not real-time, IMO. Real-time,
>> actually, speeds up the game a lot and gives new possibilities to
>> game-playing. It adds playability a lot. Try Might & Magic versions
>> 6 and higher - I like it really a lot. 3D without real-time does not
>> worth effort to make it 3D at all, I think.
>
> Since you seem to agree with this, Kornel, I shall reply here rather
> than farther up the thread.
I never said I agreed with this -- I just said it was Vlad's point ;).
> I disagree with you both. A game can have turn based mechanics and
> still make good use of 3D models.
> I, for one, liked the concept of
> the Temple of Elemental Evil game, where this was partly used.
Never saw the game ;-/
> True,
> there wasn't a complete lighting engine, as the maps were predrawn,
> but there were 3D models used. There was animation, but in combat the
> game was not realtime.
As far as I can tell, the models were animated anyway - and that starts a
lot of work.
> The Silent Storm series is a better example though, in combat there
> you have a fully rotatable and zoomable map, 3D multy-story
> structures, etc... and it's turn based. In my opinion, the result is
> very nice indeed.
I love turn-based games myself. But you're missing the point I think. In all
the more recent turn-based games (which are not many) inserting turn-based
time does not free the rendering engine from it's load! They still need
real-time rendering!
> I'm not saying "these games are good roguelike models" but rather that
> "these games are examples of commercial games using 3D that are also
> turn based" to give examples of why I feel that you and Vlad aren't
> seeing all the possibilities.
Don't worry, I have my own ideas for turn-based 3D games :).
> Yes, modelling for a roguelike would be a hellish task, way above and
> beyond that of creating a comprehensive tileset. I don't see the
> engine as as much of a problem - there are free engines out there you
> could use if you wanted to, like the cube engine -- but I've never
> done any 3D programming, so there are probably hurdles I don't see.
You could use a 3D engine, but you couldn't plug it into another one (like
the one Vlad's attempting).
> Anyway, even though modelling would as I said be a major task,
> someone might be up to doing it.
You know how much a stupid car model can cost? 1500$. Now think about the
market value of a whole bunch of characters for a rl game, and find a moron
to do it for free ;). I only created 4 human-like 3D characters in my life,
and the fastest I did one was three weeks (counting in creating textures,
vertex painting) -- they were all high detail though. Of course you could
use Poser or the like, but it has it's limitations (you'll still have to do
non-humans by yourself). It's a helluva job. Modelling space-ships is easier
;).
> Try not to dismiss the idea of a non-realtime 3D roguelike just
> because 3D != turn based.
I don't. What I would like to see is a roguelikeish DungeonMaster-view like
game.
ABCGi
> Hi!
>
> I forged this idea for a long time (a year or so). Just for case it is fated
> to die, I decided to send it here and check if it is worth enough to start
> it. I know it looks a bit too much, but everything below does not means I
> will do all of that if something is voted to do not do it - these are jut
> ideas that I would like to know if they're good enough to start something
> like below and what from below is really worth to do at all.
[...]
> The most "probable" solution for above idea in obvious time is following:
> Because my skills, I can very easy write an interface for Theatry - game
> editor/construction kit/scenario editor. It will be Web-based interface
> written using C# and hosted somewhere (luckily I already have place where to
> put it). Using C#, I can also write a prototype of game engine, and simple
> client application for it (with no design at all, just data, ASCII-based map
> and user input). I will start from the most simple parts to create something
> to start from, then extend/improve it in the process. I would not release
> specifications for game database to write other engines (for example,
> portable open-source C++ engine) till I develop the concept to the state
> when such games as ADOM could be developed without a single line of C++ code
> for the game model part, and also a bit extend the model to use graphics as
> well. Possible also (to some limit as I see from existing game construction
> kits) to create more or less universal clients that will host multiple
> games.
>
> Why Web interface? To allow something like source forge gives -
> collaborative work of large number of people (not only developers) on the
> game model development. The goal of interface development is also make it
> user-friendly enough to allow use it by non-developers. You can skip below
> example of how I see it should look like from scenario writer point of view.
[...]
> Estimated project start - July 20 (my vacation). If it all worth a start at
> all, I will establish web site for this project, if anybody else is
> interested to participate.
a) In your project plan don't rely on participation (typically won't get it till
you have an exciting useful product).
b) Don't choose language till doing design (the above is user requirements and
some analysis). Unless one is picking C# because "I want to use it etc", and if
so, state that.
c) Do analysis of other open source projects to save development effort, unless
one wants to "code it all myself", and if so, state that. Your stuff has been
done before and your requirements are already a lot of work.
d) Do some design followed by proof of technology and proto-types unless one
wants to "jump right into the code" or "extreme program" or "just doing this
for fun and don't enjoy those parts", and if so, state that.
e) Write a small simple, but complete, achievable version of your game as the
foundation.
Good luck!
--
ABCGi ab...@yahoo.com http://abcgi.fly.to S14 D15 I17 W12 C9
Jeff Lait
> > And *unless made real-time* is the key point in this sentence. There is no
> > point in fighting with 3D if you don't plan real-time. It's a lot easier
> to
> > make a 2D game then.
>
> I achnowledge that, but why use graphics at all, aside from ASCII?
> Basically, it's just to make the game look prettier and more "acceptable" in
> today's standards. I think there'd be plenty of new potential players for a
> Roguelike, if it'd look more like Unreal2 than any ASCII-based game.
>
> My point in making the game have ASCII, 2D and 3D renderers is just to make
> it reach more people - the oldschool players play in ASCII and the rest
> might play with 2D graphics or 3D, depending on their taste (and hardware,
> since 2D graphics might work on older comps just as well, when 3D might
> not). There'd be no real impact on gameplay (except if you'd program the GUI
> to have quick-buttons for several commands) - just as there's no impact when
> using 2D graphics.
No impact on gameplay? And you say it should look more like Unreal2?
Don't you think going first perspective would have a huge impact on
game play?
Consider Nethack. If you play it viewing only a small area, not the
whole 80x25 at once, you have a huge impact on gameplay. Everything
changes. (This is one of the reasons why I wanted to write POWDER
from scratch, as I wanted my gameplay to work with the small window
present)
Indeed, consider Nethack. Consider going from ascii to graphics.
Again, there are big gameplay changes. The purple @ in the plane of
earth is suddenly a lot less scary.
If you mean 3d as in an isometric engine which happens to render using
triangles rather than sprites, then I could agree with you. However,
then the claim that it "Has to be real time" is foolish.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Glen Wheeler
Yeah, I can empathise Kornel. I've just written dynamic lighting and even
a pseudo-radiosity algorithm for work. It took me three months to get
right.
If I was talking, I'd probably have virtually spit-out-my-coffee as well
:).
--
Glen
Glen Wheeler
"Hansjoerg Malthaner" <hansjoerg...@nurfuerspam.de> wrote in message
news:2jd5fqF...@uni-berlin.de...
> Vlad Grynchyshyn schrieb:
>
> > Well, if there is map terrain that is not plain (terrain height, hills,
> > moubntains etc.), ability to change point of view (from zenith to
horizon
> > and between smoothly) - is it 3D? Or 3D is just "first person view" like
in
> > Doom?
>
> game has an idea of things on top of other things, several layers of
> ground, flying, submerging and such.
>
> A hill IMO isn't enough. It's basically still a 2D grid. But a bridge
> starts to require real 3D structures, you can walk over it and through
> under it.
>
> This isn't linked to the view of the game IMO. It still could have a 2D
> view (although that might be a bit awkward to play).
>
Eeek! That makes my game 3D! I've such things as enemies hiding out in
trees and wotnot.
Well, not by my standards but at least by yours -- huzzah for my 3D
roguelike in alpha :).
--
Glen
R. Alan Monroe
>> Most 3D engines' biggest problem is the world's physics and such, not
>> the graphical effects. And in Roguelike, the 3D world wouldn't need
>> to be processed in any way, it'd be there just for the shows, so...
>
>It wouldn't? Well of course, if you have a square-turn-based map ;).
>
>> Making a roguelike look like Unreal 2? I dunno if it'd take that much
>> work. With a skilled team of 4 members or so, I'd say a month.
>
>A month you say? So tell me what features it would have? Real-time? Animated
>models? Collision-detection? Support for random map-generation? Portals?
>BSP-tree based pathfinding? Dynamic lighting? Etc?
I hacked together an ultra simplistic opengl dungeon in about three
evenings. No features other than walls and a couple of nonmoving
billboard enemies, but still... walls and models aren't super
difficult to paint onscreen. It's doing the modelling and texturing
and keyframing that is the real time sink.
My linux box bit the dust, or I'd give you a URL for my program.
Alan
Kornel Kisielewicz
Couldn't have said it better ABCGi ;)
regards,
Kornel Kisielewicz
R Dan Henry
torespon...@hotmail.com (Jeff Lait) declared:
>"Diwil" <claus.k...@pp.inet.fi> wrote in message news:<xGgAc.240$Ik5...@read3.inet.fi>...
>> > And *unless made real-time* is the key point in this sentence. There is no
>> > point in fighting with 3D if you don't plan real-time. It's a lot easier
>> to
>> > make a 2D game then.
>>
>> I achnowledge that, but why use graphics at all, aside from ASCII?
>If you mean 3d as in an isometric engine which happens to render using
>triangles rather than sprites, then I could agree with you. However,
>then the claim that it "Has to be real time" is foolish.
Yes, but Diwil wasn't the one saying it has to be real time. I think
much confusion has arisen from confusing his "I achnowledge that" as
refering to the real time bit, rather than the "It's a lot easier to
make a 2D game then" that it immediately follows.
--
R. Dan Henry
danh...@inreach.com
They can have my ASCII graphics when they pry them
from my cold dead (c) and (d) slots.
Martin Read
>Jeff Lait wrote:
>> "Diwil" <claus.k...@pp.inet.fi> wrote in message
>> news:<xGgAc.240$Ik5...@read3.inet.fi>...
>> Again, there are big gameplay changes. The purple @ in the plane of
>> earth is suddenly a lot less scary.
>
>their graphic counterparts!
Heh. I've been maintaining that that purple '@' is one of the scariest
things ever seen in a computer game for a long time :)
m.
--
Martin Read - my opinions are my own. share them if you wish.
Vlad Grynchyshyn
news:2jdr6hF...@uni-berlin.de...
>
> I'm also using a layered interface model. Right now i'm working in the
main
> game engine and a Testing Console UI, and when the engine reaches a stable
> point I will work on a IF UI, which will just divide the map in which the
> player stands in big squares and calculate a description for the big
square
> the player stands in, I think it would work well for simple maps altough
off
> course the descriptions wouldn't be as cool as in a human made IF.
>
I guess you should look to such game as Revenant. It uses similar approach,
though it is not fully 3D (no first person view and point of view is fixed).
It seems it caches prepared graphics on disk in internal format and re-uses
it later to do not do re-calculates. And it also uses approach of 3x3, 4x4,
5x5 squares of area loaded at once. It makes the area looks really large
while at the same time, amount of memory needed and processing is ok. And
also you can configure there the square size, so better computers may do
better.
Vlad Grynchyshyn
> Vlad Grynchyshyn wrote:
> > "Kornel Kisielewicz" <charon...@magma-net.pl> wrote in message
> > news:capu43$di3$1...@inews.gazeta.pl...
> >> Vlad Grynchyshyn wrote:
> >>> I understand very well what it means, despite I did not made one
> >>> (yet).
> >>
> >> So do one ;). Or at least try to do -- the experience you get while
> >> trying to make a traditional roguelike is worth a lot more then any
> >> advice anyone here can give you. And the time invested will pay back
> >> tenfold, you have my word on it :).
> >
> > Well, I wanted to. But then I'll end up the same way as others -
> > years of development.
>
> A skeleton roguelike is 1week development. A simple roguelike is 3 weeks
> development. A fun simple roguelike is 2-3 months of development (give or
> take a year for random time-eaters). Each of these would help you a lot.
Try
> at least the first one.
>
[snip]
>
> I tell you 1-3 weeks is hell worth it. (and no, by 1-3 weeks I don't mean
12
> hour development day ;)
Forget to tell - I made also mods for Diablo II, such as required to create
new items and behaviors for them.
Anyway you may be right. I'll try to create a simple game.
But if the problem, as you said, manipulating of large amounts of complex
data - that is not a problem for me. *If* it is the only problem for CRPG,
then I cans tart just now. Working on software design and a lot of
development in a lot of different programming languages and tools, I learned
how to handle such cases, optimize performance and memory load etc.
And simple CRPG creating would not help me much in this direction, because
simple game means simpler data structures :-)
> >> Well in that case... *sigh*
> >> *pulls out the BFG-9000*
> >>
> >> ;)
> >
> > Well, that would not work! *shielding by tower eternium shield*
>
> [ever saw a BFG in Doom? A shield is useless ;)]
Saw. Eternium shield is like a wall. Do you able to blow out wall by BFG?
;-] The most you can is blow out shield. Then I'll use another one. And BFG
uses a lot of ammo, so you quickly will run out of it. Better use it to blow
out large amounts of monstrous beings :-)
Vlad Grynchyshyn
>
> I use a similar model, but in your "Client" part I split it in a
> UserInterface and a System Interface.
>
> For example, I could design a UserInterface called SpriteUI, it takes the
> data from the game and displays it in a grid using flat images, (which
would
> be covered as your "additional data"). However it doesn't show anything
for
> itself; it has to use a SystemInterface capable of displaying Sprites,
which
> may be for example a "Swing Sprite Interface" or a "SDL Interface" or
> anything, which can be reused in any other project where tiles must be
> shown.
>
> The UserInterface depends on a family of SystemInterfaces, but they are
> developed independently.
>
I would not dive into such details and leave it up to the implementer of the
user interface. Some clients may require very tight integration between
parts you described, such as 3D UI. What graphics library to use - it
depends on really many things and thinking about it until implementing some
really particular case is useless for me IMO.
I'm more concerned currently about the core and engine and communication
with client part. To make them all reside in separate files and, at the same
time, work as something integrated, need to work out a lot of things.
Vlad Grynchyshyn
I would not rely on it at all. In your last sentence, you do exactly
matching with what I'm going to do:
do all alone from start (unless somebody would really like to join). It will
indicate success, if somebody else would start using approach and create
additional modules for system. But it is far in the future. The closest goal
of project is to provide approach and tools. If they would be good enough -
they will be used. If not - then I'll see how to improve it till absolutely
sure it is useless to go further.
> b) Don't choose language till doing design (the above is user requirements
and
> some analysis). Unless one is picking C# because "I want to use it etc",
and if
> so, state that.
I have a half of the design documentation made from what I already can make
some of the most generic decisions. What I wrote here is a summary 2-year
careful thinking, analysis, game-playing, mods-making, experimenting with
new user interface ideas (for large and complex data structures editing)
etc. Also, if you followed thread, I already answered to Kornel why I would
not make it multi-platform from start and why I would use C# - it just would
go quicker and better for me because my skills and experience.
It is possible I will use some other languages for client-side modules,
specially for web browser, if I ever would make it.
> c) Do analysis of other open source projects to save development effort,
unless
> one wants to "code it all myself", and if so, state that. Your stuff has
been
> done before and your requirements are already a lot of work.
I know well the process of open-source development and team-work.
What I meant by the sentence "To allow something like source forge gives..."
is mostly source code controlling for team-work, with only certain features
that soure forge gives (downloads, archive, versioning etc.). It would look
and feel more like a project in Visual Studio .NET than source forge
project. I do not plan to re-create anything large like source forge itself
:-)
> d) Do some design followed by proof of technology and proto-types unless
one
> wants to "jump right into the code" or "extreme program" or "just doing
this
> for fun and don't enjoy those parts", and if so, state that.
I'll re-use a lot of things from my previous project for UI for editing of
core data. I'm also very convenient with XML (include complex data
structures, worked with xCBL, for exmaple). I know very well technologies I
would use. There will be a few gamma and beta versions that I will use as
prototypes. I'll use "patching" approach - represent only defaul behavior of
some feature from start that will be extended later - to see general picture
of the system and see if the feature is worth to inlude at all etc.
Most probably it wil me prototyping with extreme programming at start, then
re-engineering based on the prototype review, and then careful extending of
the features, with a few complete reviews of the code to find out and fix
all major performance or memory usage flaws (that I'm sure often appear for
large systems after adding and extending features).
> e) Write a small simple, but complete, achievable version of your game as
the
> foundation.
Will do that. Maybe not only one - have a lot of new nice scenarios in mind
;-)
Anyway, my concept is a bit more generic than just game-development. It will
be much like complex objects modelling and running tool (very game-oriented
from start though). So I'll also test some other possibilities of such
system, if ever get to it.
>
> Good luck!
Your notes are valuable because they make me sure I'm on the correct path
(or I'm wrong? :-)
Thanks a lot!
Kornel Kisielewicz
>> z.e.r.o wrote:
>>
>> Hey, I didn't get the original post, may someone repost it?
>>
>
> Try:
>
http://groups.google.com/groups?threadm=Xns95097CF202E1DKostatus%40203.109.252.31
>
> (BTW, how you guys create a tiny URL out of link google groups post?)
regards,
Kornel Kisielewicz
Martin Read
>Saw. Eternium shield is like a wall. Do you able to blow out wall by BFG?
>;-] The most you can is blow out shield. Then I'll use another one. And BFG
>uses a lot of ammo, so you quickly will run out of it. Better use it to blow
>out large amounts of monstrous beings :-)
The BFG plasma ball blows out the shield; the secondary radiation from
the gun then fries *you* before you can get out another shield.
Kornel Kisielewicz
> "Vlad Grynchyshyn" <vg...@yahoo.com> wrote:
>> Saw. Eternium shield is like a wall. Do you able to blow out wall by
>> BFG? ;-] The most you can is blow out shield. Then I'll use another
>> one. And BFG uses a lot of ammo, so you quickly will run out of it.
>> Better use it to blow out large amounts of monstrous beings :-)
>
> The BFG plasma ball blows out the shield; the secondary radiation from
> the gun then fries *you* before you can get out another shield.
Couldn't have said it better ;)
regards,
Kornel Kisielewicz
Kornel Kisielewicz
>> A skeleton roguelike is 1week development. A simple roguelike is 3
>> weeks development. A fun simple roguelike is 2-3 months of
>> development (give or take a year for random time-eaters). Each of
>> these would help you a lot. Try at least the first one.
>>
> [snip]
>>
>> I tell you 1-3 weeks is hell worth it. (and no, by 1-3 weeks I don't
>> mean 12 hour development day ;)
>
> Forget to tell - I made also mods for Diablo II, such as required to
> create new items and behaviors for them.
Mods are a bad example -- they use a already established codebase and hide
that codebase from you.
> Anyway you may be right. I'll try to create a simple game.
:-)
> But if the problem, as you said, manipulating of large amounts of
> complex data - that is not a problem for me. *If* it is the only
> problem for CRPG, then I cans tart just now.
I assure you that it's not the only problem ;).
> design and a lot of development in a lot of different programming
> languages and tools, I learned how to handle such cases, optimize
> performance and memory load etc.
Oh, it's not that kind of problems.
> And simple CRPG creating would not help me much in this direction,
> because simple game means simpler data structures :-)
Believe me, it will help, even if you wont see the difference, at least you
will have a established understanding of how a roguelike engine should be
like. Your project is *HUGE*. You have a lot of time anyway, and a few weeks
for roguelike-instance-autopsy wont hurt you, and I promise it will help.\
Keep me up on progress!
...and read the note about BFG above ;) ...
regards,
Kornel Kisielewicz
Hansjoerg Malthaner
> Vlad Grynchyshyn wrote:
>>And simple CRPG creating would not help me much in this direction,
>>because simple game means simpler data structures :-)
>
> Believe me, it will help, even if you wont see the difference, at least you
> will have a established understanding of how a roguelike engine should be
> like.
At least make a prototype to get an idea what kind of problems wait for
you. Witht he expeirence from the prototype you'll get the actualy
project done much quicker and cleaner, becuase you can choose the right
structures right from the start.
> Your project is *HUGE*
IMO this is a quite a problem. The size means that a single developer
needs years to get it done. During such a long time, many things can
happen that influence the course of the project negatively.
Smaller projects reach playable state quicker, and therefore build a
community quicker. Communities help a lot to get through difficult
project phases.
> regards,
> Kornel Kisielewicz
c.u.
Hajo
Kornel Kisielewicz
> Kornel Kisielewicz schrieb:
>
>> Vlad Grynchyshyn wrote:
>
>>> And simple CRPG creating would not help me much in this direction,
>>> because simple game means simpler data structures :-)
>>
>> Believe me, it will help, even if you wont see the difference, at
>> least you will have a established understanding of how a roguelike
>> engine should be like.
>
> At least make a prototype to get an idea what kind of problems wait
> for you. Witht he expeirence from the prototype you'll get the actualy
> project done much quicker and cleaner, becuase you can choose the
> right structures right from the start.
That's exacly what I had in mind.
>> Your project is *HUGE*
>
> IMO this is a quite a problem. The size means that a single developer
> needs years to get it done. During such a long time, many things can
> happen that influence the course of the project negatively.
Unfortunately true.
> Smaller projects reach playable state quicker, and therefore build a
> community quicker. Communities help a lot to get through difficult
> project phases.
And true again ;)
regards,
Kornel Kisielewicz
Paul Pekkarinen
> their graphic counterparts!
Maybe, but what comes to graphics I didn't see the obvious reason
to use it: it has no limits. You can only represent certain amount
of things with ASCII. For example there are 166 terrain tiles in my RL
and I think it would be straightly impossible to show them with ASCII.
You can do also much cooler things with graphics like better
lighting and other effects like fog.
Vlad Grynchyshyn
news:40d21a0d$1...@news.broadpark.no...
> Kornel Kisielewicz wrote:
>
> > Vlad Grynchyshyn wrote:
> > There is no point in making 3D not real-time, IMO. Real-time, actually,
> > speeds up the game a lot and gives new possibilities to game-playing. It
> > adds playability a lot. Try Might & Magic versions 6 and higher - I like
it
> > really a lot. 3D without real-time does not worth effort to make it 3D
at
> > all, I think.
>
> Since you seem to agree with this, Kornel, I shall reply here rather
> than farther up the thread.
>
> I disagree with you both. A game can have turn based mechanics and still
> make good use of 3D models. I, for one, liked the concept of the Temple
> of Elemental Evil game, where this was partly used. True, there wasn't a
> complete lighting engine, as the maps were predrawn, but there were 3D
> models used. There was animation, but in combat the game was not realtime.
>
First of all, I talked about the 3D graphics or very nice graphics and not
3D models. 3D modeal - right, they add to game - it is always good to have
"brige" and something "under the bridge". But you can have it in the game
with bad and 2D graphics very easy.
What is "good" in the use of 3D graphics or very nice (time-consuming to
create) graphics for turn-based game? Just graphics? Different look and
feel? Can you explain more what you expect or get out of it in addition to
usual 2D games?
Let me explain a bit more my point of view:
I know that 3D *may* be better, but is it worth at all to spend really huge
amount of time to create 3D engine just for a few bits of improvements that,
IMO, have little difference for RL game? Is not it better to spend that time
for better game logic?
Following is a nature of RL game and why it have little difference: that
scary @ or D or T - you know they're you, dragon and troll. You can
_imagine_ how they look, how looks corridor made from "#" or "-" etc.
Game-playing "look and feel" in such case is up to your imagination. Now,
when you add (into the same game, but newer version) realistic 3D images and
graphics etc. and leave it the same turn-based and square-based - player may
be VERY quickly disappointed by this. Why? Just because player's imagination
rarely matches to what you represent in 3D graphics on the screen. It
quickly turns to the same - player does not look at graphics at all and is
not pleased by it at all. Player just use monster graphics as "icon" to
recognize monster and distinguish from another one. Killing 100 or more
jackals will cause you do not put much attention to how it looks - more to
what items they drop, strategy etc. Why then make it 3D at all?
The point in my words is that 3D RL games are just VERY DIFFERENT games from
ASCII or icon-based turn-based games because in first games class real-time
is used in such way that player does not care much about how monsters are
looking - it is all dynamic.
In second games class every step may have it's look and feel, but it is
usually left up to player's imagination. 3D that is turn-based makes no
sense, because if I look to graphics, I'm disappointed, If do not look - why
use 3D then?
A lot of my friends that see I'm playing ADOM or NetHack or H-World or any
other RL game say "why you're playing so bad-looking games?". My answer
always - try to play it and you'll see. After a while, they do not ask that
stupid question any more :-)
I know all above very well on example of Might&Magic games series. Versions
prior to 6 were exactly as you described - 3D turn-based. They were
no-so-poor 3D graphics (DOS games), no layers/floors, no bridge/underbridge
etc, but 3D. Playing it, I did not care much that it is 3D or not. More, it
added some complexities to game-playing, such as very often use of map, got
stuck because disoriented and dived into wrong labyrinth branch etc. Much
like Wolfenstein game but turn-based.
Version 6 and higher added a lot to it by adding real-time. It was a
completely new look and feel. You just have no time to think about "look"
and "feel" if you see next multi-eyed wyrm, even if it differs from what you
imagined before - you just fight.
There is also turn-based mode in Might&magic 6 and higher that you can
switch on. I hate to do it and switch it on only in that rare case when
fighting in real-time may be too dangerous. I hate it because I have time to
look more accurately to the monster's face (or whatever monster have) and
say "hey, I though it should look different!"
3D and good graphics is nice, but it is nice when used on purpose.
Hansjoerg Malthaner
> What is "good" in the use of 3D graphics or very nice (time-consuming to
> create) graphics for turn-based game? Just graphics? Different look and
> feel? Can you explain more what you expect or get out of it in addition to
> usual 2D games?
I favour 2D graphics (and isometric view is still 2D) becuase usually
they provide more style than the 3D models.
There are some exceptions, like Doom III but in average, 2D graphics in
games have more style and detail than 3D graphics.
Good graphics can add a lot to the atmosphere and mood of a game. They
can carry additional information, i.e. show equipment and relative sizes.
> I know that 3D *may* be better, but is it worth at all to spend really huge
> amount of time to create 3D engine just for a few bits of improvements that,
> IMO, have little difference for RL game?
It might be worth the effort, if you make use of all 3 dimensions.
Roguelike world is usually flat enough that a 2D engine can be sued to
display it. Even bridges can be done in 2D to some extend.
> Is not it better to spend that time
> for better game logic?
Yes. That's i.e. why I made my decision against animations. I rather
spend the time on the game engine.
> Following is a nature of RL game and why it have little difference: that
> scary @ or D or T - you know they're you, dragon and troll. You can
> _imagine_ how they look, how looks corridor made from "#" or "-" etc.
> Game-playing "look and feel" in such case is up to your imagination. Now,
> when you add (into the same game, but newer version) realistic 3D images and
> graphics etc. and leave it the same turn-based and square-based - player may
> be VERY quickly disappointed by this. Why? Just because player's imagination
> rarely matches to what you represent in 3D graphics on the screen.
Opinions on this point vary strongly. E.g. I like good graphics. If they
are presented right from the start - and they are in games - then
imagination will use them, because no other reference exists (yet).
I've played and play Diablo, Diablo II, Diablo II/LOD since they came
out, and I never had a problem with the graphics - I rather admired the
nice look of the things.
<flamewar starter>
We've got enough ASCII Roguelike projects. One more isn't needed at all.
Let's break the barrier and do a Diablolike!
</flamewar starter>
> It
> quickly turns to the same - player does not look at graphics at all and is
> not pleased by it at all.
I can't follow you here. I play DII for years, and I still like the
graphics.
> Player just use monster graphics as "icon" to
> recognize monster and distinguish from another one. Killing 100 or more
> jackals will cause you do not put much attention to how it looks - more to
> what items they drop, strategy etc. Why then make it 3D at all?
I'd advice to make it 2D. Textures polygons are unsuitabel to display a
lot of details IMO. 2D sprites/tiles/bitmaps allow more freedom to the
artists. Although sometimes - if you need a lot of different views for
each item - 3D models might be more economic in creation.
> A lot of my friends that see I'm playing ADOM or NetHack or H-World or any
> other RL game say "why you're playing so bad-looking games?".
Hey! H-World isn't bad looking! At least it improves all the time,
low-quality graphics are used as placeholders until better images are
available, but the number of high quality images continuously rises,
particularly since Sheep (thanks a lot!) joined the team :)
> My answer
> always - try to play it and you'll see. After a while, they do not ask that
> stupid question any more :-)
I once made a graphical frontend for Angband becuase I didn't like the
ASCII display ... that time such thing was not available for my
preferred platform.
Not all people are ASCII lovers exactly.
> 3D and good graphics is nice, but it is nice when used on purpose.
Sure. List your requirements, look at the choices, and see what fits
best to your needs.
c.u.
Hajo
Kornel Kisielewicz
> <flamewar starter>
> We've got enough ASCII Roguelike projects. One more isn't needed at
> all. Let's break the barrier and do a Diablolike!
> </flamewar starter>
Wooaahhh!! You're asking for a beating ;).
No, I won't get provoked, I won't get provoked, I won't get provoked, I
won't get prov...
Vlad Grynchyshyn
> Vlad Grynchyshyn schrieb:
> <flamewar starter>
> We've got enough ASCII Roguelike projects. One more isn't needed at all.
> Let's break the barrier and do a Diablolike!
> </flamewar starter>
You already doing it well :-)
The reason of ASCII - if you have 100+ different monsters, it is hard to
make graphics for all of them, specially if everything is done by a single
developer.
> > It
> > quickly turns to the same - player does not look at graphics at all and
is
> > not pleased by it at all.
>
> I can't follow you here. I play DII for years, and I still like the
> graphics.
I like it too. Do you know how much it costs to make it so good? The point
is how much you get from it compare to what it costs.
> > Player just use monster graphics as "icon" to
> > recognize monster and distinguish from another one. Killing 100 or more
> > jackals will cause you do not put much attention to how it looks - more
to
> > what items they drop, strategy etc. Why then make it 3D at all?
>
> I'd advice to make it 2D. Textures polygons are unsuitabel to display a
> lot of details IMO. 2D sprites/tiles/bitmaps allow more freedom to the
> artists. Although sometimes - if you need a lot of different views for
> each item - 3D models might be more economic in creation.
It depends. Smooth 3D rotation of objet to preview it requires a lot of
complex math ans alike stuff. Not smooth rotation (6-10 posiotions made of
images) is not very ecomnomic compare to 2D - you probably would not have so
much variants of images for the same item (different sizes, equipped by
character etc.)
> > A lot of my friends that see I'm playing ADOM or NetHack or H-World or
any
> > other RL game say "why you're playing so bad-looking games?".
>
> Hey! H-World isn't bad looking! At least it improves all the time,
> low-quality graphics are used as placeholders until better images are
> available, but the number of high quality images continuously rises,
> particularly since Sheep (thanks a lot!) joined the team :)
I know. Sorry, but for players that play Diablo II, HMM III and Quacke III
most of the time it is still a big difference. I'm saying what I heard just
yesterday. For *me* it looks much better than ok :-)
> > 3D and good graphics is nice, but it is nice when used on purpose.
>
> Sure. List your requirements, look at the choices, and see what fits
> best to your needs.
There is such thing as a cost compare to what you get from it.
Vlad Grynchyshyn
........
*my amulet of life saving turns to dust*
(Damn, why I did not wear ring of fire resistance???)
*firing back coins that make strong illumination around because BFG and
using stealth abilities*
Hansjoerg Malthaner
> "Hansjoerg Malthaner" <hansjoerg...@nurfuerspam.de> wrote in message
> news:2jfudtF...@uni-berlin.de...
>
>>Vlad Grynchyshyn schrieb:
>><flamewar starter>
>>We've got enough ASCII Roguelike projects. One more isn't needed at all.
>>Let's break the barrier and do a Diablolike!
>></flamewar starter>
>
> You already doing it well :-)
H-World isn't realtime and has no animations. OTOH I would do a more
Diablolike project if I could (in regard of skills + time).
> The reason of ASCII - if you have 100+ different monsters, it is hard to
> make graphics for all of them, specially if everything is done by a single
> developer.
Yes. But there have been games that were successful with (much) less
monsters. So maybe it can be worked around? 100 monster tiles seem
doable. There is a NetHack tile set, called the "Absurd tile set". It
has a lot of high quality tiles; IIRC the native size of the tiles is
128x128 pixels. It has more than 100 tiles IIRC.
Maybe this is a sign that it's stiull doable for tradional
high-monster-type-count roguelikes?
>>I play DII for years, and I still like the
>>graphics.
>
> I like it too. Do you know how much it costs to make it so good?
Not exactly. I've heard figures of up to 1.000.000 dollars being spent.
I somewhat believe this figure, because Diablo I sold 2.000.000 copies,
they had a lot of money to spend on the new development.
> The point
> is how much you get from it compare to what it costs.
This is a commercial product, so sales are the number one driving
factor. The profit must be greater than the expenses; the sizte of the
project only mater sfor small companies that can't get thge funds.
>>>A lot of my friends that see I'm playing ADOM or NetHack or H-World or
>>>any
>>>other RL game say "why you're playing so bad-looking games?".
>>
>>Hey! H-World isn't bad looking! At least it improves all the time,
>>low-quality graphics are used as placeholders until better images are
>>available, but the number of high quality images continuously rises,
>>particularly since Sheep (thanks a lot!) joined the team :)
>
> I know. Sorry, but for players that play Diablo II, HMM III and Quacke III
> most of the time it is still a big difference.
I agree. Yet I have hope to get close, except for the missing animations.
> I'm saying what I heard just yesterday.
I'll probably hear that often. At some point the voices will get fewer
and some day, they'll say it looks good for a hobby project.
> For *me* it looks much better than ok :-)
:)
>>>3D and good graphics is nice, but it is nice when used on purpose.
>>
>>Sure. List your requirements, look at the choices, and see what fits
>>best to your needs.
>
> There is such thing as a cost compare to what you get from it.
Low cost/cost efficency/quick result can be requirements, too. If you
forgot it on your list, quickly add it and evaluate again :)
I like this one: "get the most bang for the least bucks"
c.u.
Hajo
Kornel Kisielewicz
Maybe try IDDQD ;)
regards,
Kornel Kisielewicz
Kornel Kisielewicz
Just wait for my SDL/ASCII roguelike demo ;)
regards,
Kornel Kisielewicz
Kornel Kisielewicz
> "Hansjoerg Malthaner" <hansjoerg...@nurfuerspam.de> wrote in
> message news:2jfudtF...@uni-berlin.de...
>> Vlad Grynchyshyn schrieb:
>> <flamewar starter>
>> We've got enough ASCII Roguelike projects. One more isn't needed at
>> all. Let's break the barrier and do a Diablolike!
>> </flamewar starter>
>
> You already doing it well :-)
> The reason of ASCII - if you have 100+ different monsters, it is hard
> to make graphics for all of them, specially if everything is done by
> a single developer.
Very true. I for instance use ASCII for the same reason why a book is more
immersive then a movie. And it can be scarier (at least on the deep level,
not the "Oh my god that's horrible!" level ) ;)
>> I can't follow you here. I play DII for years, and I still like the
>> graphics.
>
> I like it too. Do you know how much it costs to make it so good? The
> point is how much you get from it compare to what it costs.
Again for instance -> a Ford Escort 95 3D model created (by a
med-experienced 3d artist) in a week was sold for 1500$. 100 monsters *
1500$ = 150000$ already for the models :)
>> I'd advice to make it 2D. Textures polygons are unsuitabel to
>> display a lot of details IMO. 2D sprites/tiles/bitmaps allow more
>> freedom to the artists. Although sometimes - if you need a lot of
>> different views for each item - 3D models might be more economic in
>> creation.
>
> It depends. Smooth 3D rotation of objet to preview it requires a lot
> of complex math ans alike stuff.
Nah. It's not so complex when you finaly understand it :). "Math is not as
scary as you imagine..."
>> Hey! H-World isn't bad looking! At least it improves all the time,
>> low-quality graphics are used as placeholders until better images are
>> available, but the number of high quality images continuously rises,
>> particularly since Sheep (thanks a lot!) joined the team :)
>
> I know. Sorry, but for players that play Diablo II, HMM III and
> Quacke III
It's spelled Quake with a "k", not "ck". (I'm just pointing this out not
because i'm criticizing, but in the memory of a helpfull soul that showed me
that it's not rougelikes we're writing but roguelikes :). And throughout my
first year of roguelike posting nobody corrected me!).
>>> 3D and good graphics is nice, but it is nice when used on purpose.
>>
>> Sure. List your requirements, look at the choices, and see what fits
>> best to your needs.
>
> There is such thing as a cost compare to what you get from it.
Profit? :)
regards,
Kornel Kisielewicz
Kornel Kisielewicz
> Vlad Grynchyshyn schrieb:
>
>> "Hansjoerg Malthaner" <hansjoerg...@nurfuerspam.de> wrote in
>> message news:2jfudtF...@uni-berlin.de...
>>
>>> Vlad Grynchyshyn schrieb:
>>> <flamewar starter>
>>> We've got enough ASCII Roguelike projects. One more isn't needed at
>>> all. Let's break the barrier and do a Diablolike!
>>> </flamewar starter>
>>
>> You already doing it well :-)
>
> H-World isn't realtime and has no animations. OTOH I would do a more
> Diablolike project if I could (in regard of skills + time).
That would require 3D models. Not for the game itself, but for rendering
stills (like it was done in Diablo).
>>> I play DII for years, and I still like the
>>> graphics.
>>
>> I like it too. Do you know how much it costs to make it so good?
>
> Not exactly. I've heard figures of up to 1.000.000 dollars being
> spent.
>
> I somewhat believe this figure, because Diablo I sold 2.000.000
> copies, they had a lot of money to spend on the new development.
I wait for the first game to break the movie budget. And yes, I believe that
will someday happen.
>>>> A lot of my friends that see I'm playing ADOM or NetHack or
>>>> H-World or any
>>>> other RL game say "why you're playing so bad-looking games?".
>>>
>>> Hey! H-World isn't bad looking! At least it improves all the time,
>>> low-quality graphics are used as placeholders until better images
>>> are available, but the number of high quality images continuously
>>> rises, particularly since Sheep (thanks a lot!) joined the team :)
>>
>> I know. Sorry, but for players that play Diablo II, HMM III and
>> Quacke III most of the time it is still a big difference.
>
> I agree. Yet I have hope to get close, except for the missing
> animations.
Without animations you will be always a class behind :(.
>> I'm saying what I heard just yesterday.
>
> I'll probably hear that often. At some point the voices will get fewer
> and some day, they'll say it looks good for a hobby project.
For that it looks realy good already!
regards,
Kornel Kisielewicz
Vlad Grynchyshyn
> Vlad Grynchyshyn wrote:
> > "Hansjoerg Malthaner" <hansjoerg...@nurfuerspam.de> wrote in
> > message news:2jfudtF...@uni-berlin.de...
> >> Vlad Grynchyshyn schrieb:
> >> <flamewar starter>
> >> We've got enough ASCII Roguelike projects. One more isn't needed at
> >> all. Let's break the barrier and do a Diablolike!
> >> </flamewar starter>
> >
> > You already doing it well :-)
> > The reason of ASCII - if you have 100+ different monsters, it is hard
> > to make graphics for all of them, specially if everything is done by
> > a single developer.
>
> Very true. I for instance use ASCII for the same reason why a book is more
> immersive then a movie. And it can be scarier (at least on the deep level,
> not the "Oh my god that's horrible!" level ) ;)
Sure. You casn make scary graphics and it is interpreted differently by
different people. One would dislike it, another would be glad to have it
because it adds to look&feel, one more will get several psychic damage.
ASCII character gives you possibility to use your own imagination, that
always match to *your* point of view what is "scary" and how it may look
like :-)
> >> I'd advice to make it 2D. Textures polygons are unsuitabel to
> >> display a lot of details IMO. 2D sprites/tiles/bitmaps allow more
> >> freedom to the artists. Although sometimes - if you need a lot of
> >> different views for each item - 3D models might be more economic in
> >> creation.
> >
> > It depends. Smooth 3D rotation of objet to preview it requires a lot
> > of complex math ans alike stuff.
>
> Nah. It's not so complex when you finaly understand it :). "Math is not as
> scary as you imagine..."
I know, but you should either have ap rofessional in it, or forget about
everything else and learn it by self. But then no RL development, just
graphics creating...
> >> Hey! H-World isn't bad looking! At least it improves all the time,
> >> low-quality graphics are used as placeholders until better images are
> >> available, but the number of high quality images continuously rises,
> >> particularly since Sheep (thanks a lot!) joined the team :)
> >
> > I know. Sorry, but for players that play Diablo II, HMM III and
> > Quacke III
>
> It's spelled Quake with a "k", not "ck". (I'm just pointing this out not
> because i'm criticizing, but in the memory of a helpfull soul that showed
me
> that it's not rougelikes we're writing but roguelikes :). And throughout
my
> first year of roguelike posting nobody corrected me!).
>
Sorry, typo. Get used too much to "ck" :(
> >>> 3D and good graphics is nice, but it is nice when used on purpose.
> >>
> >> Sure. List your requirements, look at the choices, and see what fits
> >> best to your needs.
> >
> > There is such thing as a cost compare to what you get from it.
>
> Profit? :)
Well, it requires already a lot for a team of developers to make RL
profitable. What say about single developer?
Hansjoerg Malthaner
> Hansjoerg Malthaner wrote:
>
>>Vlad Grynchyshyn schrieb:
>>H-World isn't realtime and has no animations. OTOH I would do a more
>>Diablolike project if I could (in regard of skills + time).
>
> That would require 3D models. Not for the game itself, but for rendering
> stills (like it was done in Diablo).
I've hacked together a skeletal animaton tool that outputs PovRay scene
files. It's still very crude, but starts to work. OTOH it hs some
serious problems.
ATM it's mostly useful to test poses (got a puppet-like body model), but
I hope some day I can use it to render animations, too.
OTOH such tools are alrady available, but the good ones are very expensive.
>>>>I play DII for years, and I still like the
>>>>graphics.
>>>
>>>I like it too. Do you know how much it costs to make it so good?
>>
>>Not exactly. I've heard figures of up to 1.000.000 dollars being
>>spent.
>>
>>I somewhat believe this figure, because Diablo I sold 2.000.000
>>copies, they had a lot of money to spend on the new development.
>
> I wait for the first game to break the movie budget. And yes, I believe that
> will someday happen.
This should happen soon. Game sales were bigger than movie sales in 2003 :)
>>>>>A lot of my friends that see I'm playing ADOM or NetHack or
>>>>>H-World or any
>>>>>other RL game say "why you're playing so bad-looking games?".
>>>>
>>>>Hey! H-World isn't bad looking! At least it improves all the time,
>>>>low-quality graphics are used as placeholders until better images
>>>>are available, but the number of high quality images continuously
>>>>rises, particularly since Sheep (thanks a lot!) joined the team :)
>>>
>>>I know. Sorry, but for players that play Diablo II, HMM III and
>>>Quacke III most of the time it is still a big difference.
>>
>>I agree. Yet I have hope to get close, except for the missing
>>animations.
>
> Without animations you will be always a class behind :(.
Somewhere the missing 1.000.000$ show their effect ... but I'm not
really worried. Diablo II has some weaknesses. I hope I can trade
animation for other improvements, and some of the players will accept
that trade.
I don't want to compete with commercial products, although I sometimes
like to see how close one can get. H-World plays in another league, and
it's important that it performs well there -> TkAngband,
Nethack/NoeGnued, Crawl/Tiles are the competitors IMO. All of them still
far ahead of H-World/The Jungle :(
>>>I'm saying what I heard just yesterday.
>>
>>I'll probably hear that often. At some point the voices will get fewer
>>and some day, they'll say it looks good for a hobby project.
>
> For that it looks realy good already!
Thanks :)
I also want to hand over the thanks to Sheep who helped a lot in regard
to images lately!
Vlad Grynchyshyn
Nah, cheating would not get me close to victory.
Kornel Kisielewicz
> Kornel Kisielewicz schrieb:
>
>> Hansjoerg Malthaner wrote:
>>
>>> Vlad Grynchyshyn schrieb:
>
>>> H-World isn't realtime and has no animations. OTOH I would do a more
>>> Diablolike project if I could (in regard of skills + time).
>>
>> That would require 3D models. Not for the game itself, but for
>> rendering stills (like it was done in Diablo).
>
> I've hacked together a skeletal animaton tool that outputs PovRay
> scene files. It's still very crude, but starts to work. OTOH it hs
> some serious problems.
>
> ATM it's mostly useful to test poses (got a puppet-like body model),
:)
> OTOH such tools are alrady available, but the good ones are very
> expensive.
Hell true. I have the luck, that our University has a educational copy of
Maya (don't ask me about MAX) -- i saw the Univ. order form for Maya:
Cost : 65540$ (!!!)
Reduction: -65540$ ;)
There was a funny problem though, when suddenly our staff panicked, for it
came out that somebody has to pay the tax for shipping it to Poland (22%!).
Luckily the supplier proved to be a nice guy ;).
>>> I agree. Yet I have hope to get close, except for the missing
>>> animations.
>>
>> Without animations you will be always a class behind :(.
>
> Somewhere the missing 1.000.000$ show their effect ...
Suprising, isn't it? ;)
> but I'm not
> really worried. Diablo II has some weaknesses. I hope I can trade
> animation for other improvements, and some of the players will accept
> that trade.
And maybe someday you'll find a few geeks to do the models for you ;). Or
maybe a commercial "animated" version? This could prove reasonable!
> I don't want to compete with commercial products, although I sometimes
> like to see how close one can get. H-World plays in another league,
> and it's important that it performs well there -> TkAngband,
> Nethack/NoeGnued, Crawl/Tiles are the competitors IMO. All of them
> still far ahead of H-World/The Jungle :(
Not on the field of graphics quality though :)
>> For that it looks realy good already!
>
> Thanks :)
>
> I also want to hand over the thanks to Sheep who helped a lot in
> regard to images lately!
I know ;).
regards,
Kornel Kisielewicz
Kornel Kisielewicz
> "Kornel Kisielewicz" <charon...@magma-net.pl> wrote in message
> news:caun6d$fmq$2...@inews.gazeta.pl...
>> not as scary as you imagine..."
>
> I know, but you should either have ap rofessional in it, or forget
> about everything else and learn it by self. But then no RL
> development, just graphics creating...
Hey, I'm aiming to be a computer graphics creator ;). Kinda funny considered
I'm on the ASCII side of the roguelike battlefront ;).
>> It's spelled Quake with a "k", not "ck". (I'm just pointing this out
>> not because i'm criticizing, but in the memory of a helpfull soul
>> that showed me that it's not rougelikes we're writing but roguelikes
>> :). And throughout my first year of roguelike posting nobody
>> corrected me!).
>>
>
> Sorry, typo. Get used too much to "ck" :(
Np ;).
regards,
Kornel Kisielewicz
SZDev - Slash
"Vlad Grynchyshyn" <vg...@yahoo.com> escribió en el mensaje
news:2jfmljF...@uni-berlin.de...
They are very very right, you must know that you are not the first person
with this idea, through all the time here we have seen lots of people start
high with this just to stall.
Roguelike development doesn't seems as complicated as it really is until you
wield your arms and go to the war of implementation, only then you know what
problem you got into ;)
> But if the problem, as you said, manipulating of large amounts of complex
> data - that is not a problem for me. *If* it is the only problem for CRPG,
> then I cans tart just now. Working on software design and a lot of
> development in a lot of different programming languages and tools, I
learned
> how to handle such cases, optimize performance and memory load etc.
>
The problem is not the language, the tools or the memory; some of the
problems are the interaction between all the data, the persistence you need
to achieve and the most proper way to show the huge ammount of things to the
player.
I sincerely recommend you to make a game, don't take genericity or
scalability in mind, just make the game and make it work. You will be
surprised when 4 months have passed and it is not very playable yet ;)
> And simple CRPG creating would not help me much in this direction, because
> simple game means simpler data structures :-)
>
>
> > >> Well in that case... *sigh*
> > >> *pulls out the BFG-9000*
> > >>
> > >> ;)
> > >
> > > Well, that would not work! *shielding by tower eternium shield*
> >
> > [ever saw a BFG in Doom? A shield is useless ;)]
>
> Saw. Eternium shield is like a wall. Do you able to blow out wall by BFG?
> ;-] The most you can is blow out shield. Then I'll use another one. And
BFG
> uses a lot of ammo, so you quickly will run out of it. Better use it to
blow
> out large amounts of monstrous beings :-)
>
>
--
---------------------------------------
Santiago Zapata
L:Java E++ T- R+ !P D+ G++ F:ADoM RL* RLA-
W:G Q++ AI+ GFX- SFX- RN++++ PO--- Hp- Re+ S+ c-- ?OS *KG
---------------------------------------