Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a Nape physics Body editor #4

Open
andrey-p opened this issue Apr 7, 2014 · 9 comments
Open

Create a Nape physics Body editor #4

andrey-p opened this issue Apr 7, 2014 · 9 comments

Comments

@andrey-p
Copy link

andrey-p commented Apr 7, 2014

I was evaluating PhysicsEditor to use for the game I'm working on, but the Haxe output is a mammoth class that you need to edit manually to fit with HaxeFlixel. (Not to mention it doesn't work on Linux so I'm having to run it through Wine.)

I'm thinking it'll be straightforward to make a Nape physics body editor similar to PhysicsEditor, specifically aimed for use with HaxeFlixel and Nape. There is already a Nape example which demonstrates creating a body from a sprite.

Then you could serialise all the shape data in a JSON format (Physics Editor sort of does that if you export for Lime + Corona (JSON) but it doesn't quite fit with the way Nape works) and store it in your assets folder.

This is something I'd probably end up building for myself anyway so I'd be more than happy to contribute.

@Gama11
Copy link
Member

Gama11 commented Apr 7, 2014

This would be an amazing contribution! 👍

Slightly related I guess: HaxeFlixel/flixel#961

@andrey-p
Copy link
Author

andrey-p commented Apr 9, 2014

Just put up a very quick and dirty proof-of-concept app:

https://github.com/andrey-p/nape-physics-editor

I'll work on this until it becomes a bit more acceptable (add the ability to move vertices, change materials, interaction filters etc) and I'll add it as a fork of this repo.

@sruloart
Copy link

sruloart commented Apr 9, 2014

This is so very cool, I've tried testing it with openfl but I got:
C:\HaxeToolkit\haxe\lib\nape-physics-editor\git>openfl test flash
source/MenuState.hx:82: characters 36-43 : x : Float -> y : Float -> Float should be nape.geom.IsoFunctionDef
source/MenuState.hx:82: characters 36-43 : x : Float -> y : Float -> Float should be nape.geom.IsoFunction
source/MenuState.hx:82: characters 36-43 : For function argument 'iso'

@andrey-p
Copy link
Author

Shoulda mentioned, it currently only works with cpp / neko targets. I'll make the Flash target work next I think, the systools library that deals with file dialogs doesn't work very well on my system.

@Gama11
Copy link
Member

Gama11 commented Apr 10, 2014

Looking promising, but still very basic.

@andrey-p
Copy link
Author

Oh yeah, I won't even try and pretend it was anything but basic. :) I'll work on it a bit more, will probably pop into IRC if there's any new and exciting features.

Also, thanks for the pull request, much appreciated!

@sruloart
Copy link

Can't this be used with the debugger? I have a dream of a world in which the debugger behaves like a in-game editor...

@Gama11
Copy link
Member

Gama11 commented Apr 10, 2014

@sruloart Not sure what you mean.

@sruloart
Copy link

Just reflecting out loud. I'm thinking of a Unity like in-game editor for a while now and this is a very important part: you run your game in debug-mode, but you can choose every object you have on screen and add a Physics body to it like you would on Unity. This is where the editor comes in, to automate the process of creating and saving the physics bodies for your sprites so you can load them in your game.

I've learned by now that big ideas should come with a viable way of accomplishing them, so I'm not getting into particularities just yet...(If you want to read a completely theoretical rambling keep reading).

Rambling begins here

  • The only thing that make sense to me is to have one place where editing is done (an IDE).
  • It can't be a unique software (even though the Godot's HaxeFlixel looks pretty decent) because it's complicated, and what's easier than having a in-game-editor as an integral part of your project (the debugger)?
  • It barely adds size or complexity (just a matter of saving and loading), and when you don't want the debugger, you just disable it and have your game (or allow your players to use it if you want to).
  • Animator can be a part of a in-game-editor, but I really don't see people using it without a simple link to their project. People rarely use even the Flixel-UI because of it.
  • There's no reason for that to happen as with a file that saves all the changes you do in the debugger you can have Unlimited undo's so you can store your sprites preferred positions, create and record tweens, arrange your polygonal spritesheets, link your states and animations with a uml-like editor in which you can create loading nodes to decide when and where do you want to load any of your assets and the list goes on a lot longer...

Rambling was terminated due to excess amount of day dreaming

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants