The Journey of a Game Engine, Is this the right step?

[Jacquelinett]

So, I had been learning c++ lately, and i'm actually working to get the engine started. But, I made this post to ask about what are the steps to make a game engine. I mean like, where to start and where to end.

So, for me right now, what i'm thinking:

1\. Set up basic GUI + graphic engine (login screen, entrance menu)
2\. Set up basic Server + Establish connection between client and server (the client will check if the server is online or not)
3\. Set up Account Registration (since we already set up the GUI, i think this is easier to do now).
4\. Set up in-game chat (to know that the account registration system work)
5\. Make map data on server, tile engine on client
6\. Make animation for sprite moving
7\. Make basic NPC
8\. Make player interact with NPC
9\. Make player fight NPC
10\. Make more advanced NPC
11\. Make features…

Are those the steps to make a game engine?

Please, when you reply, make positive + constructive post. Don't post something stupid like: 1\. Go to the kitchen, 2\. go to the kitchen,...

[erkro1]

I think thats a good order, altho I don't see player/NPC movement in it, but I'll put it in front of 6\. Make animation for sprite moving :P

[Jacquelinett]

@Erwin:

> I think thats a good order, altho I don't see player/NPC movement in it, but I'll put it in front of 6\. Make animation for sprite moving :P

isnt that what number 6 is?

but yeah, im on step 1 at the moment >:D lol

[Marsh]

Good luck.

You have but barely skimmed the surface of what you need to do.

[Yxxe]

@Marsh:

> Good luck.
>
> You have but barely skimmed the surface of what you need to do.

+1\.

[Drummerpete]

There are loads of C++/SDL tutorials on creating an engine but I don't have the bookmarks any more.

[Jacquelinett]

@Marshy:

> Good luck.
>
> You have but barely skimmed the surface of what you need to do.

What did i miss?

[The New World]

Hah, if you have to ask you don't even understand. Especially since you're using C++ you should make full use of OOP.

Your "Engine" doesn't just have to work, the way you've described above, it has to work correctly, and be easy for others to build off of or use. With that being said, you have to understand what you're doing and not just wing it off tutorials. You have to research, and experiment.

You're not going to get this thing done quickly, or at least not done right. And Marsh is correct, you're barely scratching the surface.

What're you missing? Well think about this much, you didn't mention any server sided logic, or any sort of resource or file system handling for saving and loading your objects. You did not list that you'll have to create a packet handling system, what sort of libraries you'll be using, or even how you're going to handle any basic structures such as in-game objects, maps, or entities.

Sure, they'll be able to move, but will their movement will be based on a coordinate system, which will in turn be based on the map format. It could be tile based mapping and free movement where you'd have to create your own more complicated coordinate system for things such as collision detection or map attributes, unless you'll be doing what? Adding some sort of collision rectangle to the entity?

As you can see, even just from what I've said already, there are a lot of things to consider and configure to work well with the rest of your systems.

Good luck.

[saadhamza]

Also, C > C++ ~

[iSKweek]

Honestly the first sentence is silly. Don't try and build an engine if you are just learning a language. Build a small game. Use that game base to continuously add more and more to, eventually getting to a 2d single player game. You don't have a huge chance of success with building an engine from scratch from the beginning, trust me, I've been there.

Either way, here is a site that can help you lay down something simple. It isn't the best of code but it will guide you through creating a 2D sidescroller base. http://www.sdltutorials.com/sdl-tutorial-basics

[saadhamza]

Yeah, i think that's been explained to her a few times Skweek. But, if she wants to go for it, it's her time that's being spent. And if she goes into it further, it may not be a complete waste of time.

i'll say this again, if you don't understand the programming language, anything that you try to make with it will be gibberish.

[Godlord]

@Yumi-chan:

> …

There are various types of projects that are hard, close to improbable, to pull off if you are a beginning, or even an advanced programmer. I'll name a few of those types: anything compiler-related (compilers, linkers, etc.), anything operating system related (kernels, drivers, etc.), libraries (especially if they target more than one platform, or if they offer more than one specific kind of service, or if they have to deal with platform-specific bugs), and the one you are attempting: _game engines_.

Writing a simple ORPG engine like Eclipse Origins in C/C++ (I don't get why anyone would attempt the latter, since the bloody language allows you to hit yourself with a baseball bat continuously) involves more than what you listed.

So the basic ORPG engine, where do you start? The first subject to handle is networking, which is already a complicated matter on its own. It's not as simple as establishing a connection and sending data. Well, it can be, if you do use TCP, and don't care about performance and bandwidth what-so-ever. But in reality, you do care about performance and bandwidth, and in reality you have two choices as far that is concerned.

Either you are going to implement a TCP client-server architecture, in which case you will have a simplified protocol that already ensures the reliable and ordered transfer of data, but which has to use multi-threaded to offer the most scalable performance, or you are going to implement your own UDP protocol that offers much more than TCP does: unreliable transfers, unreliable but sequenced transfers, reliable transfers, reliable but sequenced transfers, and reliable and ordered transfers. Additionally, you have to send data in such a manner that you'll save lots of bandwidth, so you can deal with more clients, and finally, you want to use multiple servers so you can share the workload between multiple physical servers.

And this is just the tip of the iceberg, since you've only written your network architecture. You aren't actually parsing and setting up packets to be sent, I haven't discussed simple issues like port forwarding (which can be automated, but which brings issues on its own, and the interfaces to do so are complicated) and network endian, and I certainly haven't discussed one of the most important matters of TCP: IOCP, epoll and kqueue (three technologies to offer scalability for TCP).

So what else do you have to do? Displaying actual content using OpenGL, Direct3D, or whatever other rendering library. OpenGL and Direct3D, although similar in matter, are as difficult as networking, maybe a bit more, maybe a bit less. For instance, what is the most efficient way to render 2D tiles? Load an entire tile set? No, not at all. That might consume memory that isn't going to be used after all. Load every tile required individually? Neither, that is going to take down the frame rate to unbearable numbers. Load every tile required and map them onto as much textures as required? Yes, that's a lot better. The tiles are guaranteed to be used, which means memory won't be wasted, and because of the minimal amount of textures you won't have to perform a lot of texture switches. That is just one single issue. I am not even talking about rendering text through TrueType fonts yet. I am not even talking about transferring pixel data to your GPU. I am simply talking about texture management, which is just one small subject.

I've only dealt with two major subjects here, and yet you would only be left with a client and a server, where the client can finally display something. I haven't discussed how files should be read or written. I haven't discussed how to actually structure your game. I have only discussed networking and graphics to some extent.

But you want to write an engine, right? Then I do encourage that you start simple, and that you start learning about every such subject, before even thinking of attempting to write an engine.

Yours faithfully
  Stephan.

[Robin]

Stephan seems to hit the nail on the head. I'll simply re-iterate what order I did things.

**1.** Learn how TCP/UDP packets work. Figure out how client events can be triggered by server packets. Set up a simple client-server chat system to get this framework down.

**2.** Get a basic graphics engine. I'd suggest anything which allows for NPOT bitmaps. No idea what kind of libraries C has to offer so talk to Stephan about that one. That guy knows everything about everything.

Find out how to render some basic tiles. Then your character. Then build your chat system on to the graphics engine and get on-screen text rendering working.

**3.** Input. Now you have a graphical environment you can talk in you should make it so you can handle input. Don't bother trying to have the input do anything yet. Simply get a few lights on the screen which turn on when certain keys are pressed.

Use an actual input library, _not_ the default Windows forms stuff. Personally I jack in to the Windows events directly and handle all mouse & keyboard events with that.

Maybe get some basic GUI elements going. Boxes you can drag around or something.

**4.** Loops. Now you have a packet driven server-client framework with event-driven processing. What you need now is logic loops. You'll want them both server and client side. The server-side loop will handle all processing for everything. The client-side loop should be limited to things like memory management, animation and input checks.

**5.** Entities. You'll probably want to start with something basic like the actual player. You'll probably be wanting to use structs (or classes if you're going OOP) so go read up on the best ways to store data. Whilst you're here you might want to look at creating a generic library for saving and loading struct data easily. Personally I just do direct memory dumps to binary for most of my things and more advanced INI (you'll probably be using XML) for things which are more dynamic.

**6.** Link it all together. You've got graphics, you've got input, you've got entities, you've got logic. Now you have the hard part. This is the part where pretty much everyone on this forum falls down. They think that because they've got a UDT and a DD7 front-end that they've got a game. So far you've had libraries do almost all of the work. You're just linking in to other people's systems and using their functions. Now you have to make the systems which are specific to your project so you can't exactly use other people's work.

Truth be told you'll probably end up here a few times. I made at least 4 or 5 different engines to handle my projects over the last few years. You learn from your mistakes, so going back and starting again allows you to go over the same old problems with a fresh look. Eventually I woke up and realised I could literally do anything I wanted. As soon as that happened I created a game engine, made Crystalshire and was set for life.

Use this time to just learn everything you can. You're at the age where you can literally do anything. It was when I was your age when I first started picking up on all the skills I have now. Don't rely on other people. Learn how to program, learn how to design, learn how to write, learn how to present, learn how to compose, learn how to create websites, learn how to bridge software, learn how to create videos… learn anything you can get your hands on.

If you have a thirst for learning then you'll never have any troubles in life. Everything I've learnt from doing this over the last decade has accumulated in to who I am today, and it's a nice feeling to know something you messed around with as a hobbyist has so many real-life worth.

[Baron]

@Robin:

> Use this time to just learn everything you can. Don't rely on other people. Learn how to program, learn how to design, learn how to write, learn how to present, learn how to compose, learn how to create websites, learn how to bridge software, learn how to create videos… learn anything you can get your hands on.
>
> If you have a thirst for learning then you'll never have any troubles in life.

^ this. This is important.

I personally went with the order of

getting / retrieving the data (network design and server side storage and retrieval)

displaying the data using "fake data" for testing purposes (client side graphics and HUD, display of items, npc's etc)

interfaces for creating the data (map editors, npc editors etc)

interacting with data at a higher level(inputs, logic loops etc, chat box interactivity, player trades etc, npc movement etc)

[SawQuart]

Don't jump on graphics too soon. Learn C++ _AND_ C in depth before you do anything. If you try to skip around too much and start trying to do graphics after only a few weeks of C++ then you'll be overwhelmed.

The thing I did was study C++ for about 4/5 months before I even began learning SDL (note that I had absolutely no previous programming experience). SDL was hard as shit for a newb like me, so I started studying again. After about a month or two of dicking around, I was finally able to develop a simple game using simple logic. Now that I've gotten into server/client networking, I'm at a point where I have to AGAIN go back and study some advanced mechanisms and pointer functions.

Don't rush into this.