Good practices for using HAXE/OPENFL?

this is hopefully just going to be something that people could add to. but whilst using HAXE/OPENFL, and whilst i have been really REALLY enjoying it, i do run into some thing that do confuse me.
maybe its because im more used to other languages or frameworks that those are still embedded in :wink:

but my general questions is:
what would be some good programming practices to know in using HAXE/OPENFL for game development?
to start off, here are a few questions :wink:

  • when making a player, is it best to have seperate PlayerControls.hx file controls, or have them inside the Player.hx? this could really be applied to any .hx file, but player seems right :wink:
  • for things like menus. is it ok to use 1 for an entire menu, such as a front menu [not including death screens], so it controls options, settings etc. or should these be split up?
  • should keyboard contros be kept in the Main.hx, or is it good to keep these with say a player?

there were a few more but ive completely forgotten them. if anyone has any pointers to add, please do. the more the better. good for new-comers and to remind others about them :wink:
but this is just something i ask possibly with any language change and general ‘good to know’ type thing :wink:

thanks

When it comes to game development I leverage a great ECS (Entity-Component-System) framework called Ash. ECS is a data-oriented approach well suited to game architecture.

If you’re not familiar with ECS as a game development paradigm check out the following articles:
What is an entity system framework for game development?
Why use an entity system framework for game development?

1 Like

@dimumurray
wow. that looks really nice. just looked at the asteroids code on github and was blown away by how clean it was. ill give that a look.
many thanks :wink:

if anyone else has things to add. by all means please do :wink:

i guess one of the more confusing things im having trouble with personally is things like bringing controls from another class into the Main.hx
because whilst it may be the same as other languages, its the call up.

see whilst i could do an update from a class in say lua pretty easy which would hold keyboard movement in a class. i HAXE/OPENFL it seem to be very long-winded [not to say thats bad or anything, just different to waht im used to ;)]
but i would have thought say doing an onKeyDown or something, then calling up a player.onKeyDown() or something would help with movement, but doesnt. it runs, bit just doesnt work :wink:

EDIT
still getting used to it all. :wink:

I personally use two classes for input, above and beyond Player.hx.

The first class is general-purpose. It listens for key events and keeps a record of which keys are down.

The second class is game-specific. It keeps track of what each key actually does. If the player were to remap their controls, the change would happen in this class.

For instance, the Player class (or some other class) might want to know if the left key is pressed. That class calls Input.check(LEFT). Input looks up the “LEFT” array (including both the left arrow and the A key), and checks Key.isDown() for those values. If any “LEFT” key is down, it returns true.


If you need to know when a key is first pressed, make a “leftWasDown” boolean and set leftWasDown = Input.check(LEFT); at the end of each frame. If the key is down, but it wasn’t down last frame, you know it was just pressed.

Normally I’d put this in my Input class, but I didn’t have time for it during the competition, and I never got around to it afterwards.

brilliant. see i always thought should they be seperate really. just because to make it easy later on. and i would personally prefer doing that

but ill give this a good solid look thorugh.

thanks again :wink:

the other thing i have noticed quite a bit, especially with not really just big games, but really any HAXE/OPENFL, even HAXEFLIXEL ones, is that the import... seems to be the same. say:

import com.something.system.BallSack;
import com.something.system.HorseHead;
import com.something.initStuff.BallSackControl;

its not just limited to the openfl, or lime stuff, but is extended to what people are making. but they are always within folders, which are inside the source one

is this good practice to get into? i get as to why it is done. but wouldnt say just having them in one folder be ok. i kind of know what the answer will be, but have to ask these questions to to clarify :wink:
plus good just to get some form of clarity for myself :wink:

EDIT
this laguage/area is getting bigger and bigger in terms of what to know. but that is interesting me even more. opening up more possibilities :wink:

one thing that is still confusing me slightly is:
why doesnt controls that are in a Player.hx, that are set, dont work?

this is starnge since i thought that things were quite universal.

i guess for starting out right now i need baby steps per-se. but just wonder why controls in Player.hx dont work. or pretty much because i may be setting them wrong :wink:

because on trying a simple thing, such as setting controls in a player, then putting a trace on if they were pressed. it doesnt print at all. so i am obviously doing something wrong.

but from the info fed to me, there are some really nice methods to go by, but i think personally i need to keep doing baby steps and then start racking up to more hardcore things :wink:

just would like to post this video up i follwed. because while text is good to follow, or myself, being disslecik, video is just beter for me. also i can see what happening.
but this uses many of the things said so far on the post. and i can easily see where i can split the code up more depending on what i need. some things to me are still bunched up :wink: but good none-the-less

any more ideas about good practices, then by all means please post them up

EDIT
also this video just screams at how i should be using flashdevelop. just need to get a widows machnie;)

From your other thread:

That’s why.

@player_03
AH HA. so its more a safety net rather than a neccessity then?

from the looks it seems it is just so things dont clash. which is fine. but i think right now i just need to get my head round many things. then ill get on to using that more when things get bigger and bigger :wink:
but thanks for pointing that out to me :wink: