ID:1725502
 
I've reflected on my prior endeavors of designing things and how many of my projects have collapsed due to loss of interest or complications on the game's framework. I thought to myself that while those projects didn't become "complete," they did however teach me more about design, and give me experience that would help my future attempts.

Completing something is difficult if you're a perfectionist. I am one of those people who can be very OCD about the way the code looks visually. I've worked with multiple design paths to see what would work best for me. Each design pattern has its benefits, but also has its shortcomings.

Then I thought that I am still learning about things even if my attempts to complete something don't work out the way I wanted. A destination is yearned for, but the journey to get there is much more valuable. everyone starts form the bottom and works their way up, and everyone's paths are different.

Zecronious said that I had inspired him with a previous project of mine that I was tackling at the time. I felt pretty glad to know that someone liked my work in an inspiring way. I'm known for having unconventional design patterns, and I love to experiment and tinker with things in unconventional ways. I like being creative, and it shows in my work.

If you've followed my devlog on MicrORPG, you might notice that I am very stubborn and decide not to use BYOND the way it should normally be used. Yes, it makes sense to use datums, and objects, and inheritance. They exist for a reason. But you know, it just ain't my style.

Programming and design has a deeper meaning than the end product. Though a piece of art should be beautiful and presentable, the design process should also be elegant. I have to stare at code for hours on end, and I feel like to make it work for me, I need to shape it to fit my standards.

Completing a project is hard because the end product can be very different from the initial blueprint. Not only that, but new features, innovative or overlooked, would inevitably be added, altering the finished product. when is a project "complete?" Is it never? It's hard to judge when something is deemed to be complete when you know that there's always something you can improve on it.

I suppose instead of thinking about how things should look in the end, I usually think about what is currently in front of me in the present. This is the tangible part that I am able to edit and change. If something needs to be changed, I will want to do that.

Deadlines. I've learned that they can be helpful for setting milestones for projects. Although the freedom to design whenever it is convenient for you may be nice, it can also be the bane of the project itself and never get done. A little bit of work every day, however, can get you far in the long run.

I think back to when I started programming. I've learned a lot since then. I think about how I started with Play Basic and how that sort of programming style followed me to where I am today. To a professional programmer, whose main goal is to write efficient and legible code, their programming will probably seem identical to anyone else's. For me, I have a distinct creative style. It might not get me anywhere in a business world, but I'd have to say that I wouldn't part it for anything. It is mine, like a style of art.

Putting MicrORPG on a public repository was a good idea to me, because most of the time I'm staring at the code that I work so many hours on, and really I feel like I'd like to show everyone else this art. Sure, the project isn't finished, but at least now you can see how my mind works in the way I program. Is it the most optimal, efficient code in the world? Very unlikely. Associative lists will never have the speed of normal variables. But their flexibility is something I admire.

So, anyway, I'll be regularly updating code and loading it into MicrORPG's repo, which is at http://www.github.com/zynkco/microrpg . Sorry in advance to the purely logical programmers out there who would most likely scream for being inefficient. If (and hopefully when) I complete the project, it will be a moment to remember.

When it comes to coding a game, most people will tell you this is the best way to do things, and that this is correct while that is not. They'll tell you lots of things you should and shouldn't do. And they're probably right.

The thing is though, this is BYOND, and these are games made by amateurs. People here are not pros working on huge projects. They don't need to worry so much about how their code looks, whether their technique is the best or not and so on. As long as it works who cares how you make it?

There are exceptions to this, like if you're making a demo/library, you'll want to do things right then because other people are relying on it. And if you work in a team you'll need to make sure people can understand your code. But for the most part, you don't need to bend over backwards doing what other people tell you is the right thing.

As for actually finishing a game. Got to get a goal, got to get a plan, got to get off your ass.

You have a goal, you want to make a game.

Now you need a plan. Before you even start making the game, you need to know what you want to do and how you're going to do it. No point in saying "I'll make a game" and then starting. Got know what kind of game it is, how it will play, what systems you need and so on. At the amateur level you don't need precise details and a 700 page design document, but you need to at least have a list of the parts of the game you will make and what these parts do.

You might think you're done with the plan. But you're no where near done. Now you need to plan out your workflow. You need to figure out what needs doing, how you'll do it and when you're going to do it by. Once you've done that, you need to figure out what the next step is. And then you repeat this until the game is done.
Need an example? If you're making a RPG, you can't make systems like combat until you have stats. You got to add stats and calculations before you can make combat. So stats are your first step, and it shouldn't take too long to add them. Then once you add stats, you work out the next step, and it's definitely not combat. You keep taking steps towards combat until you can do it.

Now you've got a goal, and you've got a plan. You need motivation. Motivation is different for everyone. You will not find anyone who can help you to get motivated.

But here is how I see it. The reason I'm not motivated is because of myself. Because I don't want to do it.
Now I know I don't want to do it, I realize motivation isn't even real. I simply do the things I want to do, and don't do the things I don't want to do. If I don't want to make the game, I don't. If I do, then what's the problem?