GMG's Forum Posts

  • I'd love to see cap files replaced with something along the lines of an IDE style project folder. The general project info would be in an XML file (settings, lists of objects & plugins, etc.). Everything else would be pushed out into sub-folders (images, music, data, layouts, events, scripts, etc.).

    C2 could then have a function to bundle entire project folders into zip based caps for sharing, but still giving teams the ability to collaborate on project using CVS systems. Event sheets, layouts, object settings and families could all be created using XML files, meaning you could even make small changes to projects using notepad.

    Unity3D has something like this, whereby dropping a file into a project folder immediately makes it available in the IDE. A really nice system, IMHO.

  • If you're talking about free 3D game creators, then maybe somebody should mention Unity and ShiVa.

  • I've been moonlighting as a Stencyl beta tester for a couple of months now, when time allows (I'm a busy guy). I just want to say a couple of things, hopefully without breaching the NDA in the process:

    • The programming system, strange though it looks, is probably the closest thing I've experienced to proper programming in a drag and drop system.
    • The games they have demoed are not the only ones in existence, are they are still in development. There are many more in the beta community, including one of mine.
    • The engine is Java based (pulpcore) and the games play in the browser, which means no hardware acceleration. It's a trade off of power vs. cross platform compatibility.
    • The big selling point for Stencyl is the collaboration. There is a real emphasis on sharing resources and creating reusable assets, so that devs don't have to reinvent the wheel all the time.

    Overall, it's a decent game making system, and like all such systems it all depends on the talents of the people using it. There is enough flexibility in the software for someone talented to do some impressive work. I wouldn't necessarily say that it is competing with Construct - they have an entirely different set of objectives.

  • Just to clarify, for my own sake (I still struggle with picking)...

    • The condition "if sprite is visible" will run once and add all visible sprites to the SOL
    • The condition "for each sprite" will loop through all of the sprites in the SOL
    • Actions under this event will be executed on each sprite in the SOL as the loop is iterated

    Is this correct?

    So, "for each sprite, if sprite is visible" will produce the exact same result as "if sprite is visible, for each sprite", however the later is more efficient because the SOL has been cut down before the loop.

    I think it's another example of the need to unlearn some of the conventions of traditional programming when working with eventing. Normally, I would do it like so (psuedocode):

    for (sprite in sprites) {
    if(sprite.visible == true) {
        do stuff
    }
}
[/code:1cv9a7p5]
But with eventing you have to think a little differently.

  • If your animation appears to be sliding, then you just need to adjust the values between movement speed and animation speed so that they match up. Either slow down or speed up you object, or lengthen/shorten your animation frames.

    Look at how many pixels your character's foot moves in a single loop, and make sure that your character moves roughly the same amount in the same timeframe. The simplest way to do this is through trial and error - test different values until you find one that works. To save compilation time, you could tie the movement speed to some keys and adjust it on the fly, then input your final values after testing.

    Of course, if your character has acceleration and deceleration, there will always be a point when the feet don't match the motion. In game maker I would fix this by tying the animation speed to the movement speed, but I'm not sure if that's possible in Construct. You could fake it by having two animations - run and walk - and switch between them when you hit a certain speed.

  • Currently just a mockup, although I have a little of the engine done. First ever try at pixel art.

    Normal size 8X8 sprites

    <img src="http://i19.photobucket.com/albums/b170/mr_flibble_hhah/pixrick-2.png">

    Blown up X4.

    <img src="http://i19.photobucket.com/albums/b170/mr_flibble_hhah/pixrick.png">

    Those look brilliant, Minor. Do you mind if I give you a little suggestion though -

    Try to establish a common light source in the tiles. Your rock walls have light coming from several directions. If you were to set up a consist light source with your highlights and shadows, the tiles will read much better.

  • The hotspot is the object's xy position as far as the game engine is concerned. The image of the sprite is drawn relative to the hotspot. So if the hotspot is at (0,0) on a 16*16 sprite, and the sprite is at (100,100) in the game, then it will be drawn in pixels (100,100) to (115,115). If, on the other hand, your hotspot was in the centre, your sprite would be drawn from (92,92) to (107,107), or there abouts.

    You can use this to trick the player into seeing a 2D world that appears 3D. Imagine looking down on your game world from directly above at 12 0'clock, with the shadows of the objects acting as collision masks. If you were to tilt the camera upwards the shadows would appear below the objects and any objects off the ground would appear further from their shadows, but the game would still see the world in terms of the collision masks (i.e. the shadows).

    I think a diagram may explain this far better than mere words, but I've been playing MegaMan 9 all night so I didn't get around to making that example I promised. It's coming, I assure you.

    Can't help with that aiming issue though.

  • The trick is with the hotspots. You need to offset them to account for the height of the object, from the ground upwards. Your cannon ball is off the ground, but in 3/4 view your hotspot needs to be the centre point of the object on the ground. In this case, you need to shift the hotspot to account for the height of the ball. I'll try to put together an example or tutorial or something later today.

  • You need to do some Z sorting on your objects, since the view you are describing will have different objects obscuring each other based on how far down the screen they are. I'm making an assumption here, but if your game is based on the top-down 3/4 view (i.e. Zelda 2D games), then you will need to sort by Z.

    The best approach i've seen uses a PV called Z. Every tick your objects set their Z to be equal to their Y, then you loop through all sortable objects based on their Z variable, and send them to back (or bring to front, can't remember now). It might take some fiddling of hotspots and image points to make it work properly, but the basics are all there.

    This will mean that your cannonball will be drawn infront of objects that are further up the screen (i.e. behind), and vice versa. There was an example of this on the forums a couple of weeks ago, try looking for it.

  • can you set the sprite to check "overlaps at offset y+1 with vertical platform object", then deactivate gravity and directly set y to be the platform's y-height? Then just reactivate gravity when you jump. Don't have construct here, so can't confirm.

  • CVS systems store details of all revisions of every file in the project, so if you're using a website stripper to pull down a copy of the entire Construct CVS site, you may well be pulling down copies of every single revisions of every single file every uploaded to the CVS.

    If you have a 'main.c' or something that has been revised 50 times, the CVS system will hold the current version of the file along with details of all changes made since the original upload, in terms of additions and deletions. This is stored as series of 'commits', likely as diff files. The online viewer for the CVS has links to all revisions, which would include a dynamically generated version of the file at that revision. Those links get recognised by your site downloader and it will download all those old versions that you probably don't need.

    Do yourself a favour and follow lucid's advice - get a CVS program like tortoise, and download the source as a set of folders and not as an offline site dump.

  • I see what you mean now. I've also wondered about flipping sprites with regards to the hotspot position, although not with the idea of scaling to those magnitudes.

    I suppose you could mitigate this problem a little, but not entirely, by using double or quad sized pixels (i.e. hs at [3,3] on an 8*8 sprite). If the hotspot is in the centre of this chunky pixeled sprite, it won't shift so much when you flip it.

  • the hotspot IS the entire pixel. This is the only way it can work - you can't place the hotspot in any particular part of the pixel - the coordinates for the hotspot are the exact same ones as the pixel it is placed in. When you are zoomed in, the pixel looks like it has a width and height, but this is deceiving - the pixel only has xy coordinates within the whole image.

  • 1800 x 1800 is not very effiicient in terms of VRAM. You should be working with power of two sized textures - 2, 4, 8, 16, 32, 64, 128 .... 1024, 2048.

    Your 1800 square image will actually use 2048x2048 pixels in VRAM, with over 200 pixels wasted in each direction. If I was you, I'd shrink it down to 1024, then stretch it up to the size you need. The texture should end up filtered and smoothed when you stretch it, and in motion you probably won't notice the reduced resolution.

    Bear I mind that I often think I know what I'm talking about only to be proven wrong by more knowledgable folks, so take this with a pinch of salt.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thanks for the reply guys. My plan was to introduce the CMB later on when things start to get more complicated. For the first couple of lessons, making games like PONG/Breakout, I was hoping to be able to keep things simple, i.e. Ball, 8-Way, etc. No big deal - the students probably won't even notice the inaccuracy (just my own perfectionism rearing its ugly head), and those that do can be pointed in the direction of the CMB.

    As far as the expression is concerned, I was just wondering why "Ball[CustomMovement].Angle" works, but "Ball[Ball].Angle" doesn't.