Squidget's Forum Posts

  • One extra layer might be helpful, but I've found that I often need more. I'm building some pretty complex levels, so the freedom of being able to add multiple parallax layers or play freely with layer ordering has been pretty helpful.

    As far as how I save the levels as text objects: My levels consist of two things, a base tileset object that represents the core terrain, and then a set of 'props' with X and Y positions that represent various game objects. So in my text file, I have to store the state of the tileset, and the name and coordinates of each prop.

    In general, the key to this method is creating lists in the text file using separators, and making use of the tokenat function to break up the lists again when you load. I pretty much just choose random character as the separators, but I'll explain it as best I can! Here are my saving events:

    <img src="http://i.imgur.com/1B9rOEN.png" border="0" />

    I originally tried to save the tileset data using the AsJSON component, but I ran into a lot of bugs and couldn't make it work consistently. I don't recommend that approach. Instead, I save the tile data for the levels by looping through each tile and saving its number, then writing them to a string as a list, with a "." separator between each one. You can see this in the setupTileString function above: It loops through each tile and appends its value to the list. This is then saved into StringToSave. Once I've done this, I add another seperator (a "|"), so I can differentiate the tile data from the prop data.

    For the props, I just add each possible prop to a family and give it an instance variable that represents the props name. Then I just loop through each prop in the list and save its name, as well as its X and Y components. Each prop is separated from the other props by a "?", and the data within each prop is separated by ";". You can refer to the code above to see exactly how the string is built. Props could be anything - enemies, items, background objects, whatever you need to have directly placed. Just make sure to give each one a unique name, as this will be important in the loading. You could also add more data parameters here, if you needed to save more about a prop than just its coordinates.

    Once the strings are all saved, you write them to a file using the Node-Webkit object, as I've done above. Node webkit makes it very easy to save files using the Open Save Dialog and On Save Dialog OK features. If you look at the two events above it should be pretty clear how that's being done.

    In the actual game, the level files are loaded in a similar way. The strings are broken up and separated out (you can do this using the tokenat and tokencount functions), the tilesets are rebuilt, and the props are created and placed based on their names. This is all done on one layout, so I never have to worry about layering issues or mirroring my changes. You can then create your individual levels in your level editor project, saving them as separate layouts, and putting all of the actual behavior in the main game project.

    Again, this may not be the best method for every game. For various reasons, it was the best fit for my game, but I only settled on it after some experimentation. Depending on how your game is structured, using a layers/layouts approach might work better for you.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • In general, if your project is going to get large I'd highly recommend that you use static local variables within groups as opposed to global variables. The global variable drop-down gets very cluttered very quickly if you are overusing them.

    My player's stats are stored this way, and I access them using getter functions.

  • Very cool! I like the basic mechanics a lot.

    Mechanics-wise, it would be cool to see some more things that make use of the hippos weight. With both the platforming physics and the effects you clearly draw a lot of attention to it, but there doesn't seem to be any actual stomping on enemies or affecting things by squishing them. In fact, the combat seems almost the opposite of that, lots of aerial attacks and movement. it might be more cohesive if those two things were brought a little more into line with each other.

    It would be nice if the level gave a bit more of a goal, like a clear path and victory condition. I think I just ended up wandering right until I fell off the screen. I imagine that's in the works though.

    In general, it seems like a great start. Hope you continue working on it!

  • I've gone with this approach and it works out okay, but layers remain a big problem. There's an excellent chance you'll need to change your layers in the future, and that's increasingly difficult to do for a huge number of layouts.

    Here's another approach:

    -Have a separate project for "level building" and build your levels within that project, each on its own layout.

    -Write a system for saving your levels to a file - this can be easy or hard depending on how your levels are constructed. A simple approach might simply save the position/name of each object, while a more complex one would incorporate things like tilemaps. Either way, make it so you can press a button to save (the Node Webkit object can help here), and save each level to a text format. If you need to change a level later, change it and then save it again.

    -For your game itself, you can put all the game logic and layers onto a single layout. When the game starts or the player transitions levels, you can remove any existing objects and load in the new ones based on the content of your text file, placing all the objects as needed. That way, all the levels can be loaded onto one layout.

    Note that this approach is good for certain types of games, and not so good for others. For example, if you need to save changes when transitioning levels (for example: an enemy you killed in a previous layout stays dead if you go back), it might make more sense to use the built in layout and persist behaviors rather than going this route.

    This approach has worked for my game, so I thought I would throw it out there. It may or may not suit yours, it just depends on your mechanics.

    Another tip: Make almost every variable a static local, and access them through functions if you need them elsewhere. Global variables clog up the drop down menu a lot once you have too many.

  • What you want for this is an Effect applied to the player sprite, not a blend mode. Effects on a sprite will only apply to that single sprite. You can get a decent-looking white flash effect by putting a Brightness effect on your player objects - set the effect parameter to 200 when the player is hit, then gradually scale it back down to 100 over a second or two. You can get more complicated if you want multiple white flashes, but that's the basic idea.

    You can also write your own effects if none of them match your needs.

  • So I'm using Spriter for my animations, and that has allowed me to create a variety of animations for my character. However, as I add more moves and options, I'm finding that the page which controls the animations I'm playing is getting pretty unwieldy to work with. My current approach started out very simple (ie: If on ground + is moving then set animation to running), but those kind of condition-checks become increasingly large and ugly as the project gets bigger.

    I'm not so much looking for specific code help as general ideas. I'd like to find an approach to controlling animations that lets me add new ones for specific events, without having to go back through a bunch of old events and changing conditions to make it all work. Has anyone found a good modular approach to controlling which animations play for complex characters? I'm thinking of doing a queue of some kind with priority levels (so a high-priority animation can override a low-priority one), but I'm looking for other ideas.

    Thoughts? How have you handled complex animation controllers in the past?

  • Is there a way to cause a sprite to cut from the texture when I scale it, instead of scaling the texture?

    An example would be a textured health bar. Rather than scaling the texture down, I want to only use 50% of the texture if I set the width of the object to 50%, and cut off the rest.

    There's probably some way I could do this with Blending modes, but doing it for each UI object would be pretty complex. Is there a simple way?

  • So what is the process for re-importing in this current version? When I drag the .scml or .scon file into Construct 2, it seems to find the file for reimporting, but then it gives me an error about how it can't find the .scml file and stops. This happens whether I drag in the .scml or the .scon.

    Using r152 of Construct, and the latest build of Spriter and the plugin. All save options enabled in Spriter.

  • Did a bit of further testing. Each time I save and load the tilemap through the asJSON function, it cuts off the right edge of each rectangular grouping of tiles, regardless of the position of the tiles in the tilemap. It only triggers when I re-save the string each time with the new tilemap, so it's likely some problem in the format in which the string is saved.

  • Link to .capx file (required!):

    drive.google.com/file/d/0B36MEu5Qi6YvRlFmU1NDMWoxZGM/edit

    Steps to reproduce:

    1. Create tileset A and tileset B, both of which use the same set of tiles. Add some tiles into tileset A, but leave B empty.

    2. Save A's AsJSON component to a string, then destroy A.

    3. Use B's SetFromJson action on the string that you saved.

    Observed result:

    The last column of tiles in the tileset is missing from B.

    Expected result:

    B should show the exact same tiles as A used to show.

    Browsers affected:

    Chrome: yes

    Node-Webkit: yes

    Operating system & service pack:

    Windows 7 64-bit

    Construct 2 version:

        

    r152

  • Go into the object properties for the spriter object, and where it says "SCML File" change yourfile.scml to yourfile.scon. That should fix it.

    If it doesn't work, make sure you're using Spriter B6, and that the spriter file is saved in your project as both scml and scon.

  • So I'm trying out the new Set From JSON feature. I want to use it to quickly save my generated levels into strings, so that I can reload them later.

    The current events in my test project are:

    -On pressing 1: set tileString to TileMap.AsJSON, Erase all tiles

    -On pressing 2: Tilemap - Load from JSON tileString.

    Unfortunately, my tilemap basically turns into a gibberish map when I do this, with a bunch of random tiles all over it.

    Am I misunderstanding this feature? Can it not save the state of a tilemap currently?

  • I'd like to have my level editor write out my level data in XML format. Is this possible right now? The XML plugin seems to only read XML data, not write it.

  • If you think of it like the difference between force and impulse in the physics behaviour, instead of applying a vector adjustment once, which would straight away be affected by deceleration, instead, set a variable, and while true , set vector.x to a certain amount.

    I did this for wall jumps in a game, I set a variable to 80, then each tick, subtracted 1 from variable, and set vector-x to a fixed number, so the character would move in the air/repel from walls.

    Once it hit 0, the vector.x wasn't affected any more.

    That approach makes a lot of sense, I'll give it a try. Thanks!

  • So I'm trying to make a system in which when a player or enemy with platform behavior gets hit with a certain attack, they are knocked back and briefly stunned. This kind of mechanic is common in a lot of games, such as fighting games. I have the basics in place - stunning the player and disabling their controls, but getting the actual knockback to work continues to give me trouble.

    Knockup in a vertical direction is fairly easy, you just set the Vector Y on the platform behavior and it behaves appropriately. Moving the player in the horizontal direction is more difficult, because the Vector X is affected by the platform behavior's natural deceleration, which is pretty high in my game. I don't want to lower the ground deceleration too much or I'll lose the precise feeling of the controls, but as it is even if I set the vector X to the max speed the platform behavior allows it still barely moves the character backwards at all.

    Is there an alternate method to handle knockback better, one that would give me more control? I'd like to be able to do large knockbacks (ie: hit a character across a screen's length), ideally with some control over things like deceleration. It's also important that the knockback continue to interact correctly with solids, such that the character can't be thrown through walls and won't end up with their platform behavior bugged out.

    Any thoughts? Have others had to approach this problem? What kind of solutions did you use?