3 ms·

Game development methodology has fascinated me recently. With the Battlefield 2042 debacle, its interesting to compare it to what I know (financial trading plat

Game development methodology has fascinated me recently. With the Battlefield 2042 debacle, its interesting to compare it to what I know (financial trading platforms). With trading platforms, they last for years, decades maybe. They're created with some ideas around how to manage performance and to support evolving requirements. Developers know this thing is going to be around for a long time, so its treated as such. Years down the line, you start creating a new platform and look to do a long migration to keep clients happy because you can't just turn off their favourite functionality. Modern AAA FPS games seem to be the complete opposite. Reinvent significant amounts every release. Dump the old game as the new one is released. Much seems to be from scratch. The BF2042 scoreboard issue seems like it should be almost off the shelf. There also seems to be this big shift towards short release cycles which pushes even more churn and reinventing the wheel. Look and feel must be updated to keep things "fresh". Although most of the popular games on Steam[1] are older games that have been around for years. So many places to shave a yak, I'm surprised games get shipped at all. Of course take all of this comment as an outsider who just yearns for the old days of cool mods and custom servers. [1] https://store.steampowered.com/stats/ https://store.steampowered.com/stats/

jhanschoo 5y ago
> Modern AAA FPS games seem to be the complete opposite. Reinvent significant amounts every release. Much seems to be from scratch. I think this should be qualified. The audience and creative workers demand new assets for new titles, but gameplay concepts and codebase seem to move at a slower pace, though live services seem to be distinct systems and not expected to live long, of course. On one extreme, you have EA's sports titles, where new releases have just incremental updates.
adampk 5y ago
If you don’t mind a digression for someone who needs help… What is the architecture pattern of a trading platform? I am looking to build a system that is able to: - receive 1000s incoming streams of data - save the data - make data available to live subscribers The closest analogous system I can think of is bond/stock/commodity/etc price subscriptions for traders. I feel like this many in - many out data stream architecture should be solved by now and I rather not start from scratch in architecture and technology choices. I can’t find the right phrase to even google to get started.
- tikkabhuna 5y ago
  I assume your live subscribers are external people over the internet? The trading platforms I've worked on tend to order things into a single stream that you can act upon. This helps with testing, race conditions, auditability. You will want to be able to replay an exact series of events to recreate conditions. LMAX Disruptor[1] and Aeron[2] are two open source examples of something widely used, either using the libraries themselves or as concepts. Some things that trading systems (generally?) need which you may not, which might simplify your architecture: - Every message must be delivered and in order. UDP is usually used over TCP, as the platform will likely want more control over handling missed messages. - It will be common to have read/write applications that need to add a message as a response. Writing is difficult as you need to be quick, otherwise a subsequent message from another application might invalidate your message. Do subscribers need older data? How do dropped packets impact the system? Can they just be forgotten? What latency requirements do you have? Do subscribers also write to the same stream? - [1] https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/ - [2] https://github.com/real-logic/aeron https://github.com/real-logic/aeron
  - adampk 5y ago
    This is great thank you much appreciated!
midnightclubbed 5y ago
The days where AAA games dumped the engine between releases are long gone (like Playstation 1 long gone). For franchise games there will be incremental improvements to engine systems; some to support new gameplay features, some to help with development tooling/pain-points, and some to improve visual fidelity. The trick is choosing the correct number of upgrades/refactors that fit the release schedule while remaining relevant and not dooming your next franchise release with insurmountable feature debt. In my experience the biggest engine changes come with new hardware platform support, typically a console generation jump. More power requires a toolchain that can handle more complex assets (and more of them), new graphical features and expectations, different optimizations, new API, different storage types or capabilities etc. Bigger franchises may use a new console generation as an opportunity to gut an existing engine and rework to the strengths of the new hardware generation (and remove the support for older hardware, such as removing 32bit pointer support, DirectX9, Windows7 etc). Historically where game engines get in trouble is when a codebase is written to one franchise and then forced on to a team making a fundamentally different game with fundamentally different requirements (open world vs compact maps, physics heavy vs platformer, single player vs MMO). At the executive level it makes total sense, they spent x million$ on a game engine and are told by everyone how great an investment it was... why not spin up a new game using that amazing (and paid for) technology? The flip-side has also sunk numerous game engine efforts, which are often buried without ever becoming public. Doing everything all at once is impossible, you can either do many things generically but with restricted performance and capabilities. Or you can do 'everything' required by a specific game and slowly introduce features that support other games and make things more generic.

jhanschoo 5y ago

> Modern AAA FPS games seem to be the complete opposite. Reinvent significant amounts every release. Much seems to be from scratch. I think this should be qualified. The audience and creative workers demand new assets for new titles, but gameplay concepts and codebase seem to move at a slower pace, though live services seem to be distinct systems and not expected to live long, of course. On one extreme, you have EA's sports titles, where new releases have just incremental updates.

adampk 5y ago

If you don’t mind a digression for someone who needs help… What is the architecture pattern of a trading platform? I am looking to build a system that is able to: - receive 1000s incoming streams of data - save the data - make data available to live subscribers The closest analogous system I can think of is bond/stock/commodity/etc price subscriptions for traders. I feel like this many in - many out data stream architecture should be solved by now and I rather not start from scratch in architecture and technology choices. I can’t find the right phrase to even google to get started.

tikkabhuna 5y ago
I assume your live subscribers are external people over the internet? The trading platforms I've worked on tend to order things into a single stream that you can act upon. This helps with testing, race conditions, auditability. You will want to be able to replay an exact series of events to recreate conditions. LMAX Disruptor[1] and Aeron[2] are two open source examples of something widely used, either using the libraries themselves or as concepts. Some things that trading systems (generally?) need which you may not, which might simplify your architecture: - Every message must be delivered and in order. UDP is usually used over TCP, as the platform will likely want more control over handling missed messages. - It will be common to have read/write applications that need to add a message as a response. Writing is difficult as you need to be quick, otherwise a subsequent message from another application might invalidate your message. Do subscribers need older data? How do dropped packets impact the system? Can they just be forgotten? What latency requirements do you have? Do subscribers also write to the same stream? - [1] https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/ - [2] https://github.com/real-logic/aeron https://github.com/real-logic/aeron
- adampk 5y ago
  This is great thank you much appreciated!

midnightclubbed 5y ago

The days where AAA games dumped the engine between releases are long gone (like Playstation 1 long gone). For franchise games there will be incremental improvements to engine systems; some to support new gameplay features, some to help with development tooling/pain-points, and some to improve visual fidelity. The trick is choosing the correct number of upgrades/refactors that fit the release schedule while remaining relevant and not dooming your next franchise release with insurmountable feature debt. In my experience the biggest engine changes come with new hardware platform support, typically a console generation jump. More power requires a toolchain that can handle more complex assets (and more of them), new graphical features and expectations, different optimizations, new API, different storage types or capabilities etc. Bigger franchises may use a new console generation as an opportunity to gut an existing engine and rework to the strengths of the new hardware generation (and remove the support for older hardware, such as removing 32bit pointer support, DirectX9, Windows7 etc). Historically where game engines get in trouble is when a codebase is written to one franchise and then forced on to a team making a fundamentally different game with fundamentally different requirements (open world vs compact maps, physics heavy vs platformer, single player vs MMO). At the executive level it makes total sense, they spent x million$ on a game engine and are told by everyone how great an investment it was... why not spin up a new game using that amazing (and paid for) technology? The flip-side has also sunk numerous game engine efforts, which are often buried without ever becoming public. Doing everything all at once is impossible, you can either do many things generically but with restricted performance and capabilities. Or you can do 'everything' required by a specific game and slowly introduce features that support other games and make things more generic.