quote:Original post by psamty10Way to miss the point.
I find this accusation against open-source largely unfounded.
Frustration with game programming
Maybe the problem is that the OP forgot a detail:
A GAME engine is not only loading models, Quake3 levels, play sounds and handle collisions. You need that little part that actually allows you to put a game together without hacking everything into the source code: some kind of scripting capability.
You could have your engine rely on external files that describe what it''s gonna do. That includes loading a level, loading entities, placing them, playing a series of animations (cutscene), displaying a menu, unloading everything, etc. That way your game could switch content without the need of everything going to globals.
For menus, if your game is gonna have plenty of them, it''s wise to create a menu file format that can be edited externally, either by using a small tool, or even a text editor. As example, you could have a file that describes the placement of all menu items, their graphics, and what they do when clicked (load another menu, start the game, etc.).
A GAME engine is not only loading models, Quake3 levels, play sounds and handle collisions. You need that little part that actually allows you to put a game together without hacking everything into the source code: some kind of scripting capability.
You could have your engine rely on external files that describe what it''s gonna do. That includes loading a level, loading entities, placing them, playing a series of animations (cutscene), displaying a menu, unloading everything, etc. That way your game could switch content without the need of everything going to globals.
For menus, if your game is gonna have plenty of them, it''s wise to create a menu file format that can be edited externally, either by using a small tool, or even a text editor. As example, you could have a file that describes the placement of all menu items, their graphics, and what they do when clicked (load another menu, start the game, etc.).
quote:Original post by Gauvir_Mucca
2. In-Game action. This is just a combination of input/AI/rendering. Make functions for each, and slap them together.
Talk about an oversimplification! You could say a 3D engine is just a combination of math and rendering and data manipulation, too. But that doesn''t help!
I think most "game programmers" spend way too much time on engine details, OOP, etc., and very little on higher-level game code. There''s an art to the latter, and a lot to learn. Your best bet is to focus on writing games, not engines, just for the experience.
Hi all,
There is always a confusion about the word ''Engine''.
Many people think that loading a bitmap, a model, an effect, setting the object factories and rendering all into screen is an engine. FALSE. At most these can be called ''Utilites'' or ''Toolbox'', but are too low level to be called ''Engine''.
An engine is an specific solution to a specific problem. That is why you have terms like RTS Engine or FPS Engine or RPG Engine or MMORPG engine. Its because the internal logic of the engine varies with each problem.
The resource loading and animation sets, dinamic shadows... all those fancy terms are just a base where the real engine stands. The engine starts when you begin joining these objects and consider the interactions between those objects. Do I need portal rendering? Do I need BSP trees? Which colision detection method? Do I need to pick objects on screen? Which AI must be implemented for my game? Do I need Client/Server or Peer-to-Peer?
Those questions have different answers for each game type. You won''t use a portal rendering for a RTS game. You wont use detailed collision detection or real physics for a RTS game but a FPS will look better with them (just see HalfLife2 trailers). On a FPS game the path finding algorithm is differrent than a RTS game. A RPG must take care about the inventory the user carries and the effects on ''encumbrance'', the more objects you carry, the slower you move... you dont need that in a RTS. But in a RTS you need to program formations, etc.
Each engine combines those elements in different ways. Because each problem is different. In a FPS you can render detailed models because you will see them closer and wont have more than 20 creature in a single frame. So you apply Bump Mapping in order to have a better detail. In a FPS you can have a battle with 5 armies in a complete pandemonium all in the same screen if you add shadows and bump to that you will get a 1 frame per second animation and your players wll leave.
Its like cooking... more of this, less than that. At the end you have a specific engine than you can use to make specific games. You got a RTS engine? Then modify the graphics and you have other RTS!!! Or you can enhance your engine and add a little more physics and perfect collision detection, or add dinamic shadows. Maybe the video cards got better and you can bump all the objects in a a RTS withouth losing framerate. But just dont try to make a FPS game using that RTS engine... it is not optimized for that.
Why do you thing game companies stick into a game mode? Diablo/DiabloII is basically the same engine on the base. Warcraft I, Warcraft II, Starcraft, Warcraft III. Better graphics, same base logic. That means... change the ''Toolbox'', keep the engine logic.
Most people have ''Toolboxes'' not engines. Engine is harder to implement. Engine is logic and experience. The most common error for a programmer is that they stop in the ''Toolbox'' and think they can program the next Quake.
If you have your toolbox, why dont you start and program those simple games you just rejected? Tetris... pong... pacman. They are simple but each one has a difficulty. Begin with a menu with a Start and Exit buttons and the game. Then add an intro with your logo. Then animate your intro in a simple way (i.e. fade). Then you will notice that the textures used for the intro are no longer required when you are loading the menu so drop them before loading the game menu resources. Then add the credits, the high score, then the initials and so...
But the most important. FINISH IT! If you cant finish a simple game... how do you expect to program a big game!
Only when you have gained the experience, you will know what went wrong and you can move into a more complicated game... multiplayer maybe... something like Gunbound... but keep it simple... and keep moving... and you will notice that the objects you made for these simple games work just fine with little modifications.
Luck!
Guimo
Spritekin Entertainment
P.D. My current game, still alpha...
http://www.spritekin.com/warscale/screen1.jpg
There is always a confusion about the word ''Engine''.
Many people think that loading a bitmap, a model, an effect, setting the object factories and rendering all into screen is an engine. FALSE. At most these can be called ''Utilites'' or ''Toolbox'', but are too low level to be called ''Engine''.
An engine is an specific solution to a specific problem. That is why you have terms like RTS Engine or FPS Engine or RPG Engine or MMORPG engine. Its because the internal logic of the engine varies with each problem.
The resource loading and animation sets, dinamic shadows... all those fancy terms are just a base where the real engine stands. The engine starts when you begin joining these objects and consider the interactions between those objects. Do I need portal rendering? Do I need BSP trees? Which colision detection method? Do I need to pick objects on screen? Which AI must be implemented for my game? Do I need Client/Server or Peer-to-Peer?
Those questions have different answers for each game type. You won''t use a portal rendering for a RTS game. You wont use detailed collision detection or real physics for a RTS game but a FPS will look better with them (just see HalfLife2 trailers). On a FPS game the path finding algorithm is differrent than a RTS game. A RPG must take care about the inventory the user carries and the effects on ''encumbrance'', the more objects you carry, the slower you move... you dont need that in a RTS. But in a RTS you need to program formations, etc.
Each engine combines those elements in different ways. Because each problem is different. In a FPS you can render detailed models because you will see them closer and wont have more than 20 creature in a single frame. So you apply Bump Mapping in order to have a better detail. In a FPS you can have a battle with 5 armies in a complete pandemonium all in the same screen if you add shadows and bump to that you will get a 1 frame per second animation and your players wll leave.
Its like cooking... more of this, less than that. At the end you have a specific engine than you can use to make specific games. You got a RTS engine? Then modify the graphics and you have other RTS!!! Or you can enhance your engine and add a little more physics and perfect collision detection, or add dinamic shadows. Maybe the video cards got better and you can bump all the objects in a a RTS withouth losing framerate. But just dont try to make a FPS game using that RTS engine... it is not optimized for that.
Why do you thing game companies stick into a game mode? Diablo/DiabloII is basically the same engine on the base. Warcraft I, Warcraft II, Starcraft, Warcraft III. Better graphics, same base logic. That means... change the ''Toolbox'', keep the engine logic.
Most people have ''Toolboxes'' not engines. Engine is harder to implement. Engine is logic and experience. The most common error for a programmer is that they stop in the ''Toolbox'' and think they can program the next Quake.
If you have your toolbox, why dont you start and program those simple games you just rejected? Tetris... pong... pacman. They are simple but each one has a difficulty. Begin with a menu with a Start and Exit buttons and the game. Then add an intro with your logo. Then animate your intro in a simple way (i.e. fade). Then you will notice that the textures used for the intro are no longer required when you are loading the menu so drop them before loading the game menu resources. Then add the credits, the high score, then the initials and so...
But the most important. FINISH IT! If you cant finish a simple game... how do you expect to program a big game!
Only when you have gained the experience, you will know what went wrong and you can move into a more complicated game... multiplayer maybe... something like Gunbound... but keep it simple... and keep moving... and you will notice that the objects you made for these simple games work just fine with little modifications.
Luck!
Guimo
Spritekin Entertainment
P.D. My current game, still alpha...
http://www.spritekin.com/warscale/screen1.jpg
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
