Hey all, myself (the coder) and the modeler are having a bit of a disagreement about modelling and game play. Our current WIP is a cartoony First Person slasher.
We are aiming to get the same sort of cartoon as shown in this video : http://www.youtube.com/watch?v=ajz5Poh_giI
(I know it resembles nothing of the game runescape, thus why we are making the game they claim to have, which is in essence false advertising)
We are arguing about whether to have open interiors, meaning you can enter buildings without the wait of a loading screen.
My Points
Imagine loading screens every time you go into a building or cave or anything on a multiplayer potential PvP game, the other player could just hide while you are loading.
Open interiors in games give alot more playability and less gameplay interruption.
Occlusion culling could greatly help us cut back anyway (When we get pro)
His points
Too high maintenance for most computers to handle
The quality of both the external and internal models will drop greatly
3 texture maps for each building
Anybody have any suggestions?
Our current pitches have not work very well.
Big areas such as cities and caves require loading/unloading however there will be open interiors
Completely open interiors
Closed interiors, wait to enter buildings
Map broken up into square sections, loaded when needed
Guildwars 2 uses closed interiors. Its quite annoying, but you get over it. Even using the teleports across the same city would make you go through a load, which I thought was quite bad.
I would say it probably depends on your target platform… im sure with occlusion culling it would be fine using open.
As a gamer and as the lead dev, I completely agree.
Skyrim annoyed me with it’s extensive loading times, but I was understanding of the fact that such high quality comes with major downsides.
Seeing as our game is not high definition, realistic textures, I see no point in limiting gameplay…
In every game, when you suddenly transport across a large distance, there’s a load time. That’s because, normally, the game preloads nearby areas as you move. So, by the time you get there, the area is already loaded. If you’re jumping a mile away, that information isn’t loaded yet. It couldn’t be (unless you’re running a few TB of RAM).
As to the question, obviously a seamless, open world is preferable, but a closed or instanced one is better for performance (and frees up memory for higher quality art). You have to decide what is most important for your game and make the choice based on that.
Open interiors +
dynamic loading based on distance to camera +
visual culling
Or even a smarter algorithm : dynamic loading upon culling info and distance (= test the culling data from several raycasts starting inside a certain radius around your cam, ending at the center of the given room, and load the objects that are returned as visible).
One possible idea is the ‘arena’ concept with PvP restricted to Arenas but I don’t know if this fits into your overall PvP planning.
In my experience whenever I found PvP in a game sucked it usually had to do with character class imbalance. They either made the archer too strong or the mage’s AoE bite such huge chunks that it gave no one else a chance or something like that and thus made the less dominant classes unplayable.
Rarely have I ever disliked PvP based on whether it was continuous or restricted or anything like that.
Old school Resident Evil. Show a very slowly opening door. Added a nice creepy factor, and most people didn’t even realize that it was a loading screen.
Open - you don’t need pro to do simple occlusion culling: have all your internal objects for each room parented to a control object that is deactivated on load, and activated when the player activates the door - I’ve been doing something similar to this, and it’s really easy and fast (enabling/disabling mesh renderers rather than activating/deactivating objects). Make the windows for the buildings reflective/dark on the outside, so that you cannot see in, but have a transparent shader on the insides so you can see out. Potentially, in a room without windows/ if the windows aren’t see through, you can have the door closing deactivate all the external objects, after the player is inside. It makes for a bit more set-up, but allows open-ness for a very small cost.
I don’t think it should be very long or fastidious to implement, as culling data would just be a big world matrix data object to create (Umbra data is not accessable at runtime it seems), in which you’d pack objects based on their transform. It can be automated easily I guess.
Then you perform a series of raycasts around your cam, starting from several points on that circle, ending at the center of the target room.
Each raycast would then iterate through the different matrix “cubes” that are placed between the origin and the goal. Each activated cube would tell its contained objects to dynamically load themselves.
To know which rooms should be tested, you can just put a box collider inside each of them, a big sphere collider on the cam, and create a list from the triggered ones.
For the unloading if camera is too far, you can simply create a coroutine on each dynamically loaded object that will check its distance with cam every couple of seconds (to save runtime), and unload itself if too far.
I see. I guess then the arena concept would be a misfit in your scheme.
Be sure to drop in a link in your sig when you are finished with your game. Would be interesting to take a peek and how it all ended up
Well, load interiors asynchronously when you’re nearby, have buildings 100% opaque, and have openable doors.
That’ll kill the loading time, it’ll stop the potential combat exploit, and it’ll deal with most of the performance issue because you don’t have to draw interiors except when you’re in or entering the building.
A “solution” to this would be LOD - people can only see through windows from quite close up, so have a shader so that they get less reflective as the player gets closer, until when the player enters a trigger zone/bounding box around the building/window, the interiors near the windows are enabled.
Any of the mentioned methods could give a performance boost to openess - but the question that you have to ask is not “is it possible?” but “is it worth it?”. How much time will you spend coding/implementing a solution (and don’t forget the time spent coding loading screens and transitions to interior levels), and what else would you spend those resources on. What proportion of buildings need openess, how regularly would the player have to encounter loading screens etc etc…
