I just started porting Honor and Money to the Mac yesterday. Having not used Torque for almost a year, there have been tons of WTF moments trying to get the it working. Initially I wanted to do a straight port, but I figure I should also fix a lot problems while adding a few more features:
- Potential for Multi-player support. Right now the codebase makes many single player assumptions. I need to re-thinking and rework some of the scripts and engine code to make it ‘work’ again with networking support
- Move save system to something better the script files, probably sqlite.
- Cleanup the script. While I will never be free of it, much of the scripts have alot of junk in it. Same with the assets
- Migrate from 1.4 to 1.5.2 Torque Game Engine. I’m not even thinking of getting it on iOS at all, well unless people ask for it and it makes sense business wise. It’s a old engine, but the game itself has great art and graphics so shouldn’t need to do much but find a high quality splash screen logo;P
Working with Honor and Money has given me flashbacks on how Garage Games killed their own goose though but releasing multiple engine versions on the same platform. There was seldom an upgrade path(or it had a lot of fine print) and the convenient excuse of ‘You have source’ doesn’t go well while plowing through the code. A Game Engine is a cumbersome beasty even if you have written yourself already.I tried using Torque Game Engine Advanced, the Advance Engine they promised to develop for the longest time then they dropped it and started selling Torque3D which was their ‘new engine’. That was the last straw for me. I am sure they comforted themselves by saying that other people shipped stuff before on it which is OK if you can get support rather than step trace debugging through code to try to understand it.
Enough with the ranting…Here is the moment of Zen…1 level loaded…working but horrible hacked camera….
Game developers are fairly practical in their implementations. The most practical of Design Patterns that every game developer should understand intimately are:
- Singleton – Singletons are needed but often abused as a design pattern. A singleton is basically a class with one instance. Most prior singletons were not thread-safe but with multi-processor architectures of hardware, this should be a consideration. Singletons are common used for creating loggers, database/networking access objects.
- Factories – Factories are usually coupled with singletons. Factories are often found in resource/assset managers allow managed assets to be created. The role of a factory class is to “create objects” based on a template with specific functionality or generic
- Model-View-Controller – The Model-View-Controller is a way to separate (but not necessarily simply) functionality of complex systems. A Game Engine could use the MVC design pattern to sort out the various components into logical blocks of code. MVC is used extensively in Flex development to break up monolithic applications into manageable portions. The Model contains all data used by the application. The View is what the user sees and the Controller is Application core, responding to events from the View and coordinating resources from the Model.
I finally had enough time to look at developing on the Android platform and got my test integration of C++ code with the Android NDK working. The biggest hurdle proved to be familiarity with the Android development environment itself. The following tips apply to NDK 1.6r1:
1) You DO NOT have to have surround your functions with a various extern “C”‘s. Unlike what people are saying out there about having to do it you do not have to do it.
2) Check the names of the class to make sure the packages match your JNI interface. (i.e. if your class with the native interfaces are com.examples.HelloWorld…..your JNI class should be Java_com_examples_HelloWorld_<class>
3) Check your android.xml file for the proper package export. When you refactor/rename things in the Eclipse editor it will not update the package export. This will result in Android not being able to find your JNI interface and complain in logcat.
As of 1.6r1, the NDK is something still to play around with and not really ready for production development. That seems to be way the Google Android teams seems to like to run things. Although the OpenGL ES 1.0 libs are available, other supporting libraries are not (i.e. those to load png or jpg’s for texture. The audio libraries). My initial experiments on writing xPhone with Android has a initial platform would prove daunting to say the least.
I was checking the Google Android site and noticed that the Native Development Kit release 1 is out. The exciting part of this release, is that now we can natively write games in C++ with access to the OpenGL ES 1.1 api. This should mean that we can start looking at developing proper games on this platform. This will also mean, that I will need to figure out how to get xPhone to start compiling against the NDK. Unlike my research into Windows Mobile and it’s broken Graphics API support at this time, this means working with a 3D API versus having to support Direct Draw.
Still need to poke around it more. The bad part will probably be working via Eclipse to get things done. I already have to use 2 other IDE’s (Visual Studio and Xcode) and so a third is fairly unproductive.
I was working on integrating tinyxm into the current xPhone build to handle configuration files and was having a heck load of problems. It seems that that Windows Mobile doesn’t like it when you don’t specify the UNICODE/_UNCODE predefines and use other data types. Understandably a mobile device should Unicode ONLY targets because phones need to be able to support multiple language out of the box. Still, it didn’t help with me having to play around with compiler settings until I was blue in the face.
That’s part of challenge of cross platform development is that everything is different on different platforms even down to the way text works.
I have always had a heck of a time reading and figuring out what ‘consts’ apply to. As some of you may well know, you should try to train yourself to use const as early and often as necessary. Read more at Const Correctness to get an idea when and where to use it.
Then I found this gem while reading Scott Meyers Effective C++, hope he won’t get mad me replicating some of it here:
char *hello = “Hello World”; // non const pointer, non const data
const char* hello = “Hello World”; // Non const pointer, const data
char * const hello = “Hello World”; // const pointer, non const data
const char* const hello = “Hello World”; ///const pointer and data
Basically the idea is to draw line on the asterix. If const appear on the left on the line, what is pointed to is const. If the const appear on the right, then the pointer is const.
This is more of a note to self about how to format a C++ header file based on what I think is important:
<Public defined enums and constants>
<Public variables OR Get/Set functions. Public variables are frowned upon anyways>
<Public defined interfaces and constructors
The basic rules of thumb are:
- Public interfaces are on top because that is the first thing programmers reading your code want to know without scrolling down through the rest of the file.
- Protected interfaces follow
- Private interfaces are last (and often don’t change)
- Be consistent
- Use white spaces
- Split up constants, variables and interfaces with seperate “public/protected/privates”s