next »

[Reactorcore]

@ four replies above:

While I do see the point of making a smaller project, I just don't see who would buy it or play it. Most smaller games can be played in large quantities for free on the web, some of which are far more involved to be even worth buying as a standalone product, yet they are available for free, making it difficult to sell small, simple games on the PC market.

Theres also the mobile platforms like iPhone and other such things, but I don't have such hardware, nor the money to buy it or am even interested in it for that matter.

I do have a PC, the tools to build a game and a solid, refined game design sitting on my lap, which might as well be the next big hit game on the PC.

My point is that why focus on anything else than achieving that?

I can start small with the big project by building it up in components over time and adding the features I've already planned and locked.


When it comes to game development, I'm not inexperienced in what it takes to make a small or a large project. I used to be a long time modder and then a content developer for the same game. I've seen and learned through trial and error and have created plenty of things the hard way, which is what you're telling me to do now with programming, but I've noticed one important thing in my life:

Sure, there are multiple ways of doing things, but if you know that there is a superior way of doing things, why would you do something that is worse? In my case, I used to go head in and mash stuff together blindly, make really stupid mistakes, do no planning or any design ahead of time what so ever and I ended up with results of poor quality that I had to go in and tweak a million times over after it was finished to get it right. It makes more sense to plan ahead and the results are far better when you do so.


So far, I've been reading, learning and internalizing various concepts and tools programming has to offer and after all that information, I already begin to see better ways to do things than I knew yesterday. Basically right now its a process of gathering information and finding out the better way of doing things and not making mistakes by charging in foolishly.

I'm not looking for a perfect way to do things, but a way that I won't regret it if I would pursue it. I may not end up with the most optimized code, but I would like to put all effort I can into making it as robust as possible, so that adding new content and features won't be a pain in the ass.

[nikki]

you could have a look at Game-Engine-Architecture

but in my experience there is not substitue for failing epicly.

have fun, don't be afraid, make a mess.

[EdgeOfProphecy]

hierarchy vs component entity systems

The component-based entity system is definitely the way to for the project due to how its designed.
How would one start building a component-based game architecture?

Btw, I'm intending to use C# with Unity3D to build the game, if that matters.

Well then you're in luck.  Unity3D already implements a component based-architecture, so you don't have to do anything special there.

[Richard Kain]

Well then you're in luck.  Unity3D already implements a component based-architecture, so you don't have to do anything special there.

This is a good point, and a fairly large answer to the questions you seem to be asking. A lot of your underlying coding design is dependent on the engine you are working with. You've already stated that you intend to use Unity, and to code for it using C#.

This is a solid decision, especially given the circumstances you claim to be working in. Unity is a good fit for your budget, and will allow you to target the kind of platforms you're hoping for. It is also one of the best engines for expanding on if your PC-centric title becomes successful. Unity-developed games can be ported to just about anything. (Android, iOS, 360, PS3, Wii, you name it) The next iteration of Unity is even going to be able to port games to Linux.

And EdgeOfProphecy is correct. Unity's underlying structure is based on component architecture. Developing with a component system in mind isn't merely optional, it's required by the very nature of the software.

Unfortunately, I can't provide you with too much structural advice past that. I'm actually in the process of learning Unity myself, and porting a game I developed in AS3/HaXe over to Unity's component system. While it's been a bit of a challenge for me, I have been rather enjoying the experience of using Unity.

[ThemsAllTook]

I do have a PC, the tools to build a game and a solid, refined game design sitting on my lap, which might as well be the next big hit game on the PC.

My point is that why focus on anything else than achieving that?

Gaining experience from small projects is focusing on achieving that. If you're learning to play the piano, you don't choose Flight of the Bumblebee as the first song to play; you keep it in mind as a long-term goal, and play simpler songs until you have the skill to move on to the next level and eventually get to where you want to be.

Sure, there are multiple ways of doing things, but if you know that there is a superior way of doing things, why would you do something that is worse?

Because trial and error is one of the most powerful methods of learning. How do you know there's a superior way of doing things? Do you have a deep understanding of why it's superior? Maybe it's not the same for everyone, but programming is based almost entirely on intuition for me. All the book learning in the world can't compare to direct experience. In many cases, applying a design pattern to your code without having arrived at a need for it through trial and error leads to superstitious coding, which is never a good thing.

[Reactorcore]

Gaining experience from small projects is focusing on achieving that. If you're learning to play the piano, you don't choose Flight of the Bumblebee as the first song to play; you keep it in mind as a long-term goal, and play simpler songs until you have the skill to move on to the next level and eventually get to where you want to be.

I do acknowledge that is one way of going about it, but as a person who's already gone through that way in another subject, I recognize it is a blind approach to learning anything. You can achieve far more better results if you study it first.

A good example of this is a Driving School. They give you a former training and a strict instructor to teach you properly on how to drive and behave before you hit the roads. Imagine if they'd just give you a car and say: "Go ahead, drive." without first teaching you the rules of traffic or even how to start the car. It would be a disaster of bad results. Same goes with almost any subject, including programming.

Because trial and error is one of the most powerful methods of learning. How do you know there's a superior way of doing things? Do you have a deep understanding of why it's superior? Maybe it's not the same for everyone, but programming is based almost entirely on intuition for me. All the book learning in the world can't compare to direct experience. In many cases, applying a design pattern to your code without having arrived at a need for it through trial and error leads to superstitious coding, which is never a good thing.

Trial and error is indeed powerful, but much more prone to producing bad results and low quality performance. In terms of putting out good results, trial and error learners are far slower compared to those who study before hand, due to them being stuck developing whatever through brute force, taking them away from the bigger picture.

There is a huge difference when someone studies and internalizes concepts before putting them to work as opposed to someone who just keeps bashing his head at the subject until it works.

Eventually, if they're smart enough, people who have been studying with trial and error methods long enough will realize how much wasteful moves they've made and the better results they could have achieved if they'd planned ahead. This is what happened to me.

On the other hand, to sit down and study before hand requires enormous amount of motivation to do so and most of the time people do have to go through the stage of trial and error learning to see the value of planning. So unless you can warn a new comer well enough to realize how wasteful trial and error is before he start learning that way, he won't be able to see the reason to study before hand.

As for how do I know something is superior to another method? Compare a simple drawing of a 3 year old to a artwork of a professional artist. The difference is that the artist has a massive visual library, concepts on how to draw properly (perspective, black/white values, depth) and tools to better plan out his work.

A more programming orientated example would be making a menu system.
You could just make a button that appears in the middle of the screen by putting in exact pixel coordinates or you could have it take into consideration the screen size and use that information to place it in the middle. The difference is that using pixel coordinates will only work in one screen resolution, while the other method makes sure it works equally the same on any screen.

[gears]

Reactorcore, you don't necessarily have to build the most general button/menu system on the first go, and in fact it would almost certainly not be a good design. I'd go ahead and write the code to display the button in pixel coordinates, see that it works without other failures, then consider writing it more generally if needed. You can keep in mind its ultimate direction, but don't force the design unless you have a strong understanding of what's required.

If you write code with the mentality that it's set in stone or you're afraid to touch it, I think you run the risk of introducing too much up-front design. Ideally, you're in a position where refactoring the code is a safe and ongoing practice, so it's no problem if you don't support everything now. Make sure the code is testable, either manually or through unit tests, and gradually iterate toward the right design. Each step of the way you become more informed about where the right direction is and can make better decisions.

[Poya]

Not to repeat what's already been talked about, but I found the example about an artist (a painter) interesting.

I am in no way underestimating the value of studying and leaning from others. You're right, because otherwise we would still be in caves, re-inventing the wheel. Having said that, there is no way, in my opinion (especially when it comes to arts, which I think programming is in many ways) to internalize that information without doing, and making mistakes.

It's like saying da Vinci studied and studied and learnt about drawing techniques, and one day he sat down and as his first work of art, produced the Mona Lisa. Even the most "talented" person in the world can't do that. You get there by practicing, by doing, and making mistakes, again and again. But yes, in order to even get to that point, you need to read up on the existing knowledge generated by others.

[Archibald]

How do you properly code a commercial game architecture?

It's the other way round, you code non commercial games the proper way, the commercial games code is to be thrown away after release, so there is much less point of writing it the proper way.

How do you make it not become unmaintainable spaghetti code?

I ignore this Ideally, I finish coding a game just before it becomes unamangeable.

But this is tricky, not recommended for a first game because you don't have the sense what level of code complexity/messiness is low and what is too much yet. But starting from the second game it works.

What specific things to keep in mind when building this, codewise?

The most important thing is that you are doing this so players can have fun and you can have money. Things like beauty of the code is completely, absolutelly and totally not important.