C# envy: properties

Recently I found out that in c#, if you want to put a variable behind a public getter and private setter, so that it can be read but not changed, you can do it on one line! Here it is:

public int x { get; private set; }

Or if you want both public, it would be:

public int x { get; set; }

In ActionScript3 this would be:

private var _x:int;
    
public function get x():int
{
  return _x;
}
    
public function set x(_x:int):void
{
  this._x = _x;
}

The c# way is so much nicer - feature request Adobe!

A new manifesto for Flash games

Danc over at Lost Garden has just released an inspiring call to action for Flash games developers. This is probably the most important thing I have read about Flash games, ever. In it he makes a good case for something I've known for a while - that the ad-funded Flash games business model undervalues developers efforts by a factor of 100! If you don't want to read it, the jist is that indie Flash games creators need to grow a pair and start asking for some money. But I suggest you read it.

Suggestions for RSS feed of Flash game developer blogs, and a look a Yahoo! pipes

Since the excellent site FlashGameBlogs, which aggregated many developer blogs, has mysteriously stopped working, I am trying to fill the gap with a new rss feed. I'm using pipes and feedburner. Pipes is one of the most unusual pieces of software I've ever used - a visual programming environment for creating mash-ups - all running within the browser with just javascript.

Here is the feed.

Anyway, this is the call for requests. Please have a look at the feed and tell me: have I missed anyone? I'm looking for feeds of bloggers who write mostly or entirely about Flash and other web games (e.g. Unity3d) - be that coding, art, business, whatever. Comments please!

Open-source ActionScript libraries for creating Flash games

For some reason the incredible power of Open Source is on my mind today. In light of that, here are some open source(ish*) ActionScript libraries I've come across that can help you make games. I haven't tried them all, but maybe you will? *check the licenses before using.

To get code from google code you may have to use a subversion client. On PC use the free TortoiseSVN.

1. Glaze - super-fast, easy to use rigid body physics engine based on Chipmunk. Prettier syntax than box2D. Demo.
2. Box2D - uglier (sorry) syntax than Glaze, but has more features (e.g. types of joint), and is better documented.
3. PushButtonEngine - framework to build games on - doesn't do too much out of the box, but is an admirable attempt to standardise Flash game code structure. Demo.
4. Collision Detection Kit - Pixel perfect collisions in Flash!
5. Game Poetry (blog) and CheezeWorld (blog)- these excellent blogs post the source for many of their examples and tutorials on google code.
6. PixelBlitz - engine for retro -stylee games. Blurb from Photon Storm.
7. Flixel - another retro-engine. Cool Demo!
8. PaperVision3D -if you want to go into the third dimension, this is the daddy. Also check out Away3D - it has some features that haven't yet made it to PaperVision3D. Hey, different strokes for different folks!
9. Jiglib Flash - Physics in 3D!!!
10. TweenMax - since fusekit was was sadly never ported to AS3, this tweening powerhouse has taken over the whole show. Not only is it great for animating your user-interface, menus etc, I have actually built whole minigames using only this library for all movement and animation. Also gives you quick ways to adjust brightness/contrast etc of images. Only downside is that it is time-based only so won't play nicely with your game if it has a frame-based tick - but this option has been added to the beta, and as you read this is probably now in the live version. If you need frame-based tweening, you can also check out GTween, although Grant is discontinuing the project.

What have I missed? Leave comments!

Chris Hughes: "I am a liar and will do anything to become a TED fellow!"

Update: This post was written as events unfolded, and is not the whole story. TED eventually withdrew the video and interview completely, which is evidence if it were needed that the Flash developer community's anger was justified. From what I've read about Chris Hughes, he is generally a nice guy, apart from this one huge error of judgement. So I guess we should all give him a break now. I think the whole thing serves as a Faustian morality tale for the 21st century, so here's the original post anyway...

Just caught the news on twitter about a developer called Chris Hughes tacitly taking the credit for both the FLARtoolkit and PaperVision3D open source projects at TED. UnitZeroOne has already given detailed and scathing analysis of Chris Hughes, but what nobody seems to have noticed is the cheeky blurb on his twitter page...

"I'm a freethinking nerd who believes his own bullsh*t...Facts: I want to be a TED fellow."

Just from this blurb, which was presumably written before this whole debacle, you can tell it was on the cards. How that reads in the light of his talk is that he's a self-confessed bullsh*tter and is happy to use that bullsh*t to gain his coveted TED fellowship.

The bit that takes the biscuit:

"another bit of the technology that we've managed to introduce here is the ability to take existing 3D models and import them into Flash".

and from his later interview:

"And then we took the Java port and made it work in Flash."

BOOM. The other stuff you could argue either way, but that's a lie. We didn't. You didn't. Someone else did.

He basically confirms my theory on his blog.

I hope it's worth it man!

Better rollovers in PaperVision3D

I found a little perculiarity in the latest release of PaperVision3D today, and came up with a fix, so I thought I'd post it. The way it currently works, rollovers and rollouts may not be detected if you have a moving camera (which I normally do - hey it looks cooler!).

To fix, all you need to do is open org.papervision3d.core.utils.InteractiveSceneManager and delete or comment out line 236 if ( hasMouseMoved() ) in the handleMouseOver function and line 247 if( !hasMouseMoved() ) return; in the handleMouseOut function.

Now you will get nice responsive mouse events even if you have a nice drifty camera. I have tipped off Seb from the PV3D via twitter so I think those clever people are going to look into it.

By the way, if you haven't tried combining PaperVision3D with TweenMax, I highly recomend you do! I've had some freakin' incredible results that I wish I could post (but I can't).

62% of developers are using FlashDevelop? That can't be right!

That provocative title is just to draw your attention to the voting box over there in the right hand column where you can vote for your favourite ActionScript editor. As I write this, it says 62% of you are using my favourite piece of software, FlashDevelop. I don't really believe this, considering the response I got when I stated my preference for FlashDevelop over Eclipse. So vote please! The future of Flash depends upon it.

(It doesn't).

The poll is over there >>>

Unity3D hands-on first impressions

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.
• The documentation for scripting isn't that great and it's all JavaScript not C#, although all the method names are the same so it's pretty easy to convert in your head, you just can't copy paste. C# is a great language, but if you don't already know it, it might confuse you. For example you can't type "x = 1.173" if x is a float. It has to be "x = 1.173f". I have never understood this, but there you go.
• 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!

Could Flash autogenerate classes from IDE information at design-time?

UPDATE: Chalk this post up to my own ignorance - Simon Cave has pointed out that you can basically do exactly what I proposed by just exporting a swc and compiling with the FlexSDK. Obviously that has it's own advantages and disadvantages, but for the sake of this benefit I'm probably going to move over to that workflow. Here's the original post anyway....

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?

Do you extend or compose Sprite, MovieClip and DisplayObject?

I got such a great response from my last help request that I'm posting another:

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!

Game framework architecture - view components or MVC?

I have a question for my learned readers - if anyone has an answer, please leave a comment. Here it is:

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.

Creative Commons is a tease!

I think Creative Commons licensing is pretty cool. If Flickr and CC images had existed when I was at university doing interactive art projects and learning design, it would have been a massive help. But unfortunately, I think 2 factors have aligned to make it a bit useless to me. These factors are:

1. Pretty much everyone is using the non-commercial license
2. Because of things like Adsense, pretty much everything is commercial

If you post an image on your blog, and your blog has ads, that's basically a commercial use, right? If you make a Flash game with CC non-commercial artwork, you shouldn't even upload it to a portal, as the portal will sell ads around it and so make money. Look at Aral Balkan's stitch-up by Sys-Con as an example of the mess that CC can get things into. Should I even post CC images on my blog? It doesn't have ads, but isn't it kinda part of my business?

Case in point: I love this set of CC sprites by Philipp Lensenn



They are brilliant, but to describe them as FREE as is misleading, because they're under a non-commercial license. Basically they're free, as long as you don't really want to do anything with them.

What's the solution? More people should use the commercial licence. But it wouldn't really be fair to, say, make a hit game and a bunch of money without any going to the artist. A better solution - contact the copyright holder and make a deal to share the money. But that scenario is no different than if the images had no CC license at all.

My solution:

We need to come up with some kind of "revenue share" license, like the royalties radio-stations pay when they play songs on the radio. This way the artist would get a cut, but you wouldn't have to contact them BEFORE you use their work, only once the money rolls in. Would it work? Who knows, but at the moment artists like Philipp might be missing out on a chunk of change because game developers are afraid to use his sprites for fear of breaking the terms of the license.

Thankfully, most code libraries are MIT licensed, which is very permissive, so you don't run into this problem with code. And don't get me wrong - so far I haven't personally CC'd any of my own artwork, but maybe if there was the chance of getting some pocket money from it, I probably would.

Flash Games: dimensions, resolution and screen size

What's been on my mind today is the size of Flash games. Not the minutes of gameplay, number of levels or the file size, but the amount of physical screen-size the game occupies. There are 2 competing forces pulling in opposite directions here - the world of slick experiential websites as showcased by thefwa is trending towards high-resolution, full-screen, immersive experiences, and many of these sites are games. On the other hand, there is the world of game-portals and indie-developers keeping resolutions lower, where the game only occupies a part of a larger HTML layout. Here's some positives and negatives of each approach:

High Resolution (i.e. 800px+ in width, often full-browser or even full-screen)

Positives:

• More immersive.
• Occupy a decent percentage of a high-resolution monitor.
  
• More room for gameplay elements and user interface.
  
• Greater detail possible in artwork.
• Artwork right-size to port to console
  

Negatives:

• Slower performance.
• No keyboard support in full-screen before FP10.
• No room for anything else on the page.
• May not actually fit on monitors of netbooks / older computers.

Low Resolution (i.e. 400-700 pixels wide):

Positives:

• Much faster performance / less variation between new and old computers.
  
• Leaves room to sell advertising around the game (decide for yourself if this is a good thing).
• More flexibility for use on HTML pages - e.g. "Add this to my site" embedding etc.
• Pixel art looks better in low-res games.
• Artwork right-size to port to mobile / iPhone
  

Negatives:

• Games get completely lost on high-resolution monitors, especially laptops where the pixel-density can be much higher (e.g. on 15inch screen with a 1800 pixel width, the average Flash game is only a couple of inches wide)
• Less immersive, further away from the console experience

It's a tricky problem with no right answers. I think a wide-screen format of something like 760x400 works quite well across all devices and is a good compromise. I haven't checked the exact numbers, but many portals are still restricting to around 640 pixels wide, presumably so they can sell add-space around the game and maximise the number of devices that can see the content, and Kongregate needs to fit in their chat window, for example. I think this restriction is a bit of a shame.

But hold on a minute! Flash is a re-scalable technology, right? So can't we make games that work at any size? Well, yes and no. Vector graphics scale nicely, but performance suffers at higher resolution. Bitmaps scale up smoothly but aren't so great scaled down (Remember to turn allow smoothing on in your library and/or code!). For pixel art there is the option of turning smoothing off, too. There is hardware scaling on full-screen mode, but text and some graphics start to look a bit strange to me. I think the ideal situation might be to be able to build your game at 1280x720 (720p) and scale down to the correct window size. This is how XNA handles both HD and SD TVs when publishing for Xbox. I don't think the current generation of computers is quite up to this in Flash though, without hardware acceleration. In general Flash does do a much better job at upscaling than you would expect, and if you build with rescalability in mind, it's a bit more work, but you can generally pull it off. Portals should maybe start offering the option to have alternative resolutions - like Flashkit used to!

Do we mind playing tiny games on our huge monitors? Should a Flash game be thought of more like playing a gameboy or iPhone within a window than a playing a traditional PC or console game? Leave your thoughts in the comments please!

Scarygirl: a game-changing Flash game

I have a bit of an inferiority complex when it comes to Flash as a games platform. I know from experience that Flash is a great tool for creating games, but I still can't stop myself looking for the next thing: XNA, iPhone, Unity3D, etc, etc. Maybe it's the lack of joypad support, maybe its the small window size, but something about Flash games just never seems as impactful as a console. I was trying to compose these thoughts into a blog post, when Scary Girl landed in my Twitter feed (follow twitter.com/iainlobb by the way). And wow is all I can say really. This is just awesome, and proof if proof were needed that Flash is the real deal for games. So I'm going to get over my tech envy for now, and replace it with some creative envy for this game... brought to you by the Australian tax payer I believe :)

PushButton Engine - a game engine for Flash. But will anyone use it?

First off, I recommend you go over to Jeff Tunnel's blog if you want a great read about the business of independent games. Jeff knows a bit about games, having co-founded Garage Games, and his latest venture is PushButton Engine, an open source game engine / library for Flash. I had to re-read the description a couple of times to understand what they're trying to do, but basically it's an MIT licensed AS3 library with pathfinding, physics etc, that they eventually plan to make money from by selling add-ons to developers.

I've thought for a while that Flash gaming needs something like this, to make it is easier for newcomers to create more advanced games. So my first question is - who's the target market? And I guess the answer is I am, since I make my living from Flash games. But here's my problem with that idea - surely anyone who knows enough about both Flash and game development to find this project, learn the API and make a decent game can already apply these concepts through their own code? Potentially this project could save you a lot of development time (for example I wouldn't devote months to creating my own rigid body physics engine) but some of the mechanisms it includes, such as health, teams and spriting are so intrinsic to a game, that I could easily see a developer fighting against the API. There's also a multiplayer API in the works, but that market is already saturated with decent products (although I believe there's still a gap in the market for an unbranded, hosted multiplayer platform).

I'm going to give the engine a good test when I find some time, so stay tuned.