Busy today, so so just enough time to do another screenshot. This includes the text I wrote about yesterday (though I've rewritten that code to make it more flexible), the lives indicators, and some more gameplay elements that are too complex to describe.
It's still is missing some major elements before it's really a playable game, though those in a way are the easiest bits to put in. Then lots of tweaking and improving, not least of the graphics which I've been adding to but haven't looks at changing.
Three months ago I described the class BTDText I created for Bug Tunnel Defense to replace the built-in TextField class. I used it again today to add some progress text to my game, and learned a couple of things in the process.
I wrote this shader a few days ago, but didn't want to write about it until I was able to demonstrate it working, which I did in yesterday's post. Now that's done I can describe the shader it used in more detail. It's a very simple shader, that desaturates whatever it's applied to on a scale between 0 (no effect) and 1 (greyscale).
I wrote it for this blog, but it's likely I will use it or one based on it in the future. It could be used at the end of a game or when a game is paused to indicate the game has stopped while still showing gameplay or the game state, or could be used as part of a fade-out between levels.
I wanted to write a bit more about Flash shaders, but was constrained by being unable to show my workings: I can post screenshots and could even host a working demonstration but I could not upload a shader to Wonderfl (images can be uploaded but not other data). Nor could I easily load one from elsewhere because of Flash's security model: I would need to load it from a server where I could edit the Crossdomain.xml file.
But a search of Wonderfl and a further web search turned up the solution: the data can be embedded in the source as a Base64 string.
Another screenshot, with the newest additions called at the moment 'snakes'. As always none of this is final, with the colours easily changed by changing a single line. It doesn't show any actual gameplay.
This is something I wrote for the game I'm working on but removed a few days ago as I went in a different direction in the design. As the code is fairly self-contained I thought it might be of interest.
This is a screenshot of my latest code with the Shader in effect. It's a bit of a cheat actually as I had to slow it down 10x so I could take a screenshot. Which is a way of saying a static screenshot doesn't really give an idea of how it looks in action, at 60fps with everything moving.
Also the game now uses no art assets: everything is procedurally generated. I don't rule out using art in the final game but for now it's quicker and easier to work in code where I change a few numbers to completely change the look and feel of things.
Flash has a reputation for being slow, but one I think that is largely undeserved. It is not as fast as native code but is not that far behind, and compares favourably with other interpreted cross-platform environments.
But why does it have a reputation for poor performance? I think there are a number of reasons, all of which are pitfalls developers can fall into when making Flash games. Avoid these and it becomes much easier to make games which perform well across a wide range of platforms. So what are these pitfalls?
I tried writing a shader today (Monday). Shaders have been part of Flash for a while, but as far as I know hardly any games use them. This is a shame as they can do things that are impossible in ActionScript, often with very little programming.
The half-angle formulae are formulae from trigonometry with a variety of uses. One important use is for optimising trigonometric calculations, of the sort often used in 2D geometry. In particular calculations of the form
fSin = Math.sin(fAngle);
fCos = Math.cos(fAngle);
can be done more efficiently.
