Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Mar 2013
Offline Last Active Yesterday, 04:54 AM

#5297514 Physics and Sound Engine Encapsulation

Posted by SephireX on 21 June 2016 - 06:53 PM

Thanks for the replies. I understand why wrappers are used. Maybe "encapsulation" is the wrong word. I'm talking about providing a common physics interface that would allow different physics engines to be used with the same game engine. I know that if this interface is created by a programmer that has knowledge of only one physics engine, it may not fit other physics engines that well but the interface could be updated in the future if it was decided to switch physics engine. At least the engine would never point directly to a specific physics engine but rather the interface meaning it would be easier to update the code. Then again, it might be over-engineering.


While on the subject of game engine design, I have another question regarding the level editor. Most level editors have snap functionality allowing the user to let an object snap to the ground. For the editor, to know where the ground is, it will have to do a collision query; maybe a ray cast downwards to find the nearest point of intersection. Would a game engine use the physics engine for this ray cast or would it traverse its own spatial hierarchy and do the intersection tests itself? For example, let's say the user wants to place a chair on the ground and they can hit a key that will instantly place the chair on the floor. The floor will have a static actor in the physics engine because its not going to move in the game. Though what if the user wants to move the floor after they place the chair? Would the editor make all static objects dynamic actors in the physics engine for the sake of editing or would the physics engine be in use by the editor at all? Sorry for the long winded question.





#5293765 Are Third Party Game Engines the Future

Posted by SephireX on 27 May 2016 - 04:06 AM

Thanks again for the replies. Always good to hear other people's opinions.



Sorry I misinterpreted what you were saying the first time. I would agree that UE4's code is over-engineered but I suppose the programmer suffers so the content creators have an easier time.



 I agree that most existing AAA devs won't move to third party engines in the foreseeable future. However, there are so many indie start ups using third party engines. Most of these indies will fail but some will succeed and grow into teams capable of making AAA games and they will likely continue to use the same technology. I therefore can't see engines like Unity and UE4 going anywhere. The barrier to entry is very low and so many teams are using them. For indie developers that plan to make big games, there really isn't much of a choice but to use third party engines. To make AAA quality tools that are stable would take too long. In my case, I have a full time job as a programmer but not in the games industry unfortunately. I can only dedicate 10 hours a week to work on game part time. There are many virtual teams made up of people in similar circumstances and third party engines really come in useful in these situations. Knowing how to write gameplay code in Unity or UE4 presents a lot of opportunities for joining other teams using these engines. Its also easy to carry gameplay code from one game over to another.

#5293634 Are Third Party Game Engines the Future

Posted by SephireX on 26 May 2016 - 12:47 PM


Though if you look at Unreal Engine 4, you will see a huge variety of different types of games being made with it. UE4 is very different to UE3. It supports large open worlds out of the box and small studios are making very big games with it. For example, Ark: Survival Evolved was created by a virtual team of indie developers. The engine is very flexible and although it may not be optimal for a specific genre, the source can be modified to make it optimal. An indie team starting out will not be making boundary-pushing games. If the team is successful and grows, they can hire more programmers and heavily modify the engine for more ambitious projects. UE4 is a lot more flexible. The Oculus team replaced UE4's renderer with their own for VR optimization and used it in the games they are making. They've also made this branch of the engine publicly available.

#5293615 Are Third Party Game Engines the Future

Posted by SephireX on 26 May 2016 - 10:29 AM

@Josh Petrie

I suppose in the long run it balances out. Just comes down to money. Everyone has a source license to Unreal Engine 4 now. Just 5% royalty unless you get custom license.



I suppose artists can create textures and modelers can create and rig 3D models. Designers can work on design documents. Maybe even use a third party engine to prototype.


I personally prefer to know how the tech works but not reinvent the wheel. UE4 suits me and I'll probably use it. When starting out, its also easier to move to other teams and carry over gameplay code because so many other teams are also using the same engine.


@Norman Barrows

Nicely put.

#5293605 Are Third Party Game Engines the Future

Posted by SephireX on 26 May 2016 - 09:33 AM


I'm talking about a team's decision to use third party or an internal engine. The current trend is that AAA studios make their own and indie devs use third party. Tools are always changing but a team has full control over how an internal engine changes or evolves but do not have the same control over a third party engine. My point is that I believe in time AAA studios will sacrifice having this amount of control in favor of the better tools and workflow that third party engines will provide. 



As far as Unreal Engine 4 being derided, I doubt that. A number of Microsoft studios are using it. Square Enix is using it for FF7 Remake and Kingdom Hearts 3. It was used by Namco for Tekken 7 and by Capcom for Street Fighter V. Sony Bend are using it for a PS4 exclusive. Respawn Entertainment are also using it for TitanFall sequel. The list goes on. The code in the engine is nicely structured and very readable. The codebase might be bloated because it supports many different platforms but the engine will only be compiled for the target platform so its not a big issue. Hot code compile in the editor speeds up iteration times and the engine has a nice C++ api. Blueprints is also a nice scripting language. Though I would prefer lua.

#5293576 Are Third Party Game Engines the Future

Posted by SephireX on 26 May 2016 - 07:25 AM

Thanks for the replies. 


When I said that AAA studios would use third party engines, I meant engines like UE4, Cryengine and Lumberyard that give access to source code and I meant that these studios would modify the engines as they needed. Therefore, there would still have to be engineers on the team that can write low level engine code.There are so many parts to game engines that are common. Core utilities, maths library, memory allocation, multi-threading and resource management to name a few; that may not differ depending on the game. If every AAA game studio was building things from scratch, surely that would take more time. EA let many of their studios use the Frostbite engine. Eidos Montreal took IO Interactive's Glacier engine as a base to create the Dawn Engine. Arkane Studios' Void engine is a modified Id Tech 6. Reinventing the wheel seems counter-intuitive.


"I never want to hear that all AAA game studios have halted work on their own tech and are now exclusively using UE4/Unity/CryEngine/<Insert Generic Engine here>. I feel that would slow down the development of game tech in general and reduce the number of people who know how to code lower level tech and tools."


Third party engine developers would hire more engineers in response to greater demand. Therefore I'd imagine the number of people working on low level tech and tools would remain the same. More and more developers are using third party engines and as the companies providing them make more money, they will expand and the tools and work flow of these engines will improve beyond what internal studios can keep up with. 

#5293544 Are Third Party Game Engines the Future

Posted by SephireX on 26 May 2016 - 04:41 AM

I am a programmer who is interested in the technology used to make games. I am developing a hobbyist game engine for learning purposes and plan to use UE4 for a commercial game in the future. I am interested in the current state of the industry. Most new game studios are using Unity and UE4 and some bigger studios such as Capcom Vancouver are moving from internal tech to UE4. Indie developers that choose to create their own engines for their games always mention source control as one of the major reasons for not using a third party engine. A famous example is Jonathan Blow and I wonder is this a case of not-invented-here syndrome. I can understand programmers wanting source access and that being a valid reason not to use Unity but seeing as UE4 gives source access, I don't see how not controlling the source would be a huge inconvenience. I understand that Epic could make an update that might conflict with an engine modification the developer has made but I can't see how this would happen too often or how it could not be easily addressed by the developer. It does seem to me that developers using this excuse are picking at straws but maybe I'm wrong.


As technology improves and third party tools improve, do you think that the bigger AAA game studios that have internal engines will eventually switch to using third party engines or will the industry continue as is for the foreseeable future? 

#5172440 Using Leaked Code Derived From An Open Source Project

Posted by SephireX on 09 August 2014 - 06:09 AM

Hello there. I'm considering using an open source rendering engine as part of a game engine I wish to develop. The engine is the Geometric Tools Engine and it uses the Boost License. The engine can be found here: http://geometrictools.com. I will need to modify the rendering engine over time and make improvements. Therefore my rendering engine will be a derivative work. I am unclear about a few things when it comes to licensing. GPL requires any program using GPL code to include the copyright notice at the top of all source files and also with any binaries when the derived program is distributed. However, the Boost License is a lot less restrictive. A copy of the license does not have to be included with the executable of the derived software but must be included in the source file when the code is distributed. It also states that any code distributed alongside code covered by the license is not subject to the license's requirements. This brings me to my first question:


Assuming I want to fork the rendering engine and keep it private (which the license permits), can I also add my own copyright notice under a different license to source files in the modified engine that I add? So if I create a new class and I modify an existing class from the original code to link to it, can that new class still have my copyright under a different license? I assume the code I add to the original class cannot be licensed differently.


My second question is related to leaked code:


Let's say  I set up a company and develop software derived from software covered by the Boost License and an employee leaks the derived code. Seeing as the derived code is also covered by the Boost License, can anyone obtaining the leaked code legally use it for their own purposes? Even though it may be covered by an open source license, it was not the intention of the author for the code to be distributed.


Thanks for any answers or suggestions.