Sumyjkl's Forum Posts

  • -snip-

    Well I'm confused. Here's a working one, no idea why it does work, since it's pretty much the same as yours.

    Also I tested it with a string, just like yours, and it still worked, so I'm not sure what it is.

    [attachment=0:24fuppzk][/attachment:24fuppzk]

  • Hi. So this is something I've been thinking about for a while, and that is, how do you create an actual functioning relative game world?

    Well, I sat down today and made it, and was surprised when it didn't take very long at all.

    [attachment=1:2ptxwiu8][/attachment:2ptxwiu8]

    [attachment=0:2ptxwiu8][/attachment:2ptxwiu8]

    What it does and why

    It basically finds a "center" of the universe. It means that the actual origin which in most games is at (0, 0) is not constant, but determined by the location of every other object, the average. In this way no-one can really say they are at the center of the universe, because the center is not literal, it's just where everything else seems to be.

    And as for the reason, this demonstrates that there can in fact, logically, be a center of the universe. Trouble is we would need to first explore the entire universe and find the density of everything just to find it.

    The processes

    This is such a simple idea I'd be surprised if no-one had tried it before.

    It's basically 3 steps.

    1. For each object, add the object's coordinates to a global variable.

    2. Divide this global variable by the amount of objects to find the average position.

    3. Take away this average from the current positions of every object, and add a constant offset value to keep it centered rather than in the top left corner at (0,0).

    And that is all there is to it.

  • There are a couple of ways, either an instance variable for the amount of frames left until you can shoot, a timer, or an instance variable which sets the time with a later event to check if [time] is greater than the variable + something.

    For example.

    1. I fire, it sets player.firerate to its default, 100.

    2. Every frame, decrease (firerate) by 1.

    3. When you fire, it checks that player.firerate ≦ 0

    Not the best way, but it gets the job done.

    Here's a capx.

    [attachment=0:23548nrc][/attachment:23548nrc]

  • Hm, did the exact same and it worked for me. It's in the same project right?

    [attachment=0:235cb81a][/attachment:235cb81a]

  • Depends how complicated you want the menu to be.

    There seems to be a general consensus that using multiple layouts and layers is the way to go, and it seems to work pretty seamlessly.

    This in its simplest form is where you have a "main menu" layout with a button, when the button is clicked it goes to the layout "game" and starts from the beginning of your level.

    Then you can have multiple buttons for different menus, either on other invisible layers or in different layouts. Keep in mind it's easier to fade in or move a layer than a layout however.

    An example would be:

    "Start" goes to a layout "level_00"

    "Options" moves the screen / increases the opacity of the layer which has your options screen on it.

    There's a tutorial for this as well: scirra.com/tutorials/594/building-a-global-user-interface-ui

  • Basically in each event, only instances which fulfill your conditions are affected by the action.

  • Thanks, I ended up just having to list the objects. I'll take a look at that nickname plugin. I searched for it but obviously I didn't search the right thing.

  • You need to reference the instance in the event condition. In other words, it will only pick a specific instance if you have a condition for that object. For example:

    [attachment=0:77y8jset][/attachment:77y8jset]

    In this example, when an A hits another A it becomes transparent.

  • Not sure what you mean. It would work with that too. What this does is just applies whatever your control does, to whatever instance has that control type enabled. If you do it that way then it will work for anything at all. It's not writing out the control scheme for each player, just for each control scheme. Furthermore you can add more objects to it without much hassle using a family.

    Edit: the reason it would work is because it picks the instance which has the control method.

    Edited Edit: Here's an example in a capx.

    [attachment=0:32hsj7yg][/attachment:32hsj7yg]

    Also it doesn't matter if you have an object for each player, all that would mean is that you would use a family for all these events instead of my "players" platformer. I used only one because it's simpler, but if you were to use more than one, a family with the same events would work too. If you can't use families then you should use an instance variable determining player id which changes the animations anyway.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If you're using objects in a family or of the same object type you can just set up an instance variable 0-3 which determines the control method. Then when you make the events, make them so they are segmented into the different control methods, and pick the instance of that object which has the instance variable that corresponds to the control. Ok I'll show you with pictures because this is making my head hurt.

    [attachment=0:y14m84h3][/attachment:y14m84h3]

    Then under those groups add the rest of the controls.

    Edit: Then of course in your options screen you have events which stop the user choosing the same controls for multiple players. When you want to change the control method, even during runtime, you just change the instance variable and it will instantly take effect.

  • Only way I can think of is by adding an invisible object behind each object at creation. That gives you one collision possibility for teams or whatever. Still, that means only one possibility for collision, and it would be twice the effect on performance that it would normally be.

    I think we'll just need to hope that it gets added.

  • Only way I can think of is to simulate gravity yourself for only objects that have the "gravity enable" instance variable as true.

    For example: [attachment=0:2f57zx5l][/attachment:2f57zx5l]

    Edit:

    Pick it before.

    Isn't the gravity variable global, not instance based?

  • Hello.

    So my question is basically that I seem to not be able to clone an object in-game without creating an event for each object within the family. Here's an example:

    [attachment=0:2pq34x62][/attachment:2pq34x62]

    ("Is Picked" is just a bool for if the object is chosen by the player)

    I would have expected it to pick the object type from the selection (the instance boolean) and create an object of the same type. However it just picks a random object from the family.

    Any idea of how to pick the same type from a family? Or do I just have to create an event for each object type?

    Thanks.

  • Seems I fixed it (to an extent) and I'm not entirely sure how. Here's the updated nail constraint events:

    [attachment=1:1ngj4ika][/attachment:1ngj4ika]

    As you can see the only difference is that this means the nail attaches to the two objects rather than the two objects attaching to the nail. Also for some reason doing it in the same event (instead of separating the top and bottom instances) breaks it, in a way that it for some reason only attaches to one object.

    There's still the issue that this will only work with two objects (the top and bottom) but that can be fixed with a for loop:

    [attachment=0:1ngj4ika][/attachment:1ngj4ika]

    Now I just need to make a physics driven drag and drop system...

  • Not sure how you can make pathfinding objects collide with solids, but making one follow the other is simple.

    [attachment=0:3hca7n38][/attachment:3hca7n38]

    Not sure what issue you're having but this seems to work.

    You might want to make sure the enemy object has obstacles: the default is solids, but anything other than that e.g. physics needs to be manually set at the beginning of the layout.

    The other thing is that rotating towards position would indeed rotate towards the player, regardless of the fact there's a wall between them. Thus when the object - which has no collisions - tries to move, even the opposite way, it will move straight through.