Candescence's Forum Posts

  • My first two picks:

    • Tilemap Plugin. I cannot stress how absolutely useful this would be for users in general, and a good portion of the community has been clamoring for it since the 0.x days.
    • Families. Yeah.

    My secondary wants would be a Turret behavior and Containers, but the former is mostly because I want it for my game. XD

  • Yeah, I think I'll stick with Construct...

    Also, why Flash? Why not just use Java, if not HTML5? Java should have filled the niche of web-based games that Flash mostly owns... Except that early versions of Java were so slow and so unnatural looking that Flash actually looked good in comparison. By the time they fixed it, Flash had become the de-facto standard for this kind of thing, much to the chagrin of just about everyone except Adobe.

  • Alright, might as well throw up an image of my current game idea, which I'm prototyping in Construct Classic while I wait for C2 to reach the right level of features I need for it.

    <img src="http://dl.dropbox.com/u/919275/Screenshots/TowerDefense1.png">

    Yes, it's a side-scrolling platformer tower-defense game. All the visuals are placeholder, really. Heavily inspired by Sanctum, Defense Grid: The Awakening and that old RTS game, Stronghold. Aside from enemies and turrets, as per typical of the genre:

    • The player himself can attack enemies using a whip-like weapon, in eight directions similar to Super Castlevania IV.
    • An additional layer of defense - walls, moats and traps. Walls are, obviously, obstructions that can be eventually beaten down, moats slow down enemies and damage them gradually (they can be upgraded from water moats to acid and lava), and traps include spike traps, mines, pots that dump water/acid/lava on top of enemies, and more.
    • Mana is required for making/upgrading turrets. Material is for walls, moats and traps.

    Once I've implemented a satisfactory number of enemies/turrets/traps, I'll put out a prototype demo to get opinions.

  • Well, there were three main plugins that were specifically requested in the last dev poll:

    ** Array (though, I would personally go much further and introduce proper data structures and a visual array editor)

    ** Save

    ** Tilemap (seems to be a heavily requested plugin)

    You were already planning on doing data storage anyway, so saving is covered, but I suggest doing a tilemap plugin next would be a good idea - it's been a heavily requested plugin since the 0.x days, and it can also be integrated with pre-existing tilemap editors such as Tiled, which can even make an early version of the plugin easy to use because the tools are already there for the user.

    And I'm not sure if this is a 'minor' feature, but implementing resources (especially resources that you can place in the project folder/.capx file to allow for easy relative paths) would be a great idea, especially to make it easier for plugins such as sound later along the line.

  • Sounds reasonable, though I wonder why you didn't do something else first, such as families. I know collision polygons will probably come alongside the image editor and animations for obvious reasons, but I wasn't expecting the Tiled Background plugin so soon, not that I'm complaining!

    Anyways, sweet build!

  • ... LOL.

    I forgot the Turret Behavior even existed, because I never needed to even use it until now! Looks like I would like to have it now, certainly! XD

    But, yeah, now I feel rather silly. Thanks, Ash!

  • Oh, crap, I think I discovered a bug with the distance expression - mostly to do with picking.

    Simply put, I tried a little test with placeable turrets, all of which have a range, which is calculated using the distance expression... Unfortunately, when using the "compare two values" condition, I couldn't get the turrets to fire, period. I messed about with the condition, and discovered that it only worked with the "greater or equal" sign, but then I also noticed that, when I tried to debug the output value for the distance expression, the first one to print was a number that was way too big to be possible. And then I realized that I kept the original instance of the turret object outside the layout - I brought it in, and did more tests, and I realised what the problem was.

    Simply put, the "distance" expression plus the "compare two values" condition will ONLY work if the original instances of the two objects are involved - once the TestEnemy gets outside the TestTurret's range, all turrets will cease firing, even if it's in range of the other turrets, or there are other instances of TestEnemy in the original TestTurret's range.

    Example cap (click on the black stuff to spawn turrets)

  • Okay, I just discovered that you can't access an object's ID through expressions. THAT would a good idea to implement. Unless I'm somehow missing something.

  • Ah. I forgot that condition could be used like that. STUPID STUPID DUMB. XD

    Still, it couldn't hurt.

  • Speaking of which, while distance is a good expression to have, I realized that having a "check distance" condition would also be extremely useful, as you won't have to allocate a private/instance variable in order perform a simple distance check.

    Don't know why objects don't already have it, really.

  • And as a bonus, you'd only need to do one set of C++-based plugins for a whole bunch of platforms, since it's all OpenGL!

    Hells yeah! OpenGL all the way, man!

  • Speaking of which... For the inevitable EXE exporter, are you guys gonna do OpenGL or DirectX? I would think that OpenGL is ideal, as it would make cross-platform EXE export much easier to implement, and the performance is not an issue (in fact, I hear OpenGL has faster draw cells than DirectX), and funnily enough, OpenGL has had features such as tessellation (as an extension in this case) 3 years before DX11, and unlike DX10 and 11, it can work on Windows XP, which is still widely-used.

    Though, I'm no expert on the subject, mind you.

  • Grids of points can overlap with none of their points touching! All the points just fall in between the other points. It won't do at all! Collision polygons are the standard used by physics engines and other algorithms like lighting. We may as well use collision polygons and then you get your physics polygon automatically.

    Yeah, that might work. As well, it could certainly make shadows better-quality and, well, actually fit the shapes of the sprites rather than using the bounding box!

    Also, speaking of lights, I imagine lights can be improved in some ways upon their implementation in C2, such as being able to replicate the effect of hanging a light above an object when in top-down view (to cast a shadow on the ground), and for light to either be sunlight (rays are parallel) or closer lights (which don't cast parallel light rays).

    Anyway, collision polygons are a reasonable compromise, as they're used with physics anyway, and in some ways just as effective as per-pixel without being nearly as speed-dependent.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There'll have to be collision polygons instead.

    Are we talking "manually created" polygons or automatically generated?

  • Arrays are kind of another thing to tackle entirely - if we're going to do arrays, we might as well go all-out and implement proper data structures, basically re-do the entire 'S' plugin except with a visual array editor and make the entire thing much easier to work with. But that's for another topic.

    Anyway, this is a fantastic idea, and I approve. I don't think there's any point in making them persist.