World War II Online is a Massively Multiplayer Online First Person Shooter based in Western Europe between 1939 and 1943. Through land, sea, and air combat using a ultra-realistic game engine, combined with a strategic layer, in the largest game world ever created - We offer the best WWII simulation experience around.

Share this post

Link to post

Share on other sites

IBM mainframes moved from 24-bit to 31-bit, then 64-bit, and it was relatively painless. But that has a LOT of backwards compatibility engineered in, which builds in limitations with roots in 1970s-80s software/hardware, and certainly not a lot of parallel processing in the modern sense of the word.

The nice thing about being a dev company is you control a LOT of your environment so you can do things your own way at your own pace. The bad thing is, it's not a package you can slap on/buy your way through, configure and go, all that customization is going to fall on your staff.

Share this post

Link to post

Share on other sites

Hmm, most of the time we usually find out it's just a few key people, surrounded by a good support staff, moon shot levels of QA and care and testing before they release stuff. But that's for specific arenas, it may add up to hundreds of key people taken altogether for a new OS, thousands in support people.

z/OS is proprietary, running on proprietary hardware.

In any event, not terribly relevant to the Rats' situation as they are having to play in Linux on the backend on virtual servers, with production backups specific to them and what the colo can do, and then make that all work with a not terribly backwards compatible Windows client environment. I mentioned it though because 64-bit per se doesn't have to be a complete rewrite, it just does more for sensitive not backwards-compatible language libraries and OS.

While not sure of the precise nature of the techniques he's describing, I do know that a lot of older programming would use shortcuts and tricks to deal with the lack of resources particularly memory but also processing, and so would do things that require everything operate exactly with X behavior and Y character count.

By virtue of increasing memory an OS or language will at the least use the higher addressing to extend/increase functions/instructions, change behavior, and/or process larger chunks of data/instruction, and people not concerned with backwards compatibility may break an older version entirely.

Share this post

Link to post

Share on other sites

Sry for the gobbledegook, but there is no easy way to explain the details without teaching some programming.

There are some tricks/often used techniques in programming that use the internal representation of numbers as bits to store information.

Example: Lets say we use a 32bit number to store the number of seats occupied in a transport plane. Bit 1 set to 1 means Seat 1 is occupied, Bit 2 set to 1 means Seat 2 is occupied, Bit 3 is set to 0 so seat 3 is not occupied etcpp. Each possible combination of seats occupied and not occupied represents another number between 0 (all bits set to 0) and 2.147.483.647 (all bits set to 1). So to let another client know which seats are occupied and therefore on which seat to display a player avatar, all we have to do is to sent that number to the client instead of the occupancy status of each seat.

Converting to 64bit changes that internal representation and, if not very carefully implemented, many of the aforementioned tricks/operations can lead to slightly different or totally different results with the new number format.

3 hours ago, Kilemall said:

I do know that a lot of older programming would use shortcuts and tricks to deal with the lack of resources particularly memory but also processing, and so would do things that require everything operate exactly with X behavior and Y character count.

Kile said it better than I could but I already typed my post, so there you go.

Edited January 22 by rote7Example added

Share this post

Link to post

Share on other sites

I actually had a fairly comprehensive answer written up with examples, but realised that it was rapidly getting overly complex, and really, Kilemall and rote7 basically summarised it nicely. The only thing I would add is that there are alot of issues that appear when the original code is not impeccable, and the original developers make assumptions about data type sizes that aren't true under 64-bits. Sometimes the errors are caught by the compiler, sometimes they generate obvious runtime failures, and other times they only manifest as odd behaviour in game as some calculations are 'off' that can only be caught by very extensive QA.

2 people like this

Share this post

Link to post

Share on other sites

Guys are bashing your damage models and everything else, but it probably has nothing to do with damage models. the ancient 32 bit stuff just isnt cutting the mustard anymore. So often frustrating things happen in game, like rounds not killing, or going through enemy or a host of other things and guys blame the damage models, lag etc,,.

None of that has anything to do with 32 bit vs 64 bit.

Share this post

Link to post

Share on other sites

I actually had a fairly comprehensive answer written up with examples, but realised that it was rapidly getting overly complex, and really, Kilemall and rote7 basically summarised it nicely. The only thing I would add is that there are alot of issues that appear when the original code is not impeccable, and the original developers make assumptions about data type sizes that aren't true under 64-bits. Sometimes the errors are caught by the compiler, sometimes they generate obvious runtime failures, and other times they only manifest as odd behaviour in game as some calculations are 'off' that can only be caught by very extensive QA.

Share this post

Link to post

Share on other sites

Example: Lets say we use a 32bit number to store the number of seats occupied in a transport plane. Bit 1 set to 1 means Seat 1 is occupied, Bit 2 set to 1 means Seat 2 is occupied, Bit 3 is set to 0 so seat 3 is not occupied etcpp. Each possible combination of seats occupied and not occupied represents another number between 0 (all bits set to 0) and 2.147.483.647 (all bits set to 1). So to let another client know which seats are occupied and therefore on which seat to display a player avatar, all we have to do is to sent that number to the client instead of the occupancy status of each seat.

This explains why every time i get on a transport plane, everyone sits on MY lap, i guess i am a bit friendly

Share this post

Link to post

Share on other sites

Example: Lets say we use a 32bit number to store the number of seats occupied in a transport plane. Bit 1 set to 1 means Seat 1 is occupied, Bit 2 set to 1 means Seat 2 is occupied, Bit 3 is set to 0 so seat 3 is not occupied etcpp. Each possible combination of seats occupied and not occupied represents another number between 0 (all bits set to 0) and 2.147.483.647 (all bits set to 1). So to let another client know which seats are occupied and therefore on which seat to display a player avatar, all we have to do is to sent that number to the client instead of the occupancy status of each seat.

In a language like C++ isn't that sort of thing abstracted in OOP? Do we really care how physically in memory it's being represented?

Share this post

Link to post

Share on other sites

now if only 1/3 of them were worth what they get paid.... My day job is spent trying to get IBM applications working at an Enterprise Level....

Oh I’m familiar. IBM is full of coasters and IGS is pretty useless too at the individual level. They can tackle monster jobs though ... at a glacial pace ... and for 8 or 9 figures. It’ll eventually get done though - late - and for another 7 or 8 figures over budget.

Share this post

Link to post

Share on other sites

There is not a single aspect to this game that is simple or easy to deal with. Everything from websites, graphics, 3D models, vehicle data, databases, billing service, servers, networks, marketing, community relations and the actual codebase. None of it is simple nor easy to manipulate, update or fix. There are multiple teams of multiple people that deal with these different aspects of keeping this game going and helping it to get better, so do not clump all of it together as if it were only a single person working on everything because that's not how things work.

Couldn't agree with this more. It is understood that there is some impatience, in pretty much all that we do... because people want things done quicker than things can actually be delivered on.

It's not that we don't want to or intend to bring solutions quicker, it's just a REALLY complicated thing.

Think of all of the different things going on in our game, it's complexity as a player... now think of the complexity involved with the development or production team making changes to how things work. That's part of the niche enjoyment with all of this, but it's not a simple thing.

That said we're dedicated to getting things done, and thus far, we have delivered on all that we said we would. In some cases we're still working on delivering on those things, but it's something we intend fully to follow through on.

Share this post

Link to post

Share on other sites

now if only 1/3 of them were worth what they get paid.... My day job is spent trying to get IBM applications working at an Enterprise Level....

I consider most IBM apps toxic. Usually they bought someone out and then tried to make it go, while hoarding the real brains on the backend, and culturally they aren't developers.

This is a common pattern.

Another one is that any app is unduly influenced by the needs of it's earlier customers, and so when it's mature enough to be tried by more companies, their needs or culture or business model is different then the early adopters and you get a bunch of square peg/round hole scenarios.