A Thought For Newer Game Makers...

Hello there, I just had some short thoughts to throw out there and this is from my own experience. I’ve been making video games for over 15 years now, using Game Studio, Gfactory, Multimedia Fusion, RPG Maker (mostly), Dark Basic and Dark Basic Pro. For the last 3 years I’ve worked full time in pursuing making a JPRG styled game in Unity.

I don’t really see it mentioned all that often, but clocking in now more or less 5500 hours or so, I’ve found that probably 1500 of those hours have been spent in the debugging and polishing stage of the game.

It’s very akin to I would think chiseling a stature out of stone. It could always be more polished...but it’s not just that.

There are two phases of the game making process that I don’t see enough mention of I feel. In making an RPG, I had just enough experience with programming and game design to take a data first approach. You see a lot of game makers show these fully polished graphics that they get from the asset stores from these engines, and I think that’s great....but at the same time, it can be misleading. Most of what I ended up creating through these few years, I would talk with a friend or family member all excited telling them about the incredible amount of progress I would make for example with something like encrypting save files and learning how to organize this nested structure that is the games database...

I had to create an internal scene manager and have it go scan through the database and place entities positions rotations graphics and other states according to how it was stored....none of this work was visual, but the magnitude of work that goes into delving into these state machines, and then the debugging and polishing...I’ll be honest, it’s not visual work, but it seemed to be most of the entire game making process...

...and by that, I mean I’m still literally putting in as many hours as I can get in a week, and the process I go through at this point is to playtest through it, come up with yet another list, run through that list and ‘fix’ those things, then rinse and repeat, and it’s been half a year and there are still things that need to change...not things that it’s be nice if they were better, I mean literally a menu will blink or some button will be set to interactable so you miss that bug, or some ability will be set to non-elemental, these tiny little bugs that absolutely must no matter what be fixed.

Am I saying it’s stressful? Not at all, I think it’s how you approach it, I tend to try to come in with a cup of cocoa and a calm mind and try not to be too hard on myself...

...BUT, my point is, I see today so many more people getting into game design than before, and I think the game development process can be so misleading when it’s viewed superficially. I think it’s...I mean, to ME it’s really exciting when I get in there and squash this insanely bad bug, because that feeling of breaking through when you believed it was absolutely impossible is great...but at the same time I could see, and I think this is the reason I’m writing this...I could see the debugging and polish part of the entire process being extremely disheartening to those that get all the levels and the visual part done, get the guy running, get the basic states down of all the entities, and then get to that stage where they can’t get through another month or two or even six or more of work because in their mind they’re looking at it and just thinking to themselves “Well it LOOKS complete, so therefor it must almost be done”.

My advice for game makers actually using tools like Unity and Unreal would be to have a focus on data first, get a console working, get the saving and loading part first done, then create a database structure (just a class with nested data structures), then get scene saving and loading and switching, then fade in, out and transitions.... THEN work on bringing characters on screen, so that the visuals follow the data, and not the other way around.

 

Seems like you are talking about programming more specifically than game design.

The order in which plan your work to be carried out probably depends on many things. What type of game it is. What your marketing strategy is. What your core skills are. Size and composition of the team. etc.

Unfortunately, all the tiny private victories we revel in during daily work won't be interesting to most audiences. They will only care about the final product. And maybe. But probably not, because there is too many games already.

I think you mentioned the right mindset. It is about having a fun challenge. Get some coffee, sit down, take one problem at a time. Enjoy the work.

All the things you mentioned are like pulling teeth to me. That is not game design, that is the game engineering. It is work that must be done, but just because it is your core competency doesn't mean it is the nucleus of the project. You can squash all the bugs in the world, but if other aspects of the game aren't right then it's all in vain isn't it?

In the end, you are making some experience for people to consume. However it gets started and finished doesn't matter. As long as you have some plan and keep things on schedule, I think you are doing as well as possible.


Also, about using third party tools: my general idea is to do as little technical work as possible. Because that all consumes brain bandwidth. The more I am down in the weeds with that type of thing, the less I can be up in the clouds viewing the whole thing as an end-user experience.

If somebody else has already done the leg work and I can buy it for a reasonable price, why do things myself? Doing things myself is last resort. I only invest that time if it's absolutely necessary. For instance, if the solution I need does not exist, I do it myself. Or if I can something better, or faster, than purchasing, then I will do myself. Otherwise, basically every part of making a game is already out there for sale. So it seems like pride (or poverty) to do everything from scratch.

 

I agree with the OP. In the sense that I have putz around with uncompleted works so long that after awhile I get a sense of the benefits of having a really solid base or architecture Before I get into the fancy models and looks.
Having a plan, which changes of course as you go but made easier by building in such a way to easily allow for it. That means keeping things segregated/encapsulated as much as you can.

I can blast through production and get something looking cool, only to find out it's a nightmare when it comes to trying to save Data or network it with other clients because I didn't take that into consideration early on.

There are a bunch of videos on the Solid principles which , for me, I found hugely fascinating and eye opening.

Yes, it's more a 'programming' thing but I feel like it informs your expectations of what game design is in your scope.
Personally, I'd rather do it myself, but it's all about your own personal motivation. I do this because I like it, it's a kind of peaceful past time and the journey is important to me.

From a no bones business perspective sure,..buy assets. It saves time and would be silly not to, if you can, to get to your prototype as fast as possible to test your Game design.

 

Polishing a game is hard. As graphical fidelity gets higher we are setting the bar higher. But this is a misnomer, because everything else afterwards we expect to set the same standard.

If you want to even come close to finishing a game. Keep it simple. Block prototypes, simple textures, go for 2D rather than 3D. Use discrete systems rather than continuous systems. Take part in game jams. Those things really help you think about what you need rather than what you want. Keep cutting and when you've cut some, cut some more.

Will I ever complete a game? Launch it on steam? Doubtful, but it is fun to try.

 

Also I kinda disagree with the OP in that working on loading screen, menu and datastructure should be the core focus when starting.

The core focus should be mechanics of a simple level with a character that's fun to play. That's about it.

 

That's might be it from a game design perspective, but from a software design perspective it's not even close. From this you know what to build, but it really doesn't shine much light at all on how to build it.

Making a single level with a single playable character, an ability or two, a puzzle or two and some bad guys is easy. Making just that look nice is also easy. Scaling that up so that you can manage design, content creation, maintenance and quality assurance through a large scale game is quite something else.

Consider: you get three quarters of the way through making content for your game and then find you need to change the design of something that is used in all of your levels and which integrates with other parts of the game. If you've thought about how your game works as data from the start that's pretty managable. What data do different parts of my game need? Where should it be stored? What relationships does it have with my game systems, and how will I manage that? If you haven't thought about those things then it could involve re-authoring a significant amount of content by hand.

 

I'm not disagreeing with that. I'm disagreeing with the timeline IMO. OP suggested the game engineering should possibly occur first. Perhaps in the context of an RPG or a point and click adventure he may indeed have a valid point. But otherwise you need to establish if you have a concept that has legs. The only way to test this hypothesis is a rough around the edges prototype where you have NOT thought in depth about organisation, classes, loading screens etc.

After you have established you have, or believe you have something, then I think you should start looking into making everything as streamlined and optimal as possible.

IMO what I've read here is akin to putting the horse before the cart

 

@iamthwee

I'm not trying to say that there's only one way to go about learning or doing things, I'm just trying to give my own personal perspective on what I guess I wish I knew or would tell newer game developers.

In a previous thread titled something like 'Can indie games be made as good as AAA games' some people talked about and posted graphics, and I think that's missing the point.

I'm just trying to say that there can be this superficial misconception of the work itself, and trying to give a picture of what to expect. I think that if I could say one thing to myself when I was first starting, it's that you're A) not counting the playtesting/debugging/polishing stage into how long it'll actually take to finish a product, for me this took nearly 1/3 of the entire process of finishing the base game that was worked on full time for 3 years, so about almost an entire year was spend in that phase. In that entire year of debugging, the game looked completely finished from a visual standpoint, it had a playtime of about over an hour for 'episode 1'. I thought I would maybe spend 5-10% of the time I spent making the thing or so, like 4 months on playtesting and polishing and debugging, but I think that this is underestimated by a lot of us...I mean, I hear all the time people say "I'm almost done with the game, now." because it looks like it's almost done.

Also, B) when you start a project, working with a baseline structure and absolute organization on an almost literally divine level is fundamental to having something that you can expand upon and expand upon. If you work on a base structure of data, you can re-use it for more and more projects and not have to actually re-program or start from scratch at all, so in that way everything you create builds upon the last project.

I'm talking about something simple like this code, and I'm by no means saying this is the best way or that I'm an expert at game design or programming, so there could be better ways of doing this:

Code (CSharp):

1.  
2. [System.Serializable]
3. public class Database {
4.  
5.    public List<Goblin>    goblins = new List<Goblin>();
6.    public List<Human>   humans = new List<Human>();
7.  
8.    public abstract class Entity {
9.         public int ID;
10.         public enum Type { Humanoid, Monster }
11.         public EntityType entityType;
12.         public string Name;
13.         public enum State { Loading, Idle, Moving, PickingUp, Throwing, Unloading }
14.         public State state;
15.    }
16.  
17.    [System.Serializable]
18.    public class Goblin : Entity { }
19.    [System.Serializable]
20.    public class Human : Entity { }
21.  
22.    public Human CreateHuman(string Name) {
23.         return (Human)CreateEntity(Name, Entity.Type.Humanoid);
24.    }
25.  
26.    public Goblin CreateGoblin(string Name) {
27.        return (Goblin)CreateEntity(Name, Entity.Type.Monster);
28.    }
29.  
30.    public Entity CreateEntity(string Name, Entity.Type entityType) {
31.  
32.        newEntity = new Entity();
33.        newEntity.ID = ID;
34.        newEntity.Name = Name;
35.        newEntity.Type = entityType;
36.  
37.        return newEntity;
38.       }
39.    }
40.  
41. }

Then in a MonoBehaviour class called MyGamesScript.cs:

Code (CSharp):

1.  
2. public class MyGamesScript : MonoBehaviour {
3.     void Start() {
4.       Database mainDatabase = new Database();   //< - Saving and Loading this in Windows
5.    }
6.  
7.  

My first thought is that to a beginner, taking this class and then saving this to a file would be the first thing I would focus on.

What that means it that right off the bat you're working with files in Windows and data, learning how to handle and grab files and process them and save them.

Of course this isn't the only way to do things, but it's the first thing I would have a beginner in game development work on. Today, kids use that whole social media trending phrase 'game dev' and it's like there's a misconception on what the work actually is. In the 90s maybe it was underground, but people would just call it 'software developer'. I feel that the process was more understood, even if they weren't making maybe the most interesting Windows 95 games.

There seems to be a misconception that saving and loading files and working in I/O is complex, but this is working with the operating system you're using. I think that this part needs to be classified as fundamental and if I were a beginner at game development this is the first thing I would get down, instead of working with graphics or messing around with asset store assets, I would understand creating, opening, modifying, and saving files in Windows, or maybe something like working with parsing strings, or maybe creating a console that creates, modifies and destroys objects in real time (so long as it works with modifying the database object).