Why no templates?

Hello everyone,

So I've been doing a lot of reading, and a bit of tinkering with Unity. I have a background in development (although it's been a while since I did it professionally), so I can grasp most of the concepts readily enough.

However, it occurs to me that Unity doesn't really offer any "templates" for "solved problems" out of the box.

For example, I'd love to be able to choose a template that implements the common "plumbing" most games use:

* Preload and Setup
* Splash Screen(s)
* Cinematic
* Title
* Menu
* Pause Menu
* Settings Menu
* Quit

These things are largely "standard" regardless of your target platform or genre of game in most cases.

What would be great would be to have Unity publish some simple "Starter Templates" that focus on the architecture of the game, rather than examples. Implement things like GameManager, Persistence (e.g. High scores), HUD or Score Updates, etc.

While not every game uses these things - I would contend that the majority of games need these "systems" in place to help manage the game efficiently and effectively.

Right now, I have to watch a bunch of tutorials, crawl through examples and generally spend way too much time trying to "unpack" what is happening.

Much easier would be a "Standard" bootstrap framework for games that helps me get going quickly, so I can focus on my gameplay and what makes my game unique ... instead of having to "copy and paste" (which isn't very DRY, by the way) from various examples and somehow stitch it all together.

In theory, if the template was kept simple, it wouldn't need to be updated very often - and any video tutorials that walk through how the game architecture hangs together would be relatively long-lasting.

Grateful if the Unity team could start an Open Source project or projects in this vein to help newbies like myself come up to speed quickly.

 

This might be in the right direction for you? https://forum.unity.com/threads/helping-beginners-get-started-with-unity.648076/

 

Hi @JeffDUnity3D. I had seen that thread, but it appears to have been basically abandoned ... a bit like a lot of things on Unity to be honest.

What I'm after is being able to get "1 click" access to a basic application / game framework for a particular platform and/or genre. Something that is BUILT IN to Unity so when I say "New Project", I can choose from:

"Blank Project"
"Desktop 2D Game"
"Mobile 3D Game"

etc.

And in each of those "solutions" is the basic scaffolding of the GameManager, HUD updates, Titles, Menus, etc. I don't think developers should have to "reinvent" these every time - it's all going to be required.

What we have now is very basic. I'm asking whether it might be possible for Unity to provide out of the box Scripts to manage things like menus, scene transitions, game management, high score tables, etc.

Alternatively, Unity should publish some assets / tutorials for these. Having example projects is all well and good, but you then have to strip out all the stuff you DON'T need to get to what you DO need.

Can we just get a simple "base solution" that handles most of the plumbing for us without having to write it? Surely, the team at Unity knows "best practices" for these types of things.

Heck, make it an Open Source project so the community can contribute as well. But definitely have it managed and run by Unity, so it can be updated and maintained with each new release and as new features come online.

By way of example, I have spent HOURS looking at lots of different projects, and even the Unity examples don't do things in a uniform way. All I want to do is set up the basic "plumbing" of my application in a "best practice" way - but it seems even the example projects don't apply things consistently.

For example, the 2D Roguelike uses a different way of "bootstrapping" the game to the "Trash Run" example. And the 2D Game Kit does something different again.

Can we not have a simple, straightforward way to structure our projects that makes universal sense to everyone? I'm fairly confident that would enable new developers to start on the right foot, and also enable more advanced developers to accelerate their projects.

 

They aren't uniform, because games aren't uniform. Luckily, anything made with templates is usually boring like hell and developers, who expect templates and 1-click solutions usually are lazy like hell and they don't design their games well. I'm actually glad that Unity does not invest more in pre-made game templates, they produce a ton (literately) of tutorials, some examples (2D Game Kit, 3D Game Kit, Tower Defense template) and they're working on the new "standard character controller" and they're working on the mobile-oriented Game Foundation.

When you need to poke around in the basement of your game you have the chance that you actually create something not painfully boring.

 

I get it. We all want our games to be "snowflakes", but the reality is there are many, many common "systems" within games that would benefit from not being repeated.

For example, every game is likely to need a Menu system of some kind. The visual aesthetics and game feel for this will be vastly different between games, but most games have things like Control customisation, Sound volumes, Credits, Exit, etc.

Similarly, the mechanism for managing Player movement, or managing sounds, etc. What I'm interested in more is the architecture of the game - not the implementation.

What I'm talking about here isn't what makes games unique - it's what is common. A "Game Foundation" is actually a great term for this kind of functionality. It's simply a common architecture and set of best practices to help new developers and experienced developers use similar patterns.

One good example of this is the GameManager, which is a Singleton in many cases. I've seen at least three or four ways this is implemented ... which one makes the most sense?

Then, what about the Player Controller. Some people put it on the Main Camera, others on the Player object itself, and others do some other weird things!

Again, I'm less worried about the specific implementation - because that is the "creative" part. What I'm concerned about here is the way in which components fit together - especially "essential" components like the ones I mentioned in the original post.

 

Actually, Game Foundation is exactly what I am talking about:

https://unity.com/solutions/mobile-business/game-foundation

This one seems to be focussed on mobile development - so it would be great to have a desktop version as well.

Any idea when this is coming out, and who will be able to access it?

 

My viewpoint is that it's largely a waste of time to create these templates. To understand how to implement and work with these features you generally need to go through the steps required to create them, but once you've done that you no longer have a need for a template as you've already created the system in question.

Plus it isn't like you can just take your knowledge of how to create them in one framework and use that same knowledge to implement it in Unity. Unity's UI functions and is assembled differently than another framework's UI, so even if you are an experienced developer you will still need to go through the steps you went through to learn the other framework(s).

 

I think you're missing my point here. I'm actually trying not to apply things from other frameworks, and to use Unity's best practices.

I disagree that once you learn the framework you won't need the template - in fact, I think it's essential to have consistency in your game architecture (not gameplay or game design) to help improve maintenance.

Think of it like coding standards - they make development faster, because you have to make less decisions and your choices come naturally. Your code is more readable because you have consistency. It's the same with architecture.

If I need to find a particular method or place to put something, having a "base architecture" would cut down on the decisions I need to make, and the research I need to do in the first place.

In addition to having "default" templates, it would be great if you could create your own, so that once you have the basic mechanics and items you like together - you can simply create a new project.

Obviously, this could be done via Git or similar - but it would be great to have these patterns in the editor by default all the same.

 

If you are looking for some premade solutions, you can find many on the asset store. This is exactly what it is for. Many people sharing templates of what they made for themselves. However most are different as they fill different niche. Ones that try and fit all situations are largely bloated.

But I agree, its mostly a waste of time due to the differences between games. After making your first few games, you will come up with own templates and way of doing things.

If you want some kind of menu making system, check out doozyui. https://assetstore.unity.com/packages/tools/gui/doozyui-complete-ui-management-system-47352

Over 70 people left it 5 stars, and 40 - 50$ is nothing considering the amount of effort put to keep it up to date.

If you are looking for free, check unity list: https://unitylist.com/

 

Thanks. However, my point is this should be "out of the box". After all, all games have similar patterns for many of these common systems. Menus, score keeping, titles, HUD updates, etc. That shouldn't require an Asset Store purchase - it should be something Unity is encouraging for all developers.

Differences between games makes sense when you're talking about specific game mechanics, or even the setup of the game world. But for things like the preload sequence, or the main menu, these are very standard. I don't understand why these aren't automatically included out of the box.

Again, I am talking here about game ARCHITECTURE, not game LOGIC. These are two very different things.

 

Ok, I dont think you are hearing anyone here who has posted. For example scorekeeping can be vastly different between systems. Both in architecture approaches and logic. These things are not largely standard. Furthermore, writing your own (for example) shouldnt be that much of a chore. Most templates would be just bloat. The store has lots of free examples and tuts. Things like main menu are just uGui which is included. Its all there. Pause, set Time.timeScale to 0.

After you make your first few games, you might change your mind. Have you checked out something like gamemaker if you want premade solutions?

 

I used to feel the same way as you, @matthewdporter. In fact, when I saw this thread and clicked on it, it's because I had forgotten that I changed my mind, and I came in to support your point. By the time I made it through the other comments, though, I remembered why I had changed position.

I have a tendency to over-engineer things. I have this idea that I can create a scalable, generic system for anything. Although it will cost me more time up front, the next time I use it, I'm saving boat loads of time. The problem is that no two projects, however similar at first blush, turn out to have the same needs.

Let's look at a single example: score tracking. It sounds simple... When a game finishes, save the score along with a username or something, and have a screen that can access that data and display it.

But how many different ways could you handle that? You could save it locally like an arcade machine. You could save it to Apple's Game Kit. Or Google Play. Or Firebase. Or AWS. Or a custom server. What about the name... is it three letters? A full username? The name associated with an account registered to the system? Does the name link to that person's profile? What about the score? Is it just a number like a high score? Is it a time? Maybe both? Daily leaderboards? Monthly? Seasons? Multiple leaderboards for various modes?!

Suddenly, this simple task becomes a lot more complex. If you know what you need going into it, it's not a crazy amount of work. But if you're trying to create something that's generic and suits all those use cases, you've now got a pretty monstrous pile of code. And now that code is a lot harder to use for someone that only wants the basics, right?

And this is all assuming that the template code covers every need. Because imagine the disdain and unrest that comes from someone needing to connect to a service not expressly covered by the provided template... Doing so, it becomes evident pretty quickly why Unity would rather stay out of such assumptions as to how people develop specifics of their games.

I think, as developers, we'd all love to see some of the tedium taken out of our work. To not have to feel like we're reinventing the wheel all the time. But I think we're probably best served by coming up with those solutions ourselves, and creating things that suit our own needs, within our own constraints, to achieve that.

 

Au contraire - I believe I'm not being listened to.

Your statement about "After you've made your first few games..." is exactly the problem. My point is this fills the need of those of us who are new to things.

"Go do it" is not much help when you're in the dark, to be honest.

Yes, I've looked at GameMaker, and it suffers many of the same problems. I've chosen Unity and I'm happy to learn - I'd just rather not take the "hard way" out when these should be largely solved problems.

RE: Your comment on scorekeeping ... I think you're confusing implementation from architecture. A simple question like "Where should the score be maintained?" can have many answers ... which unfortunately is of no help to those of us who are new to the environment.

If we were provided with a simple set of classes and Game Objects out of the box to help get things moving, it would accelerate and facilitate learning far more effectively than starting with a blank project. That's all I'm saying.

 

@Schneider21. I'm obviously doing a poor job of communicating here. What I'm talking about is not implementation ... it's architecture.

The items you've highlighted are implementation (score keeping) in that what's inside the objects takes care of where and how these things are done.

What I'm more interested in, to put it bluntly, is which objects make sense for most projects? For example, I have read a lot of things on Singletons as a pattern for a GameManager ... then yesterday, I watched a Unite talk about why that's a bad idea, and now I'm like "OK, so now I need to use Scriptable Objects and Actions ... where is the example I can use to learn how to do that?"

Honestly, I do appreciate every game will have a different implementation. What I'm less convinced about are the design patterns and architectures that work in service of that.

I definitely don't want an over-engineered "one size fits all" object ... but having a simple set of "base classes" to work from in terms of knowing where to start would be immensely helpful.

If that's not something people want, then perhaps having some articles on things like:

* Game Management
* Score Keeping
* Persistence
* Enemy Behaviours
* Player Control
* High Score Management

and so on would be helpful.

Or a series on when to use particular patterns for these things at least. Just some straight-up simple guidance is all I am after.

Hope that makes sense.

 

If we change subject from templates, to examples, that resolves many issues
And as far I am concerned, there is plenty of examples 'out there'.

 

No. We understand what you're trying to suggest. We just don't agree. Changing the wording in an attempt to fix what you perceive as "a failure to communicate" (I love using this movie quote) won't magically change our statements to one that agree with you.

 

To be honest, besides number of tutorials for starters, provided by Unity already, asset store takes care of many such aspects.

Leader boards
https://assetstore.unity.com/search?q=High&q=Scores&k=High Scores

Controllers
https://assetstore.unity.com/search/?k=controller+price:0&order_by=relevance&q=controller&q=price:0&rows=42

Behaviour
https://assetstore.unity.com/search/?k=price:0+behaviour&order_by=relevance&q=price:0&q=behaviour&rows=42

As it may sounds cruel, I see only three ways here:

1. 'New' dev is going to learn using search features of the internet, to find what person needs. Including asking and posting questions, if in need, to seek answers.
2. New dev is going to learn how to develop own features (most likely based on point 1).
3. 'Dev' should drop game dev.

 

I'm OK with you disagreeing with me. It's just not very helpful to tell people "go figure it out for yourself"...

 

Thanks. Seems to be that the only way to "learn" Unity is with trial and error - which seems very strange to me. Honestly, as someone with considerable development experience, it makes no sense at all.

If you look at something like Python as a language, there are reams and reams of prebuilt components and libraries, because the community really gets that it makes sense to not reinvent the wheel.

 

And that's exactly the problem. They all do things in different ways. There is no "here's how to set up the architecture of your game".

I think the root of my problem here is there is no concept of "flow" in Unity. As in, there is no "main" or similar way to "bootstrap" your application or game. I think if I can get some decent guidance on that alone, it would be a huge step forward.

 

Here is the problem though. We have two basic types of people join this community. We have experienced developers and we have new developers. Both of them will have access to these "drag-and-drop" solutions.

I was an experienced hobbyist developer when I come to Unity. I had past experience with UDK (aka Unreal Engine 3). I had past experience with C#. I learned how to use Unity using the manual (tutorials back then were just bad). Getting a third party asset working was a fairly painless process. At most I was looking at a couple days of familiarizing myself with it before I started using it. People like me are not the problem.

People who are the problem are new developers who came to Unity. Once again, just like the experienced developers, these people will have access to these "drag-and-drop" solutions, but unlike the first group who will have experience to draw on these people will have no idea what they're doing with them.

What if they need an unsupported feature? What if they encounter a bug? Well, if they decided to take your path and go with a pre-made asset, they won't be able to do anything about it because they didn't take the time to first familiarize themselves with how it was made. It will be nothing but a painful experience for them and for us since we're the ones helping out.

Plus you have no guarantee that an asset will continue to be developed. We already have problems now with Unity's official resources (eg Interactive Tutorials) becoming out of date and no longer functioning with releases that are only new by a few months. Store assets are generally better supported but they too can be dropped at any time and support is generally just one person.

If you need to see this in action go look at posts created by new developers in asset threads. We already see a form of this today, but thankfully it's very minimal since the assets are behind paywalls.

 

You see, here may be a little misconception you are carrying on. Anyone correct me, if think I am wrong.
But python was developed by community from early days. It has much fewer iterations than Unity. As of current, python have two major branches, if I recall correctly, which differ from each other. Other than that is pretty stable, from release to release.

In Unity, stuff can break from release to release, as software evolves.

In python most tutorials and assets are made by people for people. Tons of git repositories, wikis etc.
In Unity, they would have to maintain backward compatibility for every tutorial, yet keep up to date.
Asset Store takes that whole burden out of a way. Plus tons of external resources on a reach of a hand.

Yet as guys previously trying to highlight, there is no such thing in a game, as default layout, or functionality.

And indeed, development is like trial error. I mean, as far you can find many examples 'out there', you as dev, need modify, try this, try that, check if works. If not, modify, If still, replace, or dump. Nothing but trial error.

Using Unity, that is already being in good potion, in terms of tons of examples 'out there'.
As far I am aware regarding Unreal for example, (haven't used myself), from what people say, there is much fewer available resources for concurrent engine. Yet people develop there too. So doesn't seam to be concerned neither here or there, considering tons of releases every year, on any engine, or even other programming languages.

 

@Ryiah: I understand assets can get out of date. It's one of the reasons I think this should be maintained by Unity themselves, actually.

Again, it doesn't need to be massive - just a "pattern" we can follow would be enough.

For example, I have seen people attach initialisation scripts to Main Camera. My gut tells me this is a bad idea. But then, I don't know an alternative?

I've also heard people speak for and against the use of Singletons to house Managers. Which one is right?

All I really need is a nudge in the right direction with regard to where to put initialisation code for the game itself. For example, where should I instantiate the player? Should I create an object to do that, or just put the player in the scene?

How about enemy spawners. Should I create them in a Prefab and then just drop them into a scene? What if I want some "preroll" to occur before that?

Again, it's really about me understanding how to manage the flow of the game in Unity. I get that objects have behaviours (scripts), and it makes sense to encapsulate that with the object and avoid depdenencies ... but as to where to start? It's a great mystery apparently...

Can anyone tell me even some OPTIONS for where to put game initialisation code?

 

I'm really OK learning most things by looking at examples - especially things about game mechanics and the like. What I don't want to learn is the stuff that should be just out of the box ... like where to put the score.

Should I put the score on the player object? Or should it be a discreet object on its own? How should these objects communicate? Should I use Delegates and Events or Actions?

There are so many possibilities that really should be sorted out as "commonly used patterns" at very least. Right now, it's a dog's breakfast of many different ways to achieve the same thing ... and sadly, it lacks any concept of maintainability or performance ... both of which should be project goals in any software development.

 

Unity is the worst choice to maintain this. Unity's Standard Assets have been broken for months now. Unity's Interactive Tutorials were made for 2018.1 and are known to not function properly with 2018.3. Back when the Stealth tutorial series broke the solution they went with was to delete the whole thing rather than fix the problems it had.

 

The current template progress is actually:

1. make new project
2. choose a rendering template (HDRP for example)
3. use package manager to import the functionality you want

 

The fact they do this is just terrible. And I agree that any company that does that kind of thing is an awful custodian of best practices.

My point was more that they should do this, not could do this.

Seems Unity wants to treat the project like an open source "best efforts" without releasing the source...

Edit: Your point is well made, but also supports my assertion that example projects are a terrible way to manage this. There needs to be a bit of "keep it simple" applied here.

 

Are there packages for game architecture?

 

Yeah. Also Unity split some of the functionality into free packages on asset store too. Check the ones done by unity.

Hard to tell if it will do everything for you, but Unity won't be ready for code-less solutions until 2020 (visual scripting etc).

 

Actually @hippocoder, I'm not looking for visual coding (although I have been pretty impressed by what Bolt offers). I want to write my own scripts.

I'm just looking for someone (hopefully on this thread) to guide me on where and how to set up "bootstrap" code for things like Initialisation, and whether GameManagers are a good idea, and if so, how should they be structured. Things like that.

 

Unity visual scripting is best option, to be backward compatible, once is released. At least between few versions. I see this as feasible. Yet not sure, if that what it will be.
Matlab made so awkward to work with backward compatibility. Yet there was enough, to look into main config file, to just change version number, to older version. Of course, that not always the case, but mostly.

Anyway, Unity visual graph, should be easily maintained, visualized, and modifiable.
I think it will also generate a code? Kick me, if I am wrong?
Hence templates should be more stable as well.
Exact what many new devs needs.
Beyond that, anyone will develop own structure and patter anyway.
Specially if having previous solid dev experience.

 

Here's an example of when this is done right:

https://docs.unrealengine.com/en-US/Gameplay/Framework/GameMode

See that "World Settings" dialog half way down the page? That's genius, because it helps people to realise exactly the components they need to configure in order to have a working game.

In fact, anything in the Gameplay Framework section of the manual is MILES ahead of anything I've seen for Unity, to be honest.

I'd really like to stick with Unity (since I think it's a more diverse and better engine than UE4), and I prefer C# and Unity's great asset store over UE4's more "DIY" approach.

But dang. That stuff makes me jealous.

 

There are plenty of reasons to use either. There is no right. The world is grey and not black and white. Pros and cons. You are asking for premade solutions still. Again, the asset store has tons of them. Yes, they are not free, because people make them. No, unity does not make them (mostly) because different people do things different ways for different reasons. They leave it up to us, the developers to decide.Anyways, I am out of this convo, because I think plenty of other people have already made good statements as well. There are just so many tutorial already available by unity and others. Avail yourself or not

 

Only if you know what the terms mean. A new developer won't understand the terms. What's a pawn? What's an actor? What's a character? What's a Player Controller class and how does it different from a Player State class? What's a Spectator?

If a new developer takes the time to go through the tutorials step by step it will be explained what all of these terms mean and their relationship within the game engine. If they don't follow the tutorials they will be completely lost.

Incidentally there is nothing special about any of it. UE4's Actor is essentially the same as Unity's GameObject. A Pawn is simply an Actor that is assigned a Player Controller. A Character is a Pawn with features (eg animating a skeletal mesh) that you would need for a characters (ie the player, enemies, etc) in a game.

Creating the exact same functionality in Unity is at most a several minute process for an experienced developer. You simply need to create an animation controller, set its animations, create a script that checks inputs, moves the character, and plays the animations. It's a trivial process.

 

PS, it makes perfect sense. We WERE where you are now. New. Everyone who has experience started somewhere. Also no one is suggesting just go do it. They are saying, take the unity tuts, use the unity provided example scenes, buy assets and use them (or see how they work). Good luck!

 

Unfortunately do not fit for the content of this discussion, since you have shown example for multiplayer game. It is not basics template. Surely not for a beginner. And this is again, what people trying point out. You can not satisfy everyone, with generic solution, to fit all.

 

Thanks everyone. I look forward to the adventure.

 

Speaking of the asset store, there is one asset (technically it's multiple assets because the more advanced functionality is sold as add-ons) that does appear to be aimed at quickly creating game functionality. I have not used it myself but I have seen people talk about it in a positive way.

https://assetstore.unity.com/packages/templates/systems/game-creator-89443

I only just remembered it or I would have mentioned it earlier. It came up in one of the visual scripting threads.

 

Thanks @Ryiah. I'm trying to avoid these types of systems, because so many of them become abandoned after a version or two.

I'd much rather use native functionality so I am less likely to be "held ransom" by some well meaning but ultimately unsuccessful Asset Store seller.

Interestingly, I also found something that has so far been helpful in terms of forming my thinking (I haven't - and won't - purchased the asset): http://www.flipwebapps.com/unity-assets/game-framework

The patterns they are employing are more along the lines of what I was suggesting earlier.

Thanks again.

 

You told us you don't need these to use as-is, you need them to learn how to do stuff. So why don't you buy these assets, dismantle them and learn how they works? After that, you won't be held ransom, because you can develop whatever you need.
BTW, the develop whatever you need is what Unity first and foremost support (after that that you should buy assets, but since they have some income from that, it's understandable).

 

My experiences with the Asset Store have been the exact opposite, but then I thoroughly research everything I purchase to prevent that from happening. It's not like it's hard to do either. You just need to check that they have reviews, have more than one or two releases in the changelog, have a forum thread and are actively posting on it, have a good website, etc.

That said in the event that it is abandoned I make a point of never purchasing an asset that doesn't include source code.

 

Thanks all. So far, I've managed to piece together a bunch of really good resources ... it's work I would rather not have had to do, to be honest - but it has helped me understand the benefits of ScriptableObjects over Singletons - and when each of these makes sense.

Fundamentally, I'm coming up with my own Game Architecture, which I guess will evolve over time. I still think Unity should provide more explicit and cohesive guidance on Game Architecture, whether that be by way of templates, articles, examples, or videos. The unfortunate situation at the moment is that different resources from Unity take different approaches - which doesn't make for good, solid guidance for beginners.

That said, I'm prepared to accept that perhaps that is the point. Perhaps Unity doesn't WANT to provide that guidance for reasons best known to themselves.

Personally, I'm a fan of keeping things simple - so I would still love to see them have a reference architecture for games that takes into account bootstrapping, settings management and sound practices for maintainability and performance. Ideally, I'd like to see that in a reference project of sorts - and to see all their examples follow the same approach.

But, it seems there is already a lot of momentum for "do it however you'd like", so perhaps I'm shouting at the tide.