Author Topic: I'm having a heck of a time Grasping OOP with Flixel  (Read 2415 times)

Zapleaf

  • Member
  • **
  • Posts: 11
  • Karma: +0/-0
    • View Profile
I really hope I am not getting annoying with all my questions.. yet.

I've been trying to use Flixel for a while now.  I have a strong background in Coding, I started out teaching myself how to make games inside of WC3 World editor, Got excited and moved on to C++, over time I found Adobe Flash Actionscript and worked my way up to 3.0, but never in my life did I try using some one else Libraries or something like this [Flixel.]  And I am finding it very hard t apply the knowledge I have learned over the years to this.  I would love if some one could get the gears in my head working right so I can gasp how to use this to its full potential.

  • Should I make the entire game with Flixel classes?  Is it okay or wise to continue to make my own classes as I need them?
  • What happen to the parent / child concept?  I was so happy and understanding of it, there does not seem to be one in Flixel?
  • If I want to make a large scale game, say an MMO, would Flixel not be the best bet?
  • Why am I using the core trinity?  Playstate, Preloader, Main.  Is it at all possible to just make my own game, and import the parts of Flixel I need as I need them?

These are just a few examples.  A major issue that's causing me pain at the current time is understanding when and when not to use FlxGroups.  Are FlxGroups a core concept, one that I should be using when ever I want to add something to the stage?  I am also finding it very uncomforting that when I have a flxSprite (Say an option screen) over top of everything that when I click the click is registered on every FlxButton in that click ranger.  If there are buttons hidden behind the screen they too are clicked.

Really simple question, lots of reading.  Sorry, I just want to grasp the main concepts so I can get right back to work on making games like I was in Adobe Flash.

Wing Eraser

  • Guest
Re: I'm having a heck of a time Grasping OOP with Flixel
« Reply #1 on: Mon, Oct 6, 2014 »
Your questions show that you didnít fully understand how a framework/engine and OOP works.

Quote
Should I make the entire game with Flixel classes?  Is it okay or wise to continue to make my own classes as I need them?
Flixel is a game engine, you need to build your own classes that inherits flixelís classes.

Quote
What happen to the parent / child concept?  I was so happy and understanding of it, there does not seem to be one in Flixel?
Seriously, learn OOP and youíll understand how flixel works.

Quote
If I want to make a large scale game, say an MMO, would Flixel not be the best bet?
Iím afraid this is way above your head. Try something small with flixel first.

Quote
Why am I using the core trinity?  Playstate, Preloader, Main.  Is it at all possible to just make my own game, and import the parts of Flixel I need as I need them?
Again, learn OOP.

Things you need to do:
  • Learn flixel from examples.
  • Learn OOP
  • Create a simple prototype using flixel

Zapleaf

  • Member
  • **
  • Posts: 11
  • Karma: +0/-0
    • View Profile
Re: I'm having a heck of a time Grasping OOP with Flixel
« Reply #2 on: Mon, Oct 6, 2014 »
Your questions show that you didnít fully understand how a framework/engine and OOP works.
Flixel is a game engine, you need to build your own classes that inherits flixelís classes.
Seriously, learn OOP and youíll understand how flixel works.
Iím afraid this is way above your head. Try something small with flixel first.
Again, learn OOP.

Things you need to do:
  • Learn flixel from examples.
  • Learn OOP
  • Create a simple prototype using flixel

This does not help me, it feels like you're trying to insult me.  I've already made an MMO in the past with flash, a long with a game that had 200k+ plays.  I am not new to any of this.  I just never got my toes wet with a game engine before and you muttering the same words 'learn oop' does not help me in any way.

Arkeus

  • Contributor
  • ****
  • Posts: 321
  • Karma: +1/-0
    • View Profile
    • I, Arkeus
Re: I'm having a heck of a time Grasping OOP with Flixel
« Reply #3 on: Mon, Oct 6, 2014 »
I'll give this a shot.

Quote
Should I make the entire game with Flixel classes?  Is it okay or wise to continue to make my own classes as I need them?

So a good way to start out thinking about this is splitting it into three different types of classes: data, display, and utilities. One way to approach it is that anything that will represent something that will be drawn to the screen or helps describe how other things will be drawn to the screen will be something that extends a flixel class. Anything that represents data or state of your game is your own separate class. And anything that has to deal with utilities will use flixel classes directly. Utilities are something that are easy to grasp and you'll pick up quickly.

When you are doing something simple, you might have everything be considered display and have no data classes. With this, everything will extend a flixel class. For a simple platformer you might have:

Display:
The map (extends FlxTilemap or is a FlxTilemap itself)
The player, enemies, coins (extends FlxSprite)
The score (FlxText)
Health bar (extends FlxGroup and filled up with hearts that are FlxSprite)

The simpler you go the less you'll need to extend. For example, an extremely simple game might do something like:

Code: [Select]
state.player = new FlxSprite(32, 64, Resource.PLAYER_SPRITE, 12, 24);
Whereas something slight more complex might have a Player class which extends a Character class which extends a WorldObject class which extends an Entity class which extends FlxSprite.

Text, tilemaps, sprites, buttons, etc all directly have to do with drawing to the screen. Groups are used to structure how things are drawn (groups allow you to logically group sprites and other groups together, and allow you to determine which things are drawn first by putting things in a group that was added before things in another group).

When you get into more complicated things data classes become more important. For example, if you are making an rpg, you might have an NPC standing in a house. The actual display object being drawn would be something that extends from FlxSprite. It would know about the data needed to draw that sprite (which resource/bitmap is being draw, the position). However, it would also probably know about a lot of "data" type things, such as which quests the NPC can give you, what dialog they have when you talk to them (along with what triggers each different piece of dialog), and perhaps if it's a shopkeeper it would know what items they can sell you.

Each of these other things I would consider "data" and they wouldn't extend from anything in Flixel. They are simply references to information necessary in your game logic. To further elaborate on this example, you might have:

* A CharacterDatabase class which holds references to all the characters you can meet in the game. It might have a Vector.<Character> where Character is a class that has a name, a graphic, a structure containing the pieces of dialog for that character, any special attributes (are they a shopkeeping, can you recruit them to your party, etc). The database class might have helper methods that allow you to get a character by name, or by index.
* A quest log, which holds a list of quests that you are on (which point at entries in a QuestDatabase class), which can be useful when you talk to the NPC whether or not they need to advance a specific quest.
* An ItemDatabase that holds classes of type Item which contains all the data about specific items. The shopkeeper might have a ShopInventory class which has references to these items. When you create the ShopInventory, you might simple pass the names of items (for ease of development) and it will look up the items in the ItemDatabase by name, get an Item back, and create the list of items they will offer you.

All those classes would be completely separate from flixel since they are unrelated to how you are structuring your display.

The last group is simply utilities, things like sound, input, and collision are things you will directly call into Flixel for (through FlxG or FlxU for example). These are also things that, depending on your use case, you could write your own and it would interface with flixel fine. For example, Flixel has a utility function that allows you to compute the angle between two points, but if you don't like that it uses very rough estimated for constants that give you a less exact answer, you can write your own without affecting anything else. If you don't like what flixel offers in terms of sounds (perhaps you want easy control over fading different layers of music in and specific intervals, or dynamically adjusting the pitch), then you can write your own sound utilities and call those. Since these are all decoupled from how flixel displays things, there's no harm in plugging your own code in.

So overall, anything to do with drawing should be contained entirely in the Flixel system (it's really what flixel offers and you get into trouble when you go outside it), but outside of drawing you're free to build everything using your own classes.

A tiny side note on that, is that sometimes you'll need to do something outside of the flixel engine. If a sponsor wants to display a SWF animation as a splash screen, you'll need to add that outside of flixel on top of the "flixel ecosystem" and handle cleaning it up yourself. Or if you're making a 2x game and you need a 1x splash screen, you'd again have to do that outside. These things are extremely rare though.

Quote
What happen to the parent / child concept?  I was so happy and understanding of it, there does not seem to be one in Flixel?

I don't have any experience with making flash games using display lists (I'm assuming you're talking about display lists), but for the most part you can think of FlxGroups as your solution to this. Pretty much anything that you need to "add" something to will be a group. Your FlxState is already a group, and you can add things to it. There are circumstances where you have a sprite (such as a player) and later determine you want to add something like a bubble shield onto him when he collects a power up. For things like this you *could* make the player a group, but typically it's simple enough that you can attach a sprite manually to another sprite without mucking things up too badly. For example, the sprite can have a member variable of type FlxSprite that you set to a new sprite when he collects a power up. As long as it's not null, your players update function will call shield.update() and your players draw function will draw shield.draw() probably right after setting the shield's x/y to be that of the players.

Code: [Select]
If I want to make a large scale game, say an MMO, would Flixel not be the best bet?
I think a general rule to this question works for any language or library out there:

Q: Can I use X to make a large scale game.
A: As long as you're sufficiently experienced with X, yes.

For any type of large scale game, you'll find something that a library doesn't do for you, that you'll have to modify the library or implement it yourself. As long as you're comfortable enough with the library to do those things, it should work for you.

The real limiting factor of flixel is whether the performance and drawing fits your use case. For example, 3d would be a bad fit. Also, if you need something that can draw thousands of animating sprites, flixel is probably also a bad choice (and even flash in general might be). But for a non-graphically intensive mmo, I don't see anything about flixel that would prevent you from doing such a thing.

Code: [Select]
Why am I using the core trinity?  Playstate, Preloader, Main.  Is it at all possible to just make my own game, and import the parts of Flixel I need as I need them?
The whole thing with flixel is that it copies pixels from bitmaps onto a single bitmap (the "screen") and then draws that screen to the stage. There is only one Sprite in flixel which is the main screen buffer (well mostly, I think the mouse is also a sprite). If you try to go outside flixel, usually it means going outside that self contained screen buffer and adding more sprites to the stage which breaks what flixel is good at: copying pixels and drawing just that single bitmap. However, all those things about data classes being an exception still hold. But you'll want to use flx states and whatnot. If you were to try to make your own game and pull pieces of flixel in, you'd probably be better off with something else. All the most useful things (drawing, collision, etc) work on flixel objects and not on normal flash sprites.

Code: [Select]
A major issue that's causing me pain at the current time is understanding when and when not to use FlxGroups.  Are FlxGroups a core concept, one that I should be using when ever I want to add something to the stage?
In all but the simplest of games, I'd suggest building everything using a hierarchy of groups and treat them as your most important structure. A lot of beginners start by adding everything to the stage, and keeping their own references, but then they end up doing things like calling collide 50 times a frame (expensive) or doing things like colliding everything against everything which turns into a big mess of figuring out what collided with what and how you need to dispatch the collision resolution and callback.

I typically end up never adding anything that isn't a FlxGroup (or a subclass of one) to my states. An example hierarchy might be:

Code: [Select]
FlxState
|-- UI (extends FlxGroup)
|   |-- Score (isa FlxText)
|   |-- HealthBar (extends FlxGroup)
|       |-- HealthSprite (extends FlxSprite)
|-- Collideables
|   |-- Objects (isa FlxGroup)
|   |   |-- Coin x50 (extends FlxSprite)
|   |   |-- Powerup (extends FlxSprite)
|   |-- Entities (isa FlxGroup)
|       |-- Player (extends FlxSprite)
|       |-- Enemy (extends FlxSprite)
|       |-- DestroyableBlock (extends FlxSprite)
|-- World (extends FlxTilemap)
|-- Environment (extends FlxGroup)
    |-- Background x3 (extends FlxSprite)
   
The biggest things that should determine how you structure this are:

1. How and what are you going to overlap/collide
2. How do you need to handle display order

2 is mostly obvious, your UI needs to be added after everything so it's on top, your backgrounds should be at the bottom, you might want your objects on top your entities or vice versa, depending on style.

1 you quickly learn with practice. In the above example, you might have done that such that you can handle the vast majority of your interacts with a single collide (collide "entities" with "world") and a single overlap (ovelap player with collideables). That allows you to have very few collide/overlap calls, without blowing them up and having to collide and overlap everything with everything. But this will change depending on the game type and such. For example, if you were making a zelda type game, you may need to put all entities, trees, houses, etc into a single group so you can sort it each frame base on the y value (so that you appear in front of a house when below, but behind it when above). Or you can find a different way that might be more complicated but allow you to structure your groups differently.

Code: [Select]
I am also finding it very uncomforting that when I have a flxSprite (Say an option screen) over top of everything that when I click the click is registered on every FlxButton in that click ranger.  If there are buttons hidden behind the screen they too are clicked.
It might help to understand why that happens, and why it's complicated to solve it. Flixel has no event propagation, so things like clicked() and hover() are determined by whether or not your mouse coordinates are in their bounding box. They have no knowledge of whether something is above them or what, just whether the mouse is on them. Usually something like this is best solved with a "good enough" solution. Off the top of my head (this might have problems or be a terrible idea), you could do something like have the callbacks when you click something set a utility value to their actual function. So for example, the callback for all your buttons might look like "function():void { LayerHandler.clickFunction = enableSound; }" where enableSound is a function that you want to happen when you click the button. If you had multiple buttons on top each other, and clicked on them, the first one would set LayerHandler.clickFunction to its callback, then the top one would set LayerHandler.clickFunction to its callback. Then the LayerHandler actually executes it at the end of the frame before clearing it, so that it only ever executes the "top" one. You can make this work because entities in flixel are always update()'d and draw()'d in the order that you add them (taking into account recursive groups, if you add a group A after group B, everything in groupA is executed before groupB).

---

In the end, I'd suggest just practice making different types of games (different genres force you to solve things in different ways which is really useful in learning a game engine), and find open source examples to learn from if you're bored. Ludum Dare often has lots of flixel entries that are all open source so you can try there (but you have to be careful with game jam games because people are writing under the pressure of time so things might not be solved in the best way, but you can often learn neat tricks and solutions for interesting problems from them).

Hope that helps, feel free to ask if you need more clarity on any of it. :)

Zapleaf

  • Member
  • **
  • Posts: 11
  • Karma: +0/-0
    • View Profile
Re: I'm having a heck of a time Grasping OOP with Flixel
« Reply #4 on: Tue, Oct 7, 2014 »
Hope that helps, feel free to ask if you need more clarity on any of it. :)

That was absolutely mind blowing, and got my head stright.  The FlxGroup breakdown chat you made solved 90% of my hurdles right away.  I have never used a game engine before and your post really summed it up for me.  I am so excited to get started on making 'better' games now.  TYTY! :)

Wing Eraser

  • Guest
Re: I'm having a heck of a time Grasping OOP with Flixel
« Reply #5 on: Tue, Oct 7, 2014 »
The reason why I doubt your skills is because of the questions. You actually make me more in doubt with this:

Quote
I've already made an MMO in the past with flash, a long with a game that had 200k+ plays.  I am not new to any of this.

Did you make this with DisplayObject / Movieclips and timelines? I think so because you know the parent / child. I always felt a pain using this principle. It makes me stupid. I used AS2.0 all the way to 3.0 and then flixel as game engine.

If you know how to create an MMO, than you should have created something like an entity, display and classes that can be extended. A small engine only used for your MMO that is scalable. Flixel is scalable and extendable (check the homepage description ;)). Than I think you should understand flixel without sweat.

Iíve someone saying he can do OOP and the only thing he could do was extending classes. Most people didnít even read the book of Gang of Four or similar books that explain design patterns. Flixel uses design patterns, you can clearly see it in FlxGroup.

Why Iím thinking you lack OOP. Flash SDK is a framework and you inherit classes from it to build any applications with it. Flixel is an engine which is created to build games from it. Of course you can build other things too, but that is not the main purpose.
Even though you havenít use an engine before you should know this if you got the OOP skills. Base on the title of the post, I assume your OOP knowledge aren't great. OOP is generic. You can throw it to any program language. You should forget that parent / child. It's nothing than a DisplayObject that can hold other DisplayObjects. This is an AS3 class and it only confused you if you use flixel.

You couldnít get grasp with the simple basics of flixel like FlxGroup, which makes me feel uncomfortable about your skills. I feel sorry if you got insulted, but that is how I think after reading your questions and comments.

Anyway have you checked the sticky post: http://forums.flixel.org/index.php/topic,3819.0.html
FlashGameDojo (hasnít been updated for so long time): http://flashgamedojo.com/wiki/index.php?title=Category:Flixel
flixel-gdx wiki: https://github.com/flixel-gdx/flixel-gdx/wiki However not everything is relevant to flixel, just read the text and ignore the code.
How to learn flixel: http://gamedevelopment.tutsplus.com/articles/how-to-learn-flixel--gamedev-5843
« Last Edit: Tue, Oct 7, 2014 by Wing Eraser »

Zapleaf

  • Member
  • **
  • Posts: 11
  • Karma: +0/-0
    • View Profile
Re: I'm having a heck of a time Grasping OOP with Flixel
« Reply #6 on: Wed, Oct 8, 2014 »
Anyway have you checked the sticky post: http://forums.flixel.org/index.php/topic,3819.0.html
FlashGameDojo (hasnít been updated for so long time): http://flashgamedojo.com/wiki/index.php?title=Category:Flixel
flixel-gdx wiki: https://github.com/flixel-gdx/flixel-gdx/wiki However not everything is relevant to flixel, just read the text and ignore the code.
How to learn flixel: http://gamedevelopment.tutsplus.com/articles/how-to-learn-flixel--gamedev-5843

I never touch timelines.

Thank you for the links.