You’re updating an old method by adding only two simple lines of code at the end, but something is really wrong here. You checked all the method calls and parameters that you’re passing, but they are correct. So maybe their values are incorrect? You run a debugger and check. Nope, they are perfectly fine. The problem might be in the function itself, but it worked like a charm until now, so you’re rechecking your two lines and you still cannot see any issues. Continue reading “Short #2 Leave these parameters alone”
“Is it too late for me to start learning programming?”
I see a plenty of questions on Quora like “I am X years old, is it too late to start learning programming?” Many of these questions are asked by people around their 20s. Well, I believe I might know the answer, and it is not a cliche ‘It is never too late mate!’ I would say ‘It depends on how much you have left.’ Yes, I mean until you die. I assumed that the reason WHY you want to learn to program is to make your app or a game. I’ll try to estimate the time you will need, taking games into account because I kinda know the subject. I won’t even try to estimate apps or web services, as they aren’t areas of my expertise. However, if you want to try to do that for these fields, you’re more than welcome. In the article, I’ve prepared a table that estimates how much time do you need from total zero programming knowledge to finishing your game. I’ve included different kinds of games so that you can have a better picture of that. You may have a small “haha, right…” on your face right now, that’s okay because I’m basing on my experience and convictions. If you think numbers can be more accurate, feel free to add your two cents in the comments, and we’ll make it better. Now click ‘read more…’ and check out the numbers. Continue reading ““Is it too late for me to start learning programming?””
Don’t bring web development toys to Unity’s kindergarten
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”
Read it like a book – Painless way of programming Game Modes and Skills (Part III)
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.
Short #1 Don’t stick to ‘no negations in conditions’ rule
I mean, what’s the point? Let the code flow naturally after the ‘if’ and leave more unlikely situations for ‘else’ (displaying error for instance). In the ‘if’ block, you can put cases that are more natural for your game. A player wants to deal damage to living enemies. It is more common, as dead bodies are usually waiting for being cleaned up and are less attractive for the player. So: Continue reading “Short #1 Don’t stick to ‘no negations in conditions’ rule”
Read it like a book – What to do when Centralized Control does not work? (Part II)
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)”
Easy method to fix bugs in your game – Debugging (Part II)
In an ideal world, we write bug-free code. In the same universe, we don’t have to struggle with marketing our indie games, and we are skilled in design, programming, graphics and audio. Today I’ll try to make fixing bugs easier and faster for you, so you’ll have more time for more enjoyable tasks. Welcome to the second part of the series about making debugging an (almost) pleasant experience for you.
Fixing bugs is difficult enough. You don’t want to add ‘What the fuck is this shit’ on top of that. In the previous post – 7 good code practices that will help you in debugging – we tried to get rid of those unpleasant thoughts, so in this one, we’ll be dealing with a pure puzzle solving. That is because bug happens. So let’s get into it.
Continue reading “Easy method to fix bugs in your game – Debugging (Part II)”
When to stop preparing design and get to work?
In indie game development, roles in a team aren’t as purely diverse as they are in bigger studios. In a crew composed of several people most of them are probably doing more than one thing. When you’re working alone, this is unavoidable. I noticed that the role that is the most often distributed over the team members is designer. The general underestimation of that function may be the reason. The designer’s profile is often reduced to the ‘idea-guy.’ Most of us have many excellent ideas, so what’s the point in having a designer, right? Whether your crew has a designer or not, you probably have some kind of design document or game vision that you and your partners share. Or you may think that everyone has the same image of the project, while the truth may be quite different. On the second hand, you all may be very insightful designers, that have an accurate design document, but it may be just a waste of your time and effort. The 90% of it may be just rubbish. Yes, that’s a bit harsh, but I’m not telling you that IT SURELY IS trash. I’ll just try to explain how can you find out without so much work being wasted.
Continue reading “When to stop preparing design and get to work?”
Read it like a book – Centralized Control (Part I)
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)”
Debugging (Part I) – 7 good code practices that will help you in debugging
Hey guys! Welcome in the first post in a series about debugging process. This post will be treating about good practices which will help you in the debugging (and/or decrease amount of situations where you’ll need to do that). The second one will be about debugging process workflow, tools and how to use them in Visual Studio. I will focus on the most useful ones in my opinion. After these two posts, you should be equipped with a set of tools that, I think, are enough in most cases. This article collects code practices that are good in general, so even if you think you don’t need debugging (yet), you will make use of them. I decided to write this short series for two reasons. The good practices are good not because the big individuals said so. They are good for a reason. They make our development lives easier. I want to show you their usefulness during the debugging process because debugging is a reasoning about the code. It requires a lot of focus from us. This is a situation where code quality makes a huge difference. These practices make that reasoning easier. The second reason is that I see too many ‘easy’ questions on the Stack Overflow, Quora, and Facebook groups. By ‘easy’ I mean the problems that are fairly simple to solve during the debugging process. It seems like many of us just don’t debug at all. Maybe because they just don’t know how or it seems too hard or time-consuming. They prefer to delegate the problem to the Internet, what is usually more time consuming than debugging it by themselves. And the truth is, after fair amount of practice, you can find it almost easy and almost mechanical. No matter how good your code is, the bugs will happen sooner or later. You will have to get to the source of the problem. This is where the debugging begins and you better be prepared for that. Let’s get into it!
Continue reading “Debugging (Part I) – 7 good code practices that will help you in debugging”
Cohesive abstraction – solving most of your dilemmas in an easy way
Many of the code problems come from airiness during writing. We add features to the game not exactly in the best place with the thought that we’ll improve it later (yeah, sure…). And after a while, we don’t know which class does what. Maybe some classes do a bit of everything. We don’t know where to add another feature, so we pick a random class that already has the most of the needed references. Classes become just files with loosely connected methods and fields. Soon enough you’ll find yourself in a place, where you’ll have to change the current functionality. And that’s when everything fucks up. If this scenario sounds somehow familiar, read on. Continue reading “Cohesive abstraction – solving most of your dilemmas in an easy way”
Watch out, you’re being observed!
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:
Hello world of gamedev!
Hey mate! First of all, I want to thank you for coming by. I hope you’ll find next few minutes worthwhile and you’ll stay with me forever for a while to see what I’ve got. Don’t forget to look at the second post! I’m starting this blog for two reasons, but before I tell you about them I’ll give you some motivation background.
’ve worked on sooo many projects that had a codebase that literally sucked. Where any, even small change, took forever and that time felt so wasted. I’ve also heard some shit from many devs and read it on a bunch of blogs about dreaming big but starting small. This is like mantra for our beloved industry. If you’re indie game developer I’m more than sure, that you’ve read something like this as well. If not, well, you’ve just lost your gamedev virginity with me. High five! And yeah, that is a really good advice and I mean it. But the thing is, that you have to like mobile/very simple games or you must be able to force yourself to make them anyway. I have to convince myself to even play something on mobile to be up to date with the industry, but I don’t find it pleasant in most cases. How long can I possibly “do small”, if I DON’T like that small game I’m working on? How to find motivation to keep going? At some point, you’ll probably find yourself in a place where you just won’t be able to go for another small project. Or maybe you’re just there right now?
I want to share my knowledge with you that will hopefully help you make your game come true. I’ll tell you what I know about writing a code that will stand a test of time better and won’t make it harder for you than it already is. Bigger projects take much more that one-two months and working with crappy code becomes a nightmare very quickly and stops you from adding another feature. You’re starting to think ‘Oh, if I had started this once again, I would write it a lot better. Sigh.’ I’ll try to help you to avoid that in the future. Too much work is wasted because of that. Making games is a really difficult thing. Making these big ones is a hard-as-fuck thing and to make it real, one needs calmness, perseverance and humility. And of course ‘a bit’ of know-how. By ‘bigger games’ I mean bigger than you made before, so this is purely subjective.
If you dream about your Game and I mean The Game, I am writing for you.
If you want to be better as a programmer, I’m writing for you as well.
I’m also writing for myself, because I want to meet people that share the same dream. I wish to become a better game developer as I’m writing this blog and I just want to see more games out there that I actually want to play.
So the first reason is You, second is Me, as simple as that.
Below I’ll list the most important information about this blog. They will give you some perspective on the content, before I write more.
- Most of the posts will focus on programming stuff and code architecture. Basically they will try to explain how to write certain things in the way that will help you add more things in the future with pleasure. How to avoid spaghetti and write more lasagna style, if you know what I mean.
- Most of the code examples will be prepared in Unity. Does it mean that if you don’t use Unity this blog isn’t for you? Well, no. I think you’ll get the idea anyway. It will be like reading C# code, while already knowing C++ or any other object oriented language. And in many cases you won’t even notice Unity here, so give it a try. However…
- From time to time I’ll write something Unity-specific or at least somehow related to the engine. But still it will be more about code/work organization than actual tips and tricks or Unity tutorials.
- More personal aspects of the game development will also be discussed here. These topics, as I strongly believe, will help you become more approachable person and will be helpful in your work. Example? Humility and calmness will help you in interpersonal contacts as well as learning faster and debugging (to be continued…)
- I will write about design as well. This is far more difficult craft than it looks like, but liberating and satisfying as fuck. These will be in minority, but I want you to be prepared.
- Oh yea, and in case you didn’t notice yet, I’ll try to keep things simple, because I’m not a native English speaker and I really like the KISS ‘way of life’. I cannot afford fancy style, but I can afford being honest with you. Deal?
- I’m NOT finding myself as ‘knows it all’ expert, I’m just a guy who loves games, is kinda’ geeky about code quality and believes. And I want you to believe too. Take it slowly, we’ll make it. More about me in… About me.
And I think that’s all for now. We’ll be tweaking things later on. See you!