Dines's Forum Posts

  • Copy/Paste of alpha channels should be added if it aint already <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

    Also, how about a little feature to sense what's on the clipboard and seek an appropriate object to import it?

    So if I select some HTML text in IE, and paste it into the Layout Editor, Construct will think "Oo! HTML text!" and place an HTML Control floating at the mouse position, containing the HTML text we pasted. You then click and the object gets placed there.

    Similarly if the clipboard data is an image, Construct could insert a sprite containing that image.

    ASCII text would paste as a string object, RTF text would paste as an RTF object.

    Also, in the event sheet editor, t'would be lovely if we could drag a 'Set variable' action into the conditions space, thereby creating a 'Variable is equal to...' condition. Just to speed stuff up really.

  • I'm a little concerned that one or the other will be neglected, but we'll see what happens. I know that's not the plan, but often when you have two entirely different ways of coding something, one way takes precedence.

    But I really do welcome the whole modularity thing.

  • Yeah, it could be cool to deliberately store sprites externally once the game is built to an EXE. I'd love it if people could mod my games easily!!

    It worked for halflife <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

  • In the meantime, there are ways to cut down on the processing.

    You can test how close enemies are. For instance, if you have 100 enemies in the level, but only 10 are on screen, only run an LOS test on those 10.

    Also, when doing an LOS test, you may use several detectors, but only do ONE test. So on each loop, you need to arrange the events so it moves all the detectors at once.

    That'll cut it down a lot.

  • I don't think directs are a problem.

    You would handle it this way:

    Always

    • Shoot bullet at player

    if the bullet hits the player, he can be seen. If it hits a wall, then there's no line of sight.

    I think it uses 360 degrees, with decimal precision, so it'll hit its target.

    You can also layer the loops, so fire a detector to test if the player can be seen, then resize it to the size of the enemy and fire again - this time to test if the enemy will actually fit.

    You can then set these as states:

    CAN SEE PLAYER = YES

    CAN WALK TO PLAYER = NO

    -Then stay where you are and shoot

    CAN SEE PLAYER = YES

    CAN WALK TO PLAYER = YES

    -Then run towards him and shoot

    CAN SEE PLAYER = NO

    -Wander aimlessly

  • One idea may be that for the project panel, you could simply have folders like this:

    Layouts

    • Jungle Madness 1
    • Jungle Madness 2
    • Street Rage 1
    • Street Rage 2
    • Create New...

    Event Sheets

    • Loader
    • Player Movements
    • AI - Monkey
    • Create New...

    Objects

    • Player - Default
    • Player - Cool
    • Player - CyberSuit
    • MY MONSTERS

    -- Bullfrog

    -- Lizardman

    -- Chinese Person

    -- Polish Martian

    • BACKGROUNDS

    -- NORMAL

    --- Grass

    --- Sky

    --- Tree 1

    -- SNOW

    --- Grass

    --- Sky

    --- Tree 1

    • Create New...

    Subfolders, etc, would be created by the designer. So it'd be up to the designer to determine how things are organised internally. But perhaps subfolders could be changed at runtime? So an event to find all textures in 'Backgrounds\Normal' and change the active path to 'Backgrounds\Snow' would instantly load the snowy equivalent?

    This idea's only rough, but at least it'd help organise stuff. At the moment, I think it's too heavily centralised on the Layouts.

  • Lol, it's basically exactly the same as construct now, just with an extra box on the 'Project' panel.

  • I have an idea for the Interface that may help with sheets and layouts:

    http://i202.photobucket.com/albums/aa130/ChrisDines/constructidea.png

    An extra part of the projects panel for showing event sheets.

    In the Event Sheet Editor, you could even have the ability to drag a sheet from this panel onto the Event Sheet you have open in the Edit Area, and when you let go it would appear as an include where your mouse is.

    The idea is that you have normal event sheets, and 'private' or 'local' event sheets. Normal ones are just includes, and local ones are level-specific. You have just one local one per Layout, and it can't be included by another sheet.

    So for instance, in the above picture, we have some includable sheets that I've named:

    • Loader Sheet

    + Custom Movements Group

    -- Player - On Foot

    -- Player - Driving

    -- Player - Flying

    In addition, there's a 'My Groovy Layout Events' (MGLE) sheet, which doesn't appear in this list, because it belongs to the 'My Groovy Layout' layout.

    If I have code which is level specific, like 'enter the cave and the entrance collapses', this would go in the MGLE sheet. This sheet is local to that layout, a bit like a private variable.

    This is also where we define any includes that this Layout will refer to.

    Of those includes, I've (in the above example) chosen to have one include that handles all the others. So I've created a sheet called 'Loader' which determines what other includes will be refered to. So for instance, if there are no drivable cars in the level, it'll not bother to include the 'Player - Driving' sheet.

    This could quite easily get around the problem of cloning events with layouts. When a layout is cloned, perhaps its private event sheet is cloned too. This would keep all your 'include' references intact, and would allow TGF users to use the methods they've got so used to.

    But for the rest of us, it'd save us re-including the same sheets for every new level

  • <img src="http://i202.photobucket.com/albums/aa130/ChrisDines/Picture5.jpg">

    I is all kinds o fine, wiv mah big hair, an' mah sasseh grin. Mm yeh. Yous all wants mah hair.

  • Yeah, the Construct event system is a lot more powerful than MMF's, with more advanced functions and loops, and you can do subevents.

    Are you an MMF user already and just trying Construct as an alternative, or are you trying to decide between the two?

    MMF has the obvious advantage that it's finished, has a lot of users, a lot of examples and a lot of documentation already out there. But that's not a benefit of the software, per se, just its age.

    Construct also has an awesome physics engine being grafted onto it. While similar plans are underway for an extension in MMF, I don't see how it will be as powerful (because it has to be a plugin, whereas Construct can handle it a bit more directly).

  • Doesn't stop him playing with Barbie though <img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" />

    LOL. Sorry, couldn't resist! <img src="{SMILIES_PATH}/icon_lol.gif" alt=":lol:" title="Laughing" />

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • A few things that'd be nice for the Physics Movement:

    Being able to position a physics object to a non-physics object.

    So for example, positioning an object to the mouse coordinates, so you can make a brick follow the mouse, and move/slow down with the force of the mouse. So you could use the mouse to pick up an object and wack other objects with it.

    I suppose you'd do it by checking where the mouse is, and where the object is, and working out how much force it would need to have moved to that position.

    EDIT: Also, with hinges, there seems to be a problem with the Stiffness variable. It crashes if I try and edit a hing-to-object action, and the stiffness value always appears as 0 in the main event sheet editor.

  • Out of curiosity, did you ever make maps for Age Of Empires II?

    That had an event system which works the same way as Construct.

    The basic gist is thus:

    Selection Conditions

    Construct has a list of conditions and actions (the event sheet editor). It scans this list from top to bottom, then scans it again, then again, and again, every time a new frame is drawn. The most basic condition is:

    Always

    This condition will trigger on EVERY pass of the events. So if we drew 100 boxes and did this:

    Always

    ---Set X position of BOX to box.xpos + 1

    ...It would move the boxes to the right by 1 pixel on every frame.

    In addition, Construct assumes by default that you mean ALL the boxes. So EVERY box will move.

    If we want to set specific boxes to move, we have to narrow Construct's 'object focus' down using other conditions.

    So we could do this:

    X position of BOX > 320

    ---Set X position of BOX to box.xpos + 1

    The condition basically says 'Is X position of BOX greater than 320 pixels?'

    It scans EVERY box, literally asking it 'where are you?' and then it strikes off the list all boxes that don't match the criteria you gave it.

    So when it comes to process the action, only the objects with an X position of 320px or more will move. You'll basically see the objects on the right-hand-side of the screen move, and the left will stay where they are.

    You can enhance this further with more conditions:

    X position of BOX > 320

    Private Variable 'Health' > 20

    ---Set X position of BOX to box.xpos + 1

    This narrows its selection down, first selecting only those on the right-hand side of the screen.

    Then, OF THOSE OBJECTS STILL SELECTED, it checks whether their health is greater than 20.

    So now when it processes the action, it only moves the ones on the right that have a health value of 20 or more. Weaker boxes, even though they're on the right, will not move.

    This concept is ultimately like using a database. I don't know if you've used databases much, but it's a bit like having a list of names and saying

    "Select all names, where county is 'Surrey', town is 'Caterham', 'Street' is 'Beggars Green'"

    It's that kind of thing, but with objects.

    This way, you can decide whether your code will apply to just one of many objects, or to a group of objects, or to all objects.

    Trigger Conditions

    These conditions are a teensy bit different. Normally, Construct just processes the event list from top to bottom, then does it again, then again, then again.

    However, some conditions can be Triggered. These include:

    'On Function' and 'On Start of Layout'

    We can have an event like this:

    On Function 'Move'

    X position of BOX > 320

    Private Variable 'Health' > 20

    ---Set X position of BOX to box.xpos + 1

    And it will normally be skipped by Construct as it scans the list (because 'On Function "Move"' has not been triggered).

    However, we can trigger it from inside another event by doing this action:

    Run Function 'Move'

    Then suddenly, it pauses everything and looks for all the events that start with 'On Function "Move"'. It will process them all, in the order they appear in the event list.

    When it's done 'em all, Construct goes back to where it was and continues as normal.

    So this way, you can run loops and functions and stuff from within other events, and they will be processed instantly.

    That's basically how it all works. You use Trigger Conditions, to make sure something is only tested when you want it to be. And you use Selection conditions to narrow down which objects will be affected by this event. Then you define actions that will happen.

  • Would it be possible to set the frames in a time speed instead, or have the option to do that?

    Because if you use a system for slowing the frame rate depending on the system's performance, animations will go slower.

  • I could build it, but my main problems are with the image editor, so I can't really create new sprites for the object types and stuff.

    But Construct's noticably better than it used to be!