FlashPunk 2.0 - Ideas collection

(Abel Toy) #1

So, people on the forums have talked a few times about “next major version”. I thought having a topic with the features we’d like to see for the next major version would be helpful to get us focused and working on them!

I will definitely help working on them, and I hope other people will as well.

  • Console 2.0 (new debug console altogether, better done, more features and bugs fixed)
  • Collisions 2.0 (rework of the collision system altogether, allowing more collision mask types [circle, polygon, line, hitbox, etc.] and more collision customisation)
  • Image masks - hide images using other images!

Ideas are appreciated, I want this to be sort of like a draft of the features we all want for the next major version!

About new fp 2.0
(Zachary Lewis) #2
  • Stage3d Support — There is no way for FlashPunk to continue to compete without switching out the software blitting for a hardware-accelerated rendering solution.
  • Developer Tools — Create a pipeline for developers to contribute, extend and improve the platform.
  • Sprite Atlas Support
(Abel Toy) #3

Are we talking about optional or obligatory Stage3D support? Because in some cases (desktop), blitting works faster than the GPU alternative? :confused:

Can you expand on the developer tools bit?

(Justin Wolf) #4

It would be nice to have both. Stage3D optional for those who want to render to mobile devices. Or maybe a fallback as well, in case a website doesn’t have the wmode parameter set, so the game would automatically revert back to normal FP rendering.

+1 to Sprite Atlas support.

Also maybe some Spine/DragonBones support? I’ve not really tried working with a skeletal system in FP yet, and I’m not real sure how to go about it, however I’ve used it with Starling and I love it. So it would be cool to have an easy way to get Spine or DragonBones into FP2 with some native classes maybe? Really makes having character clothes, helmets, weapons and all sorts of changeable gear efficient without having a massive amount of spritesheets.

Built in physics could be neat - though maybe unnecessary.

(Jacob Albano) #5

Stage3d would absolutely have to be optional. I remember Draknek talking about how flash has no GPU acceleration under Linux, so games that used it ran far worse than with blitting.

(Zachary Lewis) #6

Stage3D would be a huge change to the way graphics are handled, so it wouldn’t be easy to just switch stuff out; however, the rendering system is pretty isolated, so that code wouldn’t mess with anything else. Even though the internals would change, I don’t want to change much of the public API.

I don’t think skeletal systems aren’t a core part of a game library. There are tons of games that a skeletal system would just complicate. I do believe that having a list of maintained, “plug and play” libraries that work with FlashPunk would be awesome.

I believe a skeletal system library would be a great tool in a developer’s toolbox, but I don’t think it’s a required tool (if you know what I mean). I feel the same way about a physics library.

(Justin Wolf) #7

For sure, I know what you mean. I suppose a skeletal system is definitely not necessary. A plug and play would be just as good, really.

Trying to think of what else might be interesting to bring into a new version of FlashPunk. Maybe the ability to rotate Particles? Or the ability to use PreRotation as a Spritemap and not just a single source image? There are ways around these issues, I know, but maybe having them built in would be neat!

These are all such small additions that I don’t even think they need to be mentioned… oh well!

(Abel Toy) #8

Mention all kind of things you’d want to see added, even if they’re really small improvements, because we may not have thought about them and they could be interesting!

(rostok) #9

Stage3D is absolutely a must have, without it FP will just wither. The rest below is really optional.

Geometric Collisions would be a nice feature yet I think this can be substituted with Box2D integration (have no experience here).

Savestate/Savegames - just a framework to start saving game state.

Performance Profiler - this would come handy if optimization is needed. I know that there are already other tools like Miner or Adobe Scout though.

and finally Input.as extension to support multitouch or game controllers (just thinking loud here).

(Zachary Lewis) #10

FlashPunk needs treat mobile development as a first-class citizen. People want to make mobile games. FlashPunk is made to make game creation easy. FlashPunk + Mobile is currently a giant headache. This is a big problem.

(Malky) #11

This is a truly minor one, but it sure would make my life more fun:

Expand the Draw class.

I used to just use it for debugging, but nowadays I mostly use FP for prototyping ideas, and so most of my art is just circles and squares created by Draw.

If that class was expanded, I’d love it.

(azrafe7) #12

I have this modified Draw.as class lying on my HD. Coded it to help me debug an old prototype.

Has been sitting there for quite a while and I don’t remember if it’s buggy so…

Anyway it adds dots, arrows, arcs and rotated rects. Not sure if it works OK, but here’s it.

Let me know if it could be of help.

(Malky) #13

Score!

Nobody’s mentioned HUD stuff yet. I never tried the HUD classes that were floating around the old FP forums, but maybe there was something there worth integrating?

Honestly, the biggest reason I’m moving away from FP is performance stuff. If there’s anything we can do to make that go smoother, that seems be the biggest priority.

(Malky) #14

How about allowing Graphics to override their Entity’s layer, so a Graphiclist can render on separate layers?

Or has someone done that already? I know people have brought this up before.

(Zachary Lewis) #15
  • Scale9 Grid support
(Zachary Lewis) #16

I view HUD stuff in the same way I view skeletal systems and physics. Every game is different, so having one solution and trying to fit your ideas into our box can be rather frustrating; however, a comprehensive UI solution (which has popped up a few times) would be a great plugin to the library.

The way I think about the system is, “What do people want to do in almost every game, and how can that be made easier?”

(Kevin Graham) #17

I definitely like the idea of having more drop ins, like the transitions thing I remember from the old forums

(Kevin Graham) #18

Though I think the next version should have built in transitions perhaps :smile:

(Malky) #19

I totally agree about only including features that belong in every game, but I see HUD issues as being ubiquitous.

(Abel Toy) #20

I think having a library (drop-in) for that and the other non-that-common tasks is better.

Thing is, while HUDs are a common element in game, they are very different from game to game. This would be equivalent to having a movement system already in the library. Yeah, most games have an avatar that moves, but this movement varies wildly from game to game. For this reason, I don’t think this belongs to the core library, but I’m all for a punk.HUD library of some sort :stuck_out_tongue: