TODO: Scoring System

[antfarmar]

Implement a scoring system.

[ghost]

If you want to look at one way to do it, I made a pull request

https://github.com/antfarmar/Unity-3D-Asteroids/pull/18

One thing I forgot to do was to use GameManagers audio sources for playing score update sound. But hopefully you could easily change that - I tried to make the code as simple to replace as possible.

[antfarmar]

Nice implementation. It appears to be pretty robust and fully featured. (you really like your static classes & variables :see_no_evil:)

I might keep the initial base implementation simpler though.

[ghost]

Yes. If there is a need to have 7 different score channels, I write 7 different score channels.

Nothing prevents you from using a singleton behind a static interface, but you can ask yourself what you actually have won doing so. Singleton, to me, is just bollox. It's such an ugly solution to a simple problem.

To try and make an example of why I don't like it

Would be annoying to do Input.instance.GetKey() or Physics.instance.Raycast() now, wouldn't it?

And what would the difference be?

What have you won?

What have you lost?

[antfarmar]

I was mostly joking about the "evils" of globally-accessible statics, but since you ask:

Singleton, to me, is just bollox. And what would the difference be? What have you won/lost?

1. You can’t extend MonoBehaviour with a static class, hence it can't be a Script Component.
2. You can’t implement an interface with a static class.
3. You can’t pass around a static class as a parameter.

I'm with you, though. Statics classes have their place and uses (as you point out with Input, Physics, Loggers, etc.), and are not as problematic as everybody seems to make them out to be if used properly. I guess they're mostly an issue on large complex multi-threaded codebases with lots of classes and developers poking at them.

I usually try to avoid them, though, and I'm not exactly sure why, but I'm guessing it's because the literature claims to do so.

[antfarmar]

Implemented a simple scoring system.

commit 91ffd09

[ghost]

For the sake of reflection, I add some thoughts. You don't need to defend your choices. This is not meant to be viewed as a means trying to convince you into one way or another. I am not religious about how to solve problems, but I tend to lean toward the cleaner and simpler solutions until there's a more complex need. In your case just adding a variable, formatting & presentation code to GameManager, so I'd call it relatively simple, for now.

But a heed of caution. Your GameManager is building up micromanagement. It is dealing with lots of tiny implementation details. At first glance it may not be that bad but if you keep on cramming variables and functions into GameManager, it'll risk becoming a god object.

God objects do have practical issues: This might make collaboration tricky, since collaborators could change the same file or even the same lines of that same file. They might do so often (the god does all, right?), and for completely different reasons (the god knows all, right?). Merging becomes painful. It becomes harder to find code specific to a certain responsibility.

Just pay attention to it so you don't let it slip away, if you wish to collaborate on that code base. It doesn't stop collaboration, but it most likely will be a lot harder if you don't separate concerns.

You can ponder yourself: How many reasons does GameManager expose, for any change in that file to occur?

Consider to apply Single responsibility principle of SOLID.

[antfarmar]

Good post. You clearly know your stuff.

I am aware of the issues you state here. But bear in mind that I'm using this project to experiment with and learn different game/software design philosophies (along with Unity/C#). I'm not just trying to get a finished product.

And I'm not really trying to get it right on the first go. I wan't to make every design mistake there is so that I can fix them and understand the whole reason and process behind using/avoiding them. Just reading about them doesn't/hasn't really helped me much.I'll just forget or not know when to apply them effectively.

While I've made small hobby games from scratch before in several different languages, usually I just try to hammer them out to get a finished product just to learn the language & framework/engine, and I end up with the classic 1 god-object class. I guess now I'm more focused on proper design, and plan on rewriting the code several times to learn each one, starting from a base mediocre design

Perhaps I'm just taking the Agile development approach here. But I'm glad you know of and are noticing these design issues. :+1:

[ghost]

Good post. You clearly know your stuff.

Thank you, I try to learn. I have a huge interest in clean code but I consider myself a novice in the area. I've read books, tried to think rationally about things and more recently I started subscribing to Uncle Bobs cleancoders.com videos after reading a few of his books. I may get overzealous at times, but pushing it to the limit is also one way to stand back and think "Hm, maybe I pushed it a bit too far. What problem did I even solve?"

I wan't to make every design mistake there is so that I can fix them and understand the whole reason and process behind using/avoiding them.

I think you are hitting the nail right on its head. This is a sure-way method of learning why things don't work and builds into your intuition memory. I am like-minded to some degree. I like to dive in, see what burns, figure out solutions, and learn from mistakes. I hate black boxes. Sometimes you have to reinvent the wheel, to understand why the wheel is round.

Rewriting or refactoring the code is fine. I am not asking to do a BDUP. I just try to boyscout.

But your point is heard loud and clear - I'll make sure to remind myself that your main objective is to get acquainted with Unity, allowing for errors to happen, and force yourself to think hard about solutions. I'll relax on code policing.

---

I don't really know if I am just being an elephant in the room. It feels that way. At the very least, I can offer to answer questions regarding Unity if you have specific concerns. I don't know everything, but I know some. I've worked with Unity since 2009-ish and hit all kinds of bumps along the road trying to master it. I've since also got employed at Unity for some time, which gave me a quite interesting perspective. I've helped hobbyists and large (Triple-A?) studios to get their products out of various sinkholes, most of which were successful. I absolutely don't mean to gloat. I absolutely don't mean to say I have all answers. I just mean to say; I understand if you want to tug your war learning Unity. Your approach sounds very sane to me and I feel like the fifth wheel. I think it's better to let you decide on actions unhindered, and instead ask when/if you actually feel you want help.

I'll go into hibernation mode, until (and if) I get a clear "this would be something you could chip in with!" kind of response. But I will answer questions directed to me in the meanwhile, of course. And I'm also quite active at answers.unity3d.com under the alias Statement.

[antfarmar]

I'll relax on code policing. I don't really know if I am just being an elephant in the room. It feels that way.

Dude, you're not. So don't worry about this :laughing:.

Like I said in issue #23, I appreciate your feedback and collaboration. It's helping me learn different ways of approaching things :+1:. I hope it's helping you too.

Just understand that if I don't end up accepting a pull request it's not because that I don't want or appreciate your help, it's that I have to reason through the code and design decisions, and so far I have found it easier if I do it manually myself first, rather than have it done for me.

But I do read your code and solutions, and while they are well designed and robust, I feel they are too complex for the codebase right now, which is meant to be naive and simple, at least for now. Kind of like the Unity tutorials.

I've worked with Unity since 2009-ish and hit all kinds of bumps along the road trying to master it. I've since also got employed at Unity for some time.

Congratulations on the job at Unity! I remember first using Unity around 2009 too (2.6 was it?) and messing around with the Island demo :laughing:. I also wrote a quick Asteroids clone in UnityScript back then as well, but haven't really touched Unity since.

I mostly just hopped around reading about and experimenting with different game engines and software as a hobby. I always found the indie/game market so competitive, and haven't really taken it seriously. But now I see Unity jobs are popping up everywhere, even in my area. I'm guessing because it's a free powerful engine which lets you deploy to multiple platforms easily.

There's a lot to master, though. More than you'd initially expect. I do have a CS degree (I mostly focused on theoretical CS), but practical, applied CS (i.e. actually writing code) is a whole different beast. While it's easy to get something up and running in Unity, it would probably take a lifetime to fully master. It's fun though. :smiley: