I am curious as to how you go about designing BPs. I personally make them in my head to a degree then work it out as I go. I do everything in my head.
Do you guys write down a plan or have a planning phase? I hear many do and that some even follow the coder’s graph thing I saw once. I just forgot the name of it but I remember the existence of it.
So yeah are you a skull keeper that keeps it all up there rattling about cooking til something goes ding the idea is done use this or do you go at it with a plan or something else?
I ask this because it is something I am curious about it could be beneficial to many people and it can be interesting to see how people think. If you wish can toss down if you are a pro or a newb as well.
I am obviously a newb who I have been told has twisted logic by a lot of people in the community. However, this thinking method has been with me since I can remember for some reason. Be it 3D art or otherwise.
I really like the idea behind this discussion. Get ideas on individuals preferred method of development. So I’ll throw in my “mess of process” as a “don’t do it this way” use case scenario lol.
So, to start; I’m a 100% complete newb/hobbyist in this realm. I am working on a very ambitious project that is teaching me a lot as it touches on virtually everything. The idea/goal isn’t necessarily to actually finish the project, but to learn from and I have learned a lot; with still tons and tons to learn.
My current process is really simple. Basically I just have an end result idea to start. “This is what I want to accomplish, now how do I get there” mentality. Since I am still learning, I have to start a BP and mock up the idea; building blocks if you will. Basically start with the most basic end result and slowly add bits and pieces until I get the end result I want. Quite often starting with a static mesh component (or basic component for whatever it is doing) and then add functionality in from there.
This is/can be a very slow process as you are constantly doing changes -> compile, save -> test -> repeat. This was the same process when I first started learning PHP development back in the day. For me personally, this helps with learning as you can visually see what a particular change will accomplish that has the added benefit of helping later down the road.
Eventually, I got to the point in PHP dev that I could write an entire script on paper and/or my head until I could get back to a computer and bang it out of the keyboard and see how well it truly worked. This was when I was in middle school so I didn’t have my computer during the day and writing on paper was all I could do, lol.
At some point, I’ll get to the same point for BP as well as C++. Basic stuff worked out in my head and quickly thrown together in BP afterwards.
For the most part though, complex stuff will most likely always be “try this then check” method for me. This general concept is always how I’ve had to do and learn things, so I’ve learned how to get this to work for me in many ways rather than against. Its a good learning method for me, but once I’ve learned enough, then the “work it out in my head” method seems to be the go to.
It depends how complex the task is. Since I make many Multiplayer features it quickly becomes impossible to keep an overview in the head. Using trial and error is also not an option as it takes too long to code that way.
The graph thing you talk about is probably UML (Unified Modeling Language) which I use to visualize complex mechanics before even starting with C++ or Blueprint. Many (or most) skip this part of the planning maybe because they feel it is a waste of time. Systems quickly get complicated though and having a UML diagram to fall back on can save you a lot of debugging. While creating the UML diagram I discover many flaws that can quickly be solved since I haven’t begun coding anything yet.
The disadvantage of UML diagrams is that it is purely pseudo-code so while you are making it you won’t get any feedback if what you are doing is even possible so it might not be well suited for beginners.
I mostly coding in Blueprint, it is fantastic because of its fast feed back and accelerate my thinking iteration. I spend 80%~90% of my time in thinking, designing how the logic flows or how the functional component should be organized, only 20%~10% in sitting down coding. In such way, I can sure my code is composable, extensible, and most important: Simple.
I see newbies spending most of his time in coding, and waste twice more time in finding& killing bug, no time in thinking&designing, which results fairly complex and buggy code.
I draw diagram to help me think, not UML, but some simple circle/arrow with words/expression.
I also write down what I’m thinking in the design steps below :
Problem statements;
Solutions propose;
Investigate the tradeoffs of proposed solutions;
Iterate until I’m sure which is the best among all the solutions.
After years of such thinking practice, I found myself solve the problem more quickly and cleanly.
What I learned is:
Coding is about thinking, thinking is the most hard part.
Design is about taking things apart, if there is no tradeoffs, you are not designing.
Blueprints are Awesome! They're funner to script with then boring text in my opinion. I design them both on paper (actual code translation|psuedocode) and on-demand relying Search function.
Would love to see more features that enhance the aesthetics even greater, because.... as they can turn into an ugly mess visually. Node Connection Wires literally become spaghetti before your eyes. Organization is critical to keep from getting your own mental wires crossed up. I've devised a strategy of organization using naming conventions, node alignment/collapsing rules, and design patterns in using macros, function libs, and other constructs.
[/TR]
