Jump to content
LOTROCommunity
Sign in to follow this  
LasraelLarson

Big Game Development - future to be won by Corporations who ... ?

Recommended Posts

this subject has been in the back of my mind since early in 2016 when GW2 started to lose key team members to some secret project in WA. State.  a few months later i found out about Amazons latest effort to jump into the game-maker market with Amazon Game Studio & a brand new game engine, Lumberyard (which turns out to be CryEngine 4.0 on the back end.)

it got me thinking about Corporations that actually focus on a core engine & if done right could be what separates pack leaders from the followers in the years to come.

here is a video, showcasing some of the markets current top game engines:

Frostbyte Engine is developed by Electronic Arts Games for studios under their Corporate umbrella.
Source Engine is developed by Valve Corporation the Company behind STEAM.
Unity Engine (simplest to learn/use), Unreal Engine (middle range to learn/use) & CryEngine (most complicated to learn/use) all have some form of terms to use/license.

anyway to get to the point in my thinking...  Warner Brothers Interactive Entertainment has at least 7 development houses under its Corporate Umbrella.  each studio has it’s own proprietary game engine, or licenses use of an existing 3rd party engine.  & to me it seems like such a fragmented strategy...  so much unnecessary redundancy.

i think the future leaders in the corporate games industry will own & develop their own proprietary engine & share it across all their studios.  & the ones who do it best will be the "creme de la creme."

so what key factors will being the best take?



-  Adaptable Architecture:
    this one is perhaps the most difficult to address as a layperson...  all data structures will grow,  new systems will evolve, resource demands will fluctuate...  future proofing to scale accordingly...  you avoid reinventing the wheel, or rebuilding your code from scratch.  architecture that is friendly to modularity.
    success in this area will be at the hands of some truly talented coders able to think far FAR ahead.
    additionally if this area is addresses in the design, it will help with increasing assembly line output as the product evolves and grows.  

- Top Notch Software Documentation:
    one thing of note with regard to Turbine, this is an area they are absolutely abysmal at.  i have heard nightmare tales of clutter & unclear developer notations all over the source code.  bad habits & bad practice, but symptomatic of a lack of competent oversight.  & it is a problem that just grows over time with code filtering through multiple teams, or transitioning employees.
    this could also be an advantage to having a central team focused on a proprietary engine.  not only to enforce and maintain standardized documentation practices, but also to provide support to development teams in periphery studios.

- Cross Platform support (PC (Mac-Linux) - Console (Generational Platforms) & Mobile):
    again with regard to Turbine, watching them switch to mobile games development & the ridiculous number of hirings they had to do for people to work on back end stuff that the Turbine engine did not support for mobile platforms.  additionally i seem to recall Alywens tale of the huge waste of time & resources developing a console port for LOTRO.  money down the drain.
    this could be yet another huge advantage to having a centralized team developing a proprietary engine.  not only could the engine support cross-platform development, but the engine could have emulation tools to test the source code for multiple platforms.  & having a centralized “source (engine) code” would go miles towards making cross-platform emulators work.  additionally that engine development team could assist in porting games, eliminating the need for 3rd party contracts.

- Top Notch Current & Updated Net Code: (Game Client):
    when did Turbine lose the original game client optimizers?  was the first cull shortly before, or after Warner took ownership in 2010? or even further back in 2004 when Turbine lost Microsoft’s assistance when they took full control of Ashrons Call?  regardless, with each additional system added... game performance always took a hit.
    optimization of game engine & client should be a perpetual process & having a centralized team constantly tuning would go miles to improving players overall experience & impression.  issues with lag must be aggressively tackled, in perpetuum.

- Graphic Toolsets & Asset (visual & sound) Libraries:
    3D model sculpting & 3D pixel painters with animation emulators.  imagine having graphic toolsets something like Zbrush to create models with & test out animations...  hairstyles, emotes, wardrobe pieces, weapons, even particle effects.  multiple studios producing assets (textures, sounds, animations, etc.) all on the same source code & having those libraries grow over time as new material is created.
    extend this to Architecture (buildings) & world construction (landscape.)  tree & foliage textures & animations.  water body varieties. wind effects.  now add sound.  all created on centralized game engine code across multiple studios.
    an asset library that would grow over time, one that could be modified based on theme & so on.  the time this would save in generating product...  and a common source code that is adaptable - modular;  production assembly time frames could drastically reduce over time.



so the above would be the essentials, but i think a corporation that is planning on being a big league (Triple AAA) contender in the coming market will have to set up a proprietary engine for their studios & multitude of game titles.  the initial investment would be significant, but the long-term gains of having something for your “umbrella studio” properties that would not require licensing fees & with multiple content contributors, a constant growing library of audio & visual assets.  all modular & if done right, assembly production at accelerated rates.

also if i had to guess, a company like Blizzard probably has most of these things in place, or is close too.

it remains to be seen just how successful Amazon will be with the games developed on Lumberyard, but there are some starts that look to hold some promise.  will be interesting to see how the “Twitch TV: support plays out...  or “cloud” support.  >.>

all the above said...  any game studio without this level of structural support, is always going to be lacking & failing to keep up with those that do.

Share this post


Link to post
Share on other sites

With regard to software documentation: there are several types of documentation - in-code notations, white papers, troubleshooting guides, implementation guides, and end-user procedures.

I've found that in-code documentation is always the least accurate, least useful form of documentation. Some developers are better than others about documenting their code, but most are just not interested in doing so, and most companies are not willing to expend the resources (i.e., a qualified technical writer) to create line-by-line documentation, especially for legacy systems that were built over years of development without documentation. Even when documentation is a "required" part of the process, it is usually low priority and one of the first things sacrificed to deadlines. It's been my experience that expecting "top-notch" documentation from programmers is a pipe dream.

  • Upvote 1

Share this post


Link to post
Share on other sites
7 hours ago, Talisman said:

With regard to software documentation: there are several types of documentation - in-code notations, white papers, troubleshooting guides, implementation guides, and end-user procedures.

I've found that in-code documentation is always the least accurate, least useful form of documentation. Some developers are better than others about documenting their code, but most are just not interested in doing so, and most companies are not willing to expend the resources (i.e., a qualified technical writer) to create line-by-line documentation, especially for legacy systems that were built over years of development without documentation. Even when documentation is a "required" part of the process, it is usually low priority and one of the first things sacrificed to deadlines. It's been my experience that expecting "top-notch" documentation from programmers is a pipe dream.

Agreed.  If there is documentation, it's usually so cryptic or jargony that you need to talk to the coder to make sense of it.  Another factor that comes into it is that designers are often dismal in being able to clearly explain things, so the coders are just as in the dark in figuring out the designer's thinking.  Their comments reflect that.

I've been in countless design reviews over the years, and have seen outright hostility from designers when other people ask reasonable questions just trying to figure things out.  The designers are so locked into their thinking that they can't empathize with others who are genuinely trying to understand it, and think they're being attacked.  

Share this post


Link to post
Share on other sites

to expand on my thoughts above re: game engine.  anyone at the corporate “Big Ideas” level needs to seriously consider the structural foundation of a robust proprietary game engine, as crucial.  corporations wanting to jump into the Interactive Entertainment race should view game engines like the “Operating Systems” for all their products.  having a centralized, or uniform structure (operating system) that is constantly evolving with the current market is (IMO) a necessity to competing against the current established market.  

Amazon Games Studio from a glance would seem to be the first to overtly tackle this with its proprietary engine, Lumberyard.  purposefully engineering a robust game engine and centralized platform to aid developers in creating products that can be distributed on multiple platforms.  it remains to be seen just how successful they will be, but (IMO) they seem to be on the right track.

Valve also has had a great deal of success with its proprietary game engine, “Source” taking it a step further with a digital distribution hub, the STEAM network.

Blizzard Entertainment which had its humble start all the way back in 1991 porting games for other studios...  i sometimes think this early foundation of working on ports was actually a key factor in guiding the early decisions and framework for when they started to work on their first games back in 1993.  i believe this early knowledge & experience with creating ports gave them a solid foundation to create their first decade of hits: Warcraft, Diablo & Starcraft.  & they just continued to build upon their successes to become the powerhouse they are today.

whilst Blizzard may not have started out with a fully operational proprietary game engine, they have certainly been successful in creating some kind of internal centralized structure to support the development of their massive game titles.

in order to compete against these powerhouses & other market leaders it is going to take more than just an idea (or IP.)

in the case of Warner (& Turbine) hindsight is indeed 20/20.  Warner went on a studio acquisition shopping spree buying up (or creating):
* TT Games
* Rocksteady Studios
* NetherRealm Studios
* Monolith Productions
* Turbine
* WB Games Montreal
* WB Games San Francisco
each of the above working on different source code & in house engines, or 3rd party licenses.

i am most familiar with Turbine, so i will just use them as example.  back in February of 2014 i took a look at Turbines history:

what Johnny Monsarrat (Turbine April 1994 founder) utilized in those early months...  perhaps Chris Pierson could provide specifics, he was with Turbine the longest:

Chris%20Pierson_zpsbp6nv0it.jpg

what i can say is that Ashrons Call was Turbines first real title & development started sometime in early 1995 with Microsoft's extensive assistance.  the original release date of late 1997 was delayed till November of 1999 due to the inexperience of the production team.  the state of Turbines proprietary game engines earliest iterations was tied directly to Microsoft, until 2004 when Turbine took over the title exclusively.  so the Turbine engine definitely has a lot of Microsoft Visual C++ core components.

when Jeff Anderson (Ultima online guy) took the lead in 2001 - 2008.  one of the key factors during his time was Turbines involvement with Middle Earth Online starting in 2002 & Turbine inheriting all the code base and assets from Vivendi - Sierra in March 2005.

& the last details with regard to Turbines proprietary game engine is post Warners acquisition in 2010...  the switch to mobile games & the extensive hires Warner had to do for technical back end engineers for mobile platforms to add those missing ingredients from the game engine.

so whilst i can’t give a blow by blow detail of the last 20 plus years of Turbines proprietary game engine, i can quite confidently say it is a patchwork of additions to original software designed for a seamless world with dynamic load balancing from all the way back in 1999.  those additions were time-consuming and not exactly cost effective.  nor were they seamless.  & that doesn’t even factor for all the employee transitions over the years.

now imagine similar development stories for each of the 5 other studios under Warners Umbrella...

measuring the fail to success ratio really shouldn't be much of a mystery taking all the above into account.  ;)



to get back to the “Operating System” structure of a central core proprietary game engine...

2 examples i’d like to point to:

-  the Mac OS X 10.0 “Cheetah” and its various iterative evolutions, “Puma” > “Jaguar” > “Panther” > “Tiger” > “Leopard” > “Snow Leopard” > “Lion” > “Mountain Lion” > “Mavericks” > “Yosemite” > “El Capitan” to the current iterative evolution “Sierra” 10.12

- Solaris OS and its similar iterative evolution.

a core proprietary game engine should have a similar development cycle of evolution.  constant tweaks - improvements or additions to reflect the current market as well as expand the existing libraries of assets.

having actual engineers to design & hard code the game engine framework, (rendering, physics, sound, scripting, input/interface, animation, A.I., networking, memory management, threading, localization, vector editing, etc.) isn’t entirely arcane, but a single example:
    * cross-platform specialist familiar with X-Box One code requirements to create engine emulator & client to run game code for...  or PS4, or mobile devices, or Mac/Linux versions on PC.

filling the needed engineering positions with technical expertise can get costly depending on just how robust a start you want to enter the market with...  that is the big hurdle, financing the endeavor.

the other component i feel is crucial, (and this should address the previous posters regarding documentation)  is the support framework around those engineers so that the entire functional knowledge base of an engine component, or version, isn't lost to antiquity when someone retires, or is restructured out of a position /  job.

& it is key to remember, this isn’t for umpteen different developer studios, but rather a single core engineering team.  these Coms support people would be responsible for documentation as well as communicating up (to Corporate “Big Ideas” folk)  and down (the periphery studio developer houses) the chain, as well as do the back and forth to the engineers to create the actual documentation.  this may not be the easiest of tasks, but ideally you’d find someone who could accomplish bridging all the different / unorthodox / idiosyncratic / distinctive / personality types...  a good communicator/doc. writer...  the art of being charismatic, without being dogmatic.  ;)

remember, the title of this thread is not about participation...  *shrug*

how does Blizzard manage it? any successful enterprise for that matter.

to compete against the top performers in the current market, you need to bring your A game, otherwise get used to playing on the losing team.  so if documentation is soo jargony, or cryptic...  and that can’t be worked around & improved...  this is what a pink slip looks like because your services are no longer required.

a premier proprietary game engine is a flagship of production, hire the best you can afford.

Share this post


Link to post
Share on other sites

I wonder if we've passed Peak Games. Large-budget games used to be aimed at PC enthusiasts, with gaming consoles associated. Now, though, everyone has enough hardware in their pocket to play games as elaborate as they want - and they might not want that much. I fear that the mass market will just want things like Farmville etc., with not much learning required, and therefore that's the direction big games companies will go. We might already be seeing that with e.g. Turbine turning away from LOTRO in favour of mobile games, and computation in games gradually moving from client to server.

Share this post


Link to post
Share on other sites

CIG recently completed the Switch to Lumberyard for Star Citizen, and apparantly it was a smooth transition.

Right now, the biggest problem with the Alpha is the horrible netcode not being able to properly handle the sizes and detail, something that should be improved upon in the next big patch (Alpha 3.0).

It should also be noted that CIG is a gold sponsor of this project: https://github.com/networkprotocol/libyojimbo/blob/master/README.md

CIG have already shown what fantastic stuff Cryengine/Lumberyard is capable of (64 bit precision with huge maps, seamless procedural generation, localized physics grids), so lets hope they can really nail the netcode bit. Not just for SC, but for all future MMOs

Share this post


Link to post
Share on other sites
On 12/31/2016 at 1:08 PM, LasraelLarson said:

[stupid quote functionality is SOOO broken]

Share this post


Link to post
Share on other sites
On 1/2/2017 at 11:38 AM, Darmokk said:
On 12/31/2016 at 10:08 AM, LasraelLarson said:

[stupid quote

i recall back when these forums switched over to the updated VBB i initially had issues using the quote system as well...  something in the way the boards remember formatting or something caused issues with quoting.  my workaround...

On 1/2/2017 at 11:38 AM, Darmokk said:
On 12/31/2016 at 10:08 AM, LasraelLarson said:

functionality

i only ever use the MultiQuote button now.  hitting it will store the post in memory (with a Quote "#" of post entry.)  if you are attempting to multi-quote a single post, you can't as it will only store once in memory.  however, you can hit the quote "#" post button adding it to the composition box, edit and respond accordingly, then go back and reselect the MultiQuote button from said post to store it into memory again.  simply place the mouse cursor in the appropriate place in the composition box to add it again.  rinse and repeat the process as needed to compose a multi-quote response.

same process can be used for different poster responses.  you can add em all at once, or one at a time.

On 12/31/2016 at 10:08 AM, LasraelLarson said:
On 1/2/2017 at 11:38 AM, Darmokk said:

is SOOO broken]

so whilst it takes a bit of editing & isn't as convenient to format as say a "quote highlighted text" would be, it isn't completely broken.  just the way the new boards stores formatting in memory is a bit ass.

nested quote in formatting, as demonstrated with my messing around in the 3 replies above.   the ability to edit out nested info is indeed broken as...

Share this post


Link to post
Share on other sites
On 12/31/2016 at 11:48 AM, Brrokk said:

I wonder if we've passed Peak Games. Large-budget games used to be aimed at PC enthusiasts, with gaming consoles associated. Now, though, everyone has enough hardware in their pocket to play games as elaborate as they want - and they might not want that much. I fear that the mass market will just want things like Farmville etc., with not much learning required, and therefore that's the direction big games companies will go. We might already be seeing that with e.g. Turbine turning away from LOTRO in favour of mobile games, and computation in games gradually moving from client to server.

i think it is more a case of "Big Market Followers" chasing "Big Market Leaders" having a low degree of success due to saturation points and established markets based off sunken costs.  why would anyone having sunk time into WOW, throw it away for the next new, that doesn't do as much as WoW?  whilst there will always be growth, the initial booms aren't perpetual & the follow up growth is not large enough to sustain multiple developments.  same goes for a DOTA 2 or League of Legends, why leave all the gains you've made in the industry leaders to start over in something that may not even do what these titles succeed at?

mobile is again new and growing, but so are those jumping into that market.  how much is sustainable & how much is clearly over reaching?

that said new development is still happening as shown by the post below.

On 1/2/2017 at 4:00 AM, vr00mie said:

CIG recently completed the Switch to Lumberyard for Star Citizen, and apparently it was a smooth transition.

Right now, the biggest problem with the Alpha is the horrible netcode not being able to properly handle the sizes and detail, something that should be improved upon in the next big patch (Alpha 3.0).

It should also be noted that CIG is a gold sponsor of this project: https://github.com/networkprotocol/libyojimbo/blob/master/README.md

CIG have already shown what fantastic stuff Cryengine/Lumberyard is capable of (64 bit precision with huge maps, seamless procedural generation, localized physics grids), so lets hope they can really nail the netcode bit. Not just for SC, but for all future MMOs

in the case of Lumber yard above, you have multiple studios tackling the issue on the same source code, any breakthroughs are potentially shared by all properties.   this is something that overtime will accrue in value.

that is the biggest setback for Big Firm Publishers who have multiple studios all on different source code.  it is also the biggest hindrance when it comes to writing ports, or emulators for cross-platform conversions...  that and input/interface differences.  having these centralized game engines, if done right, can have long term payoffs. if Amazon has set up the centralized aspects correctly, then indeed all games developed on the platform will reap each others functional>procedural benefits.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×