Jump to content

  • Log In with Google      Sign In   
  • Create Account

Shannon Barber

Member Since 23 Jun 2000
Offline Last Active Jun 03 2016 03:37 PM

Posts I've Made

In Topic: responsiveness of main game loop designs

03 June 2016 - 02:53 PM

To do this optimally you need a buffer of input events with hardware time-stamps.

I was hoping that DirectInput would evolve towards that but it was abandoned and we're back to sucking messages from the pump.

That at least provides an ordered list of events but without the time-stamps you cannot even implement something as simple as pulling back the plunger for a pinball game accurately.

You get quantized to your polling rate and experience jitter corresponding to your input-stack and thread stability.


You could compensate for this by introducing the uncertainty of your input into your hit detection.

When you receive an event you know it happened between between 'just now' and one polling period ago which gives you a delta-time.


Humans do not act "at 5Hz".  

I can push a button for less than 10 ms and routinely demonstrate how HMI's cannot handle button presses that quick (and we show on an oscilloscope that the button was indeed pressed for 7~12 ms).


60 Hz vs. 120 Hz makes a notable difference for FPS games and it's probably due to the triple-buffering.

3 x 1/60 -> 50 ms. That's an eternity.

In Topic: Custom editor undo/redo system

10 May 2016 - 12:15 PM

The (de)serialization (second) approach can have a significant performance impact for moderate data-sets.

In a tool I wrote long ago we had to stop doing it that way and use the command pattern with undo/redo stacks (otherwise every time the end-user made a trivial modification there was a pause as the data was serialized.)

In Topic: Is it C# Territory?

04 May 2016 - 08:03 PM


Your good reason is "We have hundreds of thousands of man hours invested in our giant aging C++ code base, thus we'll be keeping that around. kthxbye."


Sunk cost fallacy...


A good reason would involve comparing the expected results of the new product against the quality of the existing product to see if the value of improvement exceeds the implementation cost and risks.



... and that cost would be hundreds of millions of dollars.

In Topic: Question about Open World Survival Game Engines

29 April 2016 - 02:50 PM

You're going about this completely backwards. Normally seeing you gather a team of engineers based on your pitch (and proper compensation of course), and you let them decide what technology to use for the project, since they'll be able to make a much more educated decision than you ever will.


I actually disagree. Just like running a guild, you have to pick the game and schedule first then recruit people that fit and want it.
If you just grab a bunch of people because they are good at X/Y/Z you will end up with a group of talented people that have no feasible way of working together.

In Topic: Question about Open World Survival Game Engines

29 April 2016 - 02:15 PM

For a professional project I would see if I could license Forgelight 2 (that's the SOE/Daybreak engine used in PS2 and H1Z1).

Next I would look at Unreal 4 and determine the work it would take to scale to large worlds - ARK is progressing albeit with some issues.

Practically speaking Unreal 4 is way easier to "get off the ground" with than wooing Daybreak to license FL2 to a vaporware team - especially when the plan is to create a competing project.


Programmers will be the least of your problems.

(There are a lot of programmers with boring day-jobs that will be willing to moonlight on an interesting project.)

The biggest problem is core business organization and project management.

There is no demonstrated way to complete such a project *on schedule* without an operating budget.

Mods, total-conversions, get made but they are generally not completed according to the original schedule.

The next major problem is the creation and integration of high-quality artwork and sound.


For structuring such a thing I would create a bitcoin-mining-like value generation and then assign it to the people working on it.

There's some software infrastructure to create for tracking (e.g. a tray-icon tool you click to clock-in/clock-out, detect away, detect screwing around on reddit, et. al.) and just that infrastructure could be its own company.

By bitcoin-mining-like I mean I would track the time people put in and have accomplishment of milestones unleash value that is then distributed among the people that contributed time to make it happen.

That amount becomes how much of the company they own (e.g. issue private stock).