DEV Community: OP-Bright

How to Think About Games: Construct

OP-Bright — Mon, 09 Feb 2026 12:23:23 +0000

Introduction

Hello, and welcome to the final installment in the ‘How to Think About Games’ series. All of the articles up to this point have focused on trying to dissect the philosophy, structure, and vocabulary a game engine expects you to use, ideally without comparison up until the end. This article will be no different. Today we’re talking about Construct.

Background on Construct

Construct considers itself an entry level game engine, tailored towards non-developers, to help them make their ideas reality. Although it is not as big in the market as the others, it still has a lot of appeal amongst people trying to learn game design, and some compelling games have been made with it.

Construct supports 2D games specifically. Although you can do some trickery to make games that are kind of 3d, support seems to still be limited.
There have been 3 versions of the Construct engine, but the most recent version is Construct 3, receiving support still. Construct 3 was released on December 4th, 2017.
It’s particularly popular for making web-games, but users can pay for a professional subscription to publish for PC, or an enterprise one for some consoles.
Although the user is able to insert some JavaScript code for more fine control, the main ‘programming’ is done with their ‘eventing’ system.

Now, with some context, let’s get on to how it thinks about games.

How to Think About Construct

Layouts

Layouts are the canvas you use to place down Objects. Layouts have various settings that can be adjusted, such as resolution, and the ability to use tile sets. All Layouts have an Event Sheet related to them, which determines how the scene runs, and how objects in the scene interact. Layouts represent the different ‘scenes’ in your game, so they can be menus, or levels, or just pieces of levels.

A screenshot of different layout settings in the Construct Editor.

Event Sheets

Event sheets are the primary core of functionality in Construct. With their visual language, you select which event you want the layout to wait for, and what happens when that event occurs. Events can also have sub-events, to check for different things. Some events can be inverted, so you can check that something ISN’T happening, rather than something that is, although this only applies to certain events.There can be System events, that can wait for things like key-presses, or just that a layout has loaded in, but there’s also more game-ish events, like what to do in the case of collision.

The Anatomy of a Construct Event, sourced from the Construct Manual. The Event Block lets you set conditions that the event is waiting for. In this case, when the layout loads in. Then, you add Actions to set what to do in response. In this case, they’re displaying Text, but you could do a lot more, like change variables, and move or destroy objects.

Object Types

Object Types are what you create to populate your layouts, and create things that can interact with your events. As the name implies, you’re defining a type of object, but not the actual objects that are in the scene. Objects can be used to represent almost anything, they’re something visual that can interact with the event-sheet. When creating a new object, you can create it from a base, or from scratch. You can import in plugins to create more easy bases for you to quickly build out events.

Not that it will generally be relevant, but every Layout does have a System Object that ensures that Construct is doing what it needs to do. It’s unlikely that a user will need to create an object to handle game-logic otherwise, as that’s mostly handled by the Event Sheet.

A screenshot of a view of all the Object Instances in a layout. You can organize them into folders for easier organization. Certain instances can be next if they’re related.

Conclusion

I think this engine is interesting and has a lot of potential. Its structure is similar to some of the other higher profile game engines covered in this series, which could be something valuable to learn. It seems very good for smaller games or prototypes, but its hard to comment on its efficacy for making larger games. There are simply not that many made with them, although not 0. But even then, most of the ones I could find were made in Construct 2, not 3. Still, Iconoclasts, Small Saga, and Cyber Shadow are very ambitious games, some of them gaining a cult following. I think if you want to make a small 2D game, it seems perfect for that. The structure will not get in the way, and will transfer pretty well to other game engines.

Thanks for reading my little series! I had some fun putting it together feel like I learned a lot, I hope you got as much out of it as I have. Happy Game Development!

Sources

A Beginner's Guide to Construct 3 (Part 2)
Construct Wikipedia
Construct 3 Project Structure - Very helpful article in my research, practically was my biggest breakthrough. I recommend using this article as a starting point if you want to look more into Construct.
Construct Website
Object Types, Construct Manual
How Events Work, Construct Manual
The Event Sheet View, Construct Manual
Layouts, Construct Manual
Create New Object Interface, Construct Manual

How to Think About Games: GameMaker

OP-Bright — Mon, 26 Jan 2026 04:31:55 +0000

Introduction

Welcome to yet another installment in the ‘How to Think About Games’ series. This is the fourth article focusing on the philosophy of different engines on the market, and today we’re talking about GameMaker. Each game engine has its own idea of how to structure a game behind the scenes. This structure, and the specialties of each engine, are really important to consider when choosing which engine to make your game in. The article attempts to look at each game engine with as little comparison as I think is possible, and focuses on the mindset a developer should have when planning out their game. This should allow you to see the advantages of each for yourself, and make an informed choice.

Background on GameMaker

GameMaker was originally conceived to make game creation more approachable to beginners, it has continued to add more robust features to make it appealing for experienced developers as well. It’s an incredibly popular pick amongst indie teams, and has a lot of incredibly successful games developed through it.

Gamemaker is an engine primarily made for 2D games. It has robust features to support 2d animation, collision, and logic.
Previously known as Animo Game-Maker, and GameMaker Studio, the software has gone through a lot of iterations over time. The most recent one released in 2022 is still maintained and what most users are familiar with now.
GameMaker is not available for commercial use for free, but is useful for personal projects or learning. The rest of the engine itself is a one time purchase, although launching to consoles requires their Enterprise subscription. Although some places come at a price, it seems to generally have coverage of most things you could want to publish to.
GameMaker supports a drag and drop beginner friendly visual language, but also allows use of GML for more advanced scripting. GML is somewhat similar to Javascript.

Now that you have some background, let’s get on to how it thinks about games!

How to Think About GameMaker

Rooms

GameMaker games are built up of assets, these assets are defined by the user. Across a game, the ones you’re most likely to use consistently are Rooms and Objects, but you’ll likely constantly be dipping into the large variety of other ones.

Rooms are the space in which a game takes place, and are filled up with Objects. A game must have at least one Room, but a larger game can use Rooms to represent what they sound like, different levels, or just different screens, like a title screen Room, for example.

Sometimes Rooms can be something invisible to a user, like a loading screen that takes in values from the computer like screen resolution to size the experience properly.

Rooms have a robust layering system for placing objects, not necessarily just to handle z-fighting, but also to allow for greater organization and ease of editing. There’s support for building with tile-sets built in, tile-sets actually being one of the many kinds of assets.

A screenshot of the Room editor. You can see the visible tile-grid in the background. Sourced from the GameMaker Manual.

Objects and Object Events

Objects are less of the actual entities in the game, rather, when you create an object, you basically create a template that can have many instances of it created multiple times.These templates can be used to build anything. Objects can be entities that populate a room. They can do things around the scene, or a player, or even just things that run background logic and are fully invisible (sometimes referred to as controllers). Since when you ‘put an Object in the scene’ you’re really putting in an instance, updating the object doesn’t update the instance.

To make an object act a certain way, you have to have it react to events. There are many types of events provided, Create which runs when the object is created by the engine, Collision which runs when it collides with something, and also Step which runs every step of the game, which can be defined by the user how many steps should be in a second. There are many more event types, but even if you aren’t satisfied users can create their own events as they need it.

An example of a new empty object in the object editor. Sourced from the GameMaker Manual.

Other Common Assets

Rooms and Objects are your primary assets in GameMaker, but it comes with a lot more, and many of them are incredibly useful, and still very commonly used.

Sprites, for example, are incredibly powerful assets. You can assign sprites to an object to make them visible. Sprites are also created with masks, which you can use to define the bounds and collision of a sprite. Creating a sprite lets you also set things like animations, and the speed of it, which GameMaker can handle for you from there. GameMaker has a native image editor, best for smaller pixel art or testing.

An example of a sprite in the Sprite editor. You can see the different frames of animation and how they set up the fps of the animation. Sourced from the GameMaker Manual.

If you’re making a game with a grid based map, such as an old styled platformer or RPG, the Tile-Set asset will be hugely useful for you. Creating Tile-Sets allows you to use them in GameMaker's tile editor, an example of how many common 2D game problems that GameMaker has solutions built for.

You can create Sequences, sets of other assets that do things over time, and a record of what they do. This can be useful for cut-scenes, or simple animations, such as setting up a Title Screen. Sequences can even contain other Sequences.

GameMaker allows you to use Scripts to create common functions that can be used across your game, or even other games. The assets are very flexible which allows creators to share Scripts they’ve made to handle different pieces of common game logic, and make it so developers do not need to re-invent the wheel.

From what I can see, overall that seems to be the power of GameMaker. Most challenges, as long as they’re in 2D, have been streamlined as much as possible.

Conclusion

I will admit here at the end that I definitely have a bias towards this engine after learning about it. I found a lot of really good resources, a handful of my favorite games such as Katana Zero and Rivals of Aether were made in it, and I really am a fan of 2D games. I would definitely encourage you to look a little bit more into it yourself, but I still tried to represent the structure as fairly as I did the others.

As for my opinion, I find the system to make a lot of sense, albeit maybe a bit too granular. At least on the surface, there’s a lot of things that look like they could just be objects, and it's nice that they’re simplified down, but there are so many options that you may accidentally waste time trying to implement it yourself instead of running into one of their pre-built solutions if you do not know what it is called already, but that’s relatively minor and solvable by just getting more experience in the engine. Unless your game idea is in 3D, GameMaker seems incredibly likely to be able to handle whatever you might want to throw at it.

Sources

A Beginner's Guide to GameMaker's Core Building Blocks. (I cannot recommend this video enough. It is incredibly thorough and useful. I am very surprised it does not have more views.)
Why I Chose GameMaker For My Indie Game
GameMaker Wikipedia
Rooms, GameMaker Manual
Creating Tile Sets, GameMaker Manual
Objects and Instances, GameMaker Manual
Object Events, GameMaker Manual
Other Events, GameMaker Manual
Creating Sprites, GameMaker Manual

How to Think About Games: Unity

OP-Bright — Mon, 12 Jan 2026 10:57:27 +0000

This is the third installment of the “How to Think About Games” series. Here, we explore the philosophy behind a game engine, and how it structures a game. The goal is to get a sense for the abstraction of what will make up your game. I try to avoid comparison, and instead focus on the headspace you should be in as the one making a game in the software. From there, you can evaluate the pros and cons for yourself, and make an educated choice of which engine to choose.

Background on Unity

The focus of this article is the Unity Engine, another huge player in the game engine space. With a goal to ‘democratize game development’, they seem to have succeeded, as Unity was very popular among small developers, and still seems to be despite some semi-recent controversy. (It’s outside of the scope of this article, but you can read about the Runtime Fee controversy to learn more.)

Unity supports both 2D and 3D Games, seemingly equally as well, although it’s worth noting that even 2D Unity games are actually 3D behind the scenes.
Unity had annual releases up until recently with the version of Unity 6. As it's still somewhat recent and has less community support. Most of what's discussed in the article will be more relevant to the yearly releases.
It’s very popular for mobile game development, but also can publish well to desktop and major consoles.
It’s built using C++, but users typically write in C#.

Now that you know what it is, let’s get on to how it thinks about games.

How to Think About Unity

Scene(s)

Unity games can be a scene, or a bunch of scenes. As a game gets more complex, you’ll likely use multiple scenes to build out a game, a scene per level, for example, or maybe a title screen scene. Scenes are the space you work in to create a game. To make something of a scene, you can put GameObjects inside of them, each able to represent different parts of the game. GameObject scripts can load different scenes, letting the game navigate between them as is seen fit.

Screenshot of the Unity Editor when you open a new scene. Scenes start with a Camera and Light GameObjects by default. Sourced from the Unity Documentation.

GameObjects

GameObjects seem to be the primary meat of Unity game development. Games tend to consist of scenes that have game objects that communicate with each other. Game objects can be almost anything. They could be a player, a piece of set dressing, a camera, a light source, or even just a script that handles game logic. What form a GameObject actually takes depends on what components it has. GameObjects can even be children of other game objects, inheriting component properties from the parent selector, which can be used to make groups of objects that all move at once, for example.

An example of a basic cube GameObject, and some of its components. Sourced from the Unity Documentation.

As we can see here with an example of a Cube GameObject, it takes a lot of components to make it up, but you get a cube that can have a position in the scene, and collide with other collidable GameObjects. We can tell that its able to do this by its various components. It has a mesh-filter, deciding what shape it takes. It has a renderer, allowing the mesh to show up in the game world, and have a material applied to it. It has a Box Collider, allowing it to collide, and a Transform component, allowing it to be moved to a specific space in the game world, or to change in size.

This is but scratching the surface of what Components can do to build powerful GameObjects.

Components

GameObjects are all made up of components. Components have properties which the developer can use to change them, or have script components that change these properties over time, or based on input. Components define what that GameObject is. A player component might be a simple Cube GameObject as seen above, but with a script that allows for player controls.

Scripts in Unity by default have the functions Start, and Update (Sometimes FixedUpdate is preferable for physics calculations). Start runs the code involved when the scene starts, and Update runs the code involved every frame. To ensure certain game functions don’t just run faster on faster computers, Unity provides a Time.deltaTime value that can be used to make the game run on a more true clock.

There are also certain components that allow for events, which can be interacted with in scripts as well. Collision allows you to run code on collide, and a button UI GameObject can let you run code on click.

A screenshot of the component browser, showing the different categories of components you can add to a GameObject. Sourced from the Unity Documentation.

Components are the real power behind GameObjects.

Final Thoughts

If Unity is to be your engine of choice, you have to see if this structure makes sense to you. If it fits your style of development, and you like the flexibility, this engine may be right for you. Undoubtedly this structure is not a limitation. Unity is a tempting option, having been so big and popular, there’s a lot of community resources out there, and the variety of games it lets you make are immense. Hollow Knight, Cuphead, Subnautica, and Valheim were all made with this engine, showing you the power that it can give you.

On my opinionated note, I can see why the engine got so popular. The structure seems very free form and mostly built out by the user. Although I’m trying to avoid comparison, since I’ve been looking into these structures, it’s really interesting how similar Unity and Unreal's structure seems to be, but I believe the differences are reflected in the games made with each. A lot of the structure of a Unity game is more defined by the user. They can have as many or as few scenes as they see fit, they can write the scripts for game events in whatever way they prefer. I think this freedom may be intimidating, and could easily mess up a beginner, as it's open to a lot of holes and mistakes, but I think in the hands of a competent team, it can be used to make something great.

Sources

Unity in 100 Seconds - As usual with Fireship's content, it gives a great overview, which helped me know what I needed to start researching
How to make a Video Game in Unity - BASICS (E01) - If you're interested in using Unity, Brackeys is ones of the most well known for their huge number of tutorials for the community. I would definitely say their videos are 'further reading' if you're sure this is the engine for you.
The Unity Tutorial For Complete Beginners - However, I would start with this tutorial first. I think it really cleanly and concisely goes over the absolute core concepts in Unity very well.
Unity Wikipedia - Just for extra bits of information and background.
Creating Scenes Documentation - More about Scenes!
Using Components Documentation - More about Components!
GameObject class documentation. - More about GameObjects!
GameObjects documentation - (Yes, this is a different page. I got some information from both, so I wanted to ensure they were both represented.)

How to Think About Games: Unreal Engine

OP-Bright — Mon, 17 Nov 2025 14:38:30 +0000

Welcome! This article is the second in the series of “How to Think About Games”. Each article focuses on the philosophy of different game engines. We explore each engine in isolation, attempting to avoid comparison where possible, and focus more on just how it works, and where the head of a developer working on the software should be at. You won’t know how to make a game by the end of it, but you’ll know how one would be structured, so you can start imagining how to apply your ideas to this framework. The goal is to give you a better idea of how each engine works behind the scenes so you can decide which one makes the most sense for you.

Background on Unreal Engine

This article is about the Unreal engine, one of the longstanding powerhouses, especially for making 3d games. It is known for its high visual fidelity, being used not just in games, but by some film-making studios to create effects or full digital sets.

It is heavily specialized into 3d, it’s not that it’s impossible to make 2d games, from what I can see, but it seems incredibly rare in the engine.
Updates are consistently made to the newest version of unreal-engine, currently on unreal engine 5, but there are apparently talks of an unreal engine 6 in the coming few years. Unreal engine 4 seems to still be actively used but as they re-add more features to 5 people will continue to switch over.
Publishes to PC and most major consoles, as well as mobile.
It uses C++, but features a robust visual-coding feature called blueprints, which execute basic game functions and can be connected to each other.

Now that you know its basic background, let’s get into how they think about games.

How to Think About Unreal

Setup

A game in unreal is made up of various basic libraries and game functions that can be used in “Levels”. A level establishes its environment layout, physics, and more. I do not believe Levels are strictly actual in game levels, I believe they could be something like, for example, a title screen. Each level contains “Actors” that aren’t strictly characters in a scene, but can be.

Each level should have a GameMode ‘actor’, these establish the basic rules of the game in the current “level”, like a win condition. As you play the game, the GameState is updated based on the current state of the game. Sometimes that game could also be affected by the PlayerState, which would be something like a player’s rank in a large online game.

The player gets access to the scene through a PlayerController attached to an actor. Player controllers don’t just take your input, you can also populate the screen with a HUD and control how the camera follows the character with the PlayerController.

Game Flowchart from the Unreal Documentation.

Creating Actors to Populate Your Level

To populate your level, you’re going to want Actors. Actors can represent a lot of things, like in the last example, a character is likely to be a SkeletalMeshActor with a Controller attached. When an actor has a controller attached, whether it be an AIController that you use to build out game enemies, or a PlayerController to give the player a character to operate, this is known as a pawn.

There’s a lot more than Pawns though in games. For example, you could build out level geometry with a StaticMeshActor, or a Brush if you’re still in development. You can use Triggers to cause events to occur as you move through a level, or different Lights to build up a scene. They also have a MatineeActor that lets you give characters special animations for cutscenes. You can also add AmbientSound to play music on a loop, or when a certain Trigger is activated.

Icons of some of the different Actor Types discussed, sourced from the Unreal Documentation.

Actors have properties, which you can set. There are different properties for different types of actors, so it would be hard to cover them all. Using components you can establish the different properties an actor has, and you can use game code blueprints to change them over time.

Building from Blueprints

To give special functionality to an actor, like reacting to triggers or some kind of consistent behavior, you can code this with c++, but you can also use blueprints to build out basic behavior, like functions and objects that you want. Blueprints are built out visually, different functionality able to be connected with ‘wires’. You can connect up these functions to the GameStart trigger, or a trigger every tick of game time. You could also have them react to special placed scene triggers.

Blueprints allow for incredibly basic functionality, like printing a string, but also can perform some more complex actions like determining the reactions your pawn would take to different controls or actions from the player.

A screenshot of the blueprint editor from the Unreal Documentation.

Final Thoughts

So, if you want to make a game in Unreal, you have to ask yourself if this abstraction makes sense. Your success will vary depending on your style of development and your game idea. It’s a big player in the scene and if you’re looking to make a visually stunning 3D game it does seem to be a good choice. Many games have been built with Unreal, most notably Fortnite in recent years, but also games that aren’t shooters, like the Live-A-Live remake with a vastly different art style. Although there certainly are limitations, they aren’t so steep that it should close off many game ideas at all, and most certainly the structure isn’t the limiting factor, as you can see with the very different types of games made.

On a more opinionated note, I found Unreal to be very interesting, especially figuring out what games have been made with it made me realize there’s definitely more flexibility there than I thought. Admittedly for my personal ideas, I struggle to see how I would apply this engine to these ideas. It's less of a structural issue, I’m just less interested in making 3d games. I think if I were to make one, this would be a very tempting engine to turn to. The visuals it’s capable of are very impressive and the blueprints seem very approachable, although I’m sure it would help to understand C++ for further customization. I hope that if you are someone interested in Unreal that this article gave you an idea of how to think about making your game. Thank you for reading!

Sources

Unreal in 100 Seconds - I found entering into trying to figure out the engine behind the scenes was difficult without some background or seeing it done, and this video does an excellent job of giving you the absolute basics of how things look to make behind the scenes.

Unreal Architecture Documentation - They explain the structure of an unreal game well, especially with their nice chart that I used.

Common Actors Documentation - More detailed information on actors.

Introduction to Blueprints Documentation - More details on Blueprints.

Unreal Wikipedia - Just some extra bits for additional background on the software.

List of Unreal Engine Games Wikipedia - A list to help me reference what games I know of that are made in Unreal.

How to Think About Games: Godot

OP-Bright — Mon, 10 Nov 2025 13:46:01 +0000

Welcome to “How to Think About Games”. This series of articles will explore the design philosophy behind different game engines. Each article’s goal is to give you an idea of where the head of a developer using the engine should be at. This won’t necessarily tell you how to use it, but each article intended to help you find if the game engine's philosophy makes sense to you, quickly helping someone who's already a developer decide if the structure is useful to them. This should help you decide what engine to use without bias, as comparison to other engines will be avoided as much as possible. This is just about how to think about games.

Background on Godot

Godot is the topic of this article. Godot is an open-source game engine. A recent contender and popular choice. It’s free, and known for being particularly lightweight, not taking up a lot of space at all, and running on a lot of machines.
It can do both 2d or 3d games, although from what I have seen it seems to have a particular knack for 2D games specifically.
It is always being actively updated, and there’s a lot of community support for it as well, so it’s always changing over time.
It’s specifically good for PC, Mobile, and Web games, but doesn’t natively support console exporting due to the console companies not wanting that code to be open source.
It has its own native scripting language but allows for the use of many others.
Now that you know its basic background, let’s get into how they think about games.

How to Think About Godot

Scenes of Nodes

Godot games are built up out of “scenes”. Each scene contains “nodes”. These titles are admittedly a little misleading, as a scene doesn’t necessarily have to be a “screen” or “stage” in a game. The scene can be something like a character, or a reusable collectable. Nodes are like the absolute basics. They can handle collision, audio, images, they can be the camera, they’re usually the most simple. Scenes are more complicated things made up of these nodes.

An example of a Scene being built with a Label Node. Sourced from GODOT Documentation

Scenes of Scenes

This is how you turn it into a game. Once you make a scene with these nodes, you can reuse this “scene” in other scenes as if it were a node. This leads to a nested structure to build your games, where you can keep going deeper into the complexities of each node in a scene if you’ve built it that way. Although scenes can be connected by being parents and children of each other, they don’t have to be strictly tied to interact.

An example of a Scene Tree. Sourced from GODOT Documentation

Signals

Godot uses “signals” to have different game elements interact with each other. You can make a scene by letting out a signal in reaction to something. Once you do, you can have any number of other scenes react to that signal, without specifically referencing that element. This means you can also make multiple things react to or send out the same signal, allowing you to reuse logic all over the place.

An example of setting up a Signal. Sourced from GODOT Documentation

Final Thoughts

So, for your future game ideas you have to ask yourself, does this abstraction make sense? This will vary from developer to developer, but as it’s a serious contender right now, I definitely advise looking into it. A lot of games have been built with Godot, each very different, for example Dome Keeper, and Wrought Flesh. Dome Keeper is a pixel art roguelike where you face off waves of enemies in between side-scroller mining to keep up with their rapid progression. Wrought Flesh on the other hand is a gritty fps where enemy organs can be used to upgrade your stats. Don’t feel like this structure is a limitation, the flexibility is clearly there.

This being my first article on these engines I’m obviously very impressed by the engine. It’s already getting me to think about how I would adapt the various game ideas I have to this structure. But this is not the end! I want to cover more, as this ended up being incredibly interesting, and there are a lot more game engines out there. I hope this article gave you an idea about how to think about games, thank you for reading.

Sources

Godot Wikipedia Article
GDQuest's "The 4 Essential Building Blocks of Every Godot Game - I highly recommend this channel as a whole if you have further interest in the Godot engine, as they have many videos on the subject, and this was a breakthrough in understanding for me when writing this article.
Godot Nodes and Scenes Documentation
Godot Using Signals Documentation

Math.random, friend or foe?

OP-Bright — Tue, 04 Nov 2025 08:16:53 +0000

Math.random is flawed, as bold a claim as that may seem. It does what it sets out to do, It generates a number between 0 and 1 that’s random… Right? Wrong!

Math.random doesn’t actually produce a truly random number. The number it creates is deterministic, meaning that it’s predictable. Now maybe for a quick dice roller or game feature, this won’t matter, but for security, this matters a lot.

Computers, too smart for their own good

So, why is this even a problem in the first place?

For one, we can't generate truly random numbers, not easily at least. Computers are very bad at generating random numbers. Without some kind of outside influence, it’s hard to get anything that is truly random. Computers are good at math, but not at randomness. The problem with any kind of “outside influence”, is most of that data would need to be sent in from some other source, which we’d have to trust. If we don’t, it would be prone to being manipulated to get a desired result, for example, a previously made random number.

To get around this issue and avoid needing outside data as much as can be helped, a lot of systems implement pseudorandom number generators, which although are fine in a lot of use cases, are not random, and therefore if not made securely, can be reverse engineered.

Which brings us to our second problem. Even though it may on the surface be indistinguishable from a random number, it is different. A lot of services now will secure your account behind 6 digit codes. A lot of password managers give you the option to generate a random password. You likely don’t want people using your program to so easily know where data is stored, and you might want a secure hashing function or encryption. All of these could cause problems should a malicious actor know you’re using Math.random, as all it takes is a little bit of math to find all of your permutations.

The Problems with Math.Random, and what is Cryptographic Security?

The problem with Math.random then, in a lot of these applications, is just that it’s not cryptographically secure, which may sound like a smart jumble of words, but is kind of meaningless without explanation.

The difference between a “cryptographically secure pseudo random number generator” and one that is not, are two things:

One, they cannot be cracked with cryptoanalysis easily, using statistics to figure out future value.

Two, even when its state is potentially compromised, they cannot backtrack to see what values were previously available and what values will be available in the future.

For a long time, Math.random was actually failing at both of those, as the randomness produced collisions much more often than it does now, meaning that it would evaluate to recurring values more often (although, we’re speaking after multiple millions of invocations, but enough to be cracked easily), due to using a low quality method of getting a random number. However, despite the changes made, it still can be predicted by knowing the initial or later state of the generator.

Crypto: getRandomValue, our solution

So, how do we create a pseudorandom number generator that can’t so easily be cracked by a malicious actor who knows a little math? There’s a lot involved that goes into it, but one of the easiest to understand concepts is “Entropy”. As the generator creates new values, the state slowly shifts and morphs over time in unpredictable ways, making future and past values impossible to determine even with access to the state, current or initial. Usually, this consists of stacking other pseudorandom number generators on top of each other, of similarly unpredictable statistics, to seed values with good entropy.

Crypto: getRandomValues, being called from an API, can handle most of this externally. It uses seeds provided by the “user” to supply these so they can also add onto the entropy quickly. Since this is built into most browsers, the “user” in this case is more so the service allowing the user to interact, rather than the person typing away at the keyboard. This allows the generator to run fast itself without needing a true random number generator. They suggest that these in-betweens use their own pseudorandom generator, seeded with outside values to produce the best entropy.

Friend, or Foe?

In most situations relating to security, you really need to watch out for the PSEUDO part of pseudorandom number generators. In other situations? It’s true, it may really not matter. As some have said in my research, it may even be better to avoid it if you don’t know what you’re doing, as you may be over complicating your code for very little gain. But the second you are handling someone’s data, or need to encrypt something, just remember that Math.random could prove to be your enemy. For that very reason, getRandomValues is your friend.

DEV Community: OP-Bright

How to Think About Games: Construct

Introduction

Background on Construct

How to Think About Construct

Layouts

Event Sheets

Object Types

Conclusion

Sources

How to Think About Games: GameMaker

Introduction

Background on GameMaker

How to Think About GameMaker

Rooms

Objects and Object Events

Other Common Assets

Conclusion

Sources

How to Think About Games: Unity

Background on Unity

How to Think About Unity

Scene(s)

GameObjects

Components

Final Thoughts

Sources

How to Think About Games: Unreal Engine

Background on Unreal Engine

How to Think About Unreal

Setup

Creating Actors to Populate Your Level

Building from Blueprints

Final Thoughts

Sources

How to Think About Games: Godot

Background on Godot

How to Think About Godot

Scenes of Nodes

Scenes of Scenes

Signals

Final Thoughts

Sources

Math.random, friend or foe?

Computers, too smart for their own good

The Problems with Math.Random, and what is Cryptographic Security?

Crypto: getRandomValue, our solution

Friend, or Foe?

Further Reading