7 Days To Die Dev Tracker

LOL. I knew those dates when I posted. It was 6-7 weeks out then, which I rounded up to a few months. Remember my post about using x2 or x3 time on programming task estimates? Same concept. I know how times slip.

Yes, whether you control the servers or not makes a difference.

A warning was issued, so that trolling should be over. Calling staff liars is not acceptable. We are not perfect, but I strive to keep the company and myself honest.

I did not say that. Why would we spent time working on a feature we knew would not get approved?

Nothing in life is guaranteed. Anything the company or I say about ANYTHING could NOT happen.

Towns POIs, wilderness POIs and roads are already on a full world grid. There is random variations so wilderness POIs don't look grid like and roads have smoothing.

Autonomous Sensory Meridian Response? Creepy!

We are working on a new doc of 2.0 features as I generally only like to hint at spoilers for my own stuff and not other dev's. Hopefully that gets posted *soon and we start our 2.0 dev diary.

*soon does not indicate or guarantee any actual amount of time. Use with caution and plan accordingly. Have a nice day!

Console optimizations are mostly good for PC, but occasionally a console optimization will save memory at the expense of performance. We have the console devs leave those off for PC.

People also don't understand game optimization. All complex games are optimized or they would run at 1 or 5 FPS, be a stuttery mess and be unplayable. That is why you never wait until a game ships to optimize it or you or your testers could not even test it! I see game reviews all the time with "they didn't optimize the game" or "optimize your game dude!". What they really want is additional optimizations. Those last half, diminishing return optimizations that are harder and harder to get or take more and more time, which is why there is always a cutoff point of good enough.

Sure, it takes about 2% of my time reviewing console dev changes and giving feedback and half of those changes are for general bugs that also effect PC anywa...

If it were up to me I would never give a date for anything. Approximations are ok, but even those are often misread as some guarantee.

Most people don't understand that game dev has a lot of magic like research to it that no one can say how long it will take. A fresh example is I started on something last Friday that I thought would be a few hours improving idle<>walk<>run anim blending rates as the existing lerp on top of a lerp looked like a bad way to do it and caused a still moving bug when we turn off AI while testing. A few hours later I did not like how the new linear rate change looked. Saturday, I think I can get this done in a few hours and 9 hours later I still don't like it after trying many techniques. Today after most of the day I was mostly happy and decided it was good enough. Estimating coding time on new or rewritten features is like going to a casino. My advice these days to programmers is just say x2 or x3 of whatever you think i...

Our console team is another company and they even help us work on general features, optimizations and bugs besides console, so hiring them to do console actually speed up PC dev. Our TFP programmers work 99% on PC, many of them never touch console. We do not plan features based on console. We tell the console guys to make it work and if it does not, we don't go removing it from PC. Examples of console limits - world sizes, max player counts, mods, dedi servers, save game total size.

Over half the stuff on the internet guessing how we do development is wrong, because they don't work here and/or have no clue about game development.