 Sigil Developer Tracker
|
|
The dev tracker is no longer actively scanning, however you may continue to browse the archives collected over the past several years here.
Please remember that these developer posts
are taken out of context, so beware of any silky venom being spewed forth.
Color Key:
Green - Sigil Games Online Employee
Pink - Sony Online Entertainment
Gray - Microsoft Game Studios Employee
Orange - Community Member
|
|
I agree that moving any computation of the world state over to the client would be a dangerous idea. Even as it stands now, every input from a client needs to be reality checked by the server to prevent hacking so you wouldn't really win anything.
I suppose it's *possible* that there might be some rulesets that would be CPU intensive to evaluate but simple to verify, but I'm not sure there would be a lot of gain there.
As wrero pointed out, there are some tasks that are already offloaded to the client. In most cases, (ie movement extrapolation), this is done to conserve bandwidth. Things like animations do both: there is no need to evaluate the positions of all the bones in a skeleton on the server so the client just plays animations when instructed to do so by the server.
Server code would be a neat thing to opensource. If some things were standardized, like server to server and server to client communications protocols, I imagine that you could create something that was like a combination of NWN and FPS mods. Of course, that would have to fall under a completely different business model than your conventional MMO.
|
reply to this post
Find all posts by Caliandre.
Find all posts in "Distributed MMORPGs??".
|
|
Hi Ezzy-
The good news:
Lots of people get away with avoiding quaternions in their own code. It really depends on the application.
The bad news:
A lot of external packages, especially things like 3d modelling suites do use them.
My advice is to read up about them, check gamasutra I think. More knowledge is always better. I do think that you can manage to live your life as a coder, perhaps even a 3d coder, without fully understanding the theory, but I would highly recommend a passing familiarity at the very least. You never know when you might have to import a model from <insert random 3d package here> that exports all its animation data as quats.
Of course, if you do fully understand them, you're a lot better off. If you've someday got a cool IK solution running, or a neat follow cam that gimbal locks, it couldn't hurt.
|
reply to this post
Find all posts by Caliandre.
Find all posts in "quaternions vs. Euler angles".
|
|
We keep a fairly wide range of systems around here. Some are designated specifically as test machines and others fill multiple roles (like development machines) Everyone here jumps in and checks out/tests the game, so I guess you could say that every computer here is a test machine.
On the server side, hardware specifications are a bit easier because we can load balance across a set of machines. Then, as hardware improves, we can just increase the world size manipulated by a given number of boxes.
Graphics, on the other hand, (I'm pretty sure that's the main target of your question) is the big problem that just about every developer faces. The best we can do is look at our projected release date (wouldn't you like to know) and estimate the state of hardware at that point.
Even though the newest snazzy hardware that will be present at release isn't present throughout development, we can talk with those in the industry most knowledgable about the future. And, as aldacron mentioned, developers can often get pre-release cards to help out. Graphics APIs can help soften the transition between hardware accelerated features by providing software simulation of future features as well.
I have the coolest looking computer out of all the programmers.
|
reply to this post
Find all posts by Caliandre.
Find all posts in "Development hardware upgrade cycle".
|
|
Quote:
Originally posted by Kalthanan
When you're programming your quest tools, there should be a master "on" switch for the quest somewhere. You should be able to see every portion of the quest in your Quest Tool (TM) so that you can audit the quest for problems or updating if necessary.
Up until now, and extending into the future, we've been paying a lot of attention to our tools. The point you bring up above is a good one. For all of our assets, we are endeavouring to provide as much potential for cross-referencing as possible. In MMO development, having a living, breathing world is paramount, and we're making sure that our designers have the best possible interface to create this.
You're right about the on/off switch. Questing is something that we're currently devoting a lot of attention to, and we've come to the same conclusion. There should never be a quest on a live server that's only partially finished, and we need to be able to activate and deactivate them at will.
As for your other suggestions, I think you'll be happy with some of the ideas that our design department has cooked up. Pretty cool stuff.
|
reply to this post
Find all posts by Caliandre.
Find all posts in "KNOWN Quest Provider".
|
|
As Gebron mentioned, experience is really the best guide for determining when it's time to step back and optimize. Some things can be optimized early, and by doing so really speed the development process. It's much easier to test code if the graphics or server framerate is reasonable. Otherwise, you slideshow around the scene, wasting time trying to see what's going on.
There are some key bottlenecks that can be easily recognized based on previous experience or common sense. There is a 95% chance that positional updates are going to be a network bottleneck. It doesn't hurt to spend some extra time up front reducing the amount of data sent. Collision and visibility checks can be a big hit on the CPU. Bad occlusion will overload the graphics pipeline. Since these things are all known, it's pretty much a given that time will have to be spent optimizing them. It probably makes sense in these cases to give careful forethought to efficiency, and to dedicate a timeslice or two to watchdogging them.
On the other hand, there are a number of performance hits in every project that come out of left field. I've had a spikes in inner loops where I was just casting a floating point number to an integer. That sort of stuff is best found with a profiler, in my opinion, when the surrounding system is relatively stable.
I generally try to spend a day or so with vtune at every milestone. Many different systems tend to come together at that point, and by definition need to be fairly stable. Profiling at that point means that the code is going to be fresh in the programmers' minds, but not in a state of flux.
VTune is my favorite program, by the way. All the little graphs about what is happening in your program are just SO COOL.
|
reply to this post
Find all posts by Caliandre.
Find all posts in "Gebron, question for you.".
|
|
I certainly agree that tactics need to be improved. In fact, they need to be improved whether or not there is full collision in the game.
That said, my point was along the lines that we always need to remember to balance out all the goals of a successful mmog. One of those is making sure there aren't situations where a player can advance his or her character without risk. Because, ultimately, that isn't fun.
As a programmer, particularly one interested in and working on AI, I need to always make sure that I've got my "this is academically the most correct", or "this is absolutely the most realistic and intelligent behavior" balanced with "oops, guess that ruined gameplay"
In 90% of the cases, maybe even more, a high degree of realism is directly related to fun gameplay. This may or may not include the tank blocking the doorway example, but the important thing for a general discussion is to remember where theory meets practice.
I doubt it would be fun to force player characters to visit the trees for a restroom break every 2 hours if they are male and 15 minutes if they are female 
|
reply to this post
Find all posts by Caliandre.
Find all posts in "Collision/Pathing/AI, can Sigil overcome the challenge?".
|
|
Over the course of my career, I've worked a schedule on either side of the spectrum.
At one point, I used to sleep on an air mattress under my desk whenever I was tired, eating only vending machine food.
On the other side, I spent awhile working around 35 hour weeks.
I'm a min/maxer, so I have tried sliding the widget back and forth. I find my most productivity comes from a set schedule of 9 hour days (normal work day with lunch at my desk). I don't think it's so much an issue of buggy code from being tired, but rather maintaining energy and avoiding burnout. Plus, after holding a schedule like that, if the poo hits the fan, I'm not burned out if there comes a time that there's no choice but to crunch.
So I guess my experience tends to agree with adamc's posts, but I also think that it's different for everyone, and the best thing a manager can do is carefully watch his/her employees for signs of burnout and productivity falloff. And the employee should be honest with him/herself when trying to find their optimum output. As long as that's happening, the benefits should justify the process.
FWIW, I do think that Sigil holds fairly true to this ideal.
|
reply to this post
Find all posts by Caliandre.
Find all posts in "What are the hours like over at Sigil?".
|
|
Hi wrero-
Prior to coming to Sigil, I worked on pretty much all of the issues you mentioned for the ps2 version of EQ. Certainly, I plan on applying that experience here. As galois mentioned, we've discussed the Sigil's pathing a few times on this forum, but you are correct, the issues are related.
I'm a little busy, but here's your quick answer:
yes, as much as we can.
There really are some interesting things about collision, AE stuff, etc, and it ends up coming down to the best solution for the design of the game, imo.
For instance, when a mob cannot pass through a PC or an NPC, it's fairly easy to keep a mob from reaching certain PCs. Park the tank in a narrow hallway, and the healers can just sit back at a safe distance. Or keep your pet between you and the mob(s), and they can't damage you with melee attacks. Just one of 1000 examples, some others were mentioned.
One alternative seems to be having the mobs 1) walk through pets, and 2) give their "best try" at local obstacle avoidance. If they really want to kill the cleric, they eventually could give up trying to go around the fat tank and just walk through him. Or, if possible, they call in friends who have ranged attacks. Maybe they run away. Rest assured, we'll be trying a lot of these things, playing the game, and seeing what is the most immersive, challenging, balanced, and fun.
|
reply to this post
Find all posts by Caliandre.
Find all posts in "Collision/Pathing/AI, can Sigil overcome the challenge?".
|
|
|
|
|
All times are GMT -4. The time now is 12:19 PM.
|
 |
|
News
