Pulstar's Forum Posts

  • Check the collision polygon shape of the button sprites. Maybe the "guessed" shape got mangled up and you need to shape it manually.

  • Use a custom string to mark newlines in the text inside the XML. I used "\n\". When retrieving the text from the XML I used replace() to replace all instances of "\n\" with newline (without quotes around the newline).

  • Sup with that? The problem with using normal functions, is that you cannot use it with multiple objects. Say you have a bunch of enemys, and you attack one. If you use normal functions, every single enemy takes damage.

    You can, you just need to use pick by uid in subevents of the function. Here's an example where I pass the attacker's uid and the defenders uid in separate parameters of the function (my function object is called f):

    http://imgur.com/a/qSRqc

    Of course if I need something from the attacker (a variable value) in a sub-event where the defender is picked I use pick all to reset picks and pick by UID attacker again. Although I prefer to just store everything I need in variables local to the function.

  • The best way to do it is to use bezier curves, they are rather intuitive. Look up the math on wikipedia. Depending if you just need simple curves or very windy paths you can use more control points.

    However drawing good looking curves in C2 is not exactly easy. The best I could come up with is using small sprite sections, calculating the slope at the point in which the section is placed, rotating it to the angle of the slope and so on. Unfortunately you easily end up with hundreds of sprites just for that. That might impact performance. Maybe there is a plugin that does that better.

    However if you just want calculate a curve and translate it into a set of tiles constituting a path that you autotile, the whole thing become much simpler. No need for calculating the slope, sprite/object count goes down.

  • In your capx do the following

    Instead of :

    set width: Sprite35.Min+1+experience.nextLevel

    Do:

    set width: Sprite35.Min+1+((experience.experience/experience.nextLevel)*124)

    This way sprite35's width will always go up only to 125 and the width will be (nearly) proportional to the fraction of experience you have out of total needed to level up. So it will increase slower with each level (assuming experience gained from defeating foes stays the same).

    Also you can use a 9-patch object for an experience bar as it can be tiled easily/expanded easily without stretching it so it can look prettier.

  • My recommendation is to first get the easystar behaviour for tilemaps if you are using a square grid like AW did. I use it myself for my projects and its fantastic. It is possible to recreate its functionality with events but believe me it is faster to have a plugin/behaviour for this rather than do it via events. And by faster I mean it will use less CPU power.

    You can also get the move to plugin as well and see how the demo of easy star with move to works (found in the topic below):

    Basically you need two things. You need pathfinding functionality with diagonal movement disabled (easystar can be set to do that) that returns a list of tiles describing the path (easystar does this, accessing it might be a bit tricky at first). You also need something to move a unit along the path (after the tile is clicked/selected).

  • > For those who don't like subscriptions, but demand console export:

    > https://www.yoyogames.com/blog/437/game ... ts-out-now

    >

    Wow. I expected a high price tag for GMS, but nothing like that, and it's only for 12 months.

    I just read a dev response at their forums and apparently the sudden price hike is because in the past Sony and Microsoft "subsidised" the console export development and support of GMS (including support for getting all those certifications and other occult rituals the console companies demand before you can ship). Now they need to pay it out of their own pockets so the cost was offset to GMS users, so they introduced the subscription model for those platforms.

    Makes me wonder if Unity can afford lower subscriptions due to economics of scale.

    Also I googled a bit about TRCs for console development and to my shock console development is even more of a pain than I thought.

  • Yes, see example below. You need to use the layeropacity system expression to get the current opacity of the layer and then set it to:

    layeropacity+percentage of opacity per second*dt every tick.

    https://www.dropbox.com/s/jtqpq5cksqk53 ... .capx?dl=1

  • Just for my own understanding... (because I keep seeing this subject pop up and I never understand it)

    I am quite deep into my project,

    must be 600 events in total now,

    In game I am creating dozens of enemies and in subsequent events or sub events I am changing their instance variables, positions and pining stuff to them etc at the point of creation. and as far as I can see everything is working well and smoothly. I have never ever needed to use wait 0 seconds for a anything, I don't even know why or when I would need to use it, it sounds like a hack, could someone enlighten me?

    I use it when I need to evaluate all objects with a function after they are created.

    For example I have a radar minimap made with a tilemap. In order to drawn enemy positions on the minimap I have a function, the function uses for each enemy set tile at x = radar.positiontotilex(enemy.x) and y = radar.positiontotilex(enemy.y) to a tile representing an enemy. Since it is not necessary to refresh the radar map every tick (for each is fairly expensive CPU utilization-wise), I only call the radar refreshing function when needed.

    That is to say it the bare minimum when it needs to be called is when an entity that can move changes its current location to another tile or when new enemies are created. But if I call it without wait 0 after creating new enemies those new enemies will not show up on the map.

    Of course there are workarounds which would achieve the same thing for this example, but they all would require adding more new actions than just "wait 0, call function". Less events is better if the performance penalty is not material (less to change/debug if you decide to revise something). Sometimes it is a matter of convenience, there are probably a few cases where it is absolutely necessary and cannot be achieved otherwise. But to be honest nothing comes to my mind at the moment.

    Another use is if you want to make buttons with sprites that have different frames/animation when they are pressed. You can do the pressed/unpressed change in one event:

    conditions

    mouse over object, left mouse button down

    actions

    set frame 1 (pressed)

    wait 0

    set frame 0 (unpressed)

    The effect is that once the mouse stops being over the button sprite it will revert to the previous state by itself. However if the mouse is still over the button, the frame 0 will be changed to frame 1 anyway and the user will not see it has changed. No need to check if it was pressed but the mouse is no longer over it.

  • No and I won't. I do not see any gain for myself that would justify the extra expense over what I have with C2. The extra features are nice to have but not in the area of "I really really need this". And that is before considering my dislike for the web-based tool model.

    Also after my time with C2 I decided that in the long run I need a slightly different tool, harder to use maybe but more flexible in other aspects and with features that are not present in C2. The C3 announcement basically convinced me to buy that different tool (and I paid once for it). I was already kind of on the fence before but I was eager to see what C3 will feature, unfortunately the direction C3 is taking is simply not the one I would prefer.

  • One approach, since you are drawing/showing the connections anyway, is to store the end point nodes of a connection in two variables in the connection object (A and B in the example I added). When you arrive at a new node (via FTL jump, portal or whatever) you store all the connection where your current location is one of the end points in an array (A = node or B = node). Then all you need to do is cycle through the array's indexes based on input.

    Capx example using arrows, the random generation is a bit crude (in the way that the paths cross unlike in FTL). But you are more interested in how to store connection information and how to cycle the chosen paths from what I understand.

    https://www.dropbox.com/s/be1lanyiv7fe6 ... .capx?dl=1

  • The way I do it is that I use a 2D array for this. In your case this would be a (12.2.1) size array.

    I store the values I want to shuffle at y=1.

    At y=0 for each x element of the array I store a random number. Then I sort the array using the x axis as always the element at y=0 will be taken for sorting. Repeat this every arbitrary number of seconds.

    Example capx, after 1 second the first random sort will show then the next for values from 0 to 11:

    https://www.dropbox.com/s/b3bf1exx745z2 ... .capx?dl=1

  • If you really really need to track the bullets movement every frame one solution would be as follows. Don't use a bullet sprite for checking for collision. Use a sprite acting as a ray. Invisible ray if you wish, for collisions visibility is irrelevant. You can still have the actual bullet spawned and visible, only the logic of the game will not care what happens to it. Although personally if it is moving 333 pixels per frame as I just calculated, I would not bother with the bullet itself as nobody will see it anyway. I have a project on a similar scale and I just show bullet trails and assume the travel time is instant (so hitscan basically), then again I do not need actual bullet movement as everything is turn based and dicerolls pre-determine the hit/miss before the bulletrail is created.

    Anyway, here is a solution to your problem, capx at the bottom:

    Spawn a ray object when a bullet is fired. For a ray you need a sprite with an origin at x=0 and y equal to the middle of its height. On spawning, set its angle to the firing direction.

    First you calculate how much the bullet would move during the frame. Then you draw a ray from the beginning of its path (its x and y positions) in the current frame to its end. This is done by calculating how much distance the bullet will travel this frame (dt*speed per second in pixels) and setting the ray's width to that distance. That way you will have a sprite covering the whole path travelled by the bullet during the frame (basically what a regular bullet sprite would skip over and not collide).

    Next you check for collisions using the "object is overlapping another object" condition, you pick the instance of the object the ray collided with that is closest to the frame origin point. Do whatever hit logic you want with it (damage dealt, destroy sprites etc.). Destroy the ray and bullet unless you wish to make a Quake railgun or something.

    If there are no collisions, you set the ray's position to its end. That is x=x+(width*cos(angle)) and y=y+(width*sin(angle)).

    https://www.dropbox.com/s/mt21w5foq4v2o ... .capx?dl=1

  • Conditions:

    compare variable: score>0

    compare two values: score%5=0

    Actions:

    Create object

    Explanation: the "%" sign is for modulo, or the remainder after division. If the score is a multiple of by 5 this operation will return 0. You also need a second condition so that this action does not run when score is equal to 0 as 0%5 will also give 0.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If you just want to darken the unseen surface you can create the fog of war out of a tilemap on top of your surface tilemap. All you need is a whole black tile with less than 100% opacity set in your graphics program of choice before saving it. That is the easy part. This could also be done with just sprites but believe me, using a tilemap is much faster, especially if the map is big.

    Making things only show their last "seen" state is trickier. If it's just units you need a "dummy" ghost sprite. Basically when a unit is being set to invisible due to being in a hidden area, it would spawn a ghost sprite at it's position and with it's angle. This would be destroyed the moment the tile is revealed.

    To be honest the hardest thing with FOW is making efficient FOW reveal events. The higher the map size (in tiles not pixels) and the higher the unit count the bigger the performance hit will be, there basically is no simple solution here that is also efficient. With small unit numbers, small maps and simple map reveal mechanics (show all tiles in vision range, so no line of sight blocked by obstacles etc.) you might not notice anything. However anything more ambitious and it will become apparent there is slowdown.