Jump to content

  • Log In with Google      Sign In   
  • Create Account

Zipster

Member Since 11 Mar 2000
Offline Last Active Yesterday, 11:44 PM

Posts I've Made

In Topic: C++ how to declare something that isn't declared?!?

19 December 2014 - 12:45 PM

To be fair though, if your code were to even compile with such a mistake, then you're probably something far scarier than multiple declarations per statement.


In Topic: TCP clients-servers-servers

17 December 2014 - 01:31 PM

It comes down to server tiering and instancing, as others have mentioned. Each shard could consist of a handful of top-level world servers, and beneath each of them could be multiple region servers, and beneath each one of those many instance servers, etc. Thousands of players may be playing your game at once, but each server would only have a handful of players of connected at once (or not have to do much work per player). You'd also probably have separate servers for logging in, chat, auctioning, finding instances, persisting player data, etc., that serve very specific purposes. Basically, the work is spread out across many servers that are each designed to do one task really well.

 

Of course, the game design itself would have to be amendable to this sort of stratification. If you're trying to design a game where thousands of players can battle it out at once ala EVE, you'll need a whole separate bag of tricks!


In Topic: Should the player be just another entity in the etities list?

17 December 2014 - 12:45 PM

Note specifically that the conceptual "player" can be detached from a physical avatar object, which gracefully handles not only avatar death as Sean mentioned, but also the initialization and shutdown cases where you may want something representing a player to exist before the world and any entities are fully initialized and ready.


In Topic: Need advice on C++ reflection system

15 December 2014 - 12:49 PM


Unity builds are a step backwards for small iterations (change one file and be forced to recompile tons of code) and distributed builds only help when you're building a large number of files (which themselves don't play all that well with unity builds). The turnaround time for making small, simple code changes and being able to test those in game is paramount. Unity builds and distributed builds are more relevant when doing large rebuilds and not on those small iterations.

Compilation times are dominated by file I/O. Unity builds leverage this fact by combining multiple source files with similar header dependencies into a single translation unit, so that these header files only need to be opened and included once for a given set of source files. So yes, if you iterate on a single source file, it may be compiled along with some other source files that have similar dependencies, and it may take a few more seconds to compile than were it to be compiled alone. But what's your point? You could just as easily change a header file that triggers a partial or full rebuild of the entire project anyway. I wouldn't consider one case more likely or important than the other, but to me the overall benefits clearly outweigh any small downsides in specific scenarios. Keep in mind that engineers are not the only ones building code; where I work, we have automated builds that trigger every few hours (in addition to on-demand) with the latest changes, and those benefit from being as fast as possible as they're the builds the rest of the team has to wait on. Talk about turnaround times being of paramount importance, wait until those guys are blocked and breathing down your neck waiting on critical bug fix X.

 

As for unity builds not playing well with distributed builds, in my experience this is simply false. You're not combining every single source file into one monolithic translation unit, you're combining them according to similar dependencies (which tends to follow the existing stratification of projects and libraries), and limiting them to a reasonable size. Instead of tens of thousands of files, you only have hundreds, but still enough work for a distributed build to take advantage of. More work per translation unit might also benefit a distributed build by amortizing the initial overhead cost of transferring the build environment to agents.

 

 


"I wouldn't worry too much about compile times at this point" is one of the worst pieces of advice to ever give a systems engineer. It's one of the first and most important things to worry about when building the foundation code for a large project.

Maybe compile times were a big architectural concern in years past, but as far as I'm concerned modern hardware and build processes have solved the problem. We took a full rebuild of our entire game (engine+game+tools) from over an hour without any special build processes, to 7 minutes with both unity and distributed builds enabled. Incremental build times have increased so marginally that no one has noticed, since build times are orders of magnitude faster across the board.

 

These days I wouldn't advise any engineer to seriously consider compile times as a deciding factor for any source-level decision, especially if it leads them to an inferior solution. When/if compile times become an issue, there are build-level solutions that solve the problem without requiring any code changes and have other far-reaching benefits.


In Topic: is there an easy way to do this?

12 December 2014 - 04:21 PM

I commonly refer to this old but informative Gamasutra article when it comes to handling localized text. It discusses a full solution that handles all the various grammatical cases you can run into with different genders, plurality, etc., that are common in RPGs with customizable characters and randomly generated content, however most of the games I've worked on have gotten by with simple format string substitution, as frob described above.


PARTNERS