How does one design gameplay logic?

Hi everyone! Very happy to be here and actually making a post about Blueprints as I’m diving more and more into the UE4 system.

My question is very simple in nature and yet I struggle to find the answer on the broad range of YouTube and internets in general: How does one design the gameplay feature?

Example: Let’s say I want to create an inventory system for my Third-Person Template. What methodologies do I need to know in order to create the system on paper or in the flow-chart format?

Where I come from to understand the context better: I’m a UI / UX Designer for web & mobile applications. In my day job, in order to design something, I go through a process of research of requirements, researching market, learning what others have done in the space (what UI’s they have and why they were made this way), and getting down to it by making first sketches and low-level wireframes that help me understand the design problem better.

And for some reason I have a hard time understanding how to apply that to a video game feature.

I created two games before using Unity & Bolt VS, but since they were extremely simple, I never bothered thinking about design patterns or methodologies to implement them.

But now that my ambitions are a little bit higher, I struggle to comprehend what needs to happen in order to implement features.

Currently I’m going through Blueprint course on Udemy by Luccas Schmigel and I’m half-way through, but mostly I’m skipping everything cause I understand the concepts of functions / events / arrays etc. What I don’t understand is how do I break things down into manageable pieces that work with each other.

This might be a mental block and I’m just not seeing things clearly, but every time I ask my dev friends about their thinking process behind designing features, they just tend to talk to me about “interfaces, singletons” and what not, without actually breaking down the thought process behind coming up with those solutions.

What I’m doing so far to get to the bottom of this:

  • I’m buying marketplace projects in order to break them down and understand how they are made: training my own “solutions to borrow from” memory \ base so to speak.
  • Going through BP course mentioned above to make sure I understand all BP features correctly (And so far I understand that C++ and BP are the way to go, can’t go with BP without C++ for clean optimal code).
  • Bought Game Programming Patterns and will definitely give this a go after finishing the BP course.

Also I don’t find a lot of tutorial helpful because of this very same problem: You might have taught me how to make inventory system in some YT course, but I won’t be able to apply this knowledge to design some other gameplay system, because you showed me WHAT and now the HOW. I won’t understand why you chosen X over Y, or how you came up with that exact solution.

What puzzle piece am I missing?

I love how helpful this community is, so I just want to say thank you for taking your time to read this and to reply :heart:

Hi, if you buy markeplace projects to look at them, I would suggest that you also look at the content examples and the example projects of epic games (cause I wouldn’t guarantee that all the marketplace projects out there use good coding, so if you look at a “bad” one that might be contraproductive).

I find C++ really helpful, but I wouldn’t start learning it before knowing your way around blueprints (and why to choose X over Y in blueprints) and you will learning C++ by learning blueprints, most of the knowledge will transfer.

What puzzle piece am I missing?

Imho experience. I don’t think that you can learn programming just by looking at tutorials or example projects, its like solving exercises by looking at the solutions first without trying to solve them yourself, that way you will never be able to solve them. I mean the first step is of course looking at the solutions but at one point you need to try to solve the problem yourself and only look for specific things where you get stuck, but not for the whole solution. Or in other words, try to build an inventory system yourself and don’t look for a whole tutorial on how to do an inventory, but for specific problems that you run into when trying to build an inventory.

For me, learning UE was just redoing tutorials step by step for the first couple of weeks. Then for some months trying to solve problems without tutorials for the whole problem, but just for specific problems I ran into. During that time I also rewrote my whole logic several times from scratch when I found out some things I’ve been doing wrong and where it was easier to just start from scratch than trying to change the whole logic in place (which is also an indicator for bad code by the way, since if it where good, then I would be able to just swap out those specific parts but since I also had cross dependencies everyhwere that wasn’t possible). For me the most dangerous trap during that phase (and maybe even now) was spending too much time building things with my current knowledge and trying to go with my head trough the wall instead of spending more time experimenting and expanding that knowledge and come up with better solutions (good example there where the crazy workarounds I did in blueprints to avoid learning C++…).

Next big overhaul was when I learned C++ and shifted some logic to that (there I only rewrote my AI system, and kept most of the rest (only swapped some parts of it)). Then the next thing was when I learned about reference viewer and size map and saw that my blueprints cross reference each other, that where another adjustments/rewriting.

So just start doing things, the first couple of weeks will be the hardest. Then you should forget everything (today I don’t think there is much I would do like in those tutorials that I watched at the beginning) and work on your style and look through finished projects / more high level tutorials (online learning, gdc talks). But then with my way of coming to the knowledge about UE that I currently have I needed to rewrite things from scratch several times, so there are better and faster ways for sure =)


Hey, thanks for the reply!

That actually makes more sense for simple things, and some other complex things. And there’s plenty of them. Need to dive more. My only fear is that a lot of them are outdated but now that I think about it, a lot of principles will still work :slight_smile:

That’s true, often than not I’ve been caught up thinking that I just need to try to do something and fail and learn from that VS trying to find out the perfect solution before hand.

I think part of this has to do with the fact that it’s hard to learn without peers or senior devs who are knowledgeable and are leading a project and you could ask them about how or why etc.

I remember on my second job as a Front-End Dev job, the senior dev gave me a large task that I couldn’t comprehend how to design, and he taught me the rubber duck method, which helped me a lot, and come to think of it should help me here as well :wink:

I doubt I’d learn something like this remotely haha. But this the bane of our current era. But either way, one thing to me is clear:

  1. Become confident taking on tasks with BP
  2. Through experience I’ll eventually gain competence to solve problems

If i do not know how to code some problem i split it into smallest tasks i can think about. Then group them and try to generalize (find common parts) and make code that works for as many tasks as possible.

I prefer bottom up coding. However all those bottom functions/classes need to be flexible, so i can use same stuff later in different parts of project. When i have bunch of low level functions i usually start to see big picture and what i need next. Then at some point it is matter of connecting all those classes and functions together.

Not sure about your skill level in blueprints. But fundamental skills for that are blueprint communication, blueprint interfaces, inheritance. Those are tools that improve quality of your code and allow you to group similar code in single place. Then use it anywhere you need.

Just keep coding, you will get there.

1 Like