NS2 Q&A #2

Posted by unknownworlds 12 years ago

About a week ago we started answering the questions that were posted in this forum thread.

We recorded video responses to many of the questions, but we’ve been having some difficulty getting those into a format suitable for posting on the website. In lieu of having the video responses, I wrote up answers to all of the technical questions I saw.

When NS2 started out on the Source engine, was it being developed with the public Source SDK or did UWE obtain a private license?

Valve was kind enough to give us full access to the Source engine code. During the time that we worked with that engine, we made a lot of modifications to it which wouldn’t have been possible without that level of access.

Do you regret not taking the easier route of using an already existing engine such as Unreal Engine, Source, Cryengine etc. which would have sped up your production time significantly?

I think it’s a fallacy to say that using an existing engine is a faster route, at least for a team like ours. If you look at the timeline for the project, we spent about 1 year working with the Source engine, and about 2 years building/working with our own engine and tools. I don’t mean to imply the Source engine is bad in anyway, but it was difficult for us to work with a codebase like that where we didn’t understand a lot of it, and yet needed to make extensive changes to realize our vision.

Creating your own engine certainly brings a lot of difficulties, especially in the early stage when artists need tools so that they can be productive. When we made the decision to switch to our own engine we were hoping to continue to use the Valve toolset to avoid this problem. Unfortunately we weren’t able to do the necessary licensing deal, so we had to shift gears and develop our own toolset. If that had been possible I believe our development time would have been significantly reduced, but things don’t always go the way you want.

Is there any sort of timeline on a Linux server binary? You have removed the requirements of PhysX and DirectX from the server, but the server is still only compiled as a Win32 executable. How much more work would need to be done to port the server to Linux?

There will definitely be a Linux dedicated server for the release, but I can’t say at what point it will be available in the beta. While there aren’t any technical hurdles to creating a Linux server binary, there’s work involved in creating and maintaining a separate build configuration.

Please give us an update about your plans of porting NS2 to Linux, or the other platforms. We already know that -if at all- it will all come after 1.0 but what platforms would you prefer or prioritize in case of a port? Linux? Mac? Consoles?

For the client, the priority is Mac then Linux (as previously mentioned, the Linux server will ship with the Windows release). The lack of Steam on Linux is a hurdle at the moment, though maybe by the time we’re considering that move Steam will be available there too. Doing anything with a console is much farther down the road.

Is the eye-candy system already finished or are there features yet to come? HDR? Bloom? Is AA/AF going to be implemented?

No, in terms of eye candy we’re definitely not done. The engine does use gamma correct HDR rendering for the lighting but without bloom effects this isn’t as obvious as in some other games. Although I’d love to be working on highly visible things like that, I don’t want to spend any time working on new features until I’m satisfied with the overall performance.

When will there be some better documentation for modding and how do you make custom entities exist in Spark map editor?

We want to get some good tutorials up on our site about modding, but at the moment our attention is 100% focused on the game. So far the community has been amazing at discovering things and modifying our code (including submitting bug fixes), so there’s a good chance they will get to this before we do! For anyone that wants to take a crack at creating custom entities, check out the editor_setup.xml file.

What about water? Still no plans about adding it into the engine?

We don’t have any plans for water for the initial release since it’s not an element we’re going to be using in any of our maps. I imagine this is a feature the artists will be interested in post release, but there are no specific plans for it right now.

Are the alien warp-tunnels still a possibility or have they been axed?

I’d like to say the warp tunnels are still a possibility, since this is one of my favorite ideas for NS2. However, due to the amount of new technology that needs to be added to make it work, there’s a good chance we won’t have it for the initial release.

There are optimziation tasks in Pivotal Tracker (OnProcessMove, Hydra, etc.) that have been there for quite a few builds under gameplay tasks. When will these be done or are they awaiting engine work on Lua interface optimisation?

The gameplay tasks come from the schedule for Brian and Charlie, so I was not intending to work on these specific tasks, which I believe are currently the slowest parts of the game code. In terms of engine optimization, I am going to be working on the general slowdown we get from executing Lua code due to the garbage collector and interfacing with the C++ code. I’m hoping my system level changes will eliminate the need for any gameplay code changes in Lua and these tasks won’t be necessary.

Clearly the mini-icon competion style thing was a success, do you have many more opportunities to get the community involved?

I’m very interested in ways that we can get the community involved in the coding process, especially when it comes to supporting Mac and Linux. My dream scenario is that I can publish a simple interface for our renderer and have the community create an OpenGL version. There are some logistics that would need to be sorted out, but I’m hoping we can do this at some stage.

Despite being an indie company of less than 10 people, how much does it piss you off that people keep forgetting that?

Reading what people write about you and your work is both the most rewarding and most unpleasant part of game development for me. Even though I sometimes wish it was different, I can understand why someone might not care about the size of the company or whatever else is going on behind the scenes — at the end of the day all that really matters is whether or not the game is good. And if people are making comparisons between our work and the work of big teams, I think we’re doing something right.

When is SLI support going into this game? When will netcode be the priority?

Supporting SLI or Crossfire is low priority compared to raising performance in general (we also don’t have any SLI or Crossfire systems). Improving "netcode" has been my focus for a few months, however this doesn’t actually involve working on the networking system. The networking system will only deliver a good gameplay experience if the server is able to keep up with the work load and deliver updates at 20 times per second. If the server is only pushing out 1 update per second, you’re going to see all types of problems that people often confuse with networking issues.

From what I’ve heard you’re using PhysX. Assuming that’s true: As I have a AMD Radeon card that feeds the rage guy inside of me.

We do use PhysX but we don’t initialize it to use hardware acceleration. You’ll have exactly the same experience regardless of what kind of hardware you have (we primarily have ATI hardware in our office). I’ve often seen people on the forums cite articles about how NVIDIA has cobbled the software PhysX engine, but in my experience the performance of PhysX is better than other software engines like Bullet.

What are your plans for anti-cheat protection?

Anti-cheat is a tough one because it’s a bit like DRM, where the cure can be worse than the problem. Also like DRM, I think the significance of problem is often overstated. We have a few basic things we need to incorporate into the game, like validation of the client files; in terms of preventing more sophisticated forms of hacking, we may use the VAC system through Steam.

Approximately how many lines of code is the Spark Engine? What would you say has been the longest task to overcome besides having to release version 1.0? I also noticed a few former developers from Iron Lore are working on a new IP using the TQ engine. What do you think so far of their work?

The engine is 356,074 lines of C++ code including comments and 184,146 lines without. While it’s not exactly a feature, I would say development of the Editor was the single biggest time sink.

I’m good friends with the guys developing Grim Dawn so I think what they’re doing is great and I’m looking forward to playing their game. It’s nice to see my work on that engine living on, and always cool to see how someone else picks up what you did and enchances it. As far as I know the Titan Quest engine is being used in at least one other project too!

Is GetSatisfaction still used by the team? Have you considered giving moderation access to some of the internal testers, allowing them to work with the reporters to create proper repro steps and push the really important issues to the developers?

Our usage of GetSatisfaction is limited at the moment. Between the forums, GetSatisfaction, e-mails and the bug tracker we use with our testers, it can be a bit of information overload. That said, Brian has been diligent about going through GetSatisfaction and notifying anyone on the team about things they should look at. I used to use it more actively, but since I have been focused more on optimization than bug fixing lately I haven’t utilized it as much. Making the testers moderators is a good suggestion and I will look into that.

What is the testing process for NS2? Are there more thorough tests being done by the testers (except the Internal Builds Testing games)?

We do bug testing on the patch a couple of days before we release it with our internal team and the external playtesters. The testers are starting to organize more targeted playtests outside of our patch driven ones, though one of our goals with the beta is to have the community involved in this process as well.

Brian is currently leading an effort to improve our unit testing capabilities as well. Unit tests are small automatic tests that verify a component of the game is working properly. We’ve dabbled in this in the past, but hopefully a comprehensive system will help us avoid introducing new bugs.

Have you considered getting a full-time Unknown Worlds server running on the public build (maybe in association with one of the server admins), to be able to test server behavior, memory leaks and packets exchange in real-life conditions?

We do want to get a public Unknown Worlds server running at some point in the future. We’re able to capture the real world scenario pretty well with our testers though. It’s actually probably "worse than real world" since our testers are so geographically dispursed. It’s pretty common for us to have European and Australian players connected to our San Francisco machine.

What’s the plan to support non standard textures in custom maps, will mappers be allowed to insert just the textures that are unique to that map or is it a case of having to resort to large monolithic WADs with lots of space wasted on repeated textures?

We’ll have the ability to bundle assets with a map file.

The flashlight does not look very real right now. Will you be making changes to it or is it final?

I’m planning on adding "gobos" for light sources where the light projects a texture into the world. I’m not sure when that’s going to happen since it’s a low priority item, but I think that feature could be used to enhance the look of the flashlight.

In one of your early videos you demonstrated the dynamic lighting via a window shutter opening and having the room fill with what appeared to be natural light. The effect was visually impressive but I have not seen anything similar to that in game thus far.

This feature is still in the engine and you can enable it by typing "r_atmospherics true" in the console. (you can also see this feature in action in most of our cinematic movies like the Fade reveal). It’s much less optimized right now than it was in that video because I rewrote the rendering system since then I haven’t gotten to re-optimizing that particular feature. Cory bugs me about it on an almost daily basis, so I’m going to be working on that soon.

Will we expect more graphics options in beta so we can further tweak our performance

Probably. One of the limiting factors on this right now is that the main menu UI is coded in Flash and is very difficult for us to modify. We’re going to be rewriting the menu in Lua, like we did with the in-game interfaces, to make it easier to add additional options.

How do you process your tasks? Do you start a task and go through with it or do you work on several tasks simultaneously? (I’d guess its the latter, because often there are quite a lot of tasks tagged as "started" at the same time.)

This varies between the different programmers on the team. Ideally I like to have only a single task I’m working on at a time since switching tasks is inefficient. Due to the nature of engine programming, where a lot of other people are building off of your work, it’s often necessary to jump around a bit to make sure people are getting what they need.

Is it possible to create a post-processing filter that makes the game look like on peregrinus’ screenshots? (link)

Yes, we have a post processing system in the engine. Currently we’re only using it for the effect when you are low on health, but the system is general purpose and can be used for that type of effect. We also have a color correction system in the engine, but it’s currently disabled until we can make it more useful for the level designers.

As we get closer to release and putting more emphasis on polish, we’ll be taking advantage of both.

——

Thank you to everyone that submitted questions! This was a long post, but I hope everyone got an answer to their question. I omitted a few that I felt were duplicates or were handled by another response. If you have additional technical questions, feel free to post them.

Comments are closed.