Friday, 22 May 2009
The poll is over there >>>
Monday, 18 May 2009
Today I got together with my buddy Adrian who is a big-shot special effects guy, with the aim of trying to punch through the Unity3D learning curve and get some kind of game going. (Adrian is using the Mac in the photo, and for fairness I should point out that he was pulling that face as a joke). Adrian does Maya so he was able to grok the Unity IDE much quicker than me, as there are a lot of keyboard shortcuts you need to know (e.g. press "F" to focus the IDE on a selected object). I, on the other hand, had installed Visual Studio C# Express, so I had intellisense for coding :)
Here is my effort - MatrixPong. I had intended to post the actual game, but it crashes Firefox (see below), so I thought I'd give it a miss. All in all it was a very worthwhile session, and here's what I learned:
- You really do need to learn the Unity IDE shortcuts, e.g. Q, W, E & R to switch between tools, F to focus on the selected object, ALT-DRAG to rotate camera around object, drag with right button to point camera.
- We could find no way to look through our camera in the scene view which was annoying.
- If you edit the scene while you have the game running or paused, as soon as you stop it reverts all the changes you made. This is a massive gotcha and you can lose a few minutes work every time you forget your game is running.
- Errors in you game can easily crash the Unity IDE and the browser plug-in. In fact they don't even have to be code errors. For example, in MatrixPong, when the ball goes off the edge of the playing surface, it will fall with gravity for about 10 seconds, then when its position reaches a big number (e.g. y = -1000000000) everything suddenly crashes. For a Flash guy this is a real WTF. Imagine if setting your movieclip too far off the stage crashed the browser!
- You get loads of stuff "for free" in Unity, most importantly collision detection and physics - this is a big advantage over the other 3D game development framework I have played with, Microsoft XNA.
- Thanks to Lucas Meijer I was able to set up Unity3D code completion in Visual Studio. Very cool.
- Everything in Unity3D C# extends MonoBehaviour and relies on overriding a bunch of event functions, e.g. Update and OnCollisionEnter. You don't actually use an override keyword though which makes it hard to know from example code whether functions are built-in or not. I couldn't find a good way to get a list of these functions while typing code though, I had to look them up from the website.
- MonoBehaviour has tons of stuff in it and I only scratched the surface of what it can do.
- There's also a big global god object called GameObject where you can find things from your scene. There are lots of global, not very OOP things in Unity. Get over it!
- Pointless observation: MonoBehaviour has a British spelling for behaviour, the first British spelling I have ever seen in a language API.
- I created 3 scripts - PongBall.cs, PongPaddle.cs and PongAI.cs. Each script was only about 5-10 lines of code, but that was enough to get the ball bouncing back and forth, the AI paddle following it and the player paddle controlled via keyboard. You drag these behaviours onto your game objects rather than having game objects that extend them. Objects have scripts rather than are scripts like they would be in Flash. Basically it's like Director, but in a good way.
- To devote the necessary time to get really into Unity I would need a paying gig, so could someone please hire me to make something with it? Thanks!
Friday, 15 May 2009
Here's a "what if" post for any developer who works with the Flash IDE. Something that often bugs me is that when you want to access DisplayObjects which have been placed on the timeline of a MovieClip, you don't know what DisplayObjects are there, or their type. For example, say you have an animation, and nested 3 MovieClips deep in the animation is a "hand" MovieClip. You can access the clip with "throwAnimation.leftArm.hand", but while you are developing you can't be sure that this path actually exists, and you won't know the type of "hand". If you want to call a function in hand, you might end up doing something like: "Hand(throwAnimation.leftArm.hand).closeFist()". It works, but again you don't know while you're typing that "hand" actually is an instance of the Hand class.
One solution might be to create a ThrowAnimation class, an Arm class and a Hand class and set the linkages of each MovieClip in the library. These classes would simply contain public variables for the DisplayObjects they contain. Then you can happily type: "throwAnimation." (hit CTRL-SPACE in Eclipse) and your code editor will give you a drop-down menu showing all the variables of throwAnimation, including leftArm, hit ENTER and then get a list of leftArm's properties, including hand. The only downside is, you have to create 2 more classes just to get autocompletion.
Thinking back to my days doing Visual Basic, I think I remember that it autogenerated some code every time you added a button to the design view. Flash just needs to do the same thing. Think about it - all the information it needs is right there to autogenerate classes which know what DisplayObjects they contain and their type. It can get the instance names from the stage and the type from the Library. Then we happily know while we code that we are accessing DisplayObjects that exist. I think this is basically the same idea behind MXML and XAML - so maybe what we need is a just an XML-driven FLA format in CS5? Any thoughts?
Tuesday, 5 May 2009
On my journey to try and be a better developer, I'm questioning some of the fundamental ways I work and organise code. Like most Flash developers (I think), I normally extend Sprite or MovieClip when I want to control something on the stage. But would I be better off creating a class that composes (i.e. controls via a reference) a Sprite or MovieClip instead? What are the advantages and disadvantages? Which are you doing? Leave comments please!
Monday, 4 May 2009
I'm trying to build a very light reusable framework for my games, rather than starting from scratch each time I start a game. I have a component driven architecture - e.g. Entity model composes a Position component, a Health component, an Ai component, etc.
My big question is whether my model composes view components to allow for more than one view of the model, or whether to use a truer MVC where the model does not know about its views, and they are managed externally.
I have tried both methods but if anyone knows the pros and cons of each approach and which is the industry standard, it would be great to know. I'd particularly like to hear from people who have tried both methods.