[MattFang]

Hey there! I want to create my own Game Engine! I want to create it from scratch! I don't want to use any other game engine available for download! Can someone send me a little, basic list on how to create my own Game Engine, what resources I may need, etc.

[Fib]

Hi MattFang! Welcome to DreamInCode.

I would love to help you out in creating your own game engine. But in order to give you the best advice, I will need to know a few things.

How much programming experience do you have?
If you do have some programming experience, do you have any experience programming games?
If you do have some programming experience, what languages have you programmed in?
If you do have some programming experience, give an example or two of projects you have completed.

I hope you answer these few questions so that I can help you the best way I can!

[sparkart]

Mattfang, here is a simplified overview of how a game works:

- Initialize
- Receive Input
- Update
- Display Game
- Go back to step 2 and repeat

What is your programming background?

[macosxnerd101]

There is a lot to this. You have to manage a lot here, including the game board(s), the level(s) of difficulty, the sprites, and the user interface/managing part (ie., save game, replay, high scores, etc.).

For the Sprites, what charactersitics will be pertenant to all characters in any game. Will they have levels, hit points/life, strength, defense, etc.? Will you have a good guy/bad guy sprite? What about for collision detection? Will you use a bounding box for your sprite? How about for any graphics from the attacks? What about images for the sprites characters? Will Sprites also represent inanimate objects like rocks? What about mines/booby traps?

For the game board, you'll have a whole lot going on here. For the actual board, how will you store sprites and objects? Will it be grid-based or only constrained by the size of the window? If so, this will make collision a little trickier, as you have to take vectors into account a little more blatantly. For the levels, consider the difficulty. How will you increase/decrease it? Accuracy of the enemies, damage they do, number of them, size of the board? How about allies for the main sprite(s)?

In addition, you'll need to take a lot of math and physics into account for this. You may want to look into gravity, collision and appropriate behavior, rotations, polar coordinates, affine transforms, etc.

Lastly, will you provide a UI for the users to interact with beyond playing the game? What about saving/loading games, starting a new game, high scores, etc.?

While you may not take all of this into account, you need to design your engine so that your code is extensible and allows other developers to account for these things. Don't provide the bare minimum, but don't provide a ton of features to the point where it inhibits developer freedom. If you choose to provide extra features that make development newbie-friendly, allow for polymorphism as well so that the more advanced developers can do what they want/need to do without completely violating encapsulation. Remember- you are not writing a game; you are writing a tool for others to develop a game.

This post has been edited by macosxnerd101: 24 June 2010 - 04:43 PM

[Theaegd]

Quote

Mattfang, here is a simplified overview of how a game works:

- Initialize
- Receive Input
- Update
- Display Game
- Go back to step 2 and repeat

Maybe for a simple pac-man style game, but really don't try and make it seem so simple - because it really isn't. There is so much more to it than just that.

[sparkart]

Theaegd, on 25 June 2010 - 01:50 PM, said:

Quote

Mattfang, here is a simplified overview of how a game works:

- Initialize
- Receive Input
- Update
- Display Game
- Go back to step 2 and repeat

Maybe for a simple pac-man style game, but really don't try and make it seem so simple - because it really isn't. There is so much more to it than just that.

Not for a simple pac-man game, for a game engine you could actually extend to and not some rip off you find from some tutorial.

macosxnerd101 is taking the wrong approach. The first thing you should consider is developing an engine that is flexible enough to recycle for future projects. Do not think about how your game will play first. The first thing you need to do is figure out how most games work and build an engine that all games can work with.

Theaegd, for you to say something like that I doubt you understand basic programming concepts pertaining to OOP. If you develop the engine using the OOP paradigm, things would be simpler. Theaegd, have you developed a game before? I would like to view its source code if you have because I doubt it looks pretty.

[ghillieLEAD]

A good OOP game loop should have those exact words followed by '();' in it. Of course there may be some 'Game::' in there or something similar

This post has been edited by ghillieLEAD: 25 June 2010 - 07:48 PM

[no2pencil]

MattFang, on 21 June 2010 - 08:50 AM, said:

I want to create it from scratch! I don't want to use any other game engine available for download!

I find it ironic that you want to start one from scratch, but you need help getting it started. I would think you'll have better results (& more fun) using existing engines first to get an understanding of gaming & game engine development, rather than posting a few sentences asking for help because you don't even know where to begin.

[sparkart]

As no2pencil said, it would be easier and more fun to start at a higher level and work your way down.

For instance, you could use an already built engine that manages gamestates and objects for you. You would only need to define your own objects and states and the engine will manage everything else for you. As you gain a better understanding on how to work the engine and an abstract idea of what's going on, you can move down and start implementing what the engine manages for you.

[stayscrisp]

I agree with no2pencil, using an existing engine will enable you to see how your engine might be designed and give you ideas of what you would like to implement. Since you are looking at the overall design of a game engine then this is definitely the best place to start.

[Fib]

Assuming that OP is a beginner. I would like to add this: Write Games, Not Engines

[macosxnerd101]

sparkart, on 25 June 2010 - 10:22 PM, said:

macosxnerd101 is taking the wrong approach. The first thing you should consider is developing an engine that is flexible enough to recycle for future projects. Do not think about how your game will play first. The first thing you need to do is figure out how most games work and build an engine that all games can work with.

My point was this exactly- think about how games in general are played, including certain specifics that will help game developers. Certaintly games will vary, but if the ability to choose is provided upfront, it allows the developer to focus on writing their game, not re-write everything from scratch. As I said above, some developers may or may not take advantage of all the features, but it allows them flexibility in how the go about it (ie., for hit points, one could do one HP/round or life, or in a battle sense where different attacks cause different amounts of damage). Will all games utilize physics and Calculus? Of course not. But including those features for the developers to use at their disposal makes it easier for them, and is what a framework is all about. In fact, the Java3D API includes a lot of this.

Honestly, as much as I hate GridWorld, I think it provides a decent example of a simple game engine. It comes with the Actor superclass, which has children Bug, Rock and Critter. Basically, Actors rotate in place, Rocks don't move, and Bugs and Critters move around on the Grid, with the Critters eating Bugs if they come into contact with them, and removing themselves from the Grid if they collide with Rocks. Now the Critters have 5 helper methods, and an act() method which describes the order in which the helper methods are called. By extending Critter and overriding the helper methods, you can get different behaviors for different Critters. Certaintly GridWorld has its flaws, but the presented is why it is used as the AP CS case study, and why it serves as a basic model for a game engine. Albeit, it does abstract and do more in the way of the GUI than a normal game engine might, but it is still important to model some features of the board, to at least the point of abstracting it to force extending it or designing one's own.

[Theaegd]

Quote

Theaegd, for you to say something like that I doubt you understand basic programming concepts pertaining to OOP. If you develop the engine using the OOP paradigm, things would be simpler. Theaegd, have you developed a game before? I would like to view its source code if you have because I doubt it looks pretty.

Amazing how you make such assumptions from the short comment I made. Having a bad day?

[lesPaul456]

Theaegd, on 29 June 2010 - 01:19 PM, said:

Quote

Theaegd, for you to say something like that I doubt you understand basic programming concepts pertaining to OOP. If you develop the engine using the OOP paradigm, things would be simpler. Theaegd, have you developed a game before? I would like to view its source code if you have because I doubt it looks pretty.

Amazing how you make such assumptions from the short comment I made. Having a bad day?

Yeah, that comment did seem a little hostile.

Besides, the OP asked for help making a game engine. sparkart, technically, you described a framework, not an engine; there is a difference.

[Theaegd]

A good idea before creating a game engine, whether meant for 2D or 3D, is to actually play around with a couple game engines made by other people. Try a few very simple open-source ones and maybe a more powerful one such as Unity or UDK. This will give you a better idea on what exactly you want to develop.