Well, it’s holiday time. I’m off this week and next and it’s filled up with a family union my wife and I are hosting, but I am stealing away some time now and then and my hobby time going forward with one of my dreams, building a game engine.
Of course, it’s impossible to build a game engine yourself. So instead I am putting together a number of open source pieces and integrating them. The amount of code I need to write should be pretty small but should be significant enough to help me get some real world experience using CDT. The best way to get into the mind of some one who uses your tools and understand their needs is to actually be one for a while.
The key part of the CDT angle is multi-target development. The plug-in nature of Eclipse and CDT’s support for tool chains allows it to be used to write applications for multiple platforms. In this case I’m going to do a mix of desktop and mobile featuring Windows and Linux on the desktop side and Android and eventually MeeGo on the mobile side. Android and MeeGo are particularly interesting in that I firmly believe these platforms could eventually find their way onto desktops one day. So writing a game that targets them and Windows and regular Linux desktop isn’t really that much of a stretch. (BTW, yes, I’m purposely leaving out Apple for fear of getting trapped in the “walled garden”).
For the engine components, I’m using the OGRE 3D rendering engine that is currently being ported to Android already (very cool to see). It uses freetype for fonts for displaying text and freeimage for loading images. I’ll use bullet physics for the physics engine. There doesn’t seem to be a common audio package so this may be custom per target with my own API over top. The same may be true for input, although the OGRE samples use OIS but that would need to be ported to Android.
The final piece of the puzzle will be the blender 3d editor which is going through a re-architecture right now and is extensible using python. Create your content using blender, export it with the help of python scripts and load it up into the game engine on all four platforms. Sounds like a dream that only the pros can pull off.
We’ll see how far I get. But I benefit from it in two ways – living that dream, and getting some real life experience using Eclipse for serious application development that should lead to some ideas on making it better and maybe I’ll come up with ideas for new tools. Sounds like a win-win.
As we start the discussion about CDT and e4 on the cdt-dev list, I just want to make sure people are clear when I make statements that appear anti-e4 that I’m not anti-e4. If you like e4 and you want to use it in your project, go for it. There’s some really cool things there and the guys are doing a great job of pulling it together.
But I have other important problems to solve higher up the stack than I see e4 trying to solve. In CDT-land, our biggest issue is getting people to even use Eclipse who are using emacs or vi and gdb just fine and who struggle adapting to the world of IDEs. We need to focus on enhancing the value of Eclipse and simplifying adoption to make it more appealing for these people to buy into our wares.
At the top of our list are some workflow issues and the flexible resources work that started in e4 but moved in to 3.x is a start on that. I think we still need some work on build to support multiple build configurations per project, and for build to work just as it does from the command-line. And the launch UI is over complicated for what our users need. But those things are all the platform stuff we really need. And we do have people trying to make contributions in those areas.
And, we have some things to work out in our own kitchen. We need to fix up the CDT build system so that vendors aren’t so frustrated by it that they end up writing their own. Then there’s the world of debug and systems analysis where I think we really need some innovative UI approaches. As starters, I don’t think you can visualize a massive multi-core system using a 2 dimensional UI that assumes a single context. I’d love to see something like Clutter in SWT.
So while the world is rushing towards HTML5 and the cloud, that’s great and everything, but we still have a lot of work to do to make Eclipse a great IDE on the engineer’s desktop.
This is a bit of a follow up to a blog entry done by my product manager partner in crime here at Wind River, Emeka. I spent a couple of weeks recently (in the middle of the Helios rush too) to put together a demo he is giving today at IBM’s Innovate Conference. It was great because it reminded us of what we’re really trying to do here creating IDEs using Eclipse, *Integrating* tools.
The the code in the demo is quite small but that’s a good thing thanks to good APIs. It’s a menu item associated with the editor for Wind River Workbench’s Memory Analysis database. The item takes that database and zips it up and attaches it to a newly created Work Item from IBM’s Rational Team Concert, i.e. Jazz, product. The story goes that you see a problem in the memory analysis and you want to record it for someone to look at later. And that person takes the attached zip and opens it up in the editor to start his investigation, using the other information recorded in the work item and documenting his findings there as well.
The value of the integration becomes greater than the combined value of tools that Wind River and IBM have built on their own. And that’s the promise of Eclipse and it was great to see that promise in action. But it also brought home that we don’t see that happening enough. As we solidify the platform and the first layer of tooling, we need to keep driving the solutions and build up a bigger and better stack and sell our collective customers on the value of Eclipse and the solutions we’re building for them.
A few years ago we held a PluginFest where we brought together a number of embedded tooling vendors and tried to plug and play their products. In the end, it was more to test that they co-existed with each other than anything. A few had real integrations to show. But I think we fell short of the goal and dropped the ball on the potential. Maybe it’s time to bring us back together, not to test interoperability, but to explore opportunities to build real value add integrations that we can work on together. Emeka and I and the IBM RTC gang have started down that path. Hopefully it can be used as an example of the real value of Eclipse as an IDE and rejuvenate the ecosystem a bit.
Tools is my passion, especially tools for native programming. Being a game developer wannabe, I’m especially excited when I see game developers using the tools I help build. And that’s one reason why I’m closely following and helping out with tooling for the Android Native Development Kit. There’s a great community there that could really benefit from a good CDT integration, and maybe who will come help make that integration great.
At any rate, I watched Chris Pruett’s session on Android game development from Google I/O and found it very educational. The first half was about technical details and tips behind Android game development, but the second half was just about good game development for mobile platforms. It’s a great view and I’ve embedded it at the end of this post.
The real game changer (sorry to use the pun 🙂 in my mind is the growth of app stores or markets. Pretty much every mobile platform vendor is creating some sort of one stop shopping experience for their devices and it’s a great vehicle for app developers to quickly get their wares into the hands of paying customers. And with systems like Valve’s Steam, you also get this great experience on your desktops and laptops.
The biggest advantage of markets, as Chris illustrated, is that it’s also a great way to keep in touch with your customers. Customers tend to be brutally honest about what you’ve provided them, and it’s good to get first hand looks at that feedback. And also, thanks to the markets, it’s also easy to get updates and fixes into their hands. It’s a win/win.
Anyway, it’s a great view. Take a look.
Update: The embed didn’t work very well. Just click this link instead.