That’s right, I said it. It looks like some web developers want to bring their habits to Unity with them. I understand that you expect it will be easier this way. But I think it may be easier for you (at the beginning), but not for other game developers. Especially not for Unity developers. I came across a couple blog posts, and I saw in the comments that people that thank for the “MVC for Unity tutorial” are the ones that are already familiar with MVC and want to do something in Unity. I find it a quite dangerous approach. It looks like they don’t know what MVC is for, WHY do we even use it. Main benefits of using it shatter in Unity when understood wrong. When I want to learn Unity, I should look for “Unity tutorial” in Google. Or “Xamarin tutorial,” or “Ruby on Rails tutorial.” Looking for something like “How to make a web page in Unity” doesn’t seem the most effective path, though it may be an interesting adventure. It’s a good idea to explain some new concepts basing on the ones you are already familiar with (i.e. Unreal Engine for Unity developers). But then you should familiarize with the new framework and its “culture.” And don’t get me wrong, it’s totally okay to try new, even weird, things. It may only develop you as a programmer. Go, have fun, make a game in assembly or banking app in Unity. But if you really want to learn something new, then learn something new. Don’t stick to your habits just because you feel safe. Let’s get to some technical details. Continue reading “Don’t bring web development toys to Unity’s kindergarten”
Strategy is a meritorious pattern, and I think it may interest you. Why? Because you want your code to be flexible. That flexibility allows you, for example, to switch behavior with ease, whenever you like. You don’t want to replace half of the classes when the rules of your game change. Or maybe you want to have different game modes, and you’re struggling with
switch statements all around the place? Strategy pattern allows you to code another game mode without the fear of breaking the rest of the game.
Continue reading “Read it like a book – Painless way of programming Game Modes and Skills (Part III)”
In the previous post of ‘Read it like a book’ series we talked about Centralized Control. In this basic object-oriented concept, high-level classes call methods on lower-level ones. Lower-level classes call events that the high-level classes listened and reacted to. But it is not always the best or even a possible solution. Observers are great, but there are cases where using them leads to classes that cause some nasty problems. In the next two posts of the series we’ll introduce design patterns that’ll help you to handle foreign services (databases, analytics), multi-platform development (analogical, but separate services for Android and iOS, like In-App Purchases or Leaderboards) and such everyday things like Audio or Input Managers.
Continue reading “Read it like a book – What to do when Centralized Control does not work? (Part II)”
Oh, it’s you, hi! I want to invite you to read the first post in a new series about Centralized Control. This one is an overview of the subject. You’ll get familiar with the centralized architecture, how it looks like, and what are the biggest benefits of sticking to it. You’re probably using it already, but the chances are it has got a few holes. When it has the holes, the benefits leak through them like a blood. Are you sure that you’re okay with that?
Continue reading “Read it like a book – Centralized Control (Part I)”
Hi! Welcome in the essentially first post on Games Architecture. I’m really glad you’re here and just in a minute I’ll let you dive into the substance, but first you need to know something about me. I’ve mentioned it in the very first post, but I think it is quite important to point it out once again. I try to simplify things wherever I can and the code is first-class example. Programming is more about reading the code than writing it. You really want to make the first one as easy as you can, for future-you and the fellas that will be helping you.
There are a couple of places where you can find some information about this design pattern (and I’ll point you there at the right time) but we will focus on examples and some tangible aspects of it. Ok, so here’s the problem:
Let’s assume we have a monster and a player. Pretty common setting in games, isn’t it? The monster attacks the player, so programming it can be as simple as calling
player.TakeDamage(). But (you expected the ‘but’ didn’t you?) the games are rather multimedia experiences, so you’ll probably want to have some audio (ouch!) and maybe a screen effect, on instance red Call of Duty style indicator. Oh, oh, and somewhere on the screen the HP bar is placed. Let’s write this:
Continue reading “Watch out, you’re being observed!”