This is the stuff you’re working on – a list of numbers, an unreal object with properties, and so on. You’ve basically got many different ways of representing the “real” world data is how you present that to your program . Your logic operates on your data , using it to make decisions and either create new data or change existing data.

This all seems pretty obvious and in some ways it is. However much of the real work in programming is about finding the right way to turn the problem set into data. For example if you were writing a program to deal with customer data you’d need to store addresses in a way which handles zip codes and street address in the US, but districts and postal zones in Japan. If you making a decision about where to put effects in an unreal scene, you need data which lets you distinguish between good locations and bad ones – for example, you don’t want to spawn your effects under the floor or inside walls.

Logic and data go hand in hand: if the logic and the data work well together, your program (or blueprint) will be short and clear. If they don’t match up well the logic usually ends up being super complicated – which makes it very buggy. You’re always looking for way to organize your data that makes the logic clearer.

Sometimes you’ll break a problem up into stages where you collect data (say, looking at all the characters in your game and bucketing them into ‘allies’ and ‘enemies’) then acting on that data in a second step ( “if the numbers of enemies is 2 times or more larger than the number of allies, run away”) . More often than not there are several steps along the way, but it’s good to break a problem down into simple steps with simple answers that you can understand easily. The most common source of problems in any programming is that people get overwhelmed by the complexity of trying to do everything at once.

A critical aspect of data is what programmers call “type” – that’s a term of art for that means ‘here’s a bunch of data which always has these properties’. Type is how you know that an object name contains letters and not numbers, or that an unreal light is a light (with properties for color and intensity etc) and not a vehicle or a physics collision mesh. Programs usually rely on type information to keep things organized; in blueprint that is why you can’t connect anything to just anything else – when you run a wire into a “multiply” node that wire has to represent some numbers.