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
Tuesday, November 22, 2011
Saturday, November 12, 2011
Adobe not supporting Flash on Android and mobile devices.
It is always interesting to see how some of the larger companies move. In this article http://www.businessinsider.com/adobe-engineer-heres-why-we-killed-flash-for-mobile-2011-11 it shows that Adobe is not going to focus on supporting Flash for mobile devices. This was a hot topic between Apple and Adobe, with the iPhone not supporting Flash, but it looks like Adobe is deciding to agree.
With things like Googles Swiffy http://www.google.com/doubleclick/studio/swiffy/ which converts SWF to HTML5, it is good to see Adobe is jumping onto that and not letting Google runaway with what is still (I believe) their proprietary format. While I have not spent a lot of time working with Flash, it is still interesting to think that HTML5 will be an exact replacement for it. I think when people suggest this, they are looking at the end product, rather then the tool that Flash is (a timeline, with various tweens, staging etc). HTML5 may be able to do everything that Flash does (in terms of visuals), but the tools to create the content is what made people adopt Flash over something else (like Java Applets, or Javascript and animated .gifs).
I think Flash will still be around in some form, maybe it will create HTML5 instead of swfs, or maybe it will generate something else... time will tell if something can fill that 2D content that is relatively fast to implement on the web, but I am sure both Adobe, Google, Apple (and Microsoft) will all be playing close attention.
I am sure by the iPhone 6 there will still be something else important that separates the mobile devices :P
Cheers,
Michael Hubbard
http://michaelhubbard.ca
With things like Googles Swiffy http://www.google.com/doubleclick/studio/swiffy/ which converts SWF to HTML5, it is good to see Adobe is jumping onto that and not letting Google runaway with what is still (I believe) their proprietary format. While I have not spent a lot of time working with Flash, it is still interesting to think that HTML5 will be an exact replacement for it. I think when people suggest this, they are looking at the end product, rather then the tool that Flash is (a timeline, with various tweens, staging etc). HTML5 may be able to do everything that Flash does (in terms of visuals), but the tools to create the content is what made people adopt Flash over something else (like Java Applets, or Javascript and animated .gifs).
I think Flash will still be around in some form, maybe it will create HTML5 instead of swfs, or maybe it will generate something else... time will tell if something can fill that 2D content that is relatively fast to implement on the web, but I am sure both Adobe, Google, Apple (and Microsoft) will all be playing close attention.
I am sure by the iPhone 6 there will still be something else important that separates the mobile devices :P
Cheers,
Michael Hubbard
http://michaelhubbard.ca
Saturday, November 5, 2011
Book Review: Head First Design Patterns
Head First Design Patterns by Eric and Elisabeth Freeman is a fun read. I always was curious about what kind of content some of these books by O'Reilly that seemed so different would be like (lots of pictures, jokes, crossword puzzles etc.) but it turned out to be both entertaining and informative. The book really does try to tackle a number of important issues, and doing an "arm chair discussion" where two design patterns talk (and argue) about their differences, is both funny and some of the most useful insights into distinguishing patterns I have seen.
The Freemans really do create a useful intro to design patterns, with a number of entertaining examples that will make you enjoy reading each page, and is certainly a breath of fresh air for anyone used to very academic and "serious" books. I felt the content was great, and the format was excellent for an introduction book.
While I don't normally go for books based on Java, this was more of a theory book, and while the source code examples are in Java, it should not be difficult for anyone to follow along (outside of maybe some of the Remote Proxy examples which leverage Java's Remote Method Invocation).
The main patterns covered include: Strategy, Observer, Decorator, Factory, Singleton, Command, Adapter, Facade, Template, Iterator, Composite, State, Proxy and Compound Patterns. There is also an appendix that contains a number of other patterns. I would have prefered to have seen a chapter on Flyweight or Builder instead of Singleton, but whether or not Singleton is an Anti-Pattern is still up for debate.
One of the most interesting approaches in the book is to break apart a Model-View-Controller paradigm into separate patterns. The Model becomes and Observer pattern (allowing state information to be passed back to the View or the Controller (allowing it to be independent of the View and Controller). The View becomes a Composite (likely a collection of widgets or something similar). The Controller implements the Strategy pattern, which configures the View with a strategy and changes the state of the Model as necessary. This explanation fits well (especially the Model using an Observer) which I think is one of the nicest ways to implement the MVC design.
While I have read a few books on Design Patterns already, I think as an intro, unless you are looking for a specific language implementation or the original Design Patterns book by the Group of Four, I think this is a good intro and an overall fun read.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
The Freemans really do create a useful intro to design patterns, with a number of entertaining examples that will make you enjoy reading each page, and is certainly a breath of fresh air for anyone used to very academic and "serious" books. I felt the content was great, and the format was excellent for an introduction book.
While I don't normally go for books based on Java, this was more of a theory book, and while the source code examples are in Java, it should not be difficult for anyone to follow along (outside of maybe some of the Remote Proxy examples which leverage Java's Remote Method Invocation).
The main patterns covered include: Strategy, Observer, Decorator, Factory, Singleton, Command, Adapter, Facade, Template, Iterator, Composite, State, Proxy and Compound Patterns. There is also an appendix that contains a number of other patterns. I would have prefered to have seen a chapter on Flyweight or Builder instead of Singleton, but whether or not Singleton is an Anti-Pattern is still up for debate.
One of the most interesting approaches in the book is to break apart a Model-View-Controller paradigm into separate patterns. The Model becomes and Observer pattern (allowing state information to be passed back to the View or the Controller (allowing it to be independent of the View and Controller). The View becomes a Composite (likely a collection of widgets or something similar). The Controller implements the Strategy pattern, which configures the View with a strategy and changes the state of the Model as necessary. This explanation fits well (especially the Model using an Observer) which I think is one of the nicest ways to implement the MVC design.
While I have read a few books on Design Patterns already, I think as an intro, unless you are looking for a specific language implementation or the original Design Patterns book by the Group of Four, I think this is a good intro and an overall fun read.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
Thursday, November 3, 2011
Character Creation: How Much Customization?
In the new game trailer for Soul Calibur 5 http://www.gametrailers.com/video/character-creation-trailer/723519 they show the awesome character customization ability. This is quite well done, and while not exactly the same as something like Spore, where appendages and weight changes, it is nevertheless still quite impressive.
While it is amazing technological work for a two player game, currently this type of extreme customization wouldn't work in an MMORPG. Not to say you couldn't have customization in an MMORPG, it happens all the time, but even then 100s or 1000s of characters in a town would likely bring even the best gaming computers to a crawl as every texture and separate geometry tried to get rendered. Sure, there are tricks that can be done (different level of detail, texture resoultion sizes, combining as many pieces into a single draw call, replacing similar pieces into one piece, etc.) most of these however have the distinct chance of making all the other characters look similar and simplified (which is not what extreme customization is about).
There will likely be a time when every character, tree, rock, brick, stone and even blade of grass is unique, but until then, one of the main problems I have seen with game designers (and developers) going down the customization path is knowing where to draw the line. It is very important (crucial) to establish how much customization can be allowed by the player and whether it can be supported. If you want to go the Second Life route, you will have to make sure the engine was designed with that specifically in mind. If you find yourself worrying about how to render each character's belts, earrings, shoelaces, cufflinks, ties and shirt pins you have likely gone too far (perhaps even off the deep end).
Computer games (and graphics) are mostly a series of tricks, but you would need a whopper to trick the graphics card and cpu into rendering outrageous customizations in an MMORPG without it running like a screen saver. Still, the Soul Calibur customization sure is pretty, and it will only be a matter of time before someone tries to do that with 100s of characters (hopefully the computers in the future will be that much better).
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
While it is amazing technological work for a two player game, currently this type of extreme customization wouldn't work in an MMORPG. Not to say you couldn't have customization in an MMORPG, it happens all the time, but even then 100s or 1000s of characters in a town would likely bring even the best gaming computers to a crawl as every texture and separate geometry tried to get rendered. Sure, there are tricks that can be done (different level of detail, texture resoultion sizes, combining as many pieces into a single draw call, replacing similar pieces into one piece, etc.) most of these however have the distinct chance of making all the other characters look similar and simplified (which is not what extreme customization is about).
There will likely be a time when every character, tree, rock, brick, stone and even blade of grass is unique, but until then, one of the main problems I have seen with game designers (and developers) going down the customization path is knowing where to draw the line. It is very important (crucial) to establish how much customization can be allowed by the player and whether it can be supported. If you want to go the Second Life route, you will have to make sure the engine was designed with that specifically in mind. If you find yourself worrying about how to render each character's belts, earrings, shoelaces, cufflinks, ties and shirt pins you have likely gone too far (perhaps even off the deep end).
Computer games (and graphics) are mostly a series of tricks, but you would need a whopper to trick the graphics card and cpu into rendering outrageous customizations in an MMORPG without it running like a screen saver. Still, the Soul Calibur customization sure is pretty, and it will only be a matter of time before someone tries to do that with 100s of characters (hopefully the computers in the future will be that much better).
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
Saturday, October 15, 2011
Book Review: More Effective C++
A blast from the past More Effective C++ by Scott Meyers is not just another C++ book, but touches on a number of features and concepts that should be talked about far more than you get from most C++ books.
Some of the topics include: smart pointers, lazy evaluation, preventing resource leaks in constructors, preventing exceptions from leaving destructors, understanding the cost of exception handling, understanding the origin of temporary objects, understanding the cost of virtual functions, base classes and RTTI and more.
One part I especially liked was avoiding gratuitous default constructors. This is more of a design decision, but still a useful one, in that if member functions have to test if fields have truly been initialized it complicates the design and can lead to bugs and more complicated behaviour in handling these uninitialized classes.
Meyers talks about a number of design decisions, and side effects of going too far with overloading methods, or operator new or operator delete (and the numerous hacks and design decisions that have to be considered if you do decide to handle your own new and delete (i.e. don't do it)).
The chapter on exceptions was particularly intresting, and is probably my favorite description of exceptions:
When thinking about exceptions in this way (as something that cannot be ignored), it is a great mindset for the programmer to consider what they really consider unignorable. This is quite a bit different than return codes, or status variables, which can be ignored, although at the risk of potentially undefined behaviour. Exceptions are best used when something exceptional happens. For performance reasons, it is best to limit the usage of exceptions whenever appropriate (and exceptional).
There are also some good practical advice, such as program in the future tense. Consider how the code will grow in the future, or how it will be used. Provide complete classes, even if some parts aren't currently used. Make the class easy to use, and hard to use incorrectly. Generalize the code whenever appropriate to maximize reuse. This is not to say design and program things you aren't going to need, but rather create logically complete classes (if something can be set, it probably should also have a get, and if an entry can be added, it probably needs a way to remove that entry too).
The book even though it is not hot off the presses, still offers quite a bit of useful insight into C++ and fills a role that few books really delve into. If corners of your C++ knowledge are growing some cobwebs, this is a useful book to help dust some of them off.
Cheers,
Michael Hubbard
http://michaelhubbard.ca
Some of the topics include: smart pointers, lazy evaluation, preventing resource leaks in constructors, preventing exceptions from leaving destructors, understanding the cost of exception handling, understanding the origin of temporary objects, understanding the cost of virtual functions, base classes and RTTI and more.
One part I especially liked was avoiding gratuitous default constructors. This is more of a design decision, but still a useful one, in that if member functions have to test if fields have truly been initialized it complicates the design and can lead to bugs and more complicated behaviour in handling these uninitialized classes.
Meyers talks about a number of design decisions, and side effects of going too far with overloading methods, or operator new or operator delete (and the numerous hacks and design decisions that have to be considered if you do decide to handle your own new and delete (i.e. don't do it)).
The chapter on exceptions was particularly intresting, and is probably my favorite description of exceptions:
The addition of exceptions to C++ changes things. Profoundly. Radically. Possibly uncomfortably. The use of raw, unadorned poniters, for example, becomes risky. Opportunities for resource leaks increase in number. It becomes more difficult to write constructors and destructors that behave the way we want them to. Special care must be taken to prevent program execution from abruptly halting. Executables and libraries typically increase in size and decrease in speed... so why mess with exceptions, especially if they are problematic as I say? The answer is simple: exceptions cannot be ignored (pg 44).
When thinking about exceptions in this way (as something that cannot be ignored), it is a great mindset for the programmer to consider what they really consider unignorable. This is quite a bit different than return codes, or status variables, which can be ignored, although at the risk of potentially undefined behaviour. Exceptions are best used when something exceptional happens. For performance reasons, it is best to limit the usage of exceptions whenever appropriate (and exceptional).
There are also some good practical advice, such as program in the future tense. Consider how the code will grow in the future, or how it will be used. Provide complete classes, even if some parts aren't currently used. Make the class easy to use, and hard to use incorrectly. Generalize the code whenever appropriate to maximize reuse. This is not to say design and program things you aren't going to need, but rather create logically complete classes (if something can be set, it probably should also have a get, and if an entry can be added, it probably needs a way to remove that entry too).
The book even though it is not hot off the presses, still offers quite a bit of useful insight into C++ and fills a role that few books really delve into. If corners of your C++ knowledge are growing some cobwebs, this is a useful book to help dust some of them off.
Cheers,
Michael Hubbard
http://michaelhubbard.ca
Saturday, September 10, 2011
Book Review: Cross-Platform Development in C++
I decided to look into some more books on cross-platform work to see what more professionals were doing in this field. The book Cross-Platform Development in C++:Building Mac OS X, Linx and Windows Applications by Syd Logan, describes some of the techniques used in creating the Mozilla/Netscape browser to multiple platforms, and the challenges involved in creating such a massive project.
The basic theme of the book is abstraction, especially when dealing with low level implementation details, file I/O, threads, byte order, any platform specific code etc. Logan recommends creating factory classes that returns a concrete class implementation of an interface for these types of problems. The code should NOT be sprinkled with #if defines as it makes coding and debugging these things a nightmare as nearly every line could contain one or more #defines. Instead creating an abstract factory for returning the necessary factory and concrete implementation is essential.
In this book Logan share tips and workflow processes that allowed these projects to succeed on multiple platforms. These included having multiple experts on each of the platforms for handling, requiring developers to test on all three major platforms (Windows, Mac OS and the target flavour of Linux) before commiting to the code base. Logan also suggests another requirement is to compile with different compilers, pay attention to warnings and consider whether the native compilers for each operating system are the best approach (whichever compiler makes the most sense). One scheduling requirement was that all functionality worked on all platforms at the same time, this was essential to keeping everything working and preventing features from only being implemented on a given platform (which goes against the application being entirely cross-platform).
The book goes into quite a bit of detail on setting up Makefiles for each of the platforms using Imake and having a cross platform make system. It is also suggested to use a cross platform bug reporting system (Logan uses Bugzilla and Tinderbox since they are other Netscape/Mozilla projects). CVS is used (although Subversion is mentioned) but it is also a requirement to have cross platform tools (while also relying on Cygwin to emulate a lot of Linux tools on Windows).
There are other tips such as consider using the NSPR platform abstraction library (Netscape Portable Runtime Library), being wary of what standards floating point calculations are done, avoiding serialization of binary data (unlss you are using a convention for the data), using the limits.h for any size information (instead of using sizeof), etc.
One particularly good example in the book was related to the floating point representation:
Trixul is an interesting project and some of the functionality of a browser (like embedded Javascript to interact with the DOM) are concepts that would be interesting to apply to a game engine, although perhaps in a slightly different way. Serializing in XML for the UI is incredibly valuable, although likely something that individuals will have to write themselves (see my post on XNA Serialization for this). Trixul allows C++ components to be written that can be accessed through a Javascript component manager to extend the functionality, within the SpiderMonkey Javascript engine. I won't go into too much detail about Trixul here, but if you are interested check out the links (and the book).
All in all, I think this book gives a great insight into the complexities of cross-platform development, especially in working in a large team. I still stand by my post about indie game developers should not initially target multiple platforms: http://gameprogrammertechnicalartist.blogspot.com/2011/08/indie-multi-platform-game-development.html as the amount of effort involved in making this work, the number of experts involved and the time it takes to get just three major platforms to work can be significant. If possible try to use tools that are platform independent, and see about abstracting all platform specific code, test on all systems as you write the code, and realize this is going to take some time.
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
The basic theme of the book is abstraction, especially when dealing with low level implementation details, file I/O, threads, byte order, any platform specific code etc. Logan recommends creating factory classes that returns a concrete class implementation of an interface for these types of problems. The code should NOT be sprinkled with #if defines as it makes coding and debugging these things a nightmare as nearly every line could contain one or more #defines. Instead creating an abstract factory for returning the necessary factory and concrete implementation is essential.
In this book Logan share tips and workflow processes that allowed these projects to succeed on multiple platforms. These included having multiple experts on each of the platforms for handling, requiring developers to test on all three major platforms (Windows, Mac OS and the target flavour of Linux) before commiting to the code base. Logan also suggests another requirement is to compile with different compilers, pay attention to warnings and consider whether the native compilers for each operating system are the best approach (whichever compiler makes the most sense). One scheduling requirement was that all functionality worked on all platforms at the same time, this was essential to keeping everything working and preventing features from only being implemented on a given platform (which goes against the application being entirely cross-platform).
The book goes into quite a bit of detail on setting up Makefiles for each of the platforms using Imake and having a cross platform make system. It is also suggested to use a cross platform bug reporting system (Logan uses Bugzilla and Tinderbox since they are other Netscape/Mozilla projects). CVS is used (although Subversion is mentioned) but it is also a requirement to have cross platform tools (while also relying on Cygwin to emulate a lot of Linux tools on Windows).
There are other tips such as consider using the NSPR platform abstraction library (Netscape Portable Runtime Library), being wary of what standards floating point calculations are done, avoiding serialization of binary data (unlss you are using a convention for the data), using the limits.h for any size information (instead of using sizeof), etc.
One particularly good example in the book was related to the floating point representation:
float x = 4.0/5.0;The above example will print out "Different", since floating point expressions are evaluated to the greatest precision representation available (in this case double). The example below will print out "Same".
if (x == 4.0/5.0)
{
printf("Same\n");
}
else
{
printf("Different\n");
}
double x = 4.0/5.0;The book deals a lot with user interfaces as well (which are often a major issue with portability). Logan goes into some detail of the MVC (Model-View-Controller) paradigm, but also covers wxWidgets http://www.wxwidgets.org/, some of Netscape/Mozilla's XML-based GUI toolkit XUL https://developer.mozilla.org/En/XUL and his own open source project Trixul http://www.trixul.com/.
if (x == 4.0/5.0)
{
printf("Same\n");
}
else
{
printf("Different\n");
}
Trixul is an interesting project and some of the functionality of a browser (like embedded Javascript to interact with the DOM) are concepts that would be interesting to apply to a game engine, although perhaps in a slightly different way. Serializing in XML for the UI is incredibly valuable, although likely something that individuals will have to write themselves (see my post on XNA Serialization for this). Trixul allows C++ components to be written that can be accessed through a Javascript component manager to extend the functionality, within the SpiderMonkey Javascript engine. I won't go into too much detail about Trixul here, but if you are interested check out the links (and the book).
All in all, I think this book gives a great insight into the complexities of cross-platform development, especially in working in a large team. I still stand by my post about indie game developers should not initially target multiple platforms: http://gameprogrammertechnicalartist.blogspot.com/2011/08/indie-multi-platform-game-development.html as the amount of effort involved in making this work, the number of experts involved and the time it takes to get just three major platforms to work can be significant. If possible try to use tools that are platform independent, and see about abstracting all platform specific code, test on all systems as you write the code, and realize this is going to take some time.
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
Saturday, September 3, 2011
Coffee Break Hero 14 Day Sprint.
This is cool, a complete RPG in 14 days, with 24 hour live streaming a day, to raise money for Child's Play Charity: http://www.bigblockgames.com/games/coffeehero/challenge/
The live streams are at: http://www.twitch.tv/bigblockgames
More info on the charity is here: http://www.childsplaycharity.org/
Looks like this is shaping up quickly. They are only a few days in, but it will be interesting to see the end results.
This is a great idea for charity, and if you are reading this I'm sure they would also appreciate any donations for their game.
I look forward to seeing their end results, and hope they raise a lot.
Best of luck guys,
Michael Hubbard
http://michaelhubbard.ca
The live streams are at: http://www.twitch.tv/bigblockgames
More info on the charity is here: http://www.childsplaycharity.org/
Looks like this is shaping up quickly. They are only a few days in, but it will be interesting to see the end results.
This is a great idea for charity, and if you are reading this I'm sure they would also appreciate any donations for their game.
I look forward to seeing their end results, and hope they raise a lot.
Best of luck guys,
Michael Hubbard
http://michaelhubbard.ca
Subscribe to:
Posts (Atom)