Game Architecture -- what is your approach?

My idea of "smaller projects" and yours are probably not the same. I was thinking along the lines of a Frogger clone. And I wasn't commenting on whether anyone was competent or knowledgeable enough to implement something like an events infrastructure. Just that I seriously doubt your typical solo dev Frogger clone typically implements something along those lines, and that it is probably for the best. YMMV

 

I think it's both good points, just got to consider the situation individually. It can be hard though. I was talking with a very experienced guy about this the other day in reference to my current game project, and even for him it's just a matter at look at the big picture and then go with gut.

Me, personally, I think if it's contestable it is gonna be wiser to err on the side of doing things more modular, scalable, etc. If spending extra energy on precaution is gonna kill the budget, I think the endeavor was poor risk/reward gamble in the first place. JMO.

 

Me too.

Since your example was events, what do you see as being downsides to using events in this scope of project?

 

It can mean a lot of things. Procrastination can mean you don't know where to start, you don't think its a good idea to begin with, you've had a bad experience with it in the past etc.

I never had trouble learning programming once I got into it, but I always believed I didn't like it and it wasn't for me, despite not knowing anything much about it. I remember a pretty poor experience with my dad trying to teach me machine language when I was a kid, it looked like the most impenetrably boring thing I had ever seen. Right up until university, I would always say that programming was something that I would never be interested or able to do.

That is, until I had a very good experience with Matlab at university, which got me hooked on it. Seeing stuff happen in realtime based on what I typed in was just too exciting.

That's why I never tell people to start by rote learning or (the worst possible idea) at the beginning of a textbook. You need to be motivated by the effect, not the cause, at least that's how it is with me.

...

In terms of game architecture, I find the best approach at the start is to get something functional at all costs (not worrying too much about messy code). For me, this enables me to take the mental model out of my head as fast as possible to free up my mental energy. I can think about things much better when I am looking at them, and I also find ideas get overwritten quickly and it's better to act on them quickly than to wait or string out their implementation.

After I have some code, I start to break it down logically. For example, what are the discrete (separate) objects in the code I have written? For example, if I have coded a player walking and shooting something, I will separate the player from the weapon, the weapon from the health/damage, etc. All the different objects or concepts are things I think of as 'boxes with buttons and sockets'. Information goes in, information goes out, you can call functions and make stuff happen. They are nodes in a network, and they don't need to know where the wires are coming from or where they go, they just respond to input information, make output information available for whoever wants it, and do stuff when you call their functions.

One thing I really like a lot are Unity events, which I started implementing a short while ago in my space kit. Besides being extremely useful for people to hook up functionality in the editor, they make me question as a programmer 'what do other boxes (objects) want from this box, what is the effective and useful result of its internal functionality?'.

For example, in my kit players and AI are represented by a GameAgent component. If you saw this name you might wonder, what does it mean? It could mean all sorts of things. Is it a machine learning 'agent' that will write my game for me? ... but when you see different events, onDied, onRevived, onEnteredVehicle, onExitedVehicle etc, you quickly understand its practical function and what it represents. For me, even as the programmer, this ability to represent the most practical aspects of a complex script in a distilled manner through the inspector helps me to understand how well and succinctly I have created it. More than once I have re-written a script because I realized something was wrong/missing based on the inspector looking ugly or somehow not right.

In the end, you will probably find that you need 'GameManager' script and all that sort of thing, but I would avoid going there until it's the right time and place, usually once you have a lot of stuff going on that needs to be coordinated into a crafted player experience. In the meantime, it's best to just make boxes and connect them with wires.