Game programming with Flex

[phyxx]

I have recently posted a new tutorial series on game programming with Flex.
http://www.brighthub.com/internet/web-development/articles/11010.aspx

It's a work in progress, so I'd appreciate any suggestions or questions you might have.

[zerosum]

Hi there,

for what it matters, I think it's really good.

I'd like to see more on using Flex to create a cool UI for the game (intro/end maybe?), but this would be icing on top of the cake

[wvxvw]

Sorry, I haven't read it all, but, there's one thing that is striking, and may probably make other readers abandon reading right after seeing the code - you do not follow the coding conventions for mx framework... From the first glance it looks like C# code...

Actually, there're more things I'd never do, and won't advise anyone doing so, like setting FPS to more than 30, using singletones etc... but, it's up to developer to decide.

[rahul_7star]

good job...keep it up..its a good start for beginner
Thanks man.:thumb:

[phyxx]

Sorry, I haven't read it all, but, there's one thing that is striking, and may probably make other readers abandon reading right after seeing the code - you do not follow the coding conventions for mx framework... From the first glance it looks like C# code...

Actually, there're more things I'd never do, and won't advise anyone doing so, like setting FPS to more than 30, using singletones etc... but, it's up to developer to decide.

Actually your right. I have come from a C++ background, and I guess that influence has stuck with me. However Flex seems to be targeted at the C#, C++, Java crowd more than traditional Flash developers, so that style seems appropriate.

[wvxvw]

Hm... I believe Flex is targeting AS coders, independent of their background (believe me, Java coder would be negative about your stile all the same) ;) Anyways, it would be a good idea to look at the conventions (http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions) (hint, hint) if you're going to write a manual... It is like talking to other people, you'd rather try to find a common language than invent your own and convince others to use it.

[phyxx]

I have read the style guide before. Actually I follow it reasonably closely, although maybe not exactly to the letter. But it has nothing to do with the usage of design patterns like a Singelton...

The usage of a Singelton class is described in the book Essential ActionScript (check out this link (http://books.google.com.au/books?id=wQlYlMuTbwYC&pg=PA381&lpg=PA381&dq=gof+actionscript+singleton&source=web&ots=f93P55n3LN&sig=yzLqkj-Glm030D67g2-iWbeUy1I&hl=en&sa=X&oi=book_result&resnum=1&ct=result#PPA381,M1)). Far from being a C# concept kludged into Actionscript, it is quite a common and accepted design pattern.

[wvxvw]

I didn't say singletone has something to do with C# specifically:) The problem with it it's considered anti-pattern (i.e. something that is rather used wrongly or for the wrong purpose even more frequently than it is used for the right thing), see this wiki page for more info:
http://en.wikipedia.org/wiki/Singleton_pattern
So it's acceptance is... at least questionable ;)

Specific things about your styling:
Constanst should be all caps, method names never stat with caps, no matter what your previous background in programming is. While many other things in conventions are questionable, these are accepted by most developers, because it makes sense for this language. Method name with the leading capital letter simply makes your code more difficult to understand (because you expect it to be a constructor).
Oh, and if I've got thus far... not calling super() explicitly is an ill-suggested practice, the same goes for imports using asteriks. First lets you avoid initializing errors, second is really helpful when you need to be sure which classes do you import.

[phyxx]

I have been a little sloppy calling super() - I'll modify the code to clean that up.

Other deviations are actually a considered choice after being part of a group of developers creating an AS program. I'll explain why.

My method names do start with a lowercase - save for the "function get" functions which are capatialised to make them distinct from a public variable. Given the constructors are always the same name as the class I have not found any confusion between a constructor and a capitalized function. (Although I did notice that the mxml file has capitalized functions. I will clean that up too.)

I have found making protected constants start with a capital, as opposed to all caps, makes them more readable while still making them distinct. I don't know about you, but TIMEBEFORELEVELSHUTDOWN is a lot harder to read for me than TimeBeforeLevelShutdown. However for constants shared between classes I do use all caps. I settled on this because it makes program wide constants (i.e. those that have to make sense to others using the class) immediately distinct from those that just have to make sense in one class. This pays off if it makes one developer think twice about modifying an all caps constant (which breaks others code) as opposed to a capitalized constant (which just breaks his own code).

While I know the standards to say not to use the import blah.*, my personal feeling is that if you are using the built in libraries there is almost zero chance of having overlapping namespaces, and the overhead of importing each individual class (and then going back and cleaning up any that aren't used) just isn't worth it. Using individual imports leads to a messy import block at the top of the class file. Ideally the developer should sync this import block up with the actual classes used. In reality looming deadlines mean that this import block is ignored in favor of getting the actual code to work.

We did discus the use of Singletons quite a bit, and there was some disagreement as to whether or nor they were necessary. In the end we decided that the extra half dozen lines of code were worth trouble as it serves as a form of self documentation. Overused or not, Singletons are widely understood, and having an Instance "function get" immediately implies that a class should not be instantiated with the new keyword.

I guess at the end of the day it is a matter of individual choice, but I have adopted these deviations from the general guide for a good reason. They have proved useful in larger projects with multiple developers.

I do appreciate the feedback though. Another set of eyes never hurts :)

[wvxvw]

It shouldn't be TIMEBEFORELEVELSHUTDOWN, it should be TIME_BEFORE_LEVEL_SHUTDOWN, and you would naturally avoid giving this long names to whatever variable just because long names are difficult to read whatever you spell them :) If you want others not be able to see / access variable inside the class - make it private, naming should remain the same.

* rule is not for preventing overlapping namespaces, it is for you to know if you import some class or not. Imagine this: you wanted to extend a class from Shape, but later switched to Bitmap, and you have a useless variable in that class that was of type Shape, but it was so long ago you just don't remember what was it used for, so you just keep it there. But, would you have classes imported as they should be, then after removing a useless import you'd realize there's some more information that needs to be removed.

Dealing with "widely understood" part :) Would you mind me giving you an example from the literature rather than programming? OK, I didn't wait for the answer :)
There is a book by Gabriel García Márquez called "Autumn of the Patriarch", and it has this passage about dictator's mother which he wanted to be recognized as a catholic saint. So, he asked for the verification from Vatican. The verification lasted for a few years, the verifier asked personally some 4-5 thousands of natives that have told him in a full belief about the miracles being performed by the supposed saint. Though, after having his verification done the appointed person declared: "yes, I did ask these thousands of people, and now I can prove every one of them lies".
I'm sorry for writing that lot, but, hope you didn't suffer :) The above just intended to show how "widely understood" may be altogether a common mistake.

For the resume: inventing your own standards is evil. See how much inconvenience MS has brought into web development by not following WC3 standards. Though I can understand your reasons for not following the standards, I can find a way for how, in your situation, you could've done the same and still follow them.
And, I'm sorry for being that negative, hope you're not offended. It's just because the Internet is full of not 100% correct and verified information that overcomplicates finding the needed and correct, and may frequently do more harm than good.
Sorry, in my real life I'm a teacher, and I can imagine how people don't like to be educated, so, again, don't take it personally, but rather try to understand that what I'm saying is for the good purpose and not for making you feel bad.

[sekasi]

wvvwvvwvvvwxxx; You apologize too much.

and I agree wholeheartedly with that last post. The MS analogy was particularly effective

[phyxx]

* rule is not for preventing overlapping namespaces, it is for you to know if you import some class or not.

I couldn't agree more. However, we simply had to address the practical reality that developers didn't maintain the import block. Five import blah.* statements was more useful to us than 20 specific (and not necessarily used) import blah.class statements.


Dealing with "widely understood" part...

The self documentation aspect of using a Singleton has been beneficial to us with no real downside. The Singleton design pattern is widely understood, though I use the term "widely" here to describe my team and those programmers I have come in contact with. I suppose I can't really speak for everyone else.


For the resume: inventing your own standards is evil...

I'd have to disagree, otherwise we would all be running DOS and programming in BASIC right now...


It's just because the Internet is full of not 100% correct and verified information

Again, I couldn't agree more. But the code I have posted does compile and do what it says it does. That outcome counts for something, right?

I see your points, and while I do see the merit of your point of view I am in the position of having to produce an end product. We take what works from the standards, and add what works for us. As for taking the decisions I have made in my job and publishing them on the web... Well, no one is being forced to read my code. But I'm sure as a teacher you can appreciate the value of thinking just a little outside the box.

[sekasi]

I'd have to disagree, otherwise we would all be running DOS and programming in BASIC right now...


Not sure why you're making a connection between good coding practice and creating easily readable code and the evolution of programming languages. If anything, they are connected in the opposite way you just suggested.

[phyxx]

I'm just saying there is more than one way to skin a cat. The established method might not be the best for every situation.

[wvxvw]

There's the difference between inventing and re-inventing :) You don't write your code in some experimental language / environment. The language and environment had it's own rules before, and they wasn't invented nor by you and neither by me. So if you write the manual to that language / environment you have to take those factors in account. Or at least make a statement about why would you disagree to use them (which is also OK, and is a way to improve the existing rules).

Even though there are lots of inventive coders, and coding itself has much to do with inventing all the time, the majority is not inventive... So, the average reader of the blog of your kind would be probably someone looking for to grab a bit of your code and paste it in his project, as long as he sees it works. Though at some later time he'd discover that the system he has built using the copy-pasted code proved to be not flexible enough (according to Murphy's law, this happens when the project is about it's deadline :) )...

Now, dealing with singletones in particular, this is only one example: the use of this pattern draw many developers away from Cairngorm (http://opensource.adobe.com/wiki/display/cairngorm/Cairngorm) project to their competitors like Mate (http://mate.riaforge.org/).

[sekasi]

I like singeltons for holding xml data.

sue me ;p

[phyxx]

This thread is getting a few views, so what does everyone else think? As a coder do you feel that the style guide linked to earlier should be used as gospel, or do slight deviations not really make that much difference? Would sticking to the style guide to the letter help you read and implement the code in the tutorials for yourself?

[justkevin]

What I look for in a tutorial is: 1) Does the tutorial clearly explain the topic it claims to cover? and 2) Does it do so using code that not only produces the desired output, but is structured in a reasonably correct way of doing so?

Following standard naming conventions is a plus, because it encourages beginners to do the same, but in terms of importance for a tutorial, it would be well below my two main criteria.

I'm just learning Flex so I can't say yet whether or not your application is written "correctly," but it is a topic I'm interested in, so I've bookmarked it.