C-7's Forum Posts

  • I added a new feature today about mapping! See some of my C2 workflow:

  • Just go to your bottom-most layer and change the layer option Transparent to "yes". It will be transparent in the browser then.

  • Double check it isn't already in your project. If not, reinstall. The browser object is still there and fully functioning.

  • A nice way to go with your prototyping is to make a small, playable game (for yourself or not) that uses a few of the core systems you want. Individual systems are great, but the combination can sometimes be the tricky part. For instance, you could work on your pathfinding, layout abilities (try things like elevation, proper z-ordering, etc), and in-game events by making something simple like leading a group of units through to specific points and having something happen when you reach them. A few small things like that will give you complete ideas on where you want to go with it all, it would teach you everything you need, and you would be able to follow through with completing more bite-sized chunks of stuff. You could do a personal example strictly based on UI-handling and number management. Prototype your battles with just single units vs single units, then groups, squads, armies to make it all more manageable. Those three demos/prototypes for yourself wouldn't take incredibly long to achieve, but you would be FAR ahead of the curve in a couple months when you could start cranking on the real deal. It's much harder learning each of those individual things along the way.

    Soon after those are done, and probably while you're working on implementing everything (quickly now!) into the main game, do some concept art tests to make sure your development art will line up with how you want the game to finally look. It would stink to get everything nailed down then add in art only to find it all looks wonky. Just do a bit of graphical planning alongside your systems implementations so you don't have to rework things again later.

    And lastly, don't forget audio! You don't have to make it all until later, but you should have an idea in your mind about how you want to implement it all. IE, decide what cues what and possibly set up your functions sooner rather than later so you really can just plop in the audio files and be ready to go with some mixing.

    It sounds like you're going about it logically, I'm just encouraging making sure your prototypes are truly useful creations that can possibly kill a few birds with that one stone. If it all sounds like a lot, though, it's because it is.

  • I'm sitting at about 4500 events so far, but I'm not targeting mobile at all. Some of them get a little heavy, of course, but good optimization can help with that.

  • I added a short write-up about an important character to my Patreon page as well as some art work for her. Check it out and consider chipping in to help development and get some good stuff.

  • I think the easiest way to do it would be to have one sprite with a bunch of frames. That way you create the same object, but change the frame based on the array. Otherwise, you'd have to put them all in a family and reference things that way (I believe).

  • Congratulations on your Steam release! Everybody go buy it!

  • I have multiple layouts over 12,000 pixels wide. The largest has 17,000 objects on it, though not on-screen at once. The only thing to really keep track of at that point is being vigilant about disabling off-screen or far-away objects from doing anything so you don't eat up cpu time with unnecessary things. So the swaying grass and leaves are obviously disabled off-screen

  • SmashKAB Here, this is a quick and crude example to show you what I'm talking about. I didn't bother creating unique objects for the layers--I just used a shader to speed things up. You can see the transparent pixels at the bottom of the images. I also used a solid-color tile to fill in the rest under that. I have snap to grid on in the capx to make positioning easier.

    Anyways, here's a quick capx of what I'm talking about. (uses C2 218)

    And here's a live version of it to run/test in your browser.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The entire image just needs to be moved up a pixel either in the C2 image editor or elsewhere. So don't resize or anything for your solution. Select the entire image and move it up so that the bottom pixel row is transparent.

    But, more importantly, video cards can only store images in their memory ("vram" or video ram) in power-of-two sizes. This means 2x2, 4x4, 8x8, 16x16, 32x32, 64x64, 128x128, 256x256, 512x512, 1024x1024, 2048x2048 (this is the cutoff for iphone 4 and some low-end gpus), 4096x4096 (this is the cutoff for modern iphones and ipads to my knowledge as well as many gpus), 8192x8192 (absurd, but high-end gpu's can do it.) Any image you make that is above any of those numbers will be rounded up to the next size. So a 520x540 image will be padded out on the graphics card to a 1024x1024 image (with transparent/invisible pixels filling in the rest of the space. This is stored uncompressed like a bitmap on the card. So youre 7,000-something pixel wide image is being loaded as 8,192 pixels wide. If the gpu only can do square images, then 8192x8192. If it can do rectangular power-of-two textures, then you fare a little better.

    But the real answer is that your artist needs to be producing art within the constraints of actual game performance. It should never be a 7000-pixel wide image. Your background images are already Tiled Backgrounds (which mean they would repeat their texture instead of stretching/resizing), so your art should be in something like 1024x1024 chunks that can be repeated/looped seamlessly horizontally. This way, you can load that one image and then tile it out across the map. If you want more variation, make a few of them that share a common edge and then you can butt them up side-by-side in addition to having them tile/loop horizontally.

  • I took a loot at it. The answer to your problem is it's a graphical problem common to tiled background objects. It's the bottom row of pixels wrapping around to the top. Either shrink the object in C2 by one pixel vertically or bump the entire source image up one or two pixels.

    As a side note, though, you're going to run into all kinds of problems designing your backgrounds with such gigantic images. You're immediately cutting out a TON of low-mid tier machines (and nearly all mobile). You ought to find ways to make smaller chunks (images) and place them side-by-side. A stack of absurdly large images is just generally really bad practice. This is particularly true since they're not really all that filled with detail or anything to justify even large images. I'd stick to nothing larger than 2048x2048 (though I don't have a single image even remotely close to that size in my entire game) because anything past that will cause issues on some hardware.

    You have a simple layout and already your video ram use is six times my full-sized game with thousands of objects. So I'm not saying you shouldn't do a high-res game (mine is kind of medium), but not like this.

  • So long as you aren't working on the SAME event sheet or layout at the same time, you should have no problems with this through source control using something like svn or github. I use bitbucket and manage it through sourcetree. It's all pretty painless and lets me keep a running backup and source control over previous versions.

  • What? No more positioned sound? That is just terrible...

    They aren't the same thing. The Doppler effect is the pitch shift relative to something's position (sound gets lower further away and higher closer... Think of a car or ambulance driving by). Positioned sound is just stereo panning.

  • looks good C-7

    Thanks a lot!