Group Games!


Well, not too surprisingly, I didn't get save implemented.

@p However, I was able to get some major improvements on the organics engine, that renders trees and such:

@p - Clump properly (or, "more properly"); I used a different clumping algorithm, the algorithm also works a lot faster and doesn't require making a perlin noise field etc; there is still a bug (I should fix tonite) where the clipped values don't wrap.

@p - Display faster: partly an offset of having it clump, I need less density overall. Partly from fixing sort of a bug, well not a bug but something silly in the way I was setting it up; not sure what I was thinking. Basically, I had *two* inner disks of trees being faded, the idea was then that very close up you'd have a few more trees. Again, since the density is less uniform it ``seems'' higher (even though it's actually much, much less) and so you don't need those extra trees up close; also, as you might imagine, you don't see trees popping up right in front of you, which was the real annoyance.

@p - Fade smoother. I affected the alpha fader so that it fades more gradually (quite gradually actually) for the far, disk impostors. Still it's not perfect, but a little better anyhow. I just added an exponential interpolator (very non-fancy, render-frame-based but it works)

@p - Saves to disk cache. This means it loads quite a bit faster when you enter a planet repeatedly. Still, it's not as fast as I want, I'm not sure why, possibly it's the gluBuild2DMipmaps (but I actually dont' think so), or maybe something else I'm not considering. It IS slower than I expected, but it's acceptable anyhow. Might even be simply file access times. Of course, the time to generate the cache isn't especially fast.

@p -----------------------------

@p -----------------------------

@p NOW!! for the exciting part. I'm really seriously starting to think about network play, and I think it could be *AWESOME*. The idea I have for vex is that it will be played very different from a traditional RPG. Mainly, the "see everything" philosophy completely breaks down with such a huge, varied world. I want a lot of detail in the world, but, the player shouldn't feel the need to explore every nook and cranny, unless they have reason to believe it will pay off (which it certainly will sometimes). There are going to be a lot of uncharted places, as well as lots of charted ones. The idea is that you play it through more "real to life", i.e., not so cautiously when it comes to big decisions. Each time you play, it can after all be a totally different world with quite different problems and objectives, which don't have a set way of solving them but which must be attacked more holistically, i.e., solve it any way you can: no such thing as cheating here (unless you edit your savegame =)

@p Anyhow, what I thought (or was suggested to me, actually I hadn't thought of this...) is, why not make it small-scale multiplayer. That is, you set up your own local equivalent of a "shard", everybody has the same game world (which is NOT a problem because autogen will produce the same world on any system, given the same inputs). Then, you basically fly around any way you want. The synchronization requirements will be lax; you won't really notice that much if there is lag, until the lag becomes quite severe. But you won't be attacking fellow players anyhow! You can compete, but the competition will be friendly, i.e., who can score the most points, find key items first, and so forth. Of course, some cooperation to solve situations will certainly be required in a group game.

@p How many players in a group? I don't know, but I can't see a reason to limit it really. I have to work out what the network topology is really going to be, but I won't have it be too complex. Synchronization, again, is a bit tricky, but I *can* attack it piecewise. That is, first of all, all you see synchronized properly is time-cycles (i.e., everybody lives in the same game-time) and you basically see other friendly ships as they fly around. Then I can extend the sychronization to include enemies, and other ships. Finally (or before) certain game flags will be shared, for instance certain items or whatnot will only be collectable once across all games. But other things will be unique, for instance, if one player learns an NPCs name, not all players will automatically know it, and the NPC will respond to each player uniquely.

@p The key here, is that only a few things need to be synchronized, and very weakly. This means I can actually DO it, it's not an issue at all of refactoring the entire design to be multiplayer, it's really just an issue of adding a base network module (not a big job), and hammering out client/servers for each element that needs to be synchronized.

@p Also remember, each player will have a unique background, strengths, and story. You really role-play your own character in the given universe. Even win-conditions may be different for each player, I don't know since I really still have NO idea what the win-condition will be for vex.

@p Here are my sort of requirements for networking:

@p 1- you should see other players as they fly

@p 2- you should be able to do any trade with another player (except your current ship); this includes items, cargo, system warp coordinates, dictionary words, money, points (why not! well, maybe not if I use experience levels, but I don't think I'm going to; instead I think experience will be a commodity to spend for certain types of training, well maybe points won't be tradeable, it doens't make sense really), and even ships.

@p 3- enemies should be synchronized, to allow for group-attacks on enemies.

@p 4- certain global (story) variables will be synchronized, so that if a certain item is obtained from priest X, other players can't get it.

@p 5- a player can be added/join the game at any time. OPTIONAL! the big thing here is that it might be too hard to generate the players background. My feeling right now is, perhaps there should be a completely orthogonal model to umake for generating your character. most players probably want the freedom to generate the kind of character they would like to player, so it would be nice (and very interesting) to decouple it from the game world. IF this decoupling is possible, then it should be no problem to add players to an already running game. I think this is what I will do, so this requirement seems reasonable.

@p 6- players can commlink with each other; perhaps they must discover each other somehow, I don't know! i think it would be fun for players to have to find each other 'blind' but this should definitely be optional; after all, players can always arrange something OOC, so there is no point enforcing something that is unenforcable. But if players want to play the game so that they have to find the other players, that would be fun. Remember that players may start out in different systems. Maybe, there are commlink directories you can publish your commlink to, and see who else has published them. In this way you can hook up as you travel from system to systems. Maybe if you are too lawless, you can't post the commlinks without being tracked by a pirate or something, i don't know. Maybe like, a bad pirate could look and find your commlink and use it to trakc you down. Or maybe just NPC will occasionally track you down if you publish your commlink. I REALLY DONT KNOW! =)))

@p Specific NON-requirements:

@p 1- Players won't be able to attack each other.

@p 2- Players will not interact when they are in a base; i.e., if you enter a store, and your friend enters the same store, you don't see him/her enter. We MAY implement partial synchronization for a special type of building, namely a pub. Bottom line is that this isn't exactly a nice thing to have to sort out, and most of the time players aren't going to worry about that.

@p OTOH.... Maybe the thing to do, is have a building either synchronized, or else to have it "locked". Well no, it's just a pain. No synchronization of buildings. You won't really know anything is amiss. Well wait. What if, only NPCs are locked. It could work like an NPC. You get a generic message if someone enters the room you are in, and if they are talking to a certain NPC, and you try to talk to them, it says "so-and-so is talking to NPC X" and you have to wait until they finish. That would actually maybe be EASIER. In technical terms, what we do is only synchronize the default room actors. The extra actors can only be engaged by one player at a time. This allows us to do some very nice general code rather than have to worry about all individual stuff. What about battles then? I don't know but I think it can also be handled with a bit of generic stuff. Basically I mean, battles are turn based, but team work would be fun. I suppose, you maybe just have to wait for the other player to decide what to do. If you are in a room where a battle is taking place, you are drawn into the battle. This actually ultimately adds a lot of complexity, so perhaps it should be prioritized low. Maybe, players won't interact when in a dungeon or other battle scenario. Would be nice, its jsut a lot of work to implement and it's quite possible the whole battle thing will be scrapped, I don't know yet. Maybe this is a vote in favour of scrapping it (it always was kind of silly).... Yes, i feel more and more that this is a silly side-show to the real meat of the game. The original basis for implementing it was that it would be simple but, it turned out already to be sort of difficult even for one player battles, and multiple player battles will just get more complex. The time would be better spent enhancing NPC dialogue generators, etc.

@p 3- Hmn, any other non-requirements? I don't know! 2 sort of turned out badly as far as NON requirements go, it ended up being a requirement plus a nixing of the battle system. Hhehe. So maybe not having a 3 isn't such bad news after all.

@p WELL! Lots of ideas tonite, but I think it's very very practical which is why I am bothering to think about this stuff. I basically think, it's fairly doable, and it would add a LOT to the game, so it's probably worth it to me.

@p Tommorow is Easter. Yesterday was Good Friday. Does this make today the black sabbath? I don't know. It was the sabbath where the disciples were probably sort of moping around thinking, "man! how could we be fooled" or else just not understanding. Well I guess the Bible doesn't really say what they did today, or else I don't know. Anyhow... No working tommorow =)

2004-04-11


◀ Back