Hey all,

I'm new here at gamedev.net. I'm having some trouble finding some resources on where to start it all. Game development is a huge undertaking, so huge that I find myself looking at all the tasks ahead of me and asking myself "Where should I begin?"

Background

A little background goes a long way, so here's mine. I've always loved video games and wanted to develop them myself, either as a career or as a hobby. I worked on some side projects here and there to try and improve my knowledge. I did some work on a remake of Minecraft that was being worked on a few years ago called Spout, though that project came to a halt. I have 2 bachelors degrees: Computer Science and Pure Mathematics. Part of my CS coursework included a graphics course focused around OpenGL in C++, and for my senior project I did a small Android game that was a remake of the classic SNES game Advance Wars. Like so many with dreams of developing games, I ended up stuck in a commercial software developer position feeling like I'm not living out my life's dream. So that's why I'm here.

Technically speaking, I have a good foundation under me, but I know I have a long way to go. I've already taken a look at a lot of the articles here on gamedev.net, and I really look forward to reading more. I'm not really looking for information on how to break into the gaming industry, because I'm not even sure that's something I want to do yet. I have an idea for a game that I've wanted to make for a long time, but, again, I'm having trouble finding out where to start.

Description

This is a big project. One I've wanted to do for a very long time. I'd like to do this project in C++. My professional training has very minimal C++ involved, but I'm at a point in my career where languages are simply abstractions, and picking up new ones is relatively easy. I don't want to get into the actual game specifics right now, but I know that I want to develop it "from scratch". I want to create my own game engine and build this game on top of it. I know that this game will need to have networking capability, but I'm unsure yet if I want it to be peer-to-peer or dedicated servers. I know that I will need to develop both a client application and a server application. I also know that I will need to do most of the artwork/modeling/animations myself.

Here's where I know I stand in terms of technical tasks to be done:

• Documentation
• Client engine
• Server engine
• Modeling/Animations

I'm sure I've probably left out some tasks from that list right now, but I think I've covered the big ones. Now that you've read a novel, I think you're ready for my question: what tasks should be completed first? Should I document everything first in the form of what I want the game to be like and then develop around that? Or, if my idea is not 100% fleshed out (and it isn't), should I start to focus on the technical tasks first? If so, which? Barring none of those things, if I needed to visualize my idea more should I start with the artwork and modeling?

I realize these questions are kind of arbitrary, but I'm new to this. Most of the other "where to begin" threads I've seen on these forums are from people with little to no technical experience at all. I have the technical experience to begin working, but I don't know where to start. Generally, where should one ultimately start when developing a game (taking into account the information provided) and where should one progress from there? Any advice given would be immensely helpful, and hopefully I can be a positive figure on these forums in the future.

Thanks!

Hi, and welcome :)

In general, there is no single way to Rome (or any other city, for that matter). Different people have different preferences on how to tackle things. Finding out what works for you is perhaps part of the experience.

As for actual starting, I think it's important to have a global idea of the various big blocks of functionality, and how they relate. The topic for that is "programming in the large" iirc. What parts do you have, where do they live, what part is responsible for what, those kinds of questions. These blocks should be relatively stable. Keep things very abstract, interfaces and code comes later.

Documentation is important in the long run, but documenting beforehand has the risk that you document things that break because at the 200th line of code you realize the idea you had will not work at all, as you missed some crucial part. I make plans in my head, and document functions when I write them. The disadvantage I find is that big blocks are not very well explained, it's something I need to improve on, probably.

A strategy to make any software too large to see all details, is to plan only small parts and make that. Then plan the next small part, etc. A quite incremental way of building. As long you you stay in the idea of the big global blocks, eventually, it should all work out.

Another thing is how generic do you implement a plan. You can do the minimal amount of work to get your current plan implemented, or you can make it generic, templated with all possible types and values, extendable, modular, etc etc. All other forms fall somewhere between these extremes.

Both forms are valid I think. I do mostly the close-to-minimal version. Its advantage is that I don't have code that I don't use. Not having code means it's not in the way, I don't have to refactor it, or consider it in my plans.
The disadvantage is, that I never have anything already made. I always have to extend everything, which can be tire-ing at times. It feels like an up-hill battle sometimes :(
The other side is somewhat reversed, if you need something around your plan, it may already exist, and it may also even work on first try! Code modification is more complicated as you have to consider the more general case. A third danger is that your nice abstraction layers and extensibility interfaces may get in the way of speed. Having a getter at every interface is nice, but to get the value, you do have to dig through all those levels. If you need to do that often enough per second, it's going to be costly. (And yep, I have very few getters and setters in my code :p )

No matter how you work however, you will find by the 5 to 10th plan, that you made critical errors 4 months ago (or longer, I recently fixed one that was 3 years old or so). I think you'll find plans failing at times whatever method you use. Being able to refactor code is an important skill here. When you find an error in your plan, you decide how to fix the existing code, and you refactor and extend your changes into the code, adapting to the new situation. Then adapt the plan, and continue.

I am working on a C++ project for 4 years now, and consider all code "good enough for now", nothing is really final. It allows me to jump between code and change and adapt things, but have something that does something (it's not a game yet in my view). The other extreme, build one thing completely, and then move on to the next thing, doesn't appeal to me very much, it would mean I would not have anything running today.

However, maybe you work differently. The only way to find out, is to try. If it doesn't feel good, try a different approach. You must have fun making it, or you will have a very miserable life for the next years.

I am not quite sure why you want to make an engine. Typically, an engine is constructed to be used several times in different products, or as a product that can be sold to other developers. Making an engine, and using it for one game seems a bit overkill to me. In other words, what is the purpose of having an engine?

A second consideration is that to make an engine, you need to know what all applications of your engine will need (the point of an engine is that it makes building the applications easier, so it should provide services that are useful for the applications). Your post suggests you don't yet know what one such application needs exactly. How are you going to decide what the engine should contain, or where the border between engine and game is?

Maybe you should first aim at the game only. Having one goal makes a project a whole lot simpler. Once you have that game, you can reconsider about engines. My guess is however that you need to make at least 3 games before you see patterns emerge that make sense in splitting between engine and game application. With more games, you can also better see the common parts, and the special case parts (which belong in the game and not in the engine). With one game, it's much harder to see such parts, as everything exists one time for one game.

Thanks for responding so quickly! I'll try to address some of the things you said.

As for actual starting, I think it's important to have a global idea of the various big blocks of functionality, and how they relate. The topic for that is "programming in the large" iirc. What parts do you have, where do they live, what part is responsible for what, those kinds of questions. These blocks should be relatively stable. Keep things very abstract, interfaces and code comes later.

This is exactly right. I'm very familiar with programming in the large and would like to implement the same kind of design here. I know the specific modules that need to be created, and I believe I know how I can appropriately abstract those modules from each other. This is the approach I have when facing the game engine, for example. We want low cohesion, so each of the modules are more or less independent from each other.

Having a getter at every interface is nice, but to get the value, you do have to dig through all those levels. If you need to do that often enough per second, it's going to be costly. (And yep, I have very few getters and setters in my code )

It's funny you mention this. They teach in schools that having this kind of abstraction is a good thing in theory, but then in every software industry you find that it can lead to all kinds of mutability issues as well.

I am not quite sure why you want to make an engine. Typically, an engine is constructed to be used several times in different products, or as a product that can be sold to other developers. Making an engine, and using it for one game seems a bit overkill to me. In other words, what is the purpose of having an engine?

The technical aspect of creating a game engine from scratch is not a fantasy to me. I've done enough of it before to know most of the intricacies involved, though not all. As far as an ideological reason goes, I like being able to really know what's going on. While it is definitely harder and much more time consuming (though time isn't an issue to me), being able to know every part of what is going on is extremely desirable for me. I don't feel like I really get this with a pre-made game engine, especially if that engine can't meet all of my needs.

Being able to make my own game engine also means that if at any time I need to make drastic changes to the game, or scrap it completely and start over, I have the general template and know-how to do that quickly.

A second consideration is that to make an engine, you need to know what all applications of your engine will need (the point of an engine is that it makes building the applications easier, so it should provide services that are useful for the applications). Your post suggests you don't yet know what one such application needs exactly. How are you going to decide what the engine should contain, or where the border between engine and game is?

I'm not quite sure how my post gave you this impression, but I'm fairly caught up on what all is needed, though maybe not every part. I know that it will need the following components: rendering, sound, network, scripting, spacial analysis, process synchronization, and AI. There are possibly other components missing, and I look forward to learning about these other components and implementing them as well, but the main bulk of the components I understand, at least relatively well. Again, I'm no expert, but I think I have enough to get me going without having to ask many fundamental questions.

I'm really thankful for your comments on documentation. I've started some, but I have a hard time motivating myself to document something I know will end up changing in the future. I think the best place for me to start would be the client engine. I'll begin by implementing a basic rendering component and extend from there. As the engine becomes more and more fleshed out it may become easier to see what step to do next.

Again, thanks a lot for your comment!

t's funny you mention this. They teach in schools that having this kind of abstraction is a good thing in theory, but then in every software industry you find that it can lead to all kinds of mutability issues as well.

Teachers approach programming from programming theory, which says you must encapsulate, be modular, extensible, etc etc.

While the general idea is fine, they take it to the extreme form, perhaps also because the programs you write at school are really too small to explain the more subtle points.

Also, not all students will see the subtleties, and just get totally confused when to do what.

I started with C/C++, and worked with public, private, and protected, and so on. Had a course on Java, and met getters and setters as standard practice.

Then I met Python, and programmed it for a number of years. At first total shock and horror, no private, no protected, everything is public! How the heck do you know what you're supposed to access???

(They do have a convention to indicate private things, but it was more a "if you really insist, you can use it" kind of thing, than a recommended practice.)

In time I have learned to appreciate their philosophy. The idea is that classes respect their neighbours. They work together to obtain some greater goal. Of course you're not going to mess in the internals of your neighbour; you need him to do your own work! If you need a value, help yourself. If you need to change anything, sure, but for that and that variable, please let me know, so I can adapt my internal state.

In Java, the common approach seems to be big walls with barbwire and guard dogs around each object. There are small holes to get some value. Not the real value, but a copy. Access ports for giving a value, but you have to go through a full body search, as you're a total stranger, bringing untrusted data into the object!

The above is extreme, but there is a big difference in philosophy here. The Java approach has its merits too, but in borders between packages, or as interace for a library.

.... I don't feel like I really get this with a pre-made game engine, especially if that engine can't meet all of my needs.

Ah, right. It's just a terminology problem then. With 'engine' I think of a game-engine as a separate product, so I read your message as the desire to make two programs, namely the engine, and a game (using that engine).

It seems you only want to do the latter, build a game. That clears all my considerations then

I have a hard time motivating myself to document

I never documented anything until some years ago. The problem with documenting functions and class variables (as that's what I mostly do) is that at the moment you write the code, everything is fully clear, and documenting just feels like a waste of time (and at that moment, it is a waste of time, since you have everything in your head). On the other hand, it's also the only point in time where you fully understand all details of the code, and are capable of writing a few lines about how to access it in a very short time.

The difference however comes when you need that functionality again while doing something else. At that time, your head is filled with the other thing. Without documentation, you have to switch to the internal structure of the functionality that you need to access. What are the input parameters of this method again? hmm, a, b, and q.

Right, I see. Hmm, what does it return in this and this edge case? Oh, it calls that function. That computes the common element from a, and b. Ah yes, I remember. Here it does that calulation, and ah, it compares against 0. Right, that should work.

You need to reverse engineer your old code to understand how to call it. Since I started documenting the call interfaces, in terms of external values, I found my productivity went up. I can read in 4 sentences how to call the function. It tells me the expected meaning of the parameters, and how to interpret the result value, including the edge case. I don't have to switch context to the old code, and back to the code I am currently figuring out. I don't miss special considerations, since there would be a @note This function is slow for big values. note in the 4 lines.

Obviously, this benefit grows as your program gets larger. There is no way you're going to remember all details in 100K lines of code.

If you find a second person to work in your project, it makes a huge difference between "here are 80K lines of code, have fun" or "here is documentation of the functions".

I hope I have given you some more motivation now

One thing to keep in mind: depending on the scale of your game (2D? 3D? Simple game mechanics or physics driven? open world? Networking?), writing the game from scratch might be easier than using an existing engine, or at least be about the same time hog than facing the steep learning curve when getting to grips with a new game engine. Or you might have to write A LOT of low level plumbing that is needed to make your more ambitious project possible, before you can even start to actually code the game.

Writing a modern 3D engines takes years even for a team of experts. Its not an easy task, and certainly nothing that even a good engineer can just do in his free time if he wants to get finished at some point.

What I am trying to say:

Ask yourself these questions in advance: What is the scale of my game? What is more important to me, writing a game or an engine?

given small scale, you can do both at the same time and have time to spare. You can start small and grow from there.

IF your engine will be able to grow with your growing game project scale endlessly IDK, at some point implementing new engine features needed for larger game scales might be huge projects by themselves before you can even improve your game code to use the new game engine features yet.

If you want to start big (which is never advisable for a newcomer), you will at some point need to make the decision wheter to develop an engine or a game. A lone developer can write a modern 3D engine, but then also having the spare time to actually develop a game on top of that engine is doubling your development time.

And also keep in Mind that developing your own engine from scratch for bigger games has mostly an academic background. Apart from VERY specific needs of exotic game concepts that the current crop of high-end 3D game engines can not fullfill, and need to be coded into the very core of the engine, there is not real reason to re-invent the wheel (which is why no big studio I know of does that today, all of them license existing engines). And even then, with more and more source code of high-end engines being exposed to developers (Unreal Engine 4 for example gives you (at least part of) the source for free), taking an existing engine and adapting it to your specific needs is now also within the reaches of hobby and Indie devs.

There is also the middle way many small scale and midsized projects choose, which is to use existing frameworks like SMFL, MonoGame or PyGame that will do some low level plumbing for you, but leave part of the engine to implement for you.

I totally understand the interest in engine development, and really, if you want to become a professional game programmer, having your own engine on your portfolio can only help sell yourself to sutios later on.

For a hobbyst interest in creating an actual game, you need to be aware of the amount of time this kind of low level development will consume and if you wnat to invest the time there, when many existing, FREE Engines and Frameworks can do the work for you there already, maybe better than you would be able to do it yourself. There is nothing wrong with coding engines for personal interest and enjoyment though.... after all, there is a TON of interesting stuff going on under the hood of todays games!

Plan ahead, develop a vision of what you want to build and achieve, and then concentrate on that, instead of trying to build it all.