Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Mar 2013
Offline Last Active Aug 12 2016 05:10 AM

Posts I've Made

In Topic: Are there too many Unity Developers?

26 July 2016 - 09:15 PM


Using a game engine does not just involve "drag and drop". If you want to create complicated gameplay systems, you can't do that without writing gameplay code. There can be a huge amount of programming work that goes into writing the actual game on top of the game engine. Companies hire gamplay and A.I programmers and most of the time do not require that these programmers have knowledge of engine architecture, graphics, sound or physics. Not one job posting even for a game engine developer requires that the applicant has created their own engine. Actually its better to create smaller projects that showcase knowledge of graphics or physics than to write a full game engine that involves a lot of mundane uninteresting work. I think a lot of programmers started writing their own engines (me included) a few years ago back when engines such as UE4 and Unity weren't available or as appealing as they are now. They then developed knowledge of how to create game engines and refuse out of pride (ego) to use a third party solution for their personal projects. What ends up happening is that they try to create a game with their own engine which is far inferior to the third party solutions and the game either never gets released or when it does, it pales in comparison to what it could have been if created with a third party solution. So many indie developers are looking for people that have experience with Unity to work on the client part of their game. Companies looking for engine programmers usually require that they have already worked on x amount of shipped titles. With the number of companies using Unity and UE4 now, its more beneficial to have experience working with those engines for getting into the industry. Many engine programmers become so after joining a company as a general programmer and gaining experience working on a game engine over time. 

In Topic: Physics and Sound Engine Encapsulation

05 July 2016 - 08:34 AM



I can't see how the depth buffer would store this information. What if the floor is off camera or occluded by another object?

In Topic: Physics and Sound Engine Encapsulation

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.





In Topic: Are Third Party Game Engines the Future

30 May 2016 - 01:17 PM


For AAA studios, a royalty of 5% would not be feasible. That's why Epic offer a custom license which I think is around the 1 million mark. I think they also may offer a lifetime license but probably costs a good bit more. For indies, it does make sense especially if they are strapped for cash. Unreal allows small studios to make big games and if their games are successful, they may be able to afford a custom license in the future. Not having to pay a cent for tech until you have made money is an incentive for indies to use Unreal.

In Topic: Are Third Party Game Engines the Future

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.