00:00
00:00
Newgrounds Background Image Theme

BUNKUMBITCH just joined the crew!

We need you on the team, too.

Support Newgrounds and get tons of perks for just $2.99!

Create a Free Account and then..

Become a Supporter!

HaxeFlixel Jam Thread

2,796 Views | 33 Replies
New Topic Respond to this Topic

Talk about the game ideas, talk about HaxeFlixel, ask for help. Talk about anything related to the jam, here.


Links:

Original NG News Post about the jam

HaxeFlixel + OpenFL + Haxe

Getting Started

Ogmo 3 Editor

Command Line Basics


Haxe Discord

Newgrounds Discord


Also, you don't need to direct all HF and jam related questions to this thread. You can make a new thread if you want. I just thought this might encourage collaboration and communication

Response to HaxeFlixel Jam Thread 2020-03-27 17:47:34


i lov haxeflixel


sicko mode

BBS Signature

Response to HaxeFlixel Jam Thread 2020-04-01 09:14:04


What's the appropriate dimensions for displaying game content on NG? I've been playing around with 16:9 (1600x900 or greater).


I also appreciated the haxeflixel demos for code snippets beyond the top/down RPG example.

Response to HaxeFlixel Jam Thread 2020-04-01 09:43:13


At 4/1/20 09:14 AM, catproX wrote: What's the appropriate dimensions for displaying game content on NG? I've been playing around with 16:9 (1600x900 or greater).


1600x900 might be too big for some people. I looks up some stats and it looks like 75% of people wouldn't be able to play a 1600x900 game (of course, I don't know what percentage of these devices are owned by gamers). I recommend something around 960x540 and adding a fullscreen button that will scale up the game (which is pretty easy in flixel). you'd probably be safe with 1024x576 too but I've never tried that.

Response to HaxeFlixel Jam Thread 2020-04-02 10:45:42


At 4/1/20 09:43 AM, GeoKureli wrote:
At 4/1/20 09:14 AM, catproX wrote: What's the appropriate dimensions for displaying game content on NG? I've been playing around with 16:9 (1600x900 or greater).
1600x900 might be too big for some people. I looks up some stats and it looks like 75% of people wouldn't be able to play a 1600x900 game (of course, I don't know what percentage of these devices are owned by gamers). I recommend something around 960x540 and adding a fullscreen button that will scale up the game (which is pretty easy in flixel). you'd probably be safe with 1024x576 too but I've never tried that.


Excellent, thanks. I was looking at staying 16:9, but this will be a learning point with flixel. I've been using Godot lately and really enjoy it. I'm using this game jam to kick the tires and test drive flixel.

Response to HaxeFlixel Jam Thread 2020-04-02 16:17:34


At 4/2/20 10:45 AM, catproX wrote: Excellent, thanks. I was looking at staying 16:9, but this will be a learning point with flixel. I've been using Godot lately and really enjoy it. I'm using this game jam to kick the tires and test drive flixel.


Both 960x540 and 1024x576 are 16:9

Response to HaxeFlixel Jam Thread 2020-04-02 19:39:23


Is there a way to install Ogmo3 in Ubuntu?

I managed to go through a few Haxe tutorials but I seem to have hit a brick wall here.

Response to HaxeFlixel Jam Thread 2020-04-02 20:04:23


At 4/2/20 07:39 PM, primakrazy wrote: Is there a way to install Ogmo3 in Ubuntu?
I managed to go through a few Haxe tutorials but I seem to have hit a brick wall here.


Yes, on their download page (https://ogmoeditor.itch.io/editor) there is a link to a Linux binaries. I looked through it and didn't see a dpkg file for installation, so you may have to install it manually. If that doesn't work you could probably do the same thing with Tiled map editor (https://www.mapeditor.org/), which looks like it may support package install via apt-get. There are examples of loading Tiled maps on the haxe site.

Response to HaxeFlixel Jam Thread 2020-04-02 20:05:06


At 4/2/20 04:17 PM, GeoKureli wrote:
At 4/2/20 10:45 AM, catproX wrote: Excellent, thanks. I was looking at staying 16:9, but this will be a learning point with flixel. I've been using Godot lately and really enjoy it. I'm using this game jam to kick the tires and test drive flixel.
Both 960x540 and 1024x576 are 16:9


Even better!

Response to HaxeFlixel Jam Thread 2020-04-02 21:32:35


At 4/2/20 08:04 PM, catproX wrote:
At 4/2/20 07:39 PM, primakrazy wrote: Is there a way to install Ogmo3 in Ubuntu?
I managed to go through a few Haxe tutorials but I seem to have hit a brick wall here.
Yes, on their download page (https://ogmoeditor.itch.io/editor) there is a link to a Linux binaries. I looked through it and didn't see a dpkg file for installation, so you may have to install it manually. If that doesn't work you could probably do the same thing with Tiled map editor (https://www.mapeditor.org/), which looks like it may support package install via apt-get. There are examples of loading Tiled maps on the haxe site.


I saw the files on the itch.io page. It's odd that they have it in a zip file. Figuring out how to manually install it is a pain.

I'll also check out this mapeditor tool as well. Always looking for more tools to play with.


Thanks for the response. :)

Response to HaxeFlixel Jam Thread 2020-04-04 09:43:04


What is the best practice for detecting a gamepad on start? The examples I've seen use FlxG.gamepads.lastActive but seems error if the user hasn't interacted with the device first before making checks.


Thanks in advance.

Response to HaxeFlixel Jam Thread 2020-04-04 12:56:04


At 4/4/20 09:43 AM, catproX wrote: What is the best practice for detecting a gamepad on start? The examples I've seen use FlxG.gamepads.lastActive but seems error if the user hasn't interacted with the device first before making checks.

Thanks in advance.


I usually just check

if (FlxG.gamepads.numActiveGamepads > 0)
{
    var gamepad = FlxG.gamepads.lastActive;
    // check pad stuff here
}

Response to HaxeFlixel Jam Thread 2020-04-04 18:38:19


At 4/4/20 12:56 PM, GeoKureli wrote:
At 4/4/20 09:43 AM, catproX wrote: What is the best practice for detecting a gamepad on start? The examples I've seen use FlxG.gamepads.lastActive but seems error if the user hasn't interacted with the device first before making checks.

Thanks in advance.
I usually just check


Awesome, thanks!

Response to HaxeFlixel Jam Thread 2020-04-04 21:03:40


What sprite generation software do you guys use? My sprites are hand drawn don't fall within perfect dimensions. I'm playing around with TexturePacker and it looks like it supports it.

Response to HaxeFlixel Jam Thread 2020-04-05 01:23:44


At 4/4/20 09:03 PM, catproX wrote: What sprite generation software do you guys use? My sprites are hand drawn don't fall within perfect dimensions. I'm playing around with TexturePacker and it looks like it supports it.


I stan TexturePacker.

Response to HaxeFlixel Jam Thread 2020-04-05 19:22:36 (edited 2020-04-05 19:25:28)


My apologies for asking a lot of questions, but I'm new to haxeflixel.


Is there a way to set the size of the collision box? It seems like much of the characters graphical space and the hit box are one in the same. I did see a method for updating the hitbox if you scale the sprite, but that seems different than having a hitbox smaller than the view-able graphical area.


If this is not the case, I may have to rethink and simplify my character composition and keep it in a more defined "squared" space.


For example, I've been playing around with this gun-toting-plague-doctor character that I've created for the game jam.


iu_107720_156788.jpg


But the collision doesn't seem to line up properly with the hand drawn frames within the sprite. In Godot, I would set a collision shape (such as a capsule) and align it center of the sprite. Extra graphical bits, like the gun, wouldn't count regarding collision.


I'm also fairly new to TexturePacker, I might be missing something in the spritesheet/atlas publish settings.


Let me know if I'm missing something.


Thanks in advance!

Response to HaxeFlixel Jam Thread 2020-04-06 11:03:54 (edited 2020-04-06 11:09:04)


At 4/5/20 07:22 PM, catproX wrote: My apologies for asking a lot of questions, but I'm new to haxeflixel.

No worries, I'm happy to help!


Is there a way to set the size of the collision box? It seems like much of the characters graphical space and the hit box are one in the same. I did see a method for updating the hitbox if you scale the sprite, but that seems different than having a hitbox smaller than the view-able graphical area.

If this is not the case, I may have to rethink and simplify my character composition and keep it in a more defined "squared" space.

For example, I've been playing around with this gun-toting-plague-doctor character that I've created for the game jam.

But the collision doesn't seem to line up properly with the hand drawn frames within the sprite. In Godot, I would set a collision shape (such as a capsule) and align it center of the sprite. Extra graphical bits, like the gun, wouldn't count regarding collision.


When a FlxSprite's graphic/animation is changed it automatically sets the hitbox to that graphics frame size. you can override this by editing the width, height and offset properties. For example, if you loaded in a 32x32 graphic but want a 16x16 hitbox aligned to the bottom-center of the graphic you would do:

sprite.width = 16;
sprite.height = 16;
sprite.offset.set(8,16);
// alternatively:
// sprite.offset.x = 8;
// sprite.offset.y = 16;

and while flixel is very heavily geared towards square hitboxes (in fact, it doesn't have other shapes available out-of-box), this is surprisingly less limiting than one would think for most action games. Yes, you may need to fit your graphic to a more sqaure-ish shape, but there are other options.


You can specify a notify callback and process callback to FlxG.overlap to perform advanced checks, like if you want something to be a circle, you can do


FlxG.overlap(myCircle, circleKillerGroup, 
    function circleNotifyCallback(circle:FlxSprite, killer:FlxSprite):Void
    {
        trace('$circle hit $killer');
    },
    function circleProcessCallback(circle:FlxSprite, killer:FlxSprite):Bool
    {
        var cRad = circle.width / 2;
        var kRad = killer.width / 2;
        var distance = FlxVector.get(circle.x, circle.y).subtract(killer.x, killer.y);
        var distanceSqruared = distance.lengthSqaured;
        distanceV.put();
        return distanceSqruared < cRad*cRad + kRad*kRad;
    }
);

Aditionally you use multiple hitboxes per object. often I'll set my player's sprite's hitbox for level collision but give it's class FlxObject properties like attackBox and hurtBox and use them via:


if (player.attacking)
    FlxG.overlap(player.attack, attackableGroup, onPunchEnemy);

you can have as many hitboxes per sprite as you feel

iu_107856_488329.jpg


I'm also fairly new to TexturePacker, I might be missing something in the spritesheet/atlas publish settings.


I just use uniformly spaced spritesheets, because I think it's beneficial to the player to have blocky sprites with matching hitboxes


Edit: didn't realize Flixel could use non-uniform spritesheet's. i've removed the bottom of this post where I say otherwise

Response to HaxeFlixel Jam Thread 2020-04-07 21:10:51


Is there a best practice for checking collision detection with another object during the animation.


I'm using FSM with a punch state, and I was thinking about checking if the animation is on a frame, then do the collision check. My state below for reference. Thoughts?


class Punch extends FlxFSMState<FlxSprite>
{


    override public function enter(owner:FlxSprite, fsm:FlxFSM<FlxSprite>):Void
        {
                owner.animation.play("smash");
        }
    override public function update(elapsed:Float, owner:FlxSprite, fsm:FlxFSM<FlxSprite>):Void
    {
        trace(owner.animation.frameIndex);
        if(owner.animation.frameIndex == 7)
        {
            trace("check for collision");
        }
    }
}

Response to HaxeFlixel Jam Thread 2020-04-08 14:03:01


At 4/7/20 09:10 PM, catproX wrote: Is there a best practice for checking collision detection with another object during the animation.

I'm using FSM with a punch state, and I was thinking about checking if the animation is on a frame, then do the collision check. My state below for reference. Thoughts?


typically my collision happens in the FlxState's update method, I would make it so the FlxState can tell whether conditions were right to do a collision check and perform the FlxG.overlap check. in your case I would give the owner a punchBox:FlxObject (that is positioned relative to the owner when it moves), check the animation frame to determine whether the punchBox is solid and then have the FlxState check overlaps between the punchBox and the punchable group whenever punchBox.solid == true


The reason I do checks in the FlxState is just to avoid circular references between colliding objects, if that isn't a concern than there are various other places you can do the actual check

Response to HaxeFlixel Jam Thread 2020-04-08 23:22:01 (edited 2020-04-08 23:23:02)


At 4/8/20 02:03 PM, GeoKureli wrote:
At 4/7/20 09:10 PM, catproX wrote: Is there a best practice for checking collision detection with another object during the animation.

I'm using FSM with a punch state, and I was thinking about checking if the animation is on a frame, then do the collision check. My state below for reference. Thoughts?
typically my collision happens in the FlxState's update method, I would make it so the FlxState can tell whether conditions were right to do a collision check and perform the FlxG.overlap check. in your case I would give the owner a punchBox:FlxObject (that is positioned relative to the owner when it moves), check the animation frame to determine whether the punchBox is solid and then have the FlxState check overlaps between the punchBox and the punchable group whenever punchBox.solid == true

The reason I do checks in the FlxState is just to avoid circular references between colliding objects, if that isn't a concern than there are various other places you can do the actual check


Excellent, thanks. I've partially implemented this approach. I have collision checks in main PlayState, then update the object when it occurs. I still haven't implemented a new hitbox for the player, but will take a look at it over the next few days. I'm currently accomplishing the task by checking the animation frame only and the collision checking with the FlxSprite of player.


On a different note, I can't for the life of me understand why my enemy sprite doesn't align to the ground (see image below). In the idle state it works appropriately, but when the death animation is triggered it looks like its floating. I'm using texture packer and I've aligned the center points to bottom/center (if that maters). Any input would greatly be appreciated. Thanks!


iu_108880_156788.png

Response to HaxeFlixel Jam Thread 2020-04-09 09:10:38


At 4/8/20 11:22 PM, catproX wrote:
At 4/8/20 02:03 PM, GeoKureli wrote:
At 4/7/20 09:10 PM, catproX wrote: Is there a best practice for checking collision detection with another object during the animation.

I'm using FSM with a punch state, and I was thinking about checking if the animation is on a frame, then do the collision check. My state below for reference. Thoughts?
typically my collision happens in the FlxState's update method, I would make it so the FlxState can tell whether conditions were right to do a collision check and perform the FlxG.overlap check. in your case I would give the owner a punchBox:FlxObject (that is positioned relative to the owner when it moves), check the animation frame to determine whether the punchBox is solid and then have the FlxState check overlaps between the punchBox and the punchable group whenever punchBox.solid == true

The reason I do checks in the FlxState is just to avoid circular references between colliding objects, if that isn't a concern than there are various other places you can do the actual check
Excellent, thanks. I've partially implemented this approach. I have collision checks in main PlayState, then update the object when it occurs. I still haven't implemented a new hitbox for the player, but will take a look at it over the next few days. I'm currently accomplishing the task by checking the animation frame only and the collision checking with the FlxSprite of player.

On a different note, I can't for the life of me understand why my enemy sprite doesn't align to the ground (see image below). In the idle state it works appropriately, but when the death animation is triggered it looks like its floating. I'm using texture packer and I've aligned the center points to bottom/center (if that maters). Any input would greatly be appreciated. Thanks!


Please disregard. I just realized how big of a noob I am with sprites. The script I was using to export images was cropping the image down to size, thus skewing the sprite dimensions. It now looks better, but I will need to implement hitboxes as you mentioned.


Response to HaxeFlixel Jam Thread 2020-04-09 11:09:47


At 4/9/20 09:10 AM, catproX wrote:
At 4/8/20 11:22 PM, catproX wrote: On a different note, I can't for the life of me understand why my enemy sprite doesn't align to the ground (see image below). In the idle state it works appropriately, but when the death animation is triggered it looks like its floating. I'm using texture packer and I've aligned the center points to bottom/center (if that maters). Any input would greatly be appreciated. Thanks!
Please disregard. I just realized how big of a noob I am with sprites. The script I was using to export images was cropping the image down to size, thus skewing the sprite dimensions. It now looks better, but I will need to implement hitboxes as you mentioned.


That's looking real good, otherwise! also note that you can show hitboxes by enabling `FlxG.debugger.drawDebug` but know that it can kill your framerate.

Response to HaxeFlixel Jam Thread 2020-04-09 15:48:06


At 4/9/20 11:09 AM, GeoKureli wrote:
At 4/9/20 09:10 AM, catproX wrote:
At 4/8/20 11:22 PM, catproX wrote: On a different note, I can't for the life of me understand why my enemy sprite doesn't align to the ground (see image below). In the idle state it works appropriately, but when the death animation is triggered it looks like its floating. I'm using texture packer and I've aligned the center points to bottom/center (if that maters). Any input would greatly be appreciated. Thanks!
Please disregard. I just realized how big of a noob I am with sprites. The script I was using to export images was cropping the image down to size, thus skewing the sprite dimensions. It now looks better, but I will need to implement hitboxes as you mentioned.
That's looking real good, otherwise! also note that you can show hitboxes by enabling `FlxG.debugger.drawDebug` but know that it can kill your framerate.


Thanks. Good call on the debug. I was able to fix the sprites and make the main character hitbox more realistic. I'm working on adding "custom hitboxes". I could only get the overlap detection to work if I used FlxSprite instead of FlxObject for the hitbox, not sure why. Also, I can effectively hide them by not adding them to the scene and it still calculates collision... I'm not sure if that is intended behavior.

Response to HaxeFlixel Jam Thread 2020-04-09 16:33:01


At 4/9/20 03:48 PM, catproX wrote:


Thanks. Good call on the debug. I was able to fix the sprites and make the main character hitbox more realistic. I'm working on adding "custom hitboxes". I could only get the overlap detection to work if I used FlxSprite instead of FlxObject for the hitbox, not sure why. Also, I can effectively hide them by not adding them to the scene and it still calculates collision... I'm not sure if that is intended behavior.


It is, as collision and display hierarchies are separate. you add() things to the scene to display them and pass them into collide() or overlap() calls for collision, but neither should be required for the other (unless you want to debugDraw a collision-only shape, then you should add it to the scene). The fact that it needed to be a sprite to work for you is odd. as these FlxG checks treats everything as a FlxObject anyways.


You can also prevent debugDraw on things by setting `myObj.ignoreDebugDraw == true;`

Response to HaxeFlixel Jam Thread 2020-04-09 20:50:54


At 4/9/20 04:33 PM, GeoKureli wrote:
At 4/9/20 03:48 PM, catproX wrote:
Thanks. Good call on the debug. I was able to fix the sprites and make the main character hitbox more realistic. I'm working on adding "custom hitboxes". I could only get the overlap detection to work if I used FlxSprite instead of FlxObject for the hitbox, not sure why. Also, I can effectively hide them by not adding them to the scene and it still calculates collision... I'm not sure if that is intended behavior.
It is, as collision and display hierarchies are separate. you add() things to the scene to display them and pass them into collide() or overlap() calls for collision, but neither should be required for the other (unless you want to debugDraw a collision-only shape, then you should add it to the scene). The fact that it needed to be a sprite to work for you is odd. as these FlxG checks treats everything as a FlxObject anyways.

You can also prevent debugDraw on things by setting `myObj.ignoreDebugDraw == true;`


It took me a bit longer than I would like, but I believe I've got it working as you suggested. Using the debugger to draw hitboxes is nice. I now use a punch_hitbox that is set about wear he hits on the appropriate frame. Lol, now I need to actually try and make a game.


iu_109196_156788.png

Response to HaxeFlixel Jam Thread 2020-04-10 18:27:10


Progress is getting made. I still need to play with my hitbox logic and FSM states, but its coming along. Wasted a good hour today trying to debug the UI. I learned the importance setting scrollFactor as my energy bar in the middle wouldn't render unless set. I must say I've learned a lot.


iu_109538_156788.png

Response to HaxeFlixel Jam Thread 2020-04-11 17:51:10


At 3/27/20 05:47 PM, ninjamuffin99 wrote: i lov haxeflixel


why...?

Response to HaxeFlixel Jam Thread 2020-04-11 19:04:15


At 4/11/20 05:51 PM, TheFerridge wrote:
At 3/27/20 05:47 PM, ninjamuffin99 wrote: i lov haxeflixel
why...?


why not?

Response to HaxeFlixel Jam Thread 2020-04-22 16:15:04


So I've reached the point where I believe I have most of the bugs out of my little Flixel Jam game. I am looking for folks to test it. If you're interested, please let me know and I'll shoot you a link to try it. Thanks!

Response to HaxeFlixel Jam Thread 2020-04-29 11:57:39 (edited 2020-04-29 12:02:03)


At 4/2/20 09:32 PM, primakrazy wrote:
At 4/2/20 08:04 PM, catproX wrote:
At 4/2/20 07:39 PM, primakrazy wrote: Is there a way to install Ogmo3 in Ubuntu?
I managed to go through a few Haxe tutorials but I seem to have hit a brick wall here.
Yes, on their download page (https://ogmoeditor.itch.io/editor) there is a link to a Linux binaries. I looked through it and didn't see a dpkg file for installation, so you may have to install it manually. If that doesn't work you could probably do the same thing with Tiled map editor (https://www.mapeditor.org/), which looks like it may support package install via apt-get. There are examples of loading Tiled maps on the haxe site.
I saw the files on the itch.io page. It's odd that they have it in a zip file. Figuring out how to manually install it is a pain.
I'll also check out this mapeditor tool as well. Always looking for more tools to play with.

Thanks for the response. :)


Hi! I'm actually the person who makes the builds for Ogmo 3. I don't normally use Linux, so I just zipped up what I thought were the correct files when I built for the target.. and It looks like its the wrong stuff!


I know this is a little bit late (as the jam is already over), but if you guys would point me towards the most convenient way to distribute the app for Linux, I'd gladly make any changes needed. Feel free to PM me!