Who is using Pyro and why ( or why not ) ?
September 22, 2017 at 9:21 am #10689
As the title says…September 22, 2017 at 6:39 pm #10714
I am not using pyro. I do not think there is anything in it I would want to use. Also I think I would want my projects to stay as standalone as possible(No extra installations/work required).
If it had more game engines in it I would probably consider it more. (rpg/rts/turn based/strategy etc) More of those bigger things that take a longer time to create. It took me 10 days to create a barebones turn based game. If I could just jump in something and get somewhere it would be a lot more fun.
If there was a morrowind like of minecraft engine in it I would jump on it 😀September 23, 2017 at 2:48 am #10729
I don’t create games yet. Apps only.October 10, 2017 at 6:38 am #11054
I use Pyro because I like the simple ‘Screen’ handling and also the great but simple to use GUI.
I also worked on a simple Space Invaders clone with the scenegraph module that works also fine and helped a lot to reduce the developing time.
So I’m very happy with your module and thank you a lot for your work!October 10, 2017 at 7:18 am #11055
I shall use it when I’ll start creating my next game. (Mid December)
Too bad it’s not on Github though. I’m pretty sure I’ll want to fork it and customise some stuff.October 10, 2017 at 3:57 pm #11059
I don’t use it now, but I think I will after I finish few few programs.October 16, 2017 at 8:02 am #11118
I’m still in early stages on the first mini-project (oh someone give me more free time!), but I’m using Pyro2 for convenience. It comes with a lot of useful stuff for general use. Contrary to a comment further up I’m not looking for a too specific game engine, more for general modules and utils/helpers for development as I see Pyro 2. Anything that’s too specific I’d rather write myself, otherwise I think any framework that tries to cover too many specifics and game types out of the box will in the end be too limiting and require bandaids and workarounds to make things behave the way I want. The general approach works better for me.
So far I’m mainly using the scene graph “basics”: virtual resolution, layers, sprites, camera, etc. I’m not using much of the framework yet, but I’m sure this will come in handy sooner or later, i.e. object pool, collision, pathfinder, screen manager, and also TexturePacker support. I think it can save quite some time to have these modules available.
+1 for a Github repo, just for the ease of updating (and possibly customisation, but I’m hesitant about that). But (I guess) I understand why it’s on Itch.io, it just makes it more obvious that you can donate.
Oh, and btw, is there a reason why the Pyro framework is split up into smaller modules but GUI and Scenegraph each are one long file? Not that it makes a big difference, but I find it quicker to find the source when it’s split up.
Thanks for Pyro2, Playniax! I think it’s an awesome addition to Monkey2.October 18, 2017 at 6:45 am #11163
Thanks guys! I will continue to work on Pyro as long as Monkey2 is activly developed.
is there a reason why the Pyro framework is split up into smaller modules but GUI and Scenegraph each are one long file?
I just prefer to start modules that way and split them up later. Time sometimes just gets in the way. One day probably I will split the files up.
You must be logged in to reply to this topic.