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?””
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.
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!
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!