My ongoing list

Yeah, the actual Windows progress bar can't do custom graphics, I'd just use a tiled BG or Sprite with hotspot set to the left.

The dialogue stuff from the previous page is still biting me in the ass, but I had another cool idea.

27) Wouldn't it be cool if we could have a custom 'Character Sheet'? Whereas a 'Character' could be anything. It'd just be a container where a Character and all it's attributes and everything that has to do with it is listed and linked to the 'real' settings, so as an example:

Say we have an RPG with a Party - I could throw all the party members into a Custom Character Sheet and would directly see and be able to edit all their attributes, variables, access their animation sheets, etc. etc.

Right now, characters really aren't more than sprites with animations. And to make changes, we sometimes have to hunt down longer lists of data and so on - it'd be nice to have one simple place where the characters and all that has to do with them is stored and can directly be access in one simple, nice, streamlined place.

For that I'd recommend putting your character in a container with a hash table object or array, which you can store lots of stuff in, maybe?

28) Right now, we can't order Effects. So, say I want a black and white effect on top and then a soften effect. If I first applied the soften, I don't really see a way of how to tell Construct that the Black and White should happen first - then soften.

29) From an organizational point of view, I read that the objects folders are gonna be pretty helpful.

Can't we get the same thing for the project palette? So, instead of having a layout sheet and an event sheet and both just separated in the list to the right (right now, the only way to know which layout belongs to which event sheet is by giving both sheets similar names), we'd create a 'level' sheet and inside of that level sheet we'd find the layout and the event sheet. Then, we could manage all the level sheets that should be together in folders.

The hierarchy would still be the same, so we'd go from folders to level sheets to the layouts sheets that are then influenced by the event sheets.

It'd just give us 2 more layers of organization - I think that'd make way more sense.

30) I have a new idea for a behavior: A 'detector cone' object.

So, basically, if you've ever played Metal Gear Solid, you know what this is about:

<img src="http://thomasmahler.com/files/construct/images/radar.jpg">

We basically would assign 'cones' to a sprite and define it as their 'detector' behavior. So, we could trigger events like:

If player is being detected by enemy1's cone - enemy 1 is alerted.

The cones should be parametric, so we could define the cone angle and the radius directly in Construct - so we could dynamically create enemies that don't see very well and others that see really well, etc.

Also, the cone should be able to be stopped at obstacles. So, if I stand behind a wall and the enemy is on the other side of the wall, if his cone detects me, the event shouldn't be triggered if there's a wall between us.

This could be used for enemies in general in a multitude of genres or even for those desktop tower defense like games, where every turret would act according to such a cone detector.

This would pretty much allow us to simply emulate the visual AI of enemies - so they can actually see or not see a player and their detection 'skill' is based on the creators input.

Now, how could we solve this for sound? Like, if the player has to sneak through an area, how do we create a gameplay event that'd help us define the area in which enemies can hear the player if he starts being noisy by running, jumping, doing something noisy in general?

Now, our ears don't work like our eyes in the sense that they're not bound to a certain angle. We can hear what's behind us, but we can't see what's behind us.

So the solution should be simple - a sphere! In the same way we attach the cone to emulate an enemies visual field of view, we could create a sphere to basically emulate his ears. So, if the player makes noise inside of an enemies 'audio sphere', we could trigger an event that'd alert the enemy.

So, for a sneaky game or generally just to make our enemies smarter and sorta emulate a simple AI that could be very convincing already, we could add events and base triggers on them. So, we could make a private variable that would define how much noise the player makes - and this'd just be an additive variable.

So, the base noise would be 0. If the player just walks around, he doesn't make any noise at all. If the player starts running, we set the private variable to '+20'. If the player jumps while he's running and lands, we add another '+20' the moment he hits the ground. If the player activates some switch, we could add '+10', etc.

Because of that setup, we could again create enemies that hear well and enemies that can't hear shit. That could make for some very interesting gameplay schemes, where the enemy has to outsmart those relatively 'simple' systems, but it sorta feels real, cause you don't see the cones and spheres.

So if we give our enemies cones for sight and spheres for sound our enemies could actually SEE and HEAR us, which could be a HUGE plus for a lot of games.

Metal Gear Solid on the original PSX was awesome because the enemies seemed a lot smarter because of that - and imagine a zelda-like adventure where you have to sneak inside of the castle and actually be smart about your movement and about when you start running, activate switches, etc.

Also, it'd help for these kind of games:

31) Fuck the idea with my 'level sheets' - that's a load of crap. We can just organize everything in folders. I created a quick mockup:

<img src="http://thomasmahler.com/files/construct/images/projectMockup.jpg">

32) A 'Recorder Object' would be cool. So that'd just be a simple global non layout object like mouseKeyboard and we could set a key to it - then, at runtime, we could hit the key and the recorder object would start doing it's thing. We could record pre-defined movements for each sprite (character) to help with the cinematics stuff and could mix it with pre-defined animations.

Valve has something similar which they've used to do some of the TF2 cinematics:

http://media.moddb.com/images/groups/1/ ... mmaker.jpg

As far as I know, you basically record one character after the other, can set the camera and stuff and get a couple of export options.

This idea isn't well thought-out yet, but it'd be cool having a simple to use method to create in-game cinematics that aren't player controlled.

33) http://www.davidhellman.net/blog/the-ar ... id-part-4/

I really liked this article by David Hellman about how they created the art for Braid.

It seems like the idea was a little different than Braid. If I interpret it correctly, they were able to play the runtime directly in the editor, which would be pretty cool. That's one feature I loved about the CryEngine - you can just jump into your layouts from the editor and don't have to let another window pop up, etc.

Maybe you'll guys find some inspiration reading that

— Detector Cone: Can be done with Dist(x1,y1,x2,y2) and angles.

And obstacles?

And obstacles?

Hmm well then add "Line of Sight" behavior and you have Cone Detector.

And it'd still be a bitch to adjust the cones dynamically for each enemy type. A cone detector behavior where you could directly modify the cone and where the obstacle stuff is in there (my guess is that you shoot a vector and if the vector hits a solid, it stops detection from that point on) without me having to do workarounds would be neat. You could use them for most genres anyway, whether it's top-down or a sidescroller, it just makes sense.

31) fsck the idea with my 'level sheets' - that's a load of crap. We can just organize everything in folders. I created a quick mockup:

<img src="http://thomasmahler.com/files/construct/images/projectMockup.jpg">

I really like this one, I'll see what can be done.

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?