An old colleague of mine recently asked what I thought of Unity, I gave him my answer, but thought I would share part of it in the blog too. For starters I would like to say I really like Unity, and think that it is moving in a great direction, but thought I would try and give an objective view of what I see as the current status of the engine.
Unity3D is basically a good generalist indie game engine. It fills the niche of being cheap easy entry to game development for multiple platforms. However, because it is a generalist engine and does not offer the source code (without a special license) a developer has very little control over the low-level parts of the game engine, or optimizing or expanding any low-level behaviour. This can result in creating really nasty hacks in trying to get the desired functionality out of Unity, but often ends up being feasibly impossible to achieve certain things. Most games focus on what Unity does offer, and the result of this is that many games created using Unity end up looking and playing similar to other games created with Unity. Unity is constantly improving, so you may eventually see some AAA titles out there, but for now the games are mostly indie with a few slightly larger games, (although I suspect a few of the larger games have also bought the source code license) see: http://unity3d.com/gallery/made-with-unity/game-list. As for development experience, I have worked at companies that use Unity since 2007, and think that the best approach for success with Unity is to work in a very small tightly nit team of programmers and artists/designers. In this approach, the programmers create some standalone script components and the artists/designers apply these scripts to gameObjects to have them bounce around and interact with each other. The best paradigm to I can think of for Unity development is to treat Unity as a big scripting engine: you don't really run Unity, instead you write scripts that Unity runs.
Overall, I see a bright future for Unity, and think it is moving in an interesting direction. Hear is hoping of another 5 years (and more) of Unity fun.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
Showing posts with label game engine. Show all posts
Showing posts with label game engine. Show all posts
Sunday, January 8, 2012
Tuesday, November 22, 2011
Doom 3 id Tech 4 Game Engine Source Code Released
It is awesome to see the Doom 3 id Tech 4 Game Engine source code released and available at https://github.com/TTimo/doomhttp://www.blogger.com/img/blank.gif3.gpl. This does not include the Doom 3 assets, but is awesome to see all the code on GitHub.
Looking at the source code, a few similarities show up with other engines.
Curl for HTTP requests (common in a few engines).
OpenAL for audio (nice to see, also fairly common).
Ogg Vorbis format for sounds (used in a few places).
DirectX SDK requirement (for Windows).
JPEG (version 6) for images.
Some other notes at a glance:
Custom UI code.
MayaImport tools.
Tools for dialogs, material editors, particles and more.
It is awesome to see this, and many thanks to John Carmack and the id Tech team for sharing. I will definitely be looking at this further and will be anxious to see what the gaming community mods and comes up with, using this code.
I will be certain to be reading more of the code which looks in general to be of quite a high quality. There are not a lot of comments (which would be nice to have) but overall the functions and classes are clearely named and look to be a pleasure to read. Also, in a number of the external libraries are the custom documentaion, like Curl, OpenAL etc. so that is nice to see how those APIs are being used, and what else can be extended.
Lots of fun, I have been busy recently, but will certainly have to devote some time to this.
Cheers,
Michael Hubbard
http://michaelhubbard.ca
Looking at the source code, a few similarities show up with other engines.
Curl for HTTP requests (common in a few engines).
OpenAL for audio (nice to see, also fairly common).
Ogg Vorbis format for sounds (used in a few places).
DirectX SDK requirement (for Windows).
JPEG (version 6) for images.
Some other notes at a glance:
Custom UI code.
MayaImport tools.
Tools for dialogs, material editors, particles and more.
It is awesome to see this, and many thanks to John Carmack and the id Tech team for sharing. I will definitely be looking at this further and will be anxious to see what the gaming community mods and comes up with, using this code.
I will be certain to be reading more of the code which looks in general to be of quite a high quality. There are not a lot of comments (which would be nice to have) but overall the functions and classes are clearely named and look to be a pleasure to read. Also, in a number of the external libraries are the custom documentaion, like Curl, OpenAL etc. so that is nice to see how those APIs are being used, and what else can be extended.
Lots of fun, I have been busy recently, but will certainly have to devote some time to this.
Cheers,
Michael Hubbard
http://michaelhubbard.ca
Friday, January 14, 2011
Choosing a Game Engine for a Project
So, you have a new project, lots of shiny new game engines abound, but which one to choose?
Forget the marketing, forget the bells and whistles, forget the hype. Instead get down to the basics.
1. What do your people know? Learning a new engine is time consuming, and without experts there will be numerous "gotchas" that can crop up in even the most tried and tested engines (someone will say "you need to do it the ____ way"). If you have to hire new people, make sure there is a market for those and the budget to get some expert skill level. This can be the biggest hurdle, and often the reason that you may not be able to go with the newest engine. Having a good community that supports the engine is also important.
2. Does the engine do everything you need? Does it really? Really, really? Doing your homework on what the engine can and can't do comes back to the first point. If you don't know what the engine is capable of, you should reach out to as many people as possible to get real experience with that engine.
3. Look at the history of the engine. What kind of games have been created with the engine? What kind of timeline, investment and skill set did it require to accomplish this? A game engine is not going to do everything for you, and knowing what developers, level designers, pipeline and server developers need to do to interact with the engine will let you know approximately what the engine can do.
4. How "unique" is your game? This is often a deal breaker for which engine to choose. If you are trying something that has never been done before, or has a high level of customization of different parts, you will likely hit a wall (in some engines sooner than others) where completing that task the "right" way can not be accomplished because of restrictions on the APIs the game engine provides. If you need to do things like access internal buffers, memory or anything else to accomplish your task, make sure your engine supports this flexibility. Unfortunately these kinds of requirements happen too late, but being aware of these kinds of issues will help you choose a flexible engine.
5. Where (and on what) is your game going to run? If the engine does not support multiple platforms this can be a significant amount of effort to port over to other operating systems. Some things can port easier than others, but each platform that needs to be supported will complicate the code base.
6. Do you have the source code? It is great to have the source in order to control your own destiny (although be sure to read the license agreement), but some game engine source code is not meant for public consumption. Often times the internal workings of the game engine are very difficult to modify or extend, and touching one line of source code will make merging future updates to the engine from the distributor one more complex task to manage. Open source game engines are pretty good, but they are still a bit behind the leading engines.
There is no "perfect" engine, all have strengths and weaknesses, all can make great or bad games. Be careful with this decision though, as it can be one of the biggest decisions for the path and people that work on your game.
Good luck and do your homework,
Michael Hubbard
http://michaelhubbard.ca
Forget the marketing, forget the bells and whistles, forget the hype. Instead get down to the basics.
1. What do your people know? Learning a new engine is time consuming, and without experts there will be numerous "gotchas" that can crop up in even the most tried and tested engines (someone will say "you need to do it the ____ way"). If you have to hire new people, make sure there is a market for those and the budget to get some expert skill level. This can be the biggest hurdle, and often the reason that you may not be able to go with the newest engine. Having a good community that supports the engine is also important.
2. Does the engine do everything you need? Does it really? Really, really? Doing your homework on what the engine can and can't do comes back to the first point. If you don't know what the engine is capable of, you should reach out to as many people as possible to get real experience with that engine.
3. Look at the history of the engine. What kind of games have been created with the engine? What kind of timeline, investment and skill set did it require to accomplish this? A game engine is not going to do everything for you, and knowing what developers, level designers, pipeline and server developers need to do to interact with the engine will let you know approximately what the engine can do.
4. How "unique" is your game? This is often a deal breaker for which engine to choose. If you are trying something that has never been done before, or has a high level of customization of different parts, you will likely hit a wall (in some engines sooner than others) where completing that task the "right" way can not be accomplished because of restrictions on the APIs the game engine provides. If you need to do things like access internal buffers, memory or anything else to accomplish your task, make sure your engine supports this flexibility. Unfortunately these kinds of requirements happen too late, but being aware of these kinds of issues will help you choose a flexible engine.
5. Where (and on what) is your game going to run? If the engine does not support multiple platforms this can be a significant amount of effort to port over to other operating systems. Some things can port easier than others, but each platform that needs to be supported will complicate the code base.
6. Do you have the source code? It is great to have the source in order to control your own destiny (although be sure to read the license agreement), but some game engine source code is not meant for public consumption. Often times the internal workings of the game engine are very difficult to modify or extend, and touching one line of source code will make merging future updates to the engine from the distributor one more complex task to manage. Open source game engines are pretty good, but they are still a bit behind the leading engines.
There is no "perfect" engine, all have strengths and weaknesses, all can make great or bad games. Be careful with this decision though, as it can be one of the biggest decisions for the path and people that work on your game.
Good luck and do your homework,
Michael Hubbard
http://michaelhubbard.ca
Subscribe to:
Posts (Atom)