Printable View
Hey guys,
I just whipped together a quick tutorial on one of the concepts I use when making an action type game. Just on the main class setup. Just thought it would help a few people out. Let me know it makes sense and any improvements you can suggest.
Its really aimed at a beginner with some understanding of OOP.
Thanks
heres the link: TUTORIAL: Intro to OOP game design
[h]ooligan
Great tutorial! We have to make a game in Java at Uni, and I have no experience in making games in OOP. I still make stuff the old way in Flash, by putting code in frames and such. This is just what I needed, because it still confuses me a lot :D
I love the private constructor stuff. They told us about it, and its pretty cool how you can make something with a private constructor. Its like it bends the laws of physics :p
Thanks ihoss I'm really glad it helped. Took me a while to wrap my head around OOP too. I took Java in UNI, and the project that helped me the most was creating a scientific calculator. You watch how much more you understand OOP once you finish your game.
I know I say this a lot but you should look into OOP design patterns. The private constructor thing is part of the Singelton pattern. Another good one is the Model View Controller pattern. Its easy to apply to game related situations.
Well anyway I'm glad it helped.
nice tutorial
however, can you explain the benefits of a private constructor?
seems like useless code to me. Whats wrong with
var main:Main = new Main()
you can still have a empty public constructor.
@mr_malee: your new animated avatar gives me the creeps
@ hooligan2001: will have a look at it,- but from what I saw so far I can already tell that my new AS3 style is so different from yours- maybe I can pick up some usefull techniques for me
i was reluctant to upload it, its creeping me out a little too
i was gonna go for flashing red eyes, but thats just too much
anyway...
mr_malee: Thanks, The reason you use private for the constructor is because you only want to be able to create a new Instance of the class from within it. Just trying to ensure that only one instance of main is ever created. Its more of a safe guard I think.
renderhjs: Yeah I try to adapt my java perspective on things. I think thats where I get most of my style from. How would you normally approach this in AS3?
mr_malee is your avatar trying to tell me something?
its saying:
"money", "money", "money"
or whatever you want it to say ;)
i guess I'll look more into the private constructor, I've never really thought of making the Main a safe class which exists once, i guess i've never had anyone else work on my projects before so i know if i have one instance or not.
Not sure what you mean by the object is never created, i can access the object just fine after i create it.
var main:Main = new Main()
trace(main) //object object
Sorry mr_malee, not sure if I explained properly. I use private constructor so that when ever I use new Main(); outside the class it will generate a compiler error. I then use the public method of getInstance to ensure that only one instance is created. If one exists then return that reference else create a new one. And since the function is inside the class it can create a new Main() without the compiler error. Hope that makes sense.
Now using var main:Main = new Main(); generatesPHP Code:class Main {
private function Main() {
trace("Main Created");
}
}
Code:**Error** Scene=Scene 1, layer=Layer 1, frame=1:Line 1: The member is private and cannot be accessed.
var main:Main = new Main();
Total ActionScript Errors: 1 Reported Errors: 1
Nice tutotrial man. Definitely check it out more in-depth.
Funny thing is at work I had to help build or calc. It was first big project. The thing was a $%#!@ to code. Plus it was my first experience with OOP, so I'm glad to see a OOP tut.
gotcha, still much to learn about OOP. Not really up to scratch on design patterns and things like that.
The singleton design pattern allows you to create only one copy of a class and provide consistent, global access to it. In code:
Then any class anywhere could simply go:Code:public class Engine {
private static instance:Engine;
private Engine() {
// Do all sorts of specialized construction here that can only occur once
}
public static getInstance():Engine {
if(instance == null) {
instance = new Engine();
}
return instance;
}
public useMe():Void {
// Do something uber
}
}
The advantage to this is that you don't need to pass a reference of Engine around as anyone can access it. FYI: for you Java-heads, you should really use a static initializer to do your singleton and for the C# guys, use a static readonly variable. Both of those options remove the need for you to synchronize the getInstance method.Code:var engine:Engine = Engine.getInstance();
engine.useMe();
Singleton is an evil pattern too though, very often overused. You can't extend them well for instance. And needing to use global variables is generally considered an aspect of bad code/design in the first place. Additionally, you get only one object ever. So if you have a second piece of code that could use it as well but needs to be initialized differently, you are out of luck. Finally, too many singletons in an application has a tendency to tie it all together too tightly, making it less flexible.
For a good site that lists all the original Gang of Four patterns, go here:
http://www.dofactory.com/Patterns/Patterns.aspx
MVC, which is NOT a GoF pattern can be seen in detail here:
http://java.sun.com/blueprints/patte...-detailed.html
To read about why Singletons are evil:
http://blogs.msdn.com/scottdensmore/...25/140827.aspx
http://www.softwarereality.com/design/singleton.jsp
Edit: Figures that I eat breakfast while typing my post and several others beat me to it ;)
ive been looking for a good explanation of a singletons for a while, and thank you for finally explaning it.
I got plenty of use for them, I don't care how bad they are! Many thanks!
webgeek: Thanks for the reply. Singeltons aren't always bad, for instances like mine where you absolutely cant have more then one instance of an object. Plus Singeltons are typically used in conjunction with the MVC patteren. Mainly on the Model. But that being said I have seen instances where it is over used. Thanks for the info on the design patterns. Good links.
Flashkit: Like webgeek said, don't over use them :)
Even then you just need to pass in the object to other code that needs it rather then create a singleton to do it for you. Controlling just the construction of an object can be done via packages/namespaces and using different access levels on the constructor (protected or default rather then public)Quote:
Singeltons aren't always bad, for instances like mine where you absolutely cant have more then one instance of an object.
Actually, I'd disagree a bit here. MVC is not that common of a pattern overall. You hear about it a LOT for some reason but it isn't used nearly as often as the others. It's not even one of the original design patterns from the Gang of Four which should show how common it really is. It's used quite a bit for applications as a way to bridge code and the the view layer but thats only once in an entire app while other patterns might show up all over the place.Quote:
Plus Singeltons are typically used in conjunction with the MVC patteren. Mainly on the Model.
So you saying MVC has been hyped up to seem more used then it actually is. So which are the most common types of design patterns?
It seems like that to me. A few of the Flash gurus talked about it quite a bit a few years ago (I'll leave out names here) and next thing you know, the entire Flash community uses it as the example of the most powerful design pattern ever. Personally, I'd say the most common and consequently useful patterns overall are the various factories, facade, iterator, then something like singleton and on down the list. Iterator and both types of factories are used many times in the core Java and .NET APIs yet not a single MVC pattern is used. For instance:Quote:
So you saying MVC has been hyped up to seem more used then it actually is.
http://java.sun.com/javase/6/docs/ap...erFactory.html
That is factory in use right there (not a singleton, contrary to what it looks like). Also, it uses a "protected" constructor to limit access like I described earlier.
http://java.sun.com/javase/6/docs/ap.../Iterable.html
That is an interface used to implement the "iterator" pattern. If you look at the known implementing subclasses, you can see how often it is used.
MVC is a very useful pattern in it's place but I think most people would be better off knowing the lower-level and more fundamental patterns outlined by the Gang of Four originally. Those patterns are the ones that solve every day problems while MVC solves a specific issue that doesn't come up all the time and also doesn't need to be solved that much. Many apps never need MVC at all.
Additionally, MVC is not without it's flaws. Even some of it's features are of dubious value (multiple views, substitutable user interface) in most cases. A very good overview of both the good and bad of MVC can be found here:
http://www.phpwact.org/pattern/model_view_controller
I'm not exactly sure about this, but wouldn't using _root as the main movie clip of your game allow players to pause the game by right clicking and pressing "Play?" Is that desirable?
Interesting article though.
webgeek: That last article on the MVC was a very interesting read on the pros and cons. I know see where your coming from. But the fight over which design patterns are better is an on going one. Like the fight over which Operating System is better. Its all a matter of preference.
superdezign: Thanks, Not exactly sure what you mean about the pausing? You don't have to use root as the main game holder. You have the option of creating a container and passing that as a reference, rather then the root.
Just upgraded to a new server and changed the link structure of my blog. So here is the new link to the tutorial.
Link
Sorry for the down time