Anyway, opinion is not totally unanimous on this, however, as a a few people aren't so thrilled to change the name at all. As far as I understand though, the name *is* going to change, as the PHP people don't like other people using their brand. So if you care one way or the other, send an email to:
And tell them what name you want. I think the candidates so far are: INFRNO, Plash, amph, and Falcon. I'm sure they'd be open to other suggestions.
]]>"The flash development team at bbc news interactive (which i am a part of) is planning to release the component set we currently work with on our interactive content. This will be on external website(s) such as macromedia exchange, but the release will be under GPL license, and will cost absolutely nothing!! Not only that, but we will be supplying FULL flash documentation and diagrammatic uml of ALL classes and structures, again, completely free of charge. The component set is called smx, and feature highlights include Proper Re-skinning (ie. all components, all elements, all from the same base classes, all from library objects that follow the same rules, etc etc), Properly Functioning Livepreviews, compatible with Flash 6 AND Flash 7, Optimisations to provide the same functionality of mx components in ~a quarter of the filesize with ~double the speed, DataComponents like XmlLoader and NodeBinder that are much more streamlined than their mx counterparts whil retaining the same functionality, and useful standard components such as tabpanel and slider that are still (amazingly) omitted from the basic mx set. "You can read the full text of Rob's email here. It sounds like a very promising prospect, and knowing the BBC, there's going to be lots of good documentation. I wonder though - if you haven't paid your TV licence, can they stop you using these components?]]>
There is talk of forming a Game Developer's union, not to mention countless op-ed pieces on how to turn out a games project on schedule without losing half your developers in the process. I don't know how, but I think it's definitely time for something to change. I've eperienced long working hours on both games and web projects, and it's true that working later and harder on projects is a fact of life in creative industries - however, EA's alleged approach of a scheduled, unending crunch has got to be a sure way of destroying some of the games industry's best talent. If I had to work 12 hours a day, seven days a week, that career in carpentry would start to look damned attractive...
I, for one, am not going to be buying any EA games in the foreseeable future - and it's been a long time since I've used any of their graphics applications...
]]>"The root of all evil is the heart of a black soul, A force that has lived all eternity. A never ending search for a truth never told, The loss of all hope and your dignity."I must admit that I hate _root. It's almost always used to get around some crazy scope problem or other, and it usually makes it really hard to figure out what's going on in someone else's code when it uses _root.something() all over the place. For me, using _root is like admitting failure.
import MyMuchBetterRoot;
betterRoot = new MyMuchBetterRoot(this);
__resolve = function (name) {
//if you wanted to monitor all the calls to _root, you could do so here
trace("resolving "+name);
var f:Function = function () {
betterRoot[name].apply(this,arguments);
};
return f;
}
In the class MyMuchBetterRoot.as:
class MyMuchBetterRoot extends MovieClip{
//pass in and store a reference to _root, in case
//you need to get to it later
private var rootRef :MovieClip;
public function MyMuchBetterRoot(rootRef){
trace("I am a much better root than "+rootRef);
this.rootRef = rootRef;
}
//random test method
public function helloWorld(foo, bar){
trace("Hello World");
trace("foo="+foo);
trace("bar="+bar);
rootRef.foo = foo;
rootRef.bar = bar;
}
public function __resolve(name){
//if a method doesn't exist in the class, trace out an error
trace("ERROR:Function "+name+" does not exist.");
}
}
You then move all the _root methods into MyMuchBetterRoot.as, and let the rest of the movie call non-existant functions on _root. These calls will automatically get re-routed to the class, or, if they're referring to functions that don't exist, you'll get an error trace, with the name of the function you're calling.
This means you get the best of both worlds - you can have methods on the root, but still have them in an AS2 class, and you can also track those pesky calls to _root, and possibly figure out where they're coming from. Although if I can, I usually avoid using _root altogether, I'll definitely be using this method again.]]>Anyway, the list page is here, we'll see if anyone signs up to it.
]]>They're in flash fomat, just unzip the files and open the html page. Not sure how much sense they'll make by themselves, but there's some interesting stuff in there.
]]>Here's a demo: this demonstrates the usefulness of tree based collision detection (which gameframe makes it really easy to implement) - you can have a large number of sprites on screen at once, all moving independantly and reacting to collisions - with only a small drop in performance. This is it the expense of a small amount of accuracy, but for most games this will be good enough. I'm thinking arcade style shoot-em ups, that sort of thing. Anyway, this demo has 30 enemy sprites, and one hero sprite, moving around freely in 2 dimensions. As you can see, it performs pretty well. I'm pretty happy with the collision reactions, which I just got working tonight, thanks to Jobe Makar's Macromedia Flash MX 2004 Game Design Demystified. Anyway, check it out, let me know what you think.
Instructions: Note - this is not really a game. Just move the black square around with the arrow keys and bash into the other squares. Refresh the page to start again.
View GAMEFRAME collision demo
Mathematics For Game Developers is a really unique book. It approaches mathematical subjects from the perspective of the game developer - while still staying in-depth and accurate enough to satisfy the more mathematically minded. It covers all the essential topics - vectors, matrices,physics, calculus, manipulating equations - and it relates them directly to their applications in games programming. It introduces topics one by one, and builds upon existing knowledge - however, it's also accessible enough that you can just dip into a random chapter and not be too lost. More complex algorithmic subjects like collision detection and space partitioning are covered later on, and these topics are all handled very well. The solutions the book provides are mostly in the form of equations, so you'll need to do a little work converting them to code, but all in all I think you'll find the book invaluable. The section on space partitioning is excellent, as is its coverage of understanding lines - a topic usually skipped by math authors as it's supposedly an 'elementary' problem - however the limitations of the conventional y=mx+b approach are explored and worked around in one of the early chapters.
There is so much unique and useful information in this book, and it is presented in such an accessible way, I'd definitely recommend it to anyone who is interested in games development. A basic high school maths knowledge is assumed, but it could be read in parallel with a more conventional book to cover or revise the math basics.
The only things that count against it are the contents of the CD - no Maple evaluation (possibly not the publisher's fault), and the code samples are a little lacking - absolutely no sample code for collision detection? Unacceptable. There are also some minor typographical errors in one or two of the proofs/expansions, but nothing fatal.
Overall, a great, accessible, knowledgable book, which should find a prominent place in any serious game developer's library.
London MMUG (formerly mmug.co.uk) now have a new website, it's at:
LondonMMUG.org.
The meeting is at 6.30pm on Spetember the 18th, doors open 6.00pm.
The details can be found here. Don't forget to register! Hope to see you there!
]]>