35) Let's extend the picture (sprite) editor to have an optional collision layer on top of each sprite. Or multiple layers. That we could then trigger through events.

I think that'd be the simplest way to define weapons and stuff for collision events.

So, in the picture editor, I'd create my sprite and then create a new collision layer (like in Photoshop) that I could fill up with pixels. Then I call my collision layer "swordCollision" for example. If I go to the next frame, it'll automatically copy over the collision layer from the last frame and I'd just do my adjustments. So for the whole animation, I'd have one big collision set of layers that could be triggered through the name of the collision set.

So, to set an attack event, I could do this:

If Attack is pressed, if player.swordCollision collides with enemy = decrease enemy private variable 'HP' by 10.

Simple.

Being able to have a seperate layer in any sprite that you could fill up with pixels based on what should and shouldn't collide with whatever would be a very, very handy feature.

Event sheets go in the event sheet folder? Makes sense to me.

Displaying them twice is what's confusing me.

Wow, it does look great. It's 3D and scripting-based though. Looks like a 3D construct sort of

It's still a different ballpark.

Construct is still faster and easier to access for artists. Unity is production proven and ready, which is a big plus, but there definitely is a big difference in how Unity works and how Contruct works.

Now, if Unity would have something like the event editor and if it'd be as smart as Construct in that regard or even go for a completely nodal system...

That's very nice. Only thing I'm wondering is why you've got two layout 1 event sheets. The layout 1 event sheet is directly parented to the layout 1, which makes sense, but why is there another folder with event sheets where there's another Layout 1 event sheet in there? That's a bit confusing.

Other than that, it looks ace. Will make the organizational part much easier

What??? It definitely shouldn't be doing that - I definitely wrote it to scale and rotate collisions too. Submit a bug report!

Already did

13) Okay, I either don't get a feature here or I encountered another bug.

It's about the timeline this time:

Basically, I want the player to run across a certain point (if player overlaps...), then start a timeline event that feeds into a textbox, so we can spin the story further if the player has reached a certain point in the layout.

The problem is: I want the timeline to run once and then be gone. So if I go back and overlap that point again, I don't want to invoke the timeline AGAIN, cause I don't need to hear that part of the story twice.

So there's a Delete Checkbox in the timeline event and I thought this would be exactly what I'm looking for - so if I run cross that point, it'll run the timeline parameter and delete it afterwards. Then it'll run the next timeline param and delete it afterwards, etc.

But that's not happening. And if I re-enter the timeline object after I checked the 'Delete' checkbox, it's unchecked again.

So:

1) Is this feature supposed to do what I'm thinking it should do?

2) Is this a bug or am I misinterpreting that feature?

Just found out that if you set the collision model to be 'per pixel' and you scale the sprite in the layout editor, the 'per pixel' stuff is still being based on the 1:1 sprite.

Wouldn't it make more sense to base it off of the actual pixels of how the sprite is being drawn at runtime?

34) I'm currently trying to create an 'Attack' event and I'm wondering how we'd best set this up. Currenly, my setup looks like this:

On collision between Player and EnemyFamily

is global variable 'Attacking' Equal to 1

= enemy: subtract 5 from 'HP' (which is a private variable for each enemyType)

EnemyFamily: Value 'HP' Equal to 0

= EnemyFamily: Destroy

And that sorta works. Now, the problem comes with the collisions themselves. How would I define that only the pixels of the sword actually hurt an enemy - and not the whole playerSprite?

It'd be really cool if we could create a collision layer for each sprite in the PictureEditor that we could then trigger for events. So for my character, I'd create a collision layer for the 'Attack' Animation and color in all the pixels of the sword. Then I'd name that layer something like "Swordmask"

Then the event would be:

On collision between Player.Swordmask and Enemy Family... etc.

Or is there an easier way to set things like that up that I just don't know of?

Yeah, it'd be cool if it could work like a tiled background that we'd just feed with the source data. The current windows-y implementation isn't all that great.

Unity is geared towards 3d development not 2d. It is a quite powerfull engine and with great tutorials although it's a bit pricey! The indie licence costs $200.

Yeah, but a lot of 2d games have already been created using Unity. Here's one people might know:

http://www.thecareergamer.com/?p=513

200 bucks for the indie license is dirt cheap IMO - if you think about what you can actually do inside of it. I'd also not have a problem paying 200 bucks for Construct once all the 'basic' stuff is in there that'd allow you to ship competitive games, like controller support, networking, vram controls, etc.

http://unity3d.com/#whatsnew

I just gave it a try today and whilst I don't think it's in the same market as Construct (which is just a lot quicker for fast prototyping and the turnaround of 2d games in general), it could be one of the engines where you could build up a prototype to deploy it on different platforms, like the PC, the Mac, Wii, iPhone, etc.

Could be interesting. Lots of iPhone games have already been created using Unity.

I could just upload it on my webspace, did that here:

http://thomasmahler.com/files/construct ... %20school/