ShiVa3D
multiple scenes but same characters different scenery
All That Remainsmultiple scenes but same characters different scenery
by shivachristy » 03 Aug 2012, 18:34
I am about to duplicate a scene remove static content add new static content.
This seems like a really bad idea for iterations of future development.
I haven't spawned characters is that my problem?
What is the most efficient way to do this?
Any comments gratefully received
English grammar rule I before e except after c English spelling is mental!
This seems like a really bad idea for iterations of future development.
I haven't spawned characters is that my problem?
What is the most efficient way to do this?
Any comments gratefully received
English grammar rule I before e except after c English spelling is mental!
-

shivachristy - Platinum Boarder

- Posts: 937
- Location: UK
Re: multiple scenes but same characters different scenery
by broozar » 04 Aug 2012, 12:03
it's a matter of taste, really... and a question of style. of course, runtimeCreating all enemies etc. strikes me as more techy
but really, it should not matter.
Re: multiple scenes but same characters different scenery
by Fraser » 04 Aug 2012, 17:01
Hi,
As Broozar says, there is no right/wrong way.
I think for solo indie developers, trying to make large games spanning multiple levels then it's beneficial to create as much at runtime as possible. Also makes it easier for development iterations (as you alluded to).
I realise that if you are very familiar with the scene editor then it may be a pain to transition to runtime generation (old dog new tricks).
If we take an example of a marble maze in box game, then we could design one box with maze in it using the editor, duplicate it, remove walls, add new walls and we have a new scene for the new maze.
But what if in the future we want to put a badge on the box bezel or tweak the wall thicknesses for bigger/smaller marble etc, we'd have to hand edit every maze scene we've created.
Better to just create one "template" scene of empty box with skbox, fancy badge, etc.
Then write functions to populate the box with a maze at runtime.
Make one cube in the editor with the wood material of choice and then use code to create and position:
It seems like alot of coding would be needed, but if you wrote a CreateWall(nX1, nZ1, nX2, nZ2) function then a new maze could be created with a handful of calls to it.
Another way is to create new mazes in a text editor and store them as XML, then a maze can be made/adjusted very fast by just typing:
Then you just analyse the string from the XML and create cubes wherever you see '#'
This is my method for the current game I'm working on, to take it a step further then instead of cubes one should use finely crafted level modules that still tile together but have more organic geometry.
As Broozar says, there is no right/wrong way.
I think for solo indie developers, trying to make large games spanning multiple levels then it's beneficial to create as much at runtime as possible. Also makes it easier for development iterations (as you alluded to).
I realise that if you are very familiar with the scene editor then it may be a pain to transition to runtime generation (old dog new tricks).
If we take an example of a marble maze in box game, then we could design one box with maze in it using the editor, duplicate it, remove walls, add new walls and we have a new scene for the new maze.
But what if in the future we want to put a badge on the box bezel or tweak the wall thicknesses for bigger/smaller marble etc, we'd have to hand edit every maze scene we've created.
Better to just create one "template" scene of empty box with skbox, fancy badge, etc.
Then write functions to populate the box with a maze at runtime.
Make one cube in the editor with the wood material of choice and then use code to create and position:
- Code: Select all
scene.createRuntimeObject ( )
object.setScale ( )
object.setTranslation ( )
It seems like alot of coding would be needed, but if you wrote a CreateWall(nX1, nZ1, nX2, nZ2) function then a new maze could be created with a handful of calls to it.
Another way is to create new mazes in a text editor and store them as XML, then a maze can be made/adjusted very fast by just typing:
- Code: Select all
<MAZE1>
##########
#........#
#.######.#
#....#.#.#
####.#.#.#
#....#...#
#.########
#........#
########.#
#........#
##########
</MAZE1>
Then you just analyse the string from the XML and create cubes wherever you see '#'
This is my method for the current game I'm working on, to take it a step further then instead of cubes one should use finely crafted level modules that still tile together but have more organic geometry.
Fraser,
http://www.silicondroid.com
http://www.silicondroid.com
3 posts
• Page 1 of 1