UE5

Then I'd learn how to write code in unity. But unity causes me problems in areas that I don't need help in, and other game engines solve that. So I go with the one that causes me least issues. But to be honest I dont really want to get much deeper into code than I need for a specific project. I'd like to hire full time help. Right now I have too much divided attention trying to do entire games on my own. I really dont enjoy programming, so that would be first area I give responsibility to someone else.

It would be nice if you told me how I am approaching something the wrong way.

 

Without knowing the full details of how you approach a topic I can only speculate. A tutorial covering dictionaries in Unity is only eight and a half minutes long. That it took you an entire day to learn says there is something seriously off here.

Are you including the time it takes to memorize the approach in that?

Spoiler: C# Beginner Course - Dictionaries

 

Languages like Python have a very thorough documentation for every aspect of the language. There are pages upon pages upon pages of docs for everything.

So, basically, you need to grab a book about python, walk through the exercises and that will give you a foundation necessary for majority of languages. (Python knowledge won't help you much if you for some reason decide to tackle declarative or functional languages, but that's something that's unlikely to happen).

Dealing with dictionaries should not require a day and especially a day of a trial of an error. Because a dictionary is logically similar to an array, except you use keys instead of indexes. ar[0] = 1 could be an array or a dictionary.

If you're struggling it means there's a huge fundamental error somewhere in your knowledge, and the faster you fix that, the better.

Maybe you should post a code fragment somewhere and have someone walk through every aspect of it. Or hire a tutor.

Because going forth with just blueprint knowledge is a recipe for a trouble. You have to know how to script. You don't have to love scripting, you don't have to use scripting everywhere, but you have to know how to script.

That part in Ryiah's code snippet is engine-agnostic. If you code plain C# it will work the same.
It is also close to being LANGUAGE-agnostic, because a "Dictionary" is a concept that appears in many languages, and principles of operating it are similar, although small details can differ. it is a piece of universal knowledge.

 

In 8 minutes i'm not going to be able to actually use the thing in my own project under various conditions. There is a difference between knowing a thing and being able to actually use a thing. I am talking about being able to efficiently use it.

Also you have to understand I have worked most my life not in tech sector. A few years ago I couldn't tell you what windows explorer is. So what might seem simple to you is only so because there is a lot of prerequisite knowledge you don't understand another person might be missing.

 

In any case, I don't know what you are defending here. I dont know why every discussion here has to boil down to a battle of this versus that. A guy ask if learning unreal is hard. I tell him no, and you can use visual scripting in interim time it takes to c++. And that it's actually a very viable strategy for hobby developers.

Now everybody is arguing visual scripting verus code. And explaining to me the purpose of written language. I think you guys take too much personally, it's hard to have a regular conversation where people just share information.

 

You have to know both this and that.

And people correct you, because what you say is false, as blueprints have shortcomings, there are a lot of them, trying to avoid C++ is not good, and "hobby developer" is not a very sound concept.

 

Within that eight minute window you learn how to create them, how to add data to them, and how to extract that data. What more do you need to know to be able to use it in a project? It's not like the concepts magically change when you switch over to your code.

 

Hmm okay. So all the methods I am using that produce actual results are false.

I wonder if I will even publish my next game after all. I mean things seem to be going great but I am doing things wrong apparently.

 

Well there is a number of operations you can do with them. And knowing where and how to get a reference to a thing, and what caveats are entailed, takes time to learn. Sometimes a thing just doesnt work and you sit there debugging trying to figure out why. That takes time.

 

Just because you can bring a product to market doesn't mean you are approaching the problems correctly.

 

Aha.

Bingo, there it is.

Just think about that.

Are you guys really concerned with helping other developers produce games, or are you offended or insecure if somebody is finding a different way to accomplish same goal as you? I think there is a lot of ill-will!

 

You guys are employees, that is probably a big difference in mindset. I only work for myself, and have done so far almost ten years now. It's very different when 100% of your food comes from your own effort. No time for BS.

 

I remember working for a data collection agency back in the early 2000s. We had a programmer fresh out of college that wrote the software that we used to enter the data into our database. Fundamentally the program worked as expected and allowed you to enter data.

Until that is you made a mistake and entered one type of data where it expected a completely different type. Typos happen and when you hit a letter on the upper row instead of a number. When that happened the software wouldn't just crash on the local machine being used it would take out the database server too.

We had to restart the machine several times a day. All because we had a programmer that didn't know how to write good code.

That you completely fail to understand the difference between "skilled" and "professional" is the most telling part that there is something wrong here. I have run into many people who were skilled but not professional and many professionals that wrote crap for code all the while thinking because they had a successful product they were skilled.

 

That's a strawman.

Your next game could easily die without ever being finished.

That's partly because you refuse to investigate other approaches that can improve your efficiency. That creates risk of major failure. In case of major failure you'll face a situation where your tools fail you and you cannot proceed as things do not scale. That can cost you a half a year, a year, or the whole project.

You're currently heading into a territory where such event is a possibility, simply because you refuse to learn to script, and decide to stick with blueprints only. Blueprints have issues. You cannot reliably avoid this issues and you're very likely to run into them, no matter what you do. That's why it helps to learn basic of scripting.

No, that's an excuse, you are not different from other people here.

Working for yourself means that you need to be jack of all trades, while specializing in one thing. One more reason to pick additional skills, especially when they're related to what you're doing. People aren't telling you to do something unrelated like getting a helicopter pilot license, they're suggesting to learn something directly related to the area you work with.

 

Great, that's a good lesson learned for him and everybody.

I also stress test my work. In fact I play test my game daily to find errors. That's called risk management. I learned how to do that when I was doing dangerous missions in the military. It's not specific to tech world.

 

Lol. Real winner talk there. I got the beta about ready in another week. There is only polish left to do. My efforts are turning now towards marketing.

 

Go to steam, head to "Elite Dangerous: Odyssey", read the reviews. That's result of work of professional team.

"Beta about ready" means you aren't done, the game isn't finished, and there's still a lot of room for failure. For example, errors you never knew about could start surfacing, and those errors could be result of the approach you chose. For example, blueprints are also more error prone, among other things.

Obviously, that's only a possibility, and not a guarantee.

Anyway, as they say, you can lead horse to the water, but you can't make it drink.

The advice I gave is reasonable one as far as I can tell, and if you don't wanna follow it, that's not my problem.
Your life, your decisions, your consequences to deal with.

 

Home dawg, my game is a walking sim. There is like five different actors in the game. Any one you code geniuses could have wrote it in a day if you had the inspiration.

 

Oh, you're the one doing the land nav simulator.
Now that you are on UE, are you going back to your original idea of mostly forests?

 

Yeah, a forest setting is pretty important part for me. Unreal makes that work easier, so I stick with it.

I actually went into unreal first with intent to hire a full time programmer, but I couldnt find a person I could afford, so then I determined to learn c++, but then I realized pretty much all of the work could be accomplished with blueprints.

I dont know where this idea comes from that I am telling people don't learn to write code. Nobody said anything like that. Some people just here to argue and fight like its the only way they can get someone to talk with them or something.

 

Guys, seriously, there's no need to force a sole developer to go C++. Or trying to convince so hard

I wouldn't ever go blueprint-only way, but I already spent a few years mastering it. Might as well create an entire walking sim in that time. Trade-offs are everywhere.

- Working on walking sim that is actually by definition game so simple that might be implemented entirely in blueprints. I've done one successful walking sim. It required Kismet, Unreal Script and C++ in UE3, yes.
- It was recreated in UE4 with blueprints for new consoles (PS4/XOX). Code modifications were needed because UE4 not being mature enough. In the recent UE4 version I might go away with not touching C++. At least for the PC version, which is the usual target for solo developers.
- Sure, some things won't be too efficient in blueprints. Supporting consoles isn't easy in blueprints only, from what I heard. Still... A project can be upgraded with a C++ module if needed.

It's a different story if we're talking about teams... every time some team went the blueprint-only route, they definitely hit a wall. Ending up hiring a programmer for the next project. It's natural for teams to have a full-time programmer.
Not exactly possible to hire a programmer if someone has money only to sustain himself/herself.

 

You said it's "something a hobbyist has no business doing" and that "blueprints can do anything you need".

https://forum.unity.com/threads/ue5.1116148/page-22#post-7377995

Both arguments and fights require more than just one person. I'm not going to comment for the others but I have presented my case based on the posts made by the person you wanted to help and you've repeatedly shot it down with your own case rather than the case of the person you were helping.

Telling someone that they have no business learning programming if they have literally been writing code this entire time would be like telling an artist they have no business modeling when they have been using modeling tools this entire time or a level designer they have no business trying to make levels.

Where your advice works is if a non-coder needs to know whether they will be held back.

I'm quoting this again because it's important to understand that the purpose of a forum is to discuss and some aspect of that is going to be debating points. The definition of debate is literally "to argue about a subject".

And some tasks are completely unachievable with them. Earlier I gave Photon as an example because it's very popular with both hobbyists and sole developers but it's by no means the only example out there. Thanks to the popularity of Blueprint this gap is slowly closing but there is still a gap and it's still within hobbyist reach.

 

I literally tell people exactly this, lol.

I like making art but when I got a whole game to make it simply makes no sense to spend time making custom work. If I really got to I look for any possible way to get as much done from preexisting work as possible.

 

You could very easily replace the word "modeling" here with "texturing" or any other artistic task. It doesn't necessarily have to be from scratch either.

 

Nobody really said to go full C++.

The idea was to explain that being able to do some scripting is a good idea. Because when you stick with one approach, that approach can fail. He can't learn C++. He can, however, learn basics of imperative programming in Python and in doing so become able to script in C++ in Unreal 4. Which is a big difference. Because you only need basics.

The person in question, however, refused to budge, refused to learn and stubbornly rejected every single useful resource presented.

At which point it is "horse + water" and no longer my problem.

The statement about "Blueprints being able to do anything you'd need" is false, and so is the talk about "hobbyist shouldn't do X". I believe I conveyed that well enough.

 

Speaking of which there is an asset on the marketplace that lets you embed snippets of C++ into your Blueprints.

https://www.unrealengine.com/marketplace/en-US/product/magic-node

 

This is a step in the right direction, but at a glance it seems like the code has to be wrapped in a class. Which is not that great.

I'll probably take a better look at this at some point though.

 

I put in a week to their learning path tutorials, a second week to making stuff with blueprints and honestly it is very fast for iterating. Usually I hate node based scripting but I don't know all the namespaces off the top of my head yet so it has been really beneficial to assemble with blueprints.

Then you can look at your blueprint's base class and make your own C++ class where you move members to and still call from blueprints, the action rpg example was built with blueprints then converted to C++ after the fact and they use it as a learning example. So seems reasonable to prototype in blueprints and then refactor in the places you can gain performance until you've learned cpp and their namespaces well enough. Or you can do your code in cpp but expose members to blueprints so you or designers can edit parameters in the editor.

Then I took a step back to brush up on C++ and again I usually hate video tutorials but found a good channel that is a quick and to the point rundown of features that clears up a whole whole lot. Finally pointers, references, dereferencing and some of the syntax that makes you scratch your head at first makes sense. Then neat stuff like unions or working with memory in place rather than having to parse an object to edit it's fields, can just edit fields directly by offset much faster (if you're careful).

I really like that they keep the gameobject->component system that we all are accustomed to and it's just really damn fast in cpp.

 

Hey, @BIGTIMEMASTER do you have a site / steam page / anything related to your UE game I can see online?

 

Just a discord community for the moment. In a couple months I'll probably do something more as I'll be more focused on marketing. Trying to get some more music done and maybe hire someone to help with a trailer, etc. The game is boring to watch so I have to do a lot to make it look exciting

 

You don't have to make it look exciting, "just" make it look interesting

Music can go a long way if you're going for a more moody experience.

 

I agree, exciting I just mean "good" in a general sense. I was able to get a music guy whose work really impressed me in the past so I am happy to see what he is going to produce. I think it will be really important part of a trailer.

 

Ok, we are done here. Too much bickering and clearly not a Unity topic. Closed.