deadeye's Forum Posts

  • The head-jumping sounds like a good idea. Oddly enough, I haven't tried making any head-jumping examples yet, but I'm pretty confident I could come up with something.

    I thought about doing a melee attack also. Ghost Shooter already covers bullets, so I don't need to worry too much about that.

    I suppose I should do a bit on sound as well now that I think about it.

  • Special effects are more of an advanced thing. I'm planning to stick mainly to the basics of making a game work. The most I'm going to get into special effects is like, how to do parallax scrolling (if you can even consider that an effect).

    I might do some polishing tips at the end, like how to spice up menus screens and whatnot, and I could include a bit on effects there I suppose. But that would be like, "extra credit" .

  • Okay, so I've started working on a series of tutorials that cover the basics of constructing games. It focuses on platformers, so there will be some stuff in it that is platformer only (I plan on doing a section for moving platforms and ladders, for instance) but it will also have general knowledge about how to set up and work with animation, how to use detectors, how do do simple enemy AI, etc.

    It's called Platform School.

    <img src="http://i35.tinypic.com/2cgzdy8.png">

    The way I'm designing it is the tutorial is the actual game. You open the .cap in Construct, run the game, play through it reading the signs, and the signs tell you step-by-step how everything in the game works. (The signs even tell you how the signs work )

    Anyway, it's meant to be interactive, so like a sign will tell you to go to the IDE and check out this property or that event or whatever, so you switch back and forth between playing the tutorial game and looking at how it's constructed.

    It's going to be a series of .caps, or "classes," and in each one a couple/few new things will be added and explained, so by the time you get to the end of the lessons you have a pretty good idea of how to build a game up piece by piece.

    It's meant for beginners (especially the first part) but it will assume that they've already gone through the Ghost Shooter tutorial and gotten an idea of how to use the IDE. Hopefully by the end there will be a few advanced tricks to learn, but really I just want to stick to the basics.

    Anyway, this is where I need some help... what are the basics? What are some of the questions that come up all the time that could be covered by my tutorial? I plan on putting in information about why animations stop when they're not set to loop, and that sort of thing (it's pretty common). I'm also including tips on organizing code into groups and event sheets and such.

    I'm open to suggestions for things to put in, so I can create a lesson plan. What do you guys think?

  • No Sol, see it's... well, yes, it's a reference to dragons balls or whatever, but there's a twist... it's also a reference to my postc-

    You know what, never mind. Oh look, a bird...

    <img src="http://i35.tinypic.com/141meza.jpg">

  • Hmm, looks like no porn-stars-on-the-hoods of cars sigs for poor old Sol

  • Puny mortal. You dare defy me?

    *goes super sayin*

    *types furiously*

    Behold the power... it's over nine hundreeeeeeeeed!

  • You may have won the battle, but you will never defeat my mighty postcount ('cept Ash).

  • I would prefer to see the wiki used for explaining Construct functionality and see tutorials for individual techniques and such kept to the forums.

    Just my two cents.

  • My point is that raster graphics take a lot less processing power than equally complex vector graphics, so that would make more sense for a web app, especially since everything else in your browser is raster anyway.

    There is no commonly used web standard for vector images, for instance. Everything uses gif, jpg, or png.

    Sure, they're not scalable in the same manner, but still.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Perhaps an addition can be made as well to the point collision system to include image points added to the Sprite.

    Then no additional animations would be needed to expand the point slightly.

    You can already do this.

    +System: Sprite collides with point at Sprite2.ImagePointX("colliderpoint1"), Sprite2.ImagePointY("colliderpoint1")

+System: Sprite collides with point at Sprite2.ImagePointX("colliderpoint2"), Sprite2.ImagePointY("colliderpoint2")

etc, etc, repeat for all image points
[/code:1mwlxpc5]

But I hardly think that's easier than my way.

  • That's some sweet pixel art, man. Can't wait to play this.

    And welcome to the forums!

  • Yes, it can do particles, but you have to code your particle systems from scratch.

    Basically you can program whatever you want in Flash, but that doesn't necessarily mean it's going to run well. The more complex your game visuals, the slower it will run. And it doesn't take much complexity to start bogging down.

    Frankly, I'm surprised that Flash has become the standard that it is, and I wouldn't mind seeing it go away forever. I mean, who the hell thought it was a good idea to do vector graphics in a browser? Fundamentally it just doesn't make much sense to me.

  • A very simple solution that doesn't use any detectors at all:

    http://www.fileshack.us/get_file.php?id ... hitbox.cap

    The "bullet" (in this case, the big blue square) has two animations, one that is it's "display" animation which gets drawn to the screen, and the other which is it's "hitbox" animation that does the collision. The hitbox animation is smaller than the display animation (32x32).

    Before doing any collision checks with the player, set the animation of the bullet to "collision." After checking collision events, set it back to "display" so that Construct will draw the correct sprite. Construct only draws the screen after all the events have run, so you will never see the bullet showing it's collision box animation.

    In this example you can see that even though the player (brown box) can walk onto the "bullet," he doesn't get knocked away unless he touches the center of it.

    This should do exactly what you need it to do, and in fact would be a good way to do custom detectors in general without using separate objects.

  • My point is, its a gadget so its fun but not vital.

    I'm pretty sure I'd shrivel up into a little raisin and die if I didn't have a computer.

    That's a medical fact. You can ask my doctor.

  • I don't really understand what you mean by this:

    whats the best way to shoot a very large amount of box bullets with an object attached to it, so I get my graphics looking right with a correctly sized bounding box attached to it?

    But I'm guessing you want to make little collision detectors around an oddly-shaped object? Why don't you just use Per Pixel collision? Or if your object is too detailed, make a separate less detailed sprite that's roughly the same shape and use that as it's Per Pixel collision.

    And if that doesn't help you out, maybe try explaining what you're doing a little better.

    And you shouldn't really see any big difference in framerate until you have a couple thousand things on the screen, unless they have effects applied to them, or they're like physics objects or whatever.