Daiz's Forum Posts

  • Hint: Try out the "For each object (ordered)" under system conditions.

    For example, me & Zotged used this in our isometric game:

    For each Blue ordered by Blue.Y -> Blue: Send to front

    Should make things quite a bit simpler for you

  • For fading the object out smoothly, you could use lerp, that way'd you'll only need two events:

    random(x) -> Set LayerOpacity to 100
If LayerOpacity > 0 -> Set LayerOpacity to lerp(LayerOpacity,0,1-0.0001^TimeDelta)[/code:1u9pawev]

The smaller you make the 0.0001 part the faster the fadeout will be. One another way to speed up the fadeout would be to do this:

[code:1u9pawev]Set LayerOpacity to lerp(LayerOpacity,-100,1-0.0001^TimeDelta)[/code:1u9pawev]

By changing the target opacity from 0 to -100 in the lerp you'll speed up the time required to hit 0.

  • Construct!

    Lesson 1: save every 5 minutes, under a new filename.

    I would do this if saving didn't take about a minute or two every time I do it :I

  • Your character will die, she doesn't have a frilly hat!

  • You don't actually have to make any events to destroy things at startup - there's an attribute called "Destroy at startup" that does exactly what the name would imply

  • As newt said, you need to compare the distance of the objects. Don't forget to run that compare under For Each Enemy. So basically:

    For each Enemy

    -> Distance(enemy.X,enemy.Y,player.X,player.Y) < attackdistance

    == ATTACK!

  • In my opinion, whipping up a cap to show how to do something isn't really the best way to do things in every case - in fact, I think it could make things worse. As the proverb goes: "Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime."

    Really, quite a lot of questions boil down to the fact that person asking the question doesn't understand game logic. The first thing in learning how to make games is to understand how they work and the ability to break things down to their most basic components. When you understand what makes up something, you can start working on it and looking for ways to achieve something. At this point if you face a problem that you can't seem to solve and ask about it on the forums I'd say it's okay to answer it via a cap or comprehensive description - after all, the asker presumably knows what he wants to achieve on a basic level, just not how to do it.

    Let's take another recent example - the question "can you make teleports in Construct?" Applying some deconstruction here, you can see what "teleporting" means: moving object from point A to point B instantly. Now if we think about what things do in games in general? They move from point A to point B. In other words, if you can achieve anything where something moves from point A to point B in Construct, yes, you can have "teleporting functionality" in Construct. It doesn't take much thinking to figure something like this out - we should encourage people to think.

    So I guess the bottom line is that we should encourage newcomers to learn game logic before asking questions about how to make X in Construct, because if they don't understand game logic the answer will most likely not be of any help to them.

    Personally I don't even bother to answer topics made by people who seem to have no motivation to do anything themselves at all; maybe if no-one answered an obvious question, maybe they could think for themselves for once. I guess I'm a bit mean in that way, but honestly, even if you're new to something doesn't mean you couldn't try learning for yourself. It's not like you're going to kill yourself by doing so!

  • Layout rotation in 2D is a bad idea, honestly. Some old games like Contra on SNES do this in their topdown levels, and honestly speaking it feels terrible.

    You could probably pull off some 3D stuff with meshes and so but honestly, instead of having all that work put into making a somewhat-decent sorta-3D thing just make a good 2D thing instead with the same work.

  • Some comments from my point of view:

    About football games: Honestly speaking I wouldn't say Construct is even the right tool for them. Construct is primarily a 2D game development software, whereas if you want a realistic American football simulation you'd have to have a 3D game, really. So in my honest opinion, no 2D game creator would really fit your need if you want to bring something new to the field compared to what the commercial 3D alternatives offer at the moment.

    About visual novel / interactive fiction type games: I wouldn't recommend Construct for these either. You're better off using something like Ren'Py. It involves scripting, but it's pretty darn simple to learn, and it's cross-platform compatible (unlike Construct by nature). There was also some free visual creator for visual novels I read about quite a while ago but I totally forgot its name. It looked very promising, though, and free. Both these two are specifically aimed at creating visual novels and if that's what you want to do you're better off using these than Construct. They're better tools for this purpose! Of course you still can make a visual novel with Construct, and it'd be pretty simple to pull off too - if you want to venture into this area, I recommend using the Spritefont object for versatile text stuff.

    Also honestly speaking I have absolutely no idea what you mean by "A Web-style creation system with simple-to-program randomization". Make some sort of mockup next time, please, to save people from being confused about what you mean.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Here's one approach:

    1. First, you just set a value (global, anything) to random(100).

    2. Then you just do lots of events like this:

    Is value between 0 and 56 (System expression) -> Jump to layout X

    Is value between 57 and 57 -> Jump to layout Y

    Is value between 58 and 99 -> Jump to layout Z

    Of course there's multiple other ways to achieve this and you could even do some sort of loop to check things via private variables making it more easily customizable.

  • You know, there's another idea that I think tossed around in the chat a while ago...

    Make the expression editboxes multiline-togglable. I noticed that if you write the expression on multiple lines in say Notepad and paste it to the expression editor it doesn't destroy the multi-lining and it even shows up in the event sheet editor.

    So that instead of having just

    clamp(3*distance( mousexy, xy),0,100)

    you could have:

    clamp(

    3*distance( mousexy, xy),

    0,

    100

    )

    Of course for such a simple sentence it doesn't do much but for me it helped writing some more complex stuff.

    Another thing that would be useful is syntax highlighting. And one thing specifically - when your text cursor is over a bracket, ( or ), it will highlight the equivalent start/end bracket. This is what editors like Notepad++ do by default and it helps so ridiculously much it should seriously be implemented in everything. Especially in Construct, since you can easily write expressions that end up looking like lisp (with (all (the (goddamn (brackets))))).

  • Well, create and families seem to work quite fine for my intended purposes... though for some reason I can't get timers to work with it. The cap straight out refuses to compile. In any case, take a look at this:

    When you run it, you can see that the first bullet creates bullets to both left and right, but then only the left side creates further two bullets. The right side should also create two more bullets and destroy afterwards, but right now it only destroys.

    Any ideas on how to solve this?

  • Another example upload for the same thread.

  • Try this:

    [snip]

    By using the System object to create new instances at the bullet's location you're interrupting the normal picking. The original bullet continues to sail onward, and spawns four bullets before fading out. Is that the result you were going for?

    The problem with the approach in your image is that if I do that there's no way to set things relative to the original bullet without using something like globals. Let's say I want the bullet to spawn at [original spawner angle]-90. With the spawn function, the new object would start with the angle of the original spawner, so I could just use .angle-90 for the new bullet, but if I were to use the create object (and not use "relative to another object") I would first have to store the original angle in a global before creating the new bullet, and then set the angle as global('spawnangle')-90.

    This isn't exactly what I'd want, because it'd complicate the bullet spawning code a lot, especially if I want to set other things besides just the angle relative to the original spawner object. And since I'm going for a bullet hell game, I'm going to have to do lots and lots of different kind of bullet spawns, and even some seemingly minor increase in the code required to create a spawn, the workload could increase very notably.

    I thought about using families as well, but they'd also introduce another layer of "things to worry about" when coding bullet patterns and it could slow things down quite a bit.

    In either case, you said it yourself:

    [quote:j8dkt3jk]However, you already have a specific instance of that object picked in the condition, so it appears the selected object list is getting confused as to which instance you mean to perform actions on.

    I would say that this is a bug, since in my opinion after spawning an object all actions in the same event should be performed on the new object afterwards.

  • So I'm posting this here since I'm not sure if this is intended behavior or not, though I bet it is not.

    See example cap here:

    Basically the problem is that spawning the same object doesn't seem to be working right. I have three behaviors for the bullet object, Bullet, Fade and Timer. I want the Bullet to spawn copies of itself, but it seems that when I perform Spawn "Sprite" on "Sprite", not only a new object gets created, but the original spawner object seems to reset/respawn itself too. The fade timer starts counting from zero, the timer gets disabled, etc. There are other tries at solving the problem in other layouts, all of which fail. I've tried working around the problem by using a value for a timer instead of the timer behavior, removing the fade behavior, using ball behavior instead of bullet behavior, using create object (with both relative to another object and just spawning at Sprite.X & Sprite.Y)... everything seems to fail.

    I don't really want to have multiple sprites for similar objects because it'd make the code a whole lot complicated for no good reason, and spawning copies of itself and setting new properties for them is quite a vital thing, especially for the bullet hell game I'm working on. It just isn't a bullet hell unless there's bullets shooting bullets shooting bullets.

    So is spawning/creating duplicates simply broken or am I just missing something?