It's been an unusual couple of weeks since my last update; mostly due to play-testing the campaign in multiplayer mode (MP). It has been a long while since I have tested the code in this area, and I apologise to any players who may have been trying to play in a co-op game, as there were a few glitches that needed addressing, especially with some conversations and, in my opinion, some awful area loading times. Anyway, this week's blog is all about MP care and attention, and the up and coming v1.50E! Read on ...
MP Conversations
One of the first elements that builders have to consider in a MP game is when players may or may not be speaking to an NPC and if that conversation is relevant to all players as a plot conversation. After all, it can be boring for another player to sit and wait if there is quite an important story conversation going on elsewhere with another player. This is why we have MP conversations, which involve all players. However, problems arise when certain NPCs can be both vendors (or independent NPCs) and potentially involved in a story conversation as well. Designing a conversation to switch from one style of conversation to another (SP-MP) depending upon when the player speaks with them (and what stage of the plot we are at) can be quite involved.
Unfortunately, in some of the later module releases, I had updated the system to allow for this kind of MP interaction, but the logic was around the wrong way. It was prioritising MP conversation over SP ones, which meant whenever a player spoke to one of these types of NPCs with multiple potential conversation lines, then other players could be kicked out of what they were doing, for no reason! In latest testing, this quickly came to light and I have now reset this conversation to work the correct way. Thankfully, there are only a few of these in the first module, and can normally be navigated anyway. The latest update, however, removes unnecessary interruptions. Coming in v1.50E I have also added some gaming info in some lines so players will know if a line they are about to chose will start a MP link. See this week's screenshot. I will use my discretion as to when best to notify the player, as sometimes the MP link will be automatically done anyway.
MP Area Load Times
Another aspect that quickly came to light in latest MP testing was the (in my opinion) unreasonable load times for some areas. I also discovered some old database code that added to the confusion at times, and could cause even longer delays. The old code has now been either deleted or updated to work as intended, especially with the next modules, and I have taken time to try to improve area load times by taking a closer look at what was causing the delays. I have posted a summary of my findings and how best to prepare for MP area load times below. The calculations are still "work in progress", but are reasonable enough now to give an indication of area load times for MP games according to how many and what type of objects are in an area.
I decided to work along the lines of a maximum of 30s per area load if possible, by altering both my own scripts for area objects and transition objects, and alter area designs accordingly if they were not overly compromised by doing so. Some aspects, like the number of clients in a game, I could do nothing about, but overall, I like to think the alterations have been most beneficial. However, there may be one or two areas (I am still working on them at this stage of writing), which may take longer to load, as they are much bigger and by their nature hold more objects. But, in such circumstances, the slightly longer load times may not be so much of an issue, because they are designed in such a way that the players have no need to leave them again for some time. Therefore, the overall area load time versus the amount of time they spend there is worth the extra few seconds wait. My key aim with this exercise is to ensure areas that are often revisited do not take more than 30s if I can help it, and am aiming for less wherever possible. (NB: In a SP game, these take only a few seconds, around 4-6 only.)
Module Two
I know some may be disappointed at the lack of latest news regarding module two, but I hope you can see that these improvements to the MP environment in module one, also ensure module two goes smoothly. Admittedly, those who only play SP are less affected, but rest assured, when I sort this kind of thing out for a MP environment, the SP aspect also benefits. Also rest-assured that in most circumstances, SP gamers will not notice any difference to gameplay with these changes (apart from a very eagle-eyed player who can spot even the slightest change), as any more noticeable gameplay changes only affect the MP game due to the requirements the MP game needs different to a SP game.
Hopefully, in my next post, I will be able to bring you some extra news regarding the progress of module two. MP testing will be well underway by then, and normally, once past the starting line, things normally settle down, and allow me to get back to plot writing. One thing I will need to address in module two straight-away, are the conversations like these, and check out the area objects! Whatever happens, I will keep you posted.
v1.50E News!
On a final note, some of you may have noticed I have withdrawn module one (v1.41E) until MP testing is completed. You may also note that the version jumps from v1.41E straight to v1.50E. This is because v1.50E has had some changes that will not be backward compatible with v1.41E and below. Trying to ensure backward compatibility is extremely difficult when I am trying to move forward. Therefore, rather than spend too much time trying to accommodate earlier versions, I announced the potential issues and left it a couple of weeks before withdrawing the previous version. However, I hope the extra wait for the latest v1.50E will be worth it, as it comes along with a couple of exciting updates such as an (i) improved journal, (ii) fast map travel and (iii) lip syncing on NPCs, as well as a number of fixes that will benefit all, like one-use items that stay in the quick-slot upon buying or finding more.
 |
| Demonstrating The MP Conversation Link |
Area Load Time Investigation Summary
SUMMARY
In Summary, this is what I believe is worth considering when designing areas for a MP environment …
MP GENERAL
- Each creature in the party adds load time. (Remove summons etal before transitioning.)
- Each client adds load time. (Around 2-3s and is unavoidable.)
- Area enter scripts add little time, but no more than a second or two. (Irrelevant.)
MP AREA SPECIFIC
- Each creature already in an area can add a fair amount of time for a MP load. (0.25s each approx.)
- Placeables with dynamic content creation may also add more time for a MP game.
- Any objects created in an area (via scripting) add towards the total load time. (Remove prior leaving.)
- Next, VFX are more time consuming than most other area objects because of the number used.
The bottom line is really the number of objects(*) in an area affects the MP load time, including any dynamically created during loading. Therefore, be sure to only create objects after the On Client has finished loading and be sure to remove them before exiting an area (and recreate again at next entry if still required).
(*) The objects that appear to do so more than any other are: creatures, VFXs, and placeables with contents. In testing, environmental objects appeared to have little impact, even when running into thousands as in Tsongo’s area.
SP games are much more forgiving and compared to MP environments can probably be ignored by comparison. However, as a guideline, I would offer these figures and guidance for MP area creation to best minimise load times for MP games to under 30 s.
- Spawn constant area creatures after On Client load finishes and despawn on area exit transition.
- If many, do the same with utility placeable objects, such as “weather units” in my own module.
- Keep VFX to under 120. Keep inventory placeables under 40. (Non-scripted appear little impact.)
Doors, sound and light objects also appear to have a very small impact, but not enough to worry about unless you use a lot of them. Just compare your overall usage when considering these objects with relation to other objects used. For instance, if you do not use any VFX, then you can get away with a lot more sounds and light objects.
From following these steps, I reduced one area MP load time from 78s to 30s!
MP Load Time Guesstimate Formula
BASE: (# Player connected x 2.5 + # Additional Party Members (inc associates) x 1)
AREA: (# Creatures x 0.25) + (# Doors x 0.06) + ((#Sounds + #VFX) x 0.08) + (# Lights x 0.04)
VARIANCE: (#Placeables x 0.06 - 0.25 Subject to scripts attached.)
FINAL LOAD TIME = BASE + AREA (+ VARIANCE)
EG: My Area (With Host Only):
HOST: 2.5s + My Entry Scripts (2s) = 4.5s
- Area Creature Objects (15x0.25) = 3.75s (*)
- Area Door Objects (17x0.06) = 1.02s
- Area Sound+VFX Objects (120x0.08) = 9.6s (**)
- Area Light Objects (55x0.04) = 2.2s
- Placeables (Lowest = 34 x 0.06 = 2.04 TO Highest = 34 x 0.25 = 8.5) (***)
( * ) Using default scripts may lower this value.
( ** ) Actual VFX used in area will alter this slightly.
( *** ) Use lower value where no scripts or inventory used.
MP TOTAL LOAD TIME = 21.07s + (2.04 - 8.5s) or 23.11s - 29.57s
In practice, this example area loads in around 24s with just the host.
CAVEAT: Testing is by no means complete and these figures may be subject to further changes.
That’s as far as I have tested for now, but may add more info as time goes by. Again, my thanks goes to KevL and Tsongo for helping look at this with me.
UPDATE: Script with latest timings .... These are seconds allocated per area object:
// OBJECT LOAD TIMES (CHANGE AS EACH TEST IMPROVES)float fCREINV = 0.07; // CREATURE WITH INVENTORY
float fPLCINV = 0.15; // PLACEABLE WITH INVENTORY
float fPLCUSE = 0.24; // USEABLE PLACEABLE
float fDOORS = 0.11; // DOORS
float fVFX = 0.05; // VISUAL EFFECTS
float fLIGHTS = 0.1; // LIGHTS
No comments:
Post a Comment