Dundradal
Frog Blast the Vent Core!
Just saw this before heading off to work...
http://kotaku.com/amazon-releases-its-own-game-engine-for-free-1757995787
http://kotaku.com/amazon-releases-its-own-game-engine-for-free-1757995787
Amazon released a game engine
- Thread starter Dundradal
- Start date
Bandit LOAF
Long Live the Confederation!
From experience, very hard. 
capi3101
Admiral
Depends on the type of game, but in general I agree with LOAF wholeheartedly...
Blaster
Rear Admiral
From experience, very hard.
I guess a better question would be: how hard will it be to create a Wing Commander game with the Star Citizen mod tools once they become available?
Bandit LOAF
Long Live the Confederation!
Blaster said:
That's the joke, this new Amazon engine is, like Star Citizen, a heavily modified fork of CryEngine
This is great news for that reason, though: with this free engine available people will be learning mod skills that'll transfer directly over to SC (and hopefully it'll mean we find some new superstars to hire, too!)
Pedro
Admiral
From experience, very hard.
Particularly being based on the CryEngine? Or just a general point about the work involved from going from an engine to a game?
Our other team uses Unity and the performance issues mean they are looking at other engines right now.
I was wondering would the team have opted for a custom engine (using middleware where appropriate) if they'd known their final budget from day one? Working with third party engines, whilst by far the more practical option for small teams, always seems to incur compromises.
Quarto
Unknown Enemy
I've not had the "pleasure" myself, but among people who have worked with it, CryEngine is notorious for being tough to work with, and also poorly supported.
Generally speaking, though, for all the difficulties involved with working on a third party engine, developing your own engine these days is very, very hard to justify.
Pedro
Admiral
With all the issues associated with third party engines it's hard to justify not having your own engine. There are ways to lighten the load of development, middleware, open source software (sonys ATF tools and level editor can take a massive load off) because one day a publisher will ask you for something (or develop for some platform) you can't do well in a third party engine. Unless you are in the pleasant position where you can turn down work.
That said I do feel we are at the point now where every developer, large or small, when approaching a new project should be considering third party engines - just not yet at the point where it's wise to put all your chickens in one basket.
Blaster: no they made the right call picking CryEngine for exactly the reasons you stated - if you are kickstarting you need something to show and that means third party. It's more of a hypothetical question I was posing.
It is completely amazing that they did this but I'm a little confused as to why? It looks to me like Amazon is taking on a lot more overhead for no direct benefit, or indirect as far as I know. If they want to be another steam, they don't need to have their own game engine to do that. Or is it an attempt to get game developers to be locked into amazon web services? But developers aren't paying anything to use those services? Or do users pay? In which case why would anyone do that when steam services are free.
Last edited:
AD
Finder of things, Doer of stuff
It's hinted at in the article linked by Dund. Here's a relevant snippet:
It sounds like they're trying to find a way to monetize that and as well as monetizing twitch stream integration. They seem to be counting on the movement to turn gaming into a spectator sport. Amazon already does cloud hosting and server hosting for game companies as it is, so they're gambling that developers will be attracted to the platform because they will get a bit of a bonus because several services they would want to support anyway will be all in one place.
Quarto
Unknown Enemy
It does depend on the circumstances a lot, naturally, but I really don't see under what circumstances it is justifiable to build your engine in a small-to-medium company. And I absolutely disagree on the need for your own engine when working with a publisher. Modern game engines like Unity and Unreal are often clunky, but they are clunky precisely because they are designed to handle most game genres. Yes, you need to devote some effort to adapting an engine for your purposes, but we should always keep in mind that this effort is substantially smaller than the effort of actually building and maintaining a game engine. As you know very well, engines develop not only incrementally, but also at times they go through total revolution - major rewrites, where you basically get to throw half your code out the window. Why would you want to deal with this internally, when you can push this cost onto a third party? It's the equivalent of building your own camera when making a movie - what on earth would induce anyone today to build their own camera? What's more, this can be outright dangerous. One of the companies I collaborate with in recent years, ran into a brick wall, essentially, because they had their own proprietary engine. They had continued to update it from around 2005 until 2015. But they didn't have the resources to keep up with technological progress. Their last new game on this engine, released in 2013, was considered visually lacklustre. They then ported it onto the PS4 in 2014, adding some visual improvements again - and now they were absolutely panned, because what was passable in the previous generation was now entirely out of place. This is an almost insurmountable obstacle, because they don't have the programming power to upgrade the engine, nor the resources to hire them. The best they can do is to write off the engine, and pick up a third party engine. Only now, they also have to deal with the costs of adapting a third party engine at a time when it is least convenient for them.
You mention the other team in your company struggling with Unity. Well, how many programmers do they have onboard? Now, how many programmers would they need if they were not working with Unity? I bet you that it's not anywhere near comparable. They are struggling, because the team is just small enough to develop a project on Unity - maybe another programmer or two would be good. But without Unity, they wouldn't be anywhere near struggling, they just plain wouldn't be doing anything.
When we were developing Dogfight 1942, on a horrible, horrible third party engine that hadn't even been properly tested, there were many issues with the engine. It was a nightmare for the programmers. Now, here's the thing: we had about ten programmers. We compared our numbers to the team that had worked on a similar project, Heroes Over Europe, using their own engine - they had more programmers than we had staff altogether. I disagree with the idea that a proprietary engine is preferable, because I think that if something is impossible, it cannot be considered preferable.
Pedro
Admiral
This is actually a common difference of opinion between programmers and designers - one I feel that is probably influenced by the fact that in-house tech is often more appropriate to games that are performance critical but light on design. For many projects speed can be far more important than functionality or content. The most powerful tech I've had the opportunity to work on in a while is the WiiU, the last game I picked up was Fast Racing Neo for it - a 60fps racer, then there are games like super stardust on the playstation platforms. Now with the rise of VR on limited hardware such as the playstation 4 you're talking about a lower threshold of 90fps and an ideal of 120 with hardware that wasn't created with that in mind.
If you are competing with the big boys, making another first person shooter, another war game, another real time strategy game then the emphasis is on feature sets, and 30fps. At the other end of the spectrum if you are making a 2D platformer, a card game or want to support every mobile device then there is no sane justification for using your own technology.
I also happen to have spent a lot of time developing on 3DS, there's only one third party engine, Unity, and it requires the triple processor speed of the New Nintendo 3DS just to run.
Now these options don't represent the majority of contracts - which is why I was very careful with my choice of words; but they're there. We've spent a year producing our own tech, the results have been exactly what was anticipated, very good performance (actually exceeding my expectations), but losing programmers to tool creation and tying the hands of your content creators.
With third party engines, especially if you don't have the source (but in practice even if you do) brick walls aren't just a risk, they're an inevitability - you WILL hit them and you will have to compromise your design, or even what you chose to release.
http://www.nintendolife.com/news/2015/05/monochroma_for_wii_u_scrapped_due_to_technical_issues
I've seen them hit first hand and I've seen others hit them. Unity is the prime example of these woes when it comes to performance, due to its poor threading and poor c# compiler on non microsoft platforms, but there is no excuse for hitting any kind of brick wall with your own tech unless you don't have the right people. I would say, rather strongly that your experience there flies in the face of everything I've personally seen in the industry, and was either the case of a bad tech team or one that had been shrunk?
I am going to go out and say that whilst your general point is one easily backable, this particular claim is just plain wrong.
I will say you need the right people, I worked at one company with a very very large programming team all working on a fundamental misunderstanding of a certain design pattern and the reasoning behind it, the technology crippled it. At the same time I look at the output of a company one of my colleagues migrated to after that closure and their own engine and I marvel and admire them, and they're a surprisingly small development team (forgive my being vague, I'm not sure how much it is appropriate to say). Again, the team you have available is another factor.
I can tell you our own tech was developed with fewer programmers than you had on Dogfight 1942 then, even including the gameplay programmers. And we couldn't support every project type - I'd have to check out Dogfight 1942 to offer an opinion on that specific case - please try and remember that I am not, by any means, claiming that in-house should be the default choice, quite the reverse.
Last edited:
Quarto
Unknown Enemy
I think it's also a difference of opinion between programmers and producers. When you are managing production costs, very often "brilliant" is the enemy of "good enough but on budget". Very often, you must start off making compromises at the point of planning a project, rather than late in production. Very often, you will be shaping your project based on the technology available, rather than choosing technology for the project, because that's simply the way reality works all too frequently, unless you happen to be EA.
...Or unless you happen to be making 3DS games, of course. Mobile platforms certainly do have far fewer third party options available, and they tend to be far more demanding when it comes to optimisation, so naturally in that situation, developing an in-house engine has very strong benefits. But on most "big" platforms (Wii and WiiU excepted?), the availability of diverse third party engines, combined with the fact that most projects will not be particularly original, and more likely will be excruciatingly derivative, means that for most projects, there is no economic sense in having your own engine. That's not to say this wouldn't be beneficial in quality - but it wouldn't be worth the money.
Ah, but this is exactly the reality of that particular situation: working as they were in air combat games, without tremendous sales growth, they were stuck making their games on progressively smaller budgets. That's what prevented them from both upgrading their tech, and from switching to a different technology. You have to understand, it's a whole different world once you take economy into account. A decision that to you might seem so obvious that you find it hard to see how anyone would disagree, might not even be on the table in some situations.
And what I describe is not a one-off situation. It's a very common thing that has been the death of many, many small and mid-tier companies over the past decade. As you undoubtedly know, the mid-tier game sales have fallen through rather sharply in recent years. To be really profitable, you almost have to either be in the top ten, or be an indie - or, of course, you have to embrace one of the new sales model, for example by relying on esports. There are still huge chunks of the industry that are struggling to deal with the situation, and for many of them, any kind of long-term strategic planning has had to be set aside in favour of short-term survival. What if you've got twenty people employed, your tech is slowly going obsolete, you do not have your own funding but rely on publishers, and the publisher tells you that for your next project, they can only offer you 90% of what you developed the previous game with? What if your track record is good, but not good enough that publishers are fighting over you - not that publishers fight over anyone these days, given how many desperate devs there are out there?
And yes, it's easy to say that you need the right people. What if you're a small team positioned in a not-too-large eastern European town? Your dev team are good guys, but not necessarily brilliant. Your core team, the founders, might have been brilliant years ago, but a slew of run-of-the-mill projects has meant that they have not had time to stay abreast of leading edge developments. What if you can't very well recruit a brilliant new programmer, because you simply have not the budget to entice them, given the fact that for them, moving to your city is going to be a massive risk? Should you then relocate the whole company, disrupt or uproot the lives of twenty employees and their families (good luck persuading somebody to move, by the way, if their spouses also work, and are not guaranteed to get a new job in another city)? Or should you just give up on proprietary technology, embrace Unity, and live to fight another day? In so many of these situations, the choice of abandoning your own engine becomes a no-brainer.
Well, Dogfight 1942 is nothing to write home about. It's far from impressive, the reviews were average. Graphically it looked ok, but actually got worse towards the end of development, because the limitations of the third party engine and the lack of programmers meant that the only way we could optimise the game was by cutting down the graphics. Also, difficulties with the engine caused the game to ultimately go over time, which obviously also inflated the budget beyond what was originally planned. So far, all indicative of the third party engine being a bad choice, right? But Dogfight 1942 was developed at a time when the company had not done air combat games for about three years, and had no experience whatsoever with console games. And this game was developed first for the Wii, and then for the PC/X360/PS3. With that team of about ten programmers. Actually, I think there were a few more programmers when the Wii version was being made, but then a number of people were fired as a cost-cutting measure. So, what's the comparison to make here? On a third party engine, Dogfight overshot its budget and timeline, and didn't look great - but on a first party engine, the game would never have been made, because the costs of developing an engine for this game would have ultimately made the whole game unviable.
When do in-house engines make sense? They make sense if they are a good and viable long-term investment, the costs of which can be spread over sufficiently many projects. They make sense if you are making a huge AAA production that absolutely has to be top-notch, or else it will not sell, and you have a budget big enough that developing a new engine is actually cheaper than dealing with the painful process of adjusting your pipeline and assets for a third-party engine. They make sense, also, when you are developing games for a platform like the 3DS, where the range of third party engines is limited, and the engines themselves are slightly simpler beasts because the games are simpler beasts. They make sense also, if you're an indie, and you love programming engines. That's a lot of situations where in-house engines make sense - but what I am saying is that these situations are the absolute minority in games development as it stands today. Ten years ago, it was different. Maybe ten years from now it will be different. But today, for most developers, most of the time, third party engines are the way to go.
Pedro
Admiral
Maybe again those aren't the majority of projects I'm seeing.
Well I don't think we will agree here, but it's been an interesting discussion, and highlights very different experiences in the same industry.
That said the Wii is a special case, the jump from fixed function to shader based systems was as big a paradigm shift as the jump to hardware T&L. Had an engine been developed with a singular platform in mind (a mistake I have to say unless you are first or second party), particularly the Wii, then yes, I could see how that could lead to an engine that could not easily be extended.
Whilst I agree with them being a good choice when they are a long-term investment (especially if your company makes broadly similar titles like the Russian Gaijin Games) I actually think third party engines are a perfectly acceptable way to go for AAA titles, Unreal has served many of them fantastically. More so than small and medium budget titles they tend to be quite similar in requirements. How important performance is tends to be key - feature sets you're unlikely to top what is available unless you are spreading the costs over multiple concurrent titles.
I think how big the VR bubble turns out to be will play a factor in whether I hold the same opinion in a couple of years from now, it's fundamentally difficult to produce a third party engine that meets all developers needs yet has the performance to meet the framerates necessary.
It's easier to make an engine with a limited feature set but high performance than it is to make a feature rich one for a AAA title. They make less sense if you're an indie as indie titles are usually carried by the strength of the idea rather than the implementation.
It's the minority, yes, but not the absolute minority - but I've no motivation to talk anyone out of relying on third party - I'd rather work on the kind of games I highlighted earlier, and the less developers well placed to produce that kind of content the better
Well I don't think we will agree here, but it's been an interesting discussion, and highlights very different experiences in the same industry.
That said the Wii is a special case, the jump from fixed function to shader based systems was as big a paradigm shift as the jump to hardware T&L. Had an engine been developed with a singular platform in mind (a mistake I have to say unless you are first or second party), particularly the Wii, then yes, I could see how that could lead to an engine that could not easily be extended.
Whilst I agree with them being a good choice when they are a long-term investment (especially if your company makes broadly similar titles like the Russian Gaijin Games) I actually think third party engines are a perfectly acceptable way to go for AAA titles, Unreal has served many of them fantastically. More so than small and medium budget titles they tend to be quite similar in requirements. How important performance is tends to be key - feature sets you're unlikely to top what is available unless you are spreading the costs over multiple concurrent titles.
I think how big the VR bubble turns out to be will play a factor in whether I hold the same opinion in a couple of years from now, it's fundamentally difficult to produce a third party engine that meets all developers needs yet has the performance to meet the framerates necessary.
It's easier to make an engine with a limited feature set but high performance than it is to make a feature rich one for a AAA title. They make less sense if you're an indie as indie titles are usually carried by the strength of the idea rather than the implementation.
It's the minority, yes, but not the absolute minority - but I've no motivation to talk anyone out of relying on third party - I'd rather work on the kind of games I highlighted earlier, and the less developers well placed to produce that kind of content the better
Last edited:
AD
Finder of things, Doer of stuff
It really depends on what you want to do with it, what kind of graphics quality you are looking at, and how you want the gameplay to feel. If you just want to make a Wing Commander themed shooter, then you have a lot of modern options. If you want to make a spacesim that feels like a real Wing Commander game, going through the ropes to learn how to mod Prophecy could potentially pay off. Freespace 2 though seems to have a relatively easier to use editor, plus you can build on the foundation the WC Saga guys built. However it will still to a degree feel more like Freespace than Wing Commander. There's really not a ton of newer options out there to do any kind of total conversion. If you wanted to use Amazon's new "free" option, you will most likely have to go through a few hoops to make is useful for a spacesim since it probably doesn't have a spacesim template out of the box.