The UI layout is working really nicely and the input catching and state selection is done- it just needs to fire events, but I have yet to read about the Event model in C#. I'm figuring each button will fire an ID from an event enumerator somewhere, and this ID gets passed into its constructor. Then the UI is finished- any object that is interested should be able to subscribe to that ID.
So at the moment it is looking good, you can mouseOver or click something and it will change state and the entire set of components will be re-layed out to fit around the new state. Some of the design decisions are a compromise, I did manage to get a tidier, better encapsulated structure with less transparency in earlier revisions but the code was fucking mental and order-of-operation dependent. I'm happy with this version, the only problems being that it exposes the state (previously internalised) and also exposes some redundant properties. I spent a long time trying to find a perfect solution for this but it is way beyond the scope of this game.
What remains to be done in the UI is animation- specifically tweening between states. This should be very easy to implement and means any menu should be able to intrinsically animate its state changes with zero additional code- a cool side effect of the design. I'll probably mess about with this over the next couple of days while Gary is busy with pyweek.
In other news, I am going to be splitting my time between this project and an iPhone game project with Al- looking to make some cash from the AppStore gold-rush. Don't have a mac yet but we will be writing the game engine under windows with C++ / OpenGL-ES and doing the minimal porting required to get it running on a phone later on. It's a big job- I made a solo attempt a few months back and got as far as loading PNG files into textures. The foundational work required is pretty hefty but the potential rewards are great, and I don't see the iPhone going anywhere for a while.
Subscribe to:
Post Comments (Atom)
Splitter!
ReplyDeleteSeriously though, it's good to see input working on the UI and I hope you and Al do well.
On a related note - in the latest Edge they've got a 50 best iPhone games feature, and Dan's iBomber game is in it :D
You're welcome to join the team, if you don't mind getting your hands dirty with C++.
ReplyDeleteBecause there is money involved, I have been thinking about the best way to incorporate people into the project. What I thought was that if you contribute to the engine (I called it Turbine for no particular reason), you get full rights to use and modify it on your own games without paying any royalties at all.
That way it means finances can be agreed on a per-game basis rather than the long term. The aim of Turbine is to provide a base from which a programmer could turn around an iPhone puzzle game in 3 weeks using Windows- I suppose like XNA but with animation and UI built-in.
It's tempting man. If I ever need to get a job at another games company I'm sure they'll expect me to know C++...
ReplyDeleteLol, there are about ten people in the world who KNOW C++, it's dark magic.
ReplyDeleteI find it way more fun to code in though because it is so powerful, you can do anything you want with it (although this often means using ridiculous syntax- somebody once said that C++ is an octopus made by nailing extra legs onto a dog).
Templates, operator overloading and function pointers FTW.
This comment has been removed by the author.
ReplyDeleteJust told Dan about the Edge article he was quite excited
ReplyDelete