Arima's Forum Posts

  • Rory vladoss - Thanks!

  • I'm going to try to put loot pursuit on it. It's a humorous casual/arcade mini RPG I've been working on for about 3 1/2 years in construct classic.

    Subscribe to Construct videos now

  • Send an email to licensehelp@scirra.com, they'll get it working for you.

  • Yeah, I'm just playin'. XD

    Edit: Uhh... it's like 97% done. Like it was in January. -_-

  • I'd put Loot-Pursuit here too, it has pretty good graphics,

    <img src="http://www.amirai.net/forums/Renaevictory.png" border="0" />

    not great

    <img src="http://www.amirai.net/forums/Renaesad.png" border="0" />

    .. but it has a good style going!

    <img src="http://www.amirai.net/forums/Renaevictory.png" border="0" />

  • > FSM (finite state machine) architecture could be implemented in plugin. behavior would be better, I think, because it would allow you to have many objects in different states simultaneously.

    That's still possible with a variable, as each instance of an object can have a different value for the same variable.

    I call functions a "custom action" (they're synonymous right?).

    Close enough. Functions are entire event structures containing events, conditions, actions, groups, comments that get called as an action. So it works like this:

    Event one:

    Misc conditions

         - misc actions - place sprite somewhere, etc.

         - call function "function name"

         - other actions

    Event two:

    On function "function name" (this is a condition)

    Other condition, such as is sprite visible

         - actions, sub events, etc.

    As construct runs through the actions of event one, when it gets to the action 'call function "function name"' it puts event one on hold and immediately jumps to running event two. When it completes the event structure there, it goes back to event one and runs the rest of the actions there after the 'call function "function name"' condition. After finishing event one, it skips event two, because that only runs when then function is called.

    Why not apply the same thought to conditions? You can bundle a complex condition in a "custom condition".

    It does seem like it would be potentially useful to people. I'm not sure if I would use it though, as it seems like an extra thing I would have to keep track of and remember what it did while reading code.

    > Hmm... Instance variable groups?now what? That's actually better than what I proposed. As long as you could collapse the groups (both in the code editor and the layout editor), this should work fine.

    I like that idea too, as long as typing a variable name would search inside all of the variable folders the same way typing an object name does. Having a ton of variables on an object can make it take longer to find the one you're looking for sometimes.

  • rexrainbow - yeah, there was a finite state machine plugin for CC, but personally I find a simple variable easier to use. Each to their own, though.

  • > What was an issue was my inexperience designing code properly, which is how it turned into a tangled mess.

    My point is that everything that's complicated enough soon gets turned into a tangled mess.

    I guess we'll just have to agree to disagree here then. I'm not sure I communicated it properly, but since learning how to design code properly, I don't find things turning into a tangled mess anymore.

    The problem with that is that you have little reusability. For instance, this "If distance(enemy.x, enemy.y, player.x, player.y) < 100" could be compacted to a custom condition called "is within attacking range?" - you'll obviously need to repeat that all over your code.

    You also have similar cases, such as "is within field of view" and "no obstacles between me and player" which could be abstracted away.

    I'm not sure how that would benefit in this example, as a custom condition called "is within attacking range" would actually be more complex than a condition "If distance(enemy.x, enemy.y, player.x, player.y) < 100" as the definition of the custom condition would need to be defined somewhere else, and it would still be one condition.

    For more complex situations though, having a custom condition that has multiple conditions defined elsewhere could be handy I suppose, but personally I think it would actually be often harder to follow then just having the conditions laid out there instead. That's a matter of personal preference tho.

    Except when you're referring to instances such as:

    Similarly, if you have more than one condition that triggers "chasing code" or "pathfinding", you'll need to copy+paste the chasing/pathfinding code again at those positions, violating the "DON'T REPEAT YOURSELF" principle of software design - either that or you make a huge OR block with all the possible conditions that trigger pathfinding/chasing.

    That's what functions are for, which are in CC but not officially in C2 yet (there is a third party plug in). That basically takes the place of custom actions as well. Basically they allow you to run another event inside an action list or expression.

    The point about hidden variables is that I don't want to clutter the editor with tweakable properties (public variables), which are things I need to adjust to balance/polish my game, with internal stuff (private variables) which are just small storage bins that allow the object to do its work.

    You can edit/rename/delete/make public those hidden (private) variables, of course, it's just that they're hidden out of view in your normal workflow, similar to how you can lock a background object in the layout editor so that you can click your objects easily.

    Hmm... Instance variable groups?

    I wasn't very clear there - although you can encapsulate the "kamikaze attack" in a group, you can't say "there you go, enemy! time to do your kamikaze attack!!!"

    You can't do that without using weird workarounds like "is group active?" and "disable/enable group". It feels like a hack.

    Maybe I'm communicating wrong, because I don't have to use "is group active" or enable or disable groups using my example. I leave the groups all active and the instance switches between groups on its own based on the 'mode' variable. The code to define a behavior is going to have to be somewhere - in my example it's in the "attacking" group.

    It sounds like what you want are custom behaviors defined by events? Which are an awesome idea which has been mentioned before, and I'm hoping they are on the to do list. :)

    I know you didn't ask, but I'll give an example: I could have a sprite representing the turret body, another representing the beam (I'm thinking of a beam cannon), a particle object, a post-processing layer, and then have a big spaceship composed of other stuff, with multiple beam cannons across its surface. (the spaceship on the whole is a container composed of the hull, shields, hp bar, and then multiple copies of the "beam cannon" container).

    Yeah, you can do that stuff already, though it's not the simplest thing.

    On spaceship created

         for "loop" 1 to 10

              Create turret

              set turret.turretnumber to loopindex

              set turret.spaceshipid to spaceship.uid

    For each spaceship

         If turret.spaceshipid=spaceship.uid

              Place turret at spaceship action point turret.turretnumber

    For each laser

         if turret.uid=laser.turretid

              Place laser at turret

    I'm thinking specifically of the Factory Pattern and the Strategy Pattern

    I expect custom aces should make design patterns implementable.

    At least for one of those links, I think functions are what you want.

  • The standard way to implement AI in games is via a finite state machine. The example I mentioned is akin to one "state" of that machine (enemy). Things get a lot more complex when you have more states, and more complex behaviors. Sure, you can implement everything via events, but you can't easily go and change things once they're in place, and cascading states is also a lot more complex. Imagine your "power level" variable, now imagine 70 other variables like that, each used in a different context, by an enemy that already has to track things like distance to the player, current hp, current mp, max hp, max mp, list of available attacks, movement possibilities and tons of other stuff.

    I don't know, I've coded things using finite state machines in events before, and had no problem with it. The enemies in loot pursuit have 79 variables and the number of variables they have has never really been an issue that I can recall. What was an issue was my inexperience designing code properly, which is how it turned into a tangled mess. ^^ Subsequent designs have been much smoother.

    I do something like this:

    enemies

         wandering

              If enemy variable 'mode'="wandering"

                   Code for wandering about randomly

                   If distance(enemy.x, enemy.y, player.x, player.y) < 500, check angle for field of view

                        If player variable 'powerlevel' > enemy.powerlevel

                             set enemy.mode to "running"

                        If player variable 'powerlevel' < enemy.powerlevel

                             set enemy.mode to "chasing"

         chasing

              If enemy variable 'mode'="chasing"

                   chasing code, pathfinding, etc

                   If distance(enemy.x, enemy.y, player.x, player.y) < 100, no obstacle in way

                        set mode to "attacking"

         attacking

              If enemy variable 'mode'="attacking"

                   Code for charging towards player

                   If enemy overlaps player

                        Set player variable 'mode' to "hit"

    Which collapses to:

    enemies

         wandering

         chasing

         attacking

    Etc. Using this method I can make behaviors as complex as I want and still find it easy to work with.

    It quickly gets confusing, especially since we have no concept of "internal" variables - that is, variables that are specific to an instance, but that shouldn't be displayed in the editor, because they are used internally. A reload timer is a perfect example of this: you have the reload delay, which is a property of the object, and you have the reload counter, which the object uses internally to implement the reloading - you shouldn't see that second variable because you'll never want to mess with it in the editor.

    I'm afraid I'm not familiar with the term (even after several minutes of googling), and don't understand. What if you change your mind about what you want the value to be, or edit out that feature using that variable entirely, or change the variable name to something else? The variable has to be editable somewhere. Why not simply have it in the same list? It seems the most logical place for it. I think doing it some other way would be highly confusing.

    Wouldn't it be easier to code everything up in blocks and call those blocks something meaningful? I.E: this section means "run away from player", this section means "kamikaze attack", this other section means "try to ambush the player", and this one "flank the player" or "gang up on the player", and so on - if we had custom ACEs we'd be able to do that.

    Isn't that exactly what groups are? That's how it works the way I do it with my example above. Though I'm not arguing against custom ACEs, those would be awesome too.

    I hope containers can include other containers, and those sub-containers can contain other sub-containers, and that we can mix objects in those containers (not hard to imagine such a situation: think of a tank with a body and a turret [2 sprites], a buffer for dead reckoning in multiplayer [array object], player name [text object], post-processing layer [canvas object], health bar [another sprite] and effects [particle object]), and that we can dynamically include and exclude objects from containers.

    At least in construct classic, containers cannot include other containers (which is a great idea), but all the rest of what you said as possible regardless (dynamic ones could be created with the pairer object), having a tank with the two piece turret, etc. It works better if the health bar isn't part of the container though - all you need to do is create an instance of that for each instance of the tank, place it to the tank's position and set it to the tank's hp and it'll automatically place itself to the right instance.

    > Design patterns? I'm not quite sure what you mean by that?

    Code reusability is the capacity to reuse elements of an engine. How many times did you have to code a platforming engine? Wouldn't it be a lot better if we could just design one with all sorts of fancy stuff like double jumping, wall jumping, jetpacks, powerups and whatever, then plug a game in it and tweak the values by enabling/disabling parts of the engine, or perhaps sharing such engine in the forums? It's doable now, but what if you have to work such engine into an already in-progress game, instead of building a game from scratch on top of an engine? This process should be easier.

    I know what code reuseability is, that... wasn't what I asked. I asked about design patterns. ^^

  • There's no way to simplify coding, everything is always all over the place, it's like procedural programming all over again!

    Not sure what you mean about procedural coding, but I disagree about everything being all over the place and no way to simplify. If you use lots of groups, sub-groups and sub-events well, I find it to be extremely organized, as an entire section of code can be described in a group name. It makes it very easy to find what you're looking for. It's how I manage working with a 5000-event event sheet in loot pursuit - and things are plenty easy to find, as long as I actually place them somewhere logically labeled.

    We cannot make our custom ACEs with construct events, and that makes artificial intelligence in c2 games almost impossible - you can prototype the pieces, but you can't assemble them - it would be nice to have something like [if I have a shot at defeating the player] then [chase player], with all the complexities (that I coded myself) hidden away.

    You can actually do A.I. with events as they are, and it's not almost impossible at all. You could do what you described above by combining some of the player's character's stats into a 'power level' variable that could be compared to the enemy power level, and to fight or run depending.

    I haven't done any 'real' coding, but I'm guessing it's a lot different from how you're used to doing it though.

    In addition, object-oriented concepts such as an object composed of multiple sub-objects each with their responsibilities

    Containers are made for exactly that. :) They're not in C2 yet though.

    code reusability, design patterns and other things feel very weird (and that's not just with construct).

    Design patterns? I'm not quite sure what you mean by that?

  • Thread moved to help wanted.

  • I've tinkered with the demo for Construct, and although I really like it, having to click so much to achieve events that you could type out really quickly (especially with intellisense support) with a built-in script editor would be really handy.

    countofquad - you can actually type out events using the keyboard shortcuts.

  • Please do not create multiple threads for the same question. Also, don't expect an answer in a few minutes as it often takes more than a few minutes for people to respond. Many of us are asleep or not on the forums when you ask, so wait a day before bumping your thread.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Here's a question for you - what is your criteria for powerful enough? What is it you want to make?

    In my opinion, C2 is already powerful enough to make and play almost any 2D game ever made plenty well. The only thing it's lacking currently is an option for double or triple buffering to help smooth out the occasional frame that takes longer than a 60th of a second to process, but perhaps that can be an option for the EXE export. Even without it stuff generally plays quite smoothly (at least in chrome, haven't played with the other browser's performance all that much, and EXE is supposed to be even better performance than chrome).

    You could simply make a quick graphical prototype to test it - simply throw in the assets of the most intensive scene your game will have and a text object showing the fps to see how it runs. Maybe some basic 'fake' events for collision detection and such to see if it can handle the processing of the code as well. One of the games I'm working on is managing like 1.5 million collision checks per second on an older AMD athlon 64x2 4400+ at generally 45-50 fps.

    Also remember window size causes a significant difference in how many pixels need to be rendered by the GPU. Even a 640x480 game in a 1920x1080 browser window will get a hit to the framerate because the GPU renders the entire browser window. Shrinking it will improve performance (or at least that's how it works in chrome).

  • DeusEx - Thanks! It's made in CC because C2 wasn't out yet when I started working on it.

    CC has EXE but C2's getting that in the next version. Even though it's not native, it should be plenty fast for almost all games. CC has some extra speed executing code, but with EXE coming to C2, that's basically the only advantage it has anymore, and since most games are limited by rendering speed, not code speed, that's not much of one. As of C2 r100, I don't think there's any reason to use CC over C2 anymore.