search

useflashpunk / FlashPunk

A free ActionScript 3 library designed for developing 2D Flash games. It provides you with a fast, clean framework to prototype and develop your games in. This means that most of the dirty work (timestep, animation, input, and collision to name a few) is already coded for you and ready to go, giving you more time and energy to concentrate on the design and testing of your game.
http://useflashpunk.net
MIT License
389 stars 134 forks source link

We need milestones #139

Open AbelToy opened 10 years ago

AbelToy commented 10 years ago

We need milestones here in Issues.

We should plan, at least:

FlashPunk 1.7.3 - when is this going to be released guys? 1.7.2 was almost half a year ago! FlashPunk 1.7.X - What's missing? FlashPunk 1.8 - Aw yeah FlashPunk 2.0 - Aaaaaaaaw yeaaaaaaah.

(also, unrelated. I'm not a collaborator anymore. What happened? Who are the new guuuuuys)

zachwlewis commented 10 years ago

Keep in mind that we're using Semantic Versioning.

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible manner, and
  3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

That said, any bugs we fixed should be rolled into 1.7.3. If we make any backward-compatible additions (like new hitboxes), we'll release 1.8.0. If we break anything (like tweens), we'll release 2.0.0.

AbelToy commented 10 years ago

We should prepare more stuff for 2.0.0 though, can't be anticlimatic.

And creating the milestones here in Issues helps us visualize and motivate ourselves!

zachwlewis commented 10 years ago

We should prepare more stuff for 2.0.0 though, can't be anticlimatic.

That's not really how semantic versioning works, though. It's supposed to, at a glance, let you know if your code will be compatible with the library.

AbelToy commented 10 years ago

It doesn't forbid us to do that, though... we just need a list of issues (feature suggestions and stuff) marked as milestone 2.0, which can break stuff, and when they're done, we tag it as 2.0.0. What'd be the problem?

zachwlewis commented 10 years ago

If we have lots of updates, that's great! There's no problem with doing it like that, I'm just letting you know that the title 2.0.0 doesn't have to be brand-spanking-new.

I think we might fix tweens and pull @azrafe7's polygon hit boxes into 2.0.0. That would be a pretty sweet release.

AbelToy commented 10 years ago

yeah, the collisions is pretty much a good selling point for flashpunk 2.0. So can we safely say the implementation can break api compatibility? So what about using this to improve the rest of the collision API as well?

zachwlewis commented 10 years ago

What is wrong with the rest of the collision?

I'm not sure if the collision change actually needs a major version bump. I'll have to look and see if there are any API changes that aren't backwards compatible.

On Tue, May 20, 2014 at 5:08 PM, Abel Toy notifications@github.com wrote:

yeah, the collisions is pretty much a good selling point for flashpunk 2.0. So can we safely say the implementation can break api compatibility? So what about using this to improve the rest of the collision API as well?

Reply to this email directly or view it on GitHub: https://github.com/useflashpunk/FlashPunk/issues/139#issuecomment-43689861

AbelToy commented 10 years ago

Basically, I think the Hitbox is just weird (it changes properties of Entity) and some of the collision code looks very hacky to me...

@azrafe7 What would you add in your collision changes if you could break the api entirely?

azrafe7 commented 10 years ago

I'd say to stick with what we have for now, as it's proved sound till this moment.

Although a bit convoluted the collision works pretty well as it is (also thanks to many fixes across the years). At some point I considered rewriting it from scratch to make it more simple and mantainable, but that's too BIG of an undertaking and will surely break other things in the framework.

Indeed it would be interesting to follow the path taken by Phaser, which supports multiple collision systems (with or without physics - default, Nape, N, etc.). But obviously that too would take some real commitment to code and integrate into FlashPunk.

The one thing I'd really like to see in FlashPunk (that shouldn't even break compatibility) is some space partitioning datastructure to aid in resolving collisions faster. I don't like quadtrees, but I've recently discovered RTrees. They're really powerful and am planning to make an implementation of them (no code to show yet).

zachwlewis commented 10 years ago

No, no, no… Stop trying to break stuff just to get a pretty number. Don't worry about the version number and worry about fixes and improvements.

On Wed, May 21, 2014 at 3:07 AM, Abel Toy notifications@github.com wrote:

@azrafe7 What would you add in your collision changes if you could break the api entirely?

Reply to this email directly or view it on GitHub: https://github.com/useflashpunk/FlashPunk/issues/139#issuecomment-43725118

AbelToy commented 10 years ago

Okay, fine... hahaha.

tadeubas commented 10 years ago

@Rolpege , see: http://semver.org/ Plz read Summary and FAQ at least :smiley:

AbelToy commented 10 years ago

I've read Semver a few times already.

I just don't find the idea of quickly having version 14.2 that attractive...