Yeah, keep the info for the characters in the array, then use the array to also remember who's currently in the party. Like:

Character 1's hp

Character 1's mp

Party member slot 1: character 1

Then when starting a battle or such, if the value in party member slot 1 is character 1, create a character 1.

A quick example showing how to use timedelta. Sprite uses it, sprite 2 does not.

Aha! I think I understand why you're confused. Forget the conditions - you use timedelta in the actions only.

So instead of what you're doing:

every 2 ticks

left arrow is down

• subtract 1 from camera x

do this:

left arrow is down

• subtract (amount per second*timedelta) from camera x

Since you're using every two ticks, the event is running every other frame, resulting in 30 pixels moved per second. To get a speed equal to that, you'd use (30*timedelta). Like this:

left arrow is down

• subtract (30*timedelta) from camera x

[quote:2iatr35r]They don't have hundreds of people working for them these days though... not animators anyway... plus, a lot of that time is rendering footage :/

Since this discussion is about the art and what shows up on screen, I understand why you wouldn't count the people in finance or such, but a lot of the people are engineers and concept artists, rigging and texture artists, etc. If they're contributing to what eventually happens on screen - like writing the software to make the stuff that happens on screen possible, like fur, hair and cloth - then I really don't think they shouldn't be counted. Animators are one piece of a film. Even in 2d movies there's the animators, inbetweeners, ink & paint, background artists... Watching the credits of any 3D animated movie shows hundreds of people who're involved.

Also, the rendering happens concurrently and overnight. The film isn't finished then everyone waits to render, because not only do the movies take too long to render to do that, but then there's editing/compositing to do after the rendering's complete as well. I maintain my stance that 3D movies take as long to make. Well, good ones, anyway.

[quote:35bboa5h]If you say 200 people is unrealistic, then fine I believe you... but why does it take feature length animations made "the old way" hundreds upon hundreds of people to make over a course of 5+ years? Because they didn't have 3d, and they didn't have "bones"... everything was hand painted... frame by frame... from scratch.

3D animated movies take about that long to make too.

What you really need to do is get out of the habit of using .x+number - the more you do it, the easier it gets. You'll get used to it.

The correlation is the fps - if your .cap is running at 60 fps, then .x+1 and .x+(60*timedelta) should produce the same results. I'm not sure why you're getting x+(200*timedelta) at the same speed as .x+1. Is the application using v-sync, fixed or unlimited fps? You can check your fps by checking the 'show fps in caption' option in the application properties.

Think of it this way - how much do you want an object to move per second?

Like this. Want an object to move 100 pixels per second? Then use always, set x position to .x+(100*timedelta). Want it to be twice as fast? Use 200 instead.

You don't need to replace the always. Timedelta is a value that over the course of a second will add up to 1. So if you did: always set x to .x+(1*timedelta) then every second the sprite would be 1 pixel farther. Each frame it will move the fraction of a second the frame took to render. So if you're doing 60 frames per second, then it will move 1/60th of a pixel per frame. Does that make sense?

Since the object is moving via timedelta, it's skipping over 50. So if it's moving 100 pixels per second, then it moves 100*timedelta pixels, which results in distance travelled numbers like 50.095lotsmorenumbers. Using distance travelled = 50 would only work if you knew at some point it would equal that, like moving 10 pixels per frame, but then the speed wouldn't be consistent on all computers.

What you want to do is use the trigger once while true condition after the distance travelled is greater than 50 condition.

Wouldn't it be easier if you used two values, one for the x position and one for the y? That's how arrays work, which look a lot like what you're making.

And, from what I can gather, most of you are not even programmers, yet, for some reason you are attracted to the use of non-descriptive and counter intuitive terminology and structure. Many of you admit that you have failed to grasp "modern" programming languages, and that is why you have come here to learn Construct - which maintains that same programming paradigm that has given you such fits. Quite a dilemma for you, I should think.

It isn't the names for stuff that was confusing, it was the crazy syntax and unwritten rules about how the code needs to be arranged, and lots of that underlying stuff that Ashley mentioned. All the random symbols everywhere interspersed with the text of the code, the way the code needed to be formatted, etc is what threw me off. The concepts I understood easily. Getting them to work, I did not.

[quote:56igxqot]This statement assumes that because the industry uses this standard of terminology that it automatically makes it the "best and most suitable". For whom, I might ask?

People have been using the concept/term "variable" for at least hundreds/thousands of years. If you'd rather call it something else, then you have an issue with the very concept of language itself. Not even Einstein could have convinced the world to change the name. It's literally like claiming that the word industry isn't descriptive enough and deciding to call it something else. Then when you use your new made-up word everyone looks at you funny and has no idea what you're talking about. That's how language works.

[quote:56igxqot]And those of you who think you need to be proficient in advanced mathematics to make the simple things found in today's AAA games...

Right, because shaders and rendering and physics and real-time ambient occlusion require no advanced math at all.

It always amazes me how programmers reply to reasonable questions like the ones I have posed.

First, a lot of us here aren't programmers. In fact, most of us are probably here because we're NOT programmers. I'm proficient with construct, but I can't even manage to get through a basic javascript tutorial.

What can you call a thing other than "variable" that is more descriptive and more readily understandable to non-initiates? I'm sure you can find a better word or phrase if you cared to think about it for longer than a second or two.

This isn't a good argument. Think about it. Imagine you enounter something you've never encountered before - like an animal. You don't know what it's called. This type of thing happens all the time for scientists exploring the world. Therefore, to differentiate it from all the other animals, it needs a name.

Now, you may want to call it what you want, but the rest of the world already has a name for it. Going around referring to it by something else would only confuse people and no one would understand what you're talking about.

One of the great things about construct is it gives the power of a lot of real programming principles and makes them simple to understand and use. If you got over your reluctance to try to learn it, it probably wouldn't take you longer than a second or two to understand them, because they really are easy concepts to learn.

The other benefit of doing it this way is that even though I can't code the most basic thing in javascript, I can hold conversations with professional programmers about coding, and they can make suggestions to me that actually work in construct even though they've never used it. Calling it something like 'remember' would stunt your development as a coder and make it harder for you to jump from one dev environment to another.

I know I can. For non-global variables, instead of a dead and indeterminate noun, why not use a verb like "remember". "Remember"(something) would hold whatever you wanted in its "memory" until it is replaced by something else. A global variable could be equally descriptive by using another active phrase that everyone can understand like "remember forever" (something). This is how we speak and this is how we think.

A variable is a thing, which is referred to via a noun, not a verb. You're suggesting a replacement for the word variable, but the place remember would be used is in the action, instead of set variable. So remember what? What is the underlying part of the program you're working with? When you create new variables, what should they be called? Create a new remember? Referring to a thing with a verb doesn't work. What you're actually suggesting here is replacing the words "set variable" with remember. You'd still have to make a name for it. And what do you know, there already is one.

It really is quite logical. A variable is a number or text that can be modified - i.e. it can vary. You can give them names. So sprite('speed') will retrieve the speed. Is set variable 'speed' really that much harder?

Considering that something is "advanced" or "professional", simply because it is obscure is nonsense.

It is not advanced, nor is it obscure. It's what everyone in the entire programming and mathematics world calls it. It's also one of the most basic parts of programming. You want advanced, look at anything quazi makes.

It is quite alright that you have designed this engine for making professional quality 2D games, but that does not require you to make it difficult for non-professionals to do so. Games and game logic are incredibly simple if you care to be honest about it. There is no need to add layers of complexity just so those who consider themselves "professionals" don't feel let down.

Games are as simple or as complex as they're made to be. Most of us here are not game industry professionals. I hope you don't feel let down by this. If you put as much effort into learning it as you're putting into trying to find some way to not have to, you'd have learned it already. This is about as simple as game logic gets while still having flexibility for more advanced stuff.

If you're having trouble understanding any of the terms, all you need to do is ask. The people here are very helpful.

Actually, PhotoShop was one of those programs I learned to use quite proficiently by clicking around and not reading a single page of documentation or following a single tutorial. Any really professional application that claims to have even a fraction of PhotoShop's utility should provide the same facility.

Try that with Maya. And I did learn most of construct by clicking around.

One of these days the Priesthood of the code will be thoroughly disbanded. Mark my words.

This isn't elitist nonsense. This variable thing has been around for hundreds/thousands of years and is quite thoroughly entrenched in both programming and mathematics. From wikipedia: "Much of the basic theory for which we use variables today, such as school geometry and algebra, was developed thousands of years ago, but the use of symbolic formulae and variables is only several hundreds of years old."

You're not going to win this argument. No one's trying to bash you down, but your suggestion is both impractical and not better than the way it is. Seriously, this stuff really isn't that hard to learn and it will help you in the long run.

I think the issue is the flow of information. A cpu has no problem running the filter, but the filter needs to be run after the screen has been drawn. If I'm not mistaken, the flow of data goes CPU to GPU to monitor. To run the filter, you'd have to send the data from the CPU to GPU, back to the CPU to run the filter, back to the GPU again and then to the monitor. Your framerate would take a HUGE hit.

The reason emulators and such can do it is they're using software rendering via the CPU - the graphics card isn't doing the rendering like construct does. Unless it can be coded as a pixel shader and therefore runs on the card, or construct gets a software renderer, it's not efficient in the slightest.