Best posts made by Claudio Ficara

Well, as it seems this topic gaining some traction, I guess it wouldn't hurt to give away some tips on the HTML5 version that we are creating. Hey, is a forum for HaxeFlixel users, after all!

First of all, while some maps did run actually fine, others did not, because optimization was missing. A quick compile from the normal version (the one that had all effects) to HTML5, produced 14 unplayable maps. Yay.

Now after lots of optimizations, 19 maps, from 20 works! 60/60 fps, with occasional tiny and acceptable drops on heavy moments. For those that wonder, the map that I still can't get to work is the one that needs the Tester thingy to draw lines between objects. Those lines are way too expensive, and the optimizations I made aren't enough.

Here's the tips I found successful while optimizing the HTML5 version:

HTML5 really really hates things such as alpha, rotations, scaling and coloring. If you are using some of them, and you are suffering from performance issues, consider using less and less of these. Do not understimate this tip!
There was a map that had 40 fps max. For the love of me, couldn't figure out what was causing that. Ended up being the colored sprites that I had. The solution was simple: use already colored buttons.

Use loadRotatedGraphic() whenever possible. I had particles and lots of effects that basically crippled the performance. Reducing the amount of these and by using baked rotations, made these effects possible.

Mind your assets. By default, you might ending up just loading all the assets in your folders (<assets path="assets" />). That's is a no no, mainly because everything will be loaded. Not only because this will increase loading times, because increases memory usage as well.Consider excluding things that you don't need and reduce the quality and size of your assets whenever you can. In my case, I use exclude and I changed the paths on game.XML to use different sound folders (with lower quality) for the HTML5 version, while preserving high quality sounds for the Windows version. Here's a good article on how to handle this matter.

Not everything must be done 60 times per second! Is often a handy way to throw things that needs to always run, in your update()function. It could be a if(alive) check, or perhaps, an isOnScreen() check, it doesn't matter. The question is, do you really need to? If the answer is no, then what it comes handy, first and foremost, are FlxTimers. How so? You can create a (what I call) heart beat function, that you run aprox, once per second. In there you can check if your player is dead, or change the properties of all the members in a group, or you could update the text in your UI... anything really.
A case study: I've got lasers in my game. Those needed to always call makeGraphic() and check for overlaps with elements in screen, such as props. I changed the frequency of those instructions, by removing them from update() and placing them on a function that was called 10 times per second or so. The performance gain was inmediate with any side-effects.

super.update(elapsed) can be a life saver. The new option of update lets you specifically, change the update speed. I found it extremly useful, as I had some NPCs that had some heavy code. Reducing the update rate of these resulted in a performance gain I didn't thought it could be possible. And was by simply doing super.update(elapsed/2). I combined it with a distance check, so the objects that were far from my main character, were updated less. This saved CPU cycles and the performance increased.

Be memory friendly. Use destroy() for things that you won't ever ever need. In my case, I had permanent bodies. In some maps, the body count was way too high. You surely can use exists = false, but if you have no plans to reuse them, use destroy() This will free some memory, and that is always good :)

Use recycle() - revive() and try to create everything you are going to need, at the start of your state. Creating new objects at runtime is not always a good idea. You could recycle bullets, instead of creating new ones. You could revive NPCs you previously killed, instead of creating a new one.

Common sense is your friend. Why to do a complex collision or overlap check, when you just can simple check the.yof two objects? In my case, on the latest picture, I had some acid that did rise. Touching it of course, would kill the player. While overlap/collide was acceptable, I found out that just checking the Y position of the character and the Y of the acid, was 10x times better! This of course can't be applied on all your games, but if you are suferring from performance issues, you might find some answers by thinking outside the box!

You are human, you will miss out things, this is why you need profilers. Chrome bundles up a great profiler you can quickly use, by opening the console (F12) and going to the Profiles tab:

You can use the Take Heap Snapshot option. This will show memory distribution in your game. You can sort the values, to see which functions are the most memory consuming ones. In my case, I've got 311 particle objects that I'm not even using. I will need to decrease a bit the maxSize of my FlxEmitters :stuck_out_tongue_closed_eyes: - Also, I've memory allocated for things that I didn't add, but were created anyways (such as the character's cape).

Well, that's it for now. I hope someone else will find this tips useful! If something else pops up in my mind, I will be sure to edit this post. Laters! :heart_decoration:

Doesn't end up there tho. Shaders have differences in how they are supposed to read the mouse and to get time, for example, so you have to tweak that out. For mouse (or another position) you have to to translate the coords to screen coords. Ain't hard, just:

we have to do /FlxG.width because, also, the coords from the shaders are different (0 being left, 0.5 being center... 1 being right)

And I think it pretty much covers that up. However, this is not a way to explain how shaders are created (there are tutorials for that), just a way to make shaders compatible with HaxeFlixel so you can get new effects... right here, right now.

Without having to resort to Unity, XNA or Cocos2D (which need some long learning and things that are framework specific) you are pretty much screwed, as there aren't much libraries that are this friendly and free, like HaxeFlixel. The good thing about it, is how what you learn carries over to other languages, and also, what you already know from your days from AS3 and Flash, can be easily used here.

Prototyping is absolutely fast and they managed to do a great work on documentation, and covering all aspects that are game oriented. My only complain, (but this comes from someone saw how HaxeFlixel evolved through the years) was the code breaking changes. But this isn't a problem for people today and problably won't be anymore, since the library now is mature enough to cope with anything.

Anyone can help back by contributing or donating! If you have no money or patience for bug solve, the forums are also, a great place to help people in need.

A very long due dev log

It's been a while since I posted here. I had a major setback, because, well... my mother did pass away last month.
It's a warm welcome to be back and see how people got interested on the project over the past two months. At the moment of this writting, this very dev logs sits at 25k views! And we are happy to see how our Twitter is expanding rapidly (we got liked by #haxe and #openfl -- SENPAI NOTICES US!).
We also got invited to a special event on itch.io (where the game is hosted at) but more on that later.

This would be, probably, the best time consuming dev log entry ever, so bear with me and please stick around because this time I'm really gonna take my time. This will cover from old stuff to new stuff, in that order :)

To upgrade or not

HaxeFlixel + OpenFL combo

However, in my case, there was a major issue about shaders. We can live without them, but there were specific moments where we had graphical glitches that were located at the very root of OpenFL. Also, there are currently issues with blend modes. New per sprite shaders should make everything look the same, but it's really time consuming for me to go back and replace the images and trying to code a equivalent-looking shader.

So I guess I'm gonna wait to jump on the latest version.

Tiled

The version of Tiled that we use to do maps was seriously outdated. We updated so we can use the latest features, specially those introduced this year. The most important features would be the infinite maps, and in our case, not sure if already available or not, but the mirroring of tiles. That will allow us to make our multiplayer arenas really really quickly!

SCA itself

Online

We've been working on the basic online components. Well, I saw 'we' but it's actually @PXshadowHF 's work. We managed to connect with each other and see the other player running and shooting :D - super excited to know how that turns out!

New game mode

We added a new Last Man Standing game mode. Basically, I edited out the round based Versus, to disable respawn and do a players.countLiving() each 3 seconds or so.
This new game mode will allow us for a upcoming Battle Royale mode. A mode everyone is soooo hyped about. Lets face it tho, is really fun to play, so if we can give it a go, why not?
However, we wouldn't be copying PUBG, we should go back to the roots and see what's really is all about.

Easy to pick, hard to master

One of the most welcoming things to newcomers is easy controls. You grab the joystick and you are playing. You press a button and you have the same chances of killing the other players, as they do.
One of my main goals, from day zero, is that SCA should be easy to pick but hard to master.
That is, there should be inside the game, a much more advanced way to use the same controls to perform different things, but those things shouldn't affect the very first goal.
This is good from many different perspectives. First of all, increases the player base and covers a much bigger audience that might have fun. The newbie can stupidly kill and inspire rage on the pro but the pro can do fancy moves to kill newbies.

That bring us to the topic of what we call, the genkidama:

A move that didn't make much sense on the round based versus, but really shines by accident, on the Last man standing mode. Basically, you hold a button and you start to create a big energy ball. You can't shoot or move while you do this. You can release the button and cancel it. But if you go on, the ball end ups exploding and killing all players in the map. This, of course, ends the level for everyone.

It's inspired, somewhat, on the nuke button from Lemmings. This brings us to the next topic, in a moment. A really good old game. When I was a kid I was in awe when I discovered that button. By extension, I was in love with the people that actually put that button in. Why? Why they did it? But actually... why not?

From different playtestings, we noticed a couple of things:

The move can be used to lure in other players. You can show the intention of creating said bomb. While you do that, you are highly vulnerable. Other players wouldn't want a level switch OR would want to seize your vulnerability, so they go after you. You cancel the bomb and you are now ready to face your nearby attackers.

Puts the newcomers and pros at the same level, at that very moment. This is hard to explain, because it involves a couple of things. The general idea is that newcomers can have fun by just killing everyone. It's like "if I don't win, you won't either".

Balance things out. Players like to have matches against other players of similar skill level. If a newbie faces a pro, is highly likely to bomb the level. That won't likely happen between two newbies or between two pros. And why the balance? If a pro faces a newbie, the winner of the round would likely be said pro. That's not fair, so the newbie has the chance to bomb everything, and everyone starts again.

Inspirations... and the main story mode

I've been asked before where I get my inspiration. Well, basically, from everything that I love, I put everything together in a way I think it fits. This can't be possible, of course, without external thumbs up. Also is highly neccesary to see if you are in the right path, by playtesting what you do and getting feedback from other people, aka: your players.
If helps, where's a list of creations that somewhat, shaped SUPER Cute Alien:

Max Payne

Super Mario Bros (of course!)

Battle Block Theater

Duck Game

Soldat 2D

Dragon Ball series

Mortal Kombat series

Happy tree friends / Itchy and Scratchy

Worms

We always thought that the best games/movies features simple stories but complex characters. This is what our game is all about, story wise. We could mention a couple of creations that serves us as inspiration:

Where everything comes together: THE CHAINSAW

That's how it looked. However, it needed some love. Otherwise, it just behaves as another "sword".

The new enhanced version has a few extra steps to make it awesome:

A player is killed, a ragdoll is created

A distance joint is created. This basically is used to move a physics body around a reference point. Setting the X or Y manually of your physics objects is a no no. For this, it uses a special bone on the chainsaw skeleton:

The location is updated each frame, so the torso of the ragdoll moves around this point

As long as the player holds the button, random gibs will spawn. Random sounds will be played too.

The chainsaw is replaced by a bloody version.

When player releases the shoot button, this distance joint is removed, so the body falls naturally.

Velocity of the guy using the chainsaw is translated to the ragdoll. This is to make the ragdoll follow the momentum of the attacker. If he's moving left and releases the button, ragdoll will move to said direction.

Also, this spark effect is also featured:

Using same reference point on the chainsaw, a tiny invisible sprite is created to detect collision. It creates sparks when it touches the map.

After some tweaking, here's how it finally looks:

Yes, you can "grab" your enemy with the chainsaw, as long as you want. The movement of the killed character happens naturally: it follows the very same movement of the chainsaw fire animation, which is great.

And now, on the advanced part. The chainsaw actually features some extra bits that pros will really like, the jump chainsaw attack:

This idea was from @Aydius, and love it, since is related with a game that I love, Mortal Kombat!

If you attack a player with armor, basically, anything won't happen:

UNLESS you do an advanced move. Jump, press down, and shoot!

This will make the player go down really fast and do overhead damage. This kind of damage breaks armor and lets you kill the other player:

Final words

It's really heart warming to go back and do what you love, specially after such a long ordeal. Is lovely to see the awesome support from everyone, so thanks everyone for your words, ideas and for tracking our progress. I guess we did a thing or two since we started :D

This took longer than expected! Hope you like this very long post that almost broke Markdown.
What comes next would be a new set of polishing and new content for the upcoming itch.io summer sale!

However, it was really slow and super basic. So I extended it a bit so the performance is good enough. They look much more natural, the ones from the original source looked a bit dead... Also, multiple lights are supported, they can be switched on/off and there's light styles (for a camp fire, ie), they can be toggled, scaled up, etc. All of this can be easily set from Tiled.

Here's some comparisions:

And a few more:

This had to be done because now... there will be a new mechanic, and has something to do with power sources. Idea is to completely shutdown bases. Lights going off would be the necessary visual feedback that you did good. This will be like... puzzles within puzzles.

The other thingy that got done is the dynamic music. Supports day/night and if a puzzle is nearby, another fancy track will come in. But is better if I show a video about this, which I will do later.

That's it for now!

PS: Sounds fair that I share my improvements. This only covers the improvements made upon the basic class from ORL. Not that I don't wanna share, is just the other stuff is closely related with my own game source code. ANYHOW:

Been working with the musician. Did I mention it? Well... here's the incredibly talented guy, Robert Fenn. Idea is to have adaptive music. Is something that I did before but I'm planning to take it a step further!

Here's a video that was supposed to be internal, but if anybody wishes to see how the single player gameplay is doing, please check it out!

In the search of an optimal image quality, something more on the artistic side and less computery, less artificial, implemented HDR + Cromatic Aberration:

Notice how the lighting comes through and feels a bit more natural.

Idea is to have a final image that blends together in a better, more natural way. So the player notices less the artificial separation of sprites.

That's it for now. Next step is enhancing interaction with props, and even more effects. Cheers!

EDIT: Well, to avoid multiples post, wanted to include something else I just did, which are ... more gameplay options!

The way I see it, games should have a wide range of options to pick from, so you pick what's most fun for you. This is why brute force was added.

If player doesn't feel like completing a puzzle, he will have the option of just blowing the frigging door. The hell with it. For this though, player would need to craft a bomb by collecting... screws? Those allow the player to create physical stuff, such as the little car or bombs (for now).

The explosion basically creates a copy of any given FlxSprite, converts it to a FlxNapeSprite, and then blows it away by using the fracture from the Cutup demo.

And... hey, if cool people share source... I can do that too! Check the Explodable class I did. Is a good example of collision callbacks, since they support multiple sounds (hard/soft) based on impact force! A super handy way to copy a sprite would be to use graphic.key just like this:

Celebrating 10000 views with a gift for you all! Thanks for the support!

A new day and a new feature that I've been wanting to do for a while.

I did something awesome! Since I'm lazyI like to get results ASAP and I'm quite not planning to do a death animation for each one of the characters, I worked a bit on something I'm planning to share today, which is an automatic ragdoll generator

Basically, the way it works is really simple. Here are its features:

Grabs any spine skeleton and clones its parts. Physics bodies will have the image dimensions and the proper image itself.

Scaling of said skeleton is supported.

Position of the limbs will respect the original positions of each image (so it doesn't pop up).

Facing left|right is supported-ish.

Supports body parts replacements. So, if you want to use a damaged head, or a damaged torso, you can do so.

Now that I think of... isn't that automatic, since requires to setup what you want to clone and where the libs are tied together. This should grab the position of the Spine bones. I attempted to do so, but it would need some tweaks because not all bones were created with this in mind.

Well, that's it for now. Hope you enjoy this, in the case you are using skeletal animation in your characters it will be super useful.

They are stupidly easy to use. Quickly added because they were a left over from this project .

These are contextual, that means by simply going next to an object you can cover under, and pressing down, you enter in cover mode. That's it. Exit cover by walking off or looking the other way.

Cover systems in 2D are a bit unexplored. The first one as I recall was Blackthorne, this was later picked up by Not a Hero. This is a bit based on Soldat 2D, except is easier to use. And looks like there's nothing else on the subject :(

This will be the beginning of something new, fun times ahead as we go into unexplored territory! I've been lately playing Ghost Recon Wildlands and notice enemies indicator do blink when they are in cover so probably gonna be adding that on the next iteration.

Silly me, I guess I should have explained it better. Basically FXAA is a fast antialiasing solution. Here's an article explaining it better than myself.

Anyhow, the implementation at hand makes a subtle difference, but is there:

To reply your question:

Flixel antialiasing sometimes causes artifacts, such as pixel bleeding, this is when pixels go outside its boundaries, or simply sometimes transparency is handled poorly and black pixels might appear.

Here's the reference image. no antialiasing at all:

Here's Flixel antialiasing ON, notice the right side of the cactuses, and the black border around the rock:

Here's the FXAA solution:

Now, we should have in mind that this is a scaled up, full screen version of the original resolution. A game that has a 1024x576 internal resolution, adapted (on my case) to 1920x1080.

Also, Flixel antialiasing can work to an extent. I had sharp edges on my text even with antialiasing on, this is why I had to do this (among other things) Also FXAA, being shader based, works on the whole image, giving more cohesion.

I'm not advocating to not use Flixel's antialiasing. Everything comes down to the type of game you doing and how nitpicking can you go about the final picture.

I think you are from argentina. We should get together sometime as we are both using HF.

I was wondering myself ifFlxG.stage.quality = flash.display.StageQuality.BEST and setting in project "antialiasing X" makes a difference. Look like so in some platforms?

I don't want to hijack your tread much, but thanks for trying it! And yes, the text is a issue. Well, everything that scales up is an issue.

Not sure if doing it the right way... but check this full hd screenshot. Game resolution is 1024x576, so naturally scales up a bit blurry. Using hi-res versions of images and using scale.set(0.5,0.5) and antialiasing, helps to preserve quality when it scales up.

This is great, because different resolutions could be used. One for the game, one for the UI.

The only problem I'm facing with this method is that doing animations, using a FlxTween for example, is that you need to remember the scale, since 1,1 isn't the default anymore. But I think that FlxSprite could be hacked to... add quality ratio or something?

Well, I guess since we about to reach 5000 views (!!)... I sense there might be a person or two that is still tracking this dev log! So, quick update!

SINGLE PLAYER MODE:

Added GOOD/EVIL system. Basically, good actions give you rewards, and being a bad boy makes you evil. Being good or bad unlocks different content.

Added antenna that controls enemies for advanced gameplay. You can break the antenna, fight its drones and pick loot or save the controlled enemies individually and get coins or walk past by and ignore everything or kill everything in sight!

New enemies!

Added shader based meta balls ( this is to spawn realistic blood, like a liquid!)

Yup! Didn't know either, actually, there's lots of things you can do on OpenFL.
It's a simple trick, with lots of impact. When the game directly adresses the player, by his name, there's a moment where the person goes 'wtf, how, what why' that I just love! Can't be done on all games though :( but I'm happy that I had the chance to make it here!

@Agustín-Pérez-Fernández hey, thanks mate! The HTML5 will be free, so, yes, I will sign you up for the next batch, latest version, as soon as it is done :)

And, speaking of which, been polishing the UI. Idea is to have a quite clean interface, with the less amount of objects as possible. Most of the UI elements come and go exactly when you need them. Is a much more time consuming process, but more inmersive.

Here's how it looks so far, also here's the logo, which is WIP, of course:

Sadly, most of this UI won't be available for the Windows version. This is like... a simple UI, mobile/web oriented, with gigantic, and readable content (ugh! :sick:). The Windows version will have a different menu, with different options, and considerably smaller UI. For PC people, ya know :upside_down:

In case it helps anyone, what I did was replacing my HaxeFlixel files, for @Nallebeorn ones: FlxBasePreloader.hx and FlxPreloader.hx, then on your project.XML file make sure you got: <app preloader="flixel.system.FlxPreloader" />

I use 4.0.1 version. If not mistaken, the next release will include this by default. I thought I might share in case someone else finds it useful.

Well, can't speak for others, but so far, for me, for this project, (which is somewhat resource-heavy) the performance was quite good. Without doing much optimizations, I get 60 fps on Chrome. On Firefox it kinda lags a bit, but again: no optimizations.

Don't take my word for it tho :slight_smile: . Download FlxBunnymark, compile it on the platform you wish and check the results!

You could also check Branch Ninja, done on HTML5, using HaxeFlixel of course. It kicks a bit on my Firefox, runs flawlessly on Chrome.

In other related news, we've been working on day and night to try to get a build as polished as possible to go over big platforms, such as Steam. Idea is to gather player feedback, mostly, for the multiplayer aspect. Campaign content while is being worked on, it will be behind doors.

Game is now free to play for a bit, so people can get a taste of what's coming, specially for the campaign. Mind you: is still WIP, but we working on that.

Not much else to say, because as the game grew in size, grew also team-wise. That's good, but there's always something to do, or something to manage, 24/7. That's game dev for you. I just thought I can pop out from the shadows and post some progress :D