Hello everyone, 

Tldr: please skip to questions

I would like to start creating my own game. I used the Squad Mod kit (ue4) , Maya and substance painter/ Designer and a little bit of b2m for some time now. I also took a look into blender and unity. 

I did this for about a year on and off when ever I had the time. 

 I followed payed and free Tutorials to get a very basic understanding in game development. 

I still feel like my workflow is messy and not very "professional"

There are many answers out there, I feel like iam stuck in reading Blogs and forum posts, searching for a definite answer where maybe there isnt one. 

"Questions" 

I need a setup that can do "everything" 

*please leave your thoughts/answer/tips if you have any. 

*when possible please link a Tutorial or learning Material to a topic

Thank you

1) Hardware 

Running a "gaming" PC. The one complaint I have is that loading for example the squad kit takes *ages*. 

8700k, 32gb ram@3600, 2080ti, cheapo nvme Kingston A1000, some tb wd hdds. 

I would like to put my 8700k in a new pc that I would use as home "Server". And get  a i9 9900k for my Main rig. 

Server: cheapo z370, wd reds, maybe optane? Small nvme/ssd

Monitors: two 32 inch 100% sRGB wqhd, one vertical 1080p, one 4k TV for reference and Media consumption. 

I dont know if every Software is good to use with 4k monitors today that's why ive choosen wqhd. 

2) Backup, file Organisation and Management

My worst nightmare is to loose Progress because I f'ed up. 

File Backups on offline and online Server (like one drive) with automatic sync Software? 

Version control with git? 

What's the best way to organize your files local?

3) Software to learn 

I am pretty sure I like ue4, Maya and the substance suite. I also use PS and illustrator. 

There is Software like 3d Coat or zbrush I might consider. 

Vfx is still confusing me. 

4) workflow / Pipelines 

What is the difference between a Pipeline and s workflow. Isnt a Pipeline a workflow in a bigger picture? 

There are many different informations in the www about this topic. I am still kinda confused. 

Should I leave my project/files iam working with on the kan Server or work on my Main machine. 

Is it possible to use the second PC as a helper for, rendering, bakeing Light etc? 

If youre still reading, thank you very much youre a hero. Maybe you can leave me a reply

Best regards

11 hours ago, cloaker said:

 

I need a setup that can do "everything" 

 

Define "everything" ?

Joke aside, i think most here develop on pcs.

Quote

*when possible please link a Tutorial or learning Material to a topic

That would need a topic, or concrete question concerning a subject, the more detailed, the better.

Quote

Running a "gaming" PC. The one complaint I have is that loading for example the squad kit takes *ages*. 

8700k, 32gb ram@3600, 2080ti, cheapo nvme Kingston A1000, some tb wd hdds. 

I would like to put my 8700k in a new pc that I would use as home "Server". And get  a i9 9900k for my Main rig. 

Server: cheapo z370, wd reds, maybe optane? Small nvme/ssd

Monitors: two 32 inch 100% sRGB wqhd, one vertical 1080p, one 4k TV for reference and Media consumption. 

I am so jealous. Some here develop on much lower hardware. I think we can approve your rig for any kind of development. But if the outcome runs slow on that one it may be unacceptable on "normal" household pcs.

Quote

My worst nightmare is to loose Progress because I f'ed up. 

That happens. Make sure that the causes are different every time ?

Quote

File Backups on offline and online Server (like one drive) with automatic sync Software? 

Version control with git? 

Sounds good. Sounds like your going to become a Linuxer, if you're not already one.

Quote

What's the best way to organize your files local?

A directory tree ?

Quote

3) Software to learn 

I am pretty sure I like ue4, Maya and the substance suite. I also use PS and illustrator. 

Oh, no Linuxer. Hmm, i don't know about these, but others certainly do. And the respective websites may have links for starters ? There is an unreal subforum (i man, the subforum is real, but the subject is unreal ?) up in the forum that is waiting for content ...

Quote

There is Software like 3d Coat or zbrush I might consider. 

Vfx is still confusing me. 

All these shortcuts confuse me too ?

My adivce: just start, get going. Don't so much care about side subjects. Pick the unreal engine you mention and and do a platformer. Or so.

Quote

What is the difference between a Pipeline and s workflow. Isnt a Pipeline a workflow in a bigger picture? 

Do you mean the graphics pipeline ? Semantics aren't really that relevant. I don't have workflows. I'm just an amateur. I fail differently every time ?

Quote

Should I leave my project/files iam working with on the kan Server or work on my Main machine. 

If you have a server that's probably where the backup happens. So, why not ? If you want to work offline in a cafe or harbour bar, leave a copy on your notebook and sync with the server.

Quote

Is it possible to use the second PC as a helper for, rendering, bakeing Light etc? 

Sure. But i can only work on one machine at any time. But i have seen organists ! Sorry ... ot ?

Quote

 youre a hero.

?

tl, dr:

Download the engine you mentioned and get going. If concrete questions arise, then here are friendly people.

11 hours ago, cloaker said:

My worst nightmare is to loose Progress because I f'ed up. 

File Backups on offline and online Server (like one drive) with automatic sync Software? 

Version control with git? 

What's the best way to organize your files local?

Git is probably your best protection against "messing up your code". It's like a savegame for programmers. However, it doesn't protect you if you forgot to save/commit your progress. So you need some discipline to commit each small substep. Automatic sync software might help you in this case, but I think it is usually not necessary if you got used to committing a lot. Also, you can write a script that automatically commits your changes every hour or whatever interval you like.

11 hours ago, cloaker said:

Is it possible to use the second PC as a helper for, rendering, bakeing Light etc?  

Of course, why shouldn't it?

Greetings

13 hours ago, cloaker said:

Running a "gaming" PC. The one complaint I have is that loading for example the squad kit takes *ages*

I'm running gamedev on my home PC that is a 5 year old hardcore gaming PC but it still works well using Windows 7.

• 16 GB RAM
• Intel i7 Hexacore CPU
• Sapphire AMD Radeon R9 290 X Tri-X Overclocked
• 500 MB Sata HDD
• 3 TB Sata HDD

I can't complain about running Unity or Unreal with these specs.

13 hours ago, cloaker said:

Backup, file Organisation and Management

I always work as if I would work on a public PC so first checkout my possibly updated files, run build tool on the project then open Visual Studio and after finishing work or an important change I always upload the changes to my online reposetory.

GitHub is ok but I prefer SVN and so have my private SVN and a public publishing git on GitHub.

13 hours ago, cloaker said:

workflow / Pipelines

A workflow is not a pipeline and vice versa. A pipeline is all the tools you use for certain workflow, Maya for example starts at the beginning of your pipeline, next step is Maya Export, next step is Unity Import, next step is Unity's FBX parser then the Asset Storage. Those tools in a chain that solve certain task are called your pipeline.

A workflow covers a task like getting a new model into Unity. Workflows often use pipelines to achieve the task but to get your model into Unity you need to create it first so using Maya is an own workflow while preparing the model in Unity is one another.

I hope that helps ?

@Shaarigan @DerTroll @Green_Baron

Hey guys, I just want to say thanks for your input very much appreciate it.
 

Quote

I still feel like my workflow is messy and not very "professional"

A workflow for a hobby developer is different than a professional. Professionals are focused on a single area, their area of expertise. A map artist is not going to be writing code. A programmer is not a map artist, etc. But when you're working alone, or in a small team, you generally have to take on multiple roles.

Quote

"Questions" 

I need a setup that can do "everything" 

"everything" is rather broad. Your computer seems fine. The rest is really down to just doing the work. Stop waiting for slow tasks that you don't need to. Building a playable game is about more than pretty lighting, although lighting is part of that. Instead of baking, try doing your work and testing it without a bake. Long running tasks are things that should happen when you're pushing more towards a release or finalizing a level and such.

Quote

1) Hardware 

Some processes take a long time. Baking is one of those. If you want to bake quickly then you need to offload it to a cloud. Alternatively, learn to bake when you need to (i.e. before smoking your release), that way you can keep working without waiting for bakes. Generally speaking, any long running task should be saved until after you've completed your actual work building something and testing it out. Your setup seems fine to me.

Quote

2) Backup, file Organisation and Management

Get and use source control software. Git is free and fairly easy to use. Perforce is also free for under 5 users and works quite well with binary files (such as art). You should be regularly committing your work. Break things down into folders, the exact organization is up to you though. Generally speaking you want to organize assets into logical groupings that make sense... for instance your various NPC armies might all be grouped by army and then with more general terms such as "commander", "captain", "grunt", etc.

The same is true of code, group things by modules, and maybe further by public vs private implementation bits. Or by namespace.

Quote

4) workflow / Pipelines 

Alright, now we get to the main thing I wanted to talk about...

Workflows are not really a "thing" so much as a combination of many things. Additionally, most professional workflows are oriented about the task that the person is trying to accomplish, and is usually reinforced by their tools.

An example workflow might be taking a map artist:

Initially, they will have some concept art, along with a look and feel that will be worked out together with the game director, map designer, concept artist, etc. A map artist will take a set of concept art that gives a look and feel for the map and translate that into a grey box rough outline of the actual map in an editor. Then they would work with the designer who will be building the content for the map to determine the playable space and any additional requirements. Defining these bits gives the map artist an idea of where they can and cannot put detail, the kind of mood that the content of the map is looking for, etc. The grey box also allows a designer to start working out gameplay mechanics for the map. Then the map artist can go back and start adding in detail. Since they know the design space of the map they know where they can and cannot add in blocking geometry, where they might need to place invisible walls, pathing components, and such. This can also help to guide some of the theming of the map. For instance, maybe it's a night time map but the concept art was brighter. Or perhaps the map is set in a reclaimed ancient magical ruin, so you're expecting lots of tall trees, grasses, and mysterious ruins that could be walls, floors or ceilings with glowing crystals and such. Maybe some mysterious giant C shaped ruin that could be climbable, etc.

As you can see, this workflow is very much focused on doing one specific thing... building a map to meet some design goals. If you're working solo then your workflow is much more oriented around combining multiple tasks together to do things. If you are the map artist and the designer then you obviously don't need to collaborate with someone else on that. But many of the same parts of that workflow are very useful. For example, while you might not need to collaborate with the designer to figure out the playable space (if you are the designer as well), the goal of that task is the same. Figure out where the player will be, and what they will be doing so that you can work out what you can put where...

In general, each person will customize their workflow for themselves. 

(1) Develop on your minimum recommended hardware. This makes sure that the game is fully optimized for the worst case. Just make sure to have surround sound speakers, multiple monitors and some cheap pre-used controllers of different types and models.

With software rendering, you can do anything on any platform without any dependencies. It's just not as fast for perspective with lots of divisions and random access reads, but super fast for isometric games where the cache reads are in order and models can be pre-rendered for global deferred light. Want a 17-channel texture format for your custom rendering pipeline? Just make what you want and get more than 60 FPS anyway. Today's CPUs correspond to dedicated GPUs from 2005 with all the cores and SIMD lanes. A few more cores with better memory bandwidth and we reach the graphics of 2009 where people stopped noticing which year a game was from.

(2) I use GIT for working on the code. I also place full copies on cloud storage (in case of fire), an external SSD and USB memory sticks (in case of ransom-ware).

(3)
If you want to try something free: GIMP, CodeBlocks, CppCheck, Valgrind

If you have some money: CLion, Visual Studio, Maya, 3DSMax

GIMP really is equal to Photoshop for making games, because you're not a photographer needing those expensive features.
CLion is a bit newer than Visual Studio but works well on Linux.
CodeBlocks is not so good for debugging because many types cannot be viewed, but it's so fast and portable that you can code efficiently on a $30 ARM based mini-computer running Raspbian.
3DSMax is a bit old and expensive but with an intuitive yet precise interface.

(4) How I work alone
* Start with crude mock-ups and prototypes. Maybe even use pen and paper to try simplified game logic. Don't waste time on polishing things that will most likely to not be released anyway.
* No feature is ever going to be 100% finished, because there will always be new ideas. If you try to complete one feature at a time, you will never finish the first feature and everything else will be left undone until you're out of time. Like in Scrum sprints, just reach the next step of ready without adding too many new things while doing so. Put the other things in a list of future plans unless they are required to reach the primary goal.
* Take small breaks after a completed task and then come back. This gives time to find bugs and inspiration. You will also notice which parts are too complex and needs refactoring and encapsulation before you make them even more complex and forget all about how they worked. You should always have your code ready to be abandoned for a year and then picked up again with decent documentation.
* Make the functional interfaces as soon as possible. Otherwise you will end up with code that cannot be encapsulated in a module and exposes too many internal types. Because headers in C++ were made for functional code, the only full encapsulation in C++ comes from functional programming. Exposing private class variables in C++ will prevent using lazy compilation safely and slow down compilation times for of the whole project with duplicated header bloat. A perfect header is much smaller than the implementation, exposes no types and does not depend on any other module in the same project.
* When you have something fun that you really want to release, start making it ready to be shipped with menus, installers, custom controllers, surround sound, nationalization and all that before the game becomes too complex to ever be finished. Make regression tests for your hardware abstraction layers and math libraries so that the basics can quickly be tested on different computers.
* Reduce dynamic dependencies from the start, for both prototypes and released games, also your tools and build chain so that work can continue before you forget everything. No dependency is 100% safe, because they all have their pros and cons. You don't know if the graphics API you started with will still work when you pull the concept out of your dusty pile ten years later to finally make a real game out of it. You don't know if the player can install a huge pile of third-party libraries, unless you know that it's practically impossible after a few years of deprecated operating system features, deprecated sound and graphics APIs, abandoned open source projects, driver version conflicts, new security features...
* Make the reference implementation first. You can always use a dependency even if it's questionable, but make the fallback solution that just works before relying on a new fancy API that might obsolete something essential that you just relied on as a core feature. During my 20 years of programming, I had to abandon many projects because they relied too much on something I never thought was going to change in the future.
* Avoid putting an external dependency in your core engine like the plague. It's very hard to remove once it's in there. Make it easy to change the back-end using lambdas (functional) or class inheritance (object oriented). Keep the list of essential features minimal in your system/hardware abstraction layer.

Good for dependencies:
+ Open and free to use with static linking (Bullet physics engine, STB Image)
+ Supported by big company or lots of contributors (Direct3D, Vulkan)
+ Good deterministic hardware abstraction (OpenCL, Direct3D)
+ Has been around for at least 20 years (XLib, MS Windows, OpenGL)

Bad for dependencies:
- Just arrived with a beta (Ray-tracing APIs)
- Projects on final life support (MS Windows, OpenGL)
- Has a ton of own dependencies without adding a higher abstraction (SDL)
- Doesn't work the same on different platforms (OpenGL)
- Exposes which hardware it uses (Vulkan, OpenGL)
- Anti-commercial license that prevent selling your closed game with static linking (GPL software)