I'd suggest the second one, although you might need to do what they did in katamari, and have smaller versions of each sprite that you load up as it gets bigger to save vram, also maybe something using canvas to paste all your sprites to everytime you get a major zoom , so you're not keeping track of the rotations of hundreds of objects
imagine that you made the exact same red circle, without physics
and you made a pink circle with physics the exact same size, but set to invisible
every frame you told the red circle to set it's location and angle to the invisible pink circle
so far it behaves the same, but when you pick things up, you figure out a math formula that will change the shape of the invisible pink circle so that it circles the redball and the junk, and you'd have to find other formulas and expressions to position the ball on this new pink one, but the idea would be something like this:
Yeah, I was thinking the same also with the smaller versions of sprites. If this is anything like what I want it to be like, there's going to be hundreds of objects and I'm not sure if people's computers could handle it. But I am very new to construct and I have no idea how to use canvas to "take a screen shot" of the katamari when it goes through the zoom process so that we're not rolling the actual ball anymore.
I'm very new to Construct but I'm well-versed in MMF2 and I've been using it for years. I very recently switched to construct because it seemed much more powerful.
The pink ball is a great idea, but I'm not well versed enough in Construct to even start thinking about how to code something like that... I'm sure someone could do it though. I need a team of people for this game, I'm thinking.
Hmmm this might be doable with straght physics objects... using two hinges per object instead of one would effectively "weld" it to the new object... in theory.
I might have a tinker later with some ideas and see if I can figure something out. I love the Katamari games (no pun intended), so it would be fitting to have a Katamari clone made with Construct.
~Sol
That was my initial thought, although I couldn't find a way to get the objects stuck to the katmari stick to each other. See, an object that is stuck to the katamari needs to pick up other objects that it touches. But the objects can't stick unless one of them is stuck to the katamari, otherwise you'd have objects stuck together everywhere. So we need something like this...
If the katamari touches an object...
If object is smaller than katamari...
Stick the object to katamari
Turn on variable "stuck" to object
If variable "stuck" is on...
On collision with new object...
If new object is smaller than katamari...
Stick new object to object
Turn on variable "stuck" to new object
I'm actually working on a lot of art and sound for this game and it's going to have an interesting paper cutout style, or perhaps a retro one. But if anyone is interested in joining the team with me and helping with coding, I'd love it.
Another important feature is that every object is assigned a size, and that the katamari automatically picks up anything smaller than it. This way you don't have events for EVERY OBJECT that the katamari picks up. Something like this.
(Object is 5cm, size is a variable. Katamari is 55 cm.)
If Katamari size is > than object size, pick up object.
On collision with object smaller than katamari...
Stick object to katamari
Add object size variable to katamari size variable.
So the katamari should now be 60cm.
However there is a problem with this too (other than the fact that I don't know how to code it.) The katamari needs to only pick up objects that are at least 40% or maybe 50% smaller than it. You don't want a 200cm katamari picking up a 199cm object.