Advertisement

Repetition and world limits

Started by February 07, 2002 07:35 PM
6 comments, last by Wavinator 22 years, 10 months ago
This is an offshoot of a post I made in sara_qq''s thread on world limits... Over the last few months I''ve been testing my skills as a possible indie developer by modelling tons of ships and space stations for a space game. It''s made me clear on an important fact: art and assets probably limit your designs more so than any other factor (coding being second, I think). Which do you think is more appealing in the long run for an open-ended game: a smaller world with more unique, individual assets (ships / bases); or encountering an asset multiple times, but having the asset varied by stats? For example, I''ve modelled 20 bases so far. I''m planning for up to 5-10 bases per system, and at least 50 systems. That potentially means encountering the same graphic as many as 25 times in different places. Each place would be varied by stats and other factors, such as allegiance, services offered, etc. Ditto for NPC ships. The best I can probably do is vary the look a bit here and there, but likely nothing major. Given this limit, is less actually more? How much repetition do you think you can get away with? -------------------- Just waiting for the mothership...
--------------------Just waiting for the mothership...
I think the ideal to pursue is no repetition, unless it is intended, i.e. the same company designed and engineered the PX-2500 series of space stations you see throughout the Orion Sector.

Now, given that, the game universe has to be limited in extent by virtue of limiting repetition. So, either make a small universe (undesirable) or model like crazy (undesirable because of time and expense and lower quality per model) or procedurally generate objects.

Procedurally generating objects could possibly have the most payoff, but you need a quality generator which has enough knowledge and creativity to create plausible and unique material, otherwise it will suffer from the sameness factor also.

Wavinator, I know what you are trying to produce from numerous prior exposure to your ideas, and I would consider devoting some time and research to procedural generation.

___________________________________

_______________________________
"To understand the horse you'll find that you're going to be working on yourself. The horse will give you the answers and he will question you to see if you are sure or not."
- Ray Hunt, in Think Harmony With Horses
ALU - SHRDLU - WORDNET - CYC - SWALE - AM - CD - J.M. - K.S. | CAA - BCHA - AQHA - APHA - R.H. - T.D. | 395 - SPS - GORDIE - SCMA - R.M. - G.R. - V.C. - C.F.
Advertisement
quote: Original post by bishop_pass

Wavinator, I know what you are trying to produce from numerous prior exposure to your ideas, and I would consider devoting some time and research to procedural generation.


Thx for the input, bishop. You''re right, procedural generation is by far the most superior approach. I''ve toyed with it a bit (it''s going to be a feature of the Destiny3D engine which I''d like to use, btw).

Without turning this into an art discussion, I will say that I''m experimenting with a crude "procedural" asset generation idea that involves a "lego blocks" type concept. I''m not sure of the limits, yet, so I haven''t raised it as a viable option.

The main issues I have with pure procedural generation of geometry are twofold:

1) Ensuring that the assets look good, and QA''ing the process (so that you don''t end up with hidden mistakes like a procedurally generated cannon that incorrectly intersects a procedurally generated hull, for example)

2) Texturing, the ABSOLUTE BANE OF MY EXISTENCE! (argh! That sound you hear is the sound of ultimate suffering! ). I''m just not yet certain how procedural generation handles texturing, but unless you''re generating the textures or tiling them, you''re going to run into another asset limit (um, I think)




--------------------
Just waiting for the mothership...
--------------------Just waiting for the mothership...
quote: Original post by Wavinator
2) Texturing, the ABSOLUTE BANE OF MY EXISTENCE! (argh! That sound you hear is the sound of ultimate suffering! ). I''m just not yet certain how procedural generation handles texturing, but unless you''re generating the textures or tiling them, you''re going to run into another asset limit (um, I think)


Well, I would say that procedural texture generation is part of the process. It reminds me of a project I have been engaged in which focuses on exactly that: procedural generation of panels, doors, walls, rivets, fasteners, arches, turrets, etc.

If you read this right after I post, why don''t you hop on AIM, like right now.



___________________________________

_______________________________
"To understand the horse you'll find that you're going to be working on yourself. The horse will give you the answers and he will question you to see if you are sure or not."
- Ray Hunt, in Think Harmony With Horses
ALU - SHRDLU - WORDNET - CYC - SWALE - AM - CD - J.M. - K.S. | CAA - BCHA - AQHA - APHA - R.H. - T.D. | 395 - SPS - GORDIE - SCMA - R.M. - G.R. - V.C. - C.F.
How about a hybrid approach?

Manually create some unique base models, with some open sections
that could be used as sockets for the lego block approach. Some
blocks could be associated with particular base models, with a
category of blocks that could either be shared over various base
models or could be generic across the board.

Ditto with the textures, create a number of base textures, and
either procedurally generate some modifiers (weathering, "racing
stripes", etc) or allow for other modifiers (decals for a
particular allegiance, etc).

Toss in a couple of unique one time only models for a little bit
of variety.

I would think that this would be an ok compromise, and model the
way things in the world are anyways. If you travel coast to coast in
America, you''ll see a thousand Dodge (whatever model) pickup trucks,
but they will vary in color, condition, and some optional
components (tool box, etc). There might be some exceptional
vehicles out there (a standard car, with the back end chopped
off and a flatbed installed in its place, for example, or some
sort of hotrod).

They''re coming for you!
I don''t see anything wrong with a little repetition. I think pwd has a nice idea for that.

I had no complaints about seeing the same old planet/mining facility/ship in Privateer. It just looked like what I expected so I let it slide.

There is something to be said for a smaller, more detailed world, but I think it''d only work for an open-ended game if you detailed the hell out of it.

I wanna'' ride on the pope mobile.
Advertisement
With the varied stats route, it would then be important to make viewing the stats simple and fast. Nothing would be more annoying than to click on every ship/planet just to get the gist of a situation.

Repetition is perfectly fine. One function of varied graphics is to allow distinction between different assets. However, even a palette switch is usually good enough for that purpose.

A possible solution would be to attach mini stat windows to each asset, color coded to make each unique. This way, graphics wouldn''t matter too much, since the important info is already presented, and there is no need to check a database/manual for stats(if graphics were used).
i think repetition is fine but it depends on what you are repeating.

making key areas or buildings different and surrounding them by repeated trees is fine.

This topic is closed to new replies.

Advertisement