Game Engines???
Blitz3D Forums/Blitz3D Programming/Game Engines???
| ||
| Hey guys. I was wondering, what is a brief explanation of a game engine;how would you make one in Blitz3D??? |
| ||
| you have somewhat just asked 'how do i make a game'. There are a few ways of making a game, one is to just get on with making your game and somewhat 'hard code' most things, as in you want your box to move from A -> B then just program it to move to A->B. This is often the quickest approach, but is less robust. For example if you then have another box that needs to move in a similar way you will have to hard code that etc. My example above is somewhat of a very small example, really you would interlace your program with reusable functions as you can do the same thing over and over on different objects without having to reprogram anything. This has obvious benefits of reducing your coding overall, but you have to really have some experience with writing more robust code. If you then take that to its extreme, you can make yourself a reusable engine (or large collection of types and functions that all are already setup to work with each-other) for a certain genre of game. For example, if your making a fps, you could make a massive 'engine' that is designed for you to just slot in different content and tweak some values and you have a new game from it! Making an 'engine' has obvious benefits more to large companies, for example, the Source engine by valve can be used again and again by lots of different companies at a fee. If valve had just made 'half life' then they would miss out on that opportunity. If your making pong, then a pong engine isn't that needed. Now wether or not you should take this approach is up to you and dependent on the type of game your making. Given that it looks like you have just started, just worry about making a game not an engine. An interesting article on it here: http://scientificninja.com/advice/write-games-not-engines |
| ||
| Yes, make your own engine, then it can perform just as you want, and maybe other people can make use of it too. I am making my own engine too, called Nexus Engine, and i am planning to sell it :) But still, it requires a lot of C++ skills.. Use either Blitz3D, BlitzPlus + my engine when it is finished, or try Leadwerks with BlitzMAX ;) |
| ||
| how would you make one in Blitz3D??? Blitz3D is already a game engine. |
| ||
| >>Blitz3D is already a game engine. << If by definition of game engine we have to assume something like "The core functionality typically provided by a game engine includes a rendering engine (“renderer”) for 2D or 3D graphics, a physics engine , sound, scripting, animation, artificial intelligence, networking, streaming, memory management, threading, and a scene graph." , Then we can also assume that B3D missing majority of things listed and far as i can see it, its programming language wrapped around DX7..there is no out of box solution such as AI, Physics, Network ... so you have to use 3rd party libs or build your own...so, it cant fit in to game engine category at all.. |
| ||
| Blitz3D is already a game engine. 3D Gamemaker is a game engine. Blitz3D is not. |
| ||
| Now wether or not you should take this approach is up to you and dependent on the type of game your making. Given that it looks like you have just started, just worry about making a game not an engine. I've been programming in Blitz for 5/6 years. I've just never messed with game engines before. Anyway, thanks for the help guys. I'll begin building one right away :) p.s Any ideas on what to name it? |
| ||
| Any ideas on what to name it? I wouldn't worry about giving it a name just yet. |
| ||
p.s Any ideas on what to name it? The name is irrelevant. What kind of game are you making? |
| ||
| FPS. But i'm not actually making a game at this moment. I'm working on the engine. |
| ||
| I think that instead of making an universal engine (which would be much more time consuming and hard to think through), you should create different engines\systems for the games you make. Each game you make will have a different one (different as in built from scratch, even if it uses similar code\logic from previous ones, like if it's the same genre - you can use previous stuff). That way you can create a more customized engine for each game you make, and be able to take a more artistical approach to it. Making a universal engine means you'd have to have the same conditions from one world to another, and besides having to be data-based, you wouldn't have so much freedom as you would if you had built an adapted engine from start (well you could make it VERY universal but that would take an incredible amount of time and knowledge of the subject). I think re-writing stuff from scratch is the best way. You'll end up having a library of procedures common to all games (like special effects that are not genre-specific) since every time you write the code you naturally end up finding out which procedures get repeated each time you get a game. That can be used to ease up on the time spent developing the overall game. |
| ||
| Good idea rafael_blitz. I started to make a game engine, but you could make it VERY universal but that would take an incredible amount of time and knowledge of the subject . So I'm just going to make the game and mabye re-use the functions if needed....THANKS EVERYBODY!!! |
| ||
| I agree with Naughty - B3d is a language with which you can build your own game engine, and I know loads of people here have sucessfully done that. Gizmo - you should take what you know start creating ALL the software tools and subroutines for doing all the jobs which a game (of whatever type you have chosen to make) needs to be able to do. After identifying what type of game engine you want to build I would start with an ENTITY system - think of ALL the things you may ever need to do or know about any ENTITY in your game, and write handy routines to take all the complexity of writing the game out. You can set collisions, colours, rotations, positions, scale, textures, anything you need. For example in a game I finished early this year, I had to have some collectible objects, these all needed specific properties so I created an INCLUDE file to handle them as follows: ;gameentity(meshfile$,gescale#,gex#,gey#,gez#,gepitch#,geyaw#,geroll#,gerotation# -2 ,glow,geshadow(True/False) ,shadow size1,shadow size2,shadow size3,distance# of shadow under entity, geparticle=0, gravity=0, trigger, timer,collectable+score)) The code to call a game entity would be :
gameentity("fish001.b3d",0.15,7624,-910,-7950, 0,0,0, -2, 1,False,0,0,0,0, 0, 0,0,0,10)
I could now instantly load any model, position it, scale it, give it a rotation flag (in order to rotate constantly in my game loop), give it a shadow (by linking into another area of my code to add a shadow type here), give it gravity, set up a particle type, set if it was a trigger or not, and if it was collectable give it a score too. Now you could get even clever as with a 'world/level editor' working through a GUI, most of this kind of stuff gets hidden for the user and you just load the object in from a file menu and the actions you do in the level editor sets the objects' properties. This way a world editor can save you a lot of time, as you plan and set stuff up visually. Your game engine reads the files your game editor saves and reproduces what you set up visually, for the in game level/world etc, with all the bells and whistles working for you immediately. Preparation takes longer, but level building is incrementally faster, and the more levels the better the time saver this would be. I hope this helps some. IPete2. |
| ||
| Wow. Look's like you put in alot of effort for that include file(s). That's a good idea to do all of that, but making a modeler is way over my head. (meaning it would take too much time) |
| ||
| Let's post this here too. :) http://scientificninja.com/advice/write-games-not-engines |
| ||
| Gizmo, Yeah sorry - I wasn't suggesting you make a modeller. I am suggesting that you make a game engine and start with GameEntities or GameObjects. Ipete2. |
| ||
| Ok. Nice. |
| ||
| Any projects you create with Blitz wiklk contain 'engines' by default as all games are programmed with the core elements. However, in making your 'engine' generic or accessable/"moddable" you will need to do a lot more work and include a lot more non-specific functinality. For example, you may be coding a FPS style game with specific weapon types, though these weapons all utilise a basic cosde structure for firing: (example pseuddocode) Gun=GetCurrentGun() Dir=GetDirectionFacing(X,Y,Z) DoGunfire(Gun,XYZ) In a specific code structured 'engine' for a single specific game, you may restrict DoGunfire, knowing that all your weapon will act in a certain way:
function DoGunfire(Gun, XYZ)
if (Ammo(Gun)>0)
Hit=Check 1stTarget(XYZ)
if (Hit=ValidTarget())
GetGunDamage(Gun)
DoDamageToTarget(Hit)
endif
ReduceAmmo(Gun)
return
else
DoNoAmmoLeft()
endif
return
end function
In creating a more general and 'moddable' engine, you would need to consider all possible modification factors within the core code, so DoGunFire() would be more complex such as:
function DoGunfire(Gun, XYZ)
if (Ammo(Gun)>0)
select (GunType)
case GUN_TYPE_BALLISTIC
Hit=Check 1stTarget(XYZ)
if (Hit=ValidTarget())
GetGunDamage(Gun)
DoDamageToTarget(Hit)
endif
ReduceAmmo(Gun)
return
case GUN_TYPE_BEAM
For CheckHits=1 to Range()
Hit=GetTarget(XYZ,CheckHits)
if (Hit=ValidTarget())
GetGunDamage(Gun)
DoDamageToTarget(Hit)
endif
Next
ReduceAmmo(Gun)
return
case GUN_TYPE_GRENADE
Distance=GetDistanceFunction(XYZ)
SetGrenadeTime(Gun,Millisecs)
ThrowGrenade(Distance)
ReduceAmmo(Gun)
return
end select
else
DoNoAmmoLeft()
endif
return
end function
Of course, that's only a suggested example. In reality, grenades would likely be handled separately altogether, but I hope you see my point. :) |
| ||
| thanks. I get the point =) |
| ||
| Yeah, I strongly disagree with Malice. I agree with that "Write Games not Engines" article (which was my point of view anyway =P ). Good luck, GIZMO. |
| ||
| Thanks rafael_blitz, and everybody too for pitching in. |
| ||
| A little late, but anyhow. In my definition of a game engine the ability to load multiple levels without to run multiple EXEs is very significant. Not every EXE with multiple levels is a game engine. Especially beginners write games with multiple levels this way: Repeat ... Until level 1 complete Repeat ... Until Level 2 complete Repeat ... Until Level 3 complete But infact this way people write a game for every level. Although this gives you ultimate flexibility, it's also a lot of work. In a true game engine you are writing the game parts only once and then reuse it with various scenarios for every level. A game engine also contains level editors, or at least a documented level file structure. Things like doors, codelocks or puzzles are things you don't want to program again and again. It's much easier to tell the level editor "add a codelock to this door, password so and so". So the use of a level file makes a game engine. For example there are mesh file paths, position, rotation, scale data of them, including command codes for special functions (eg. to make something an interactive door etc.) and other parameters that could be used with the object. But not only meshes are defined this way. Positioning 3D sounds is about the same. Usually for a sound there is a dummy mesh displayed in the editor, that allows to position the sound visually, be it wind, water etc. NPCs are a further important part. Whether they use a simple algorythm by following some predefined ways, or they use sophisticated AI and path finding algos, that's rather a question of complexity and available time and programming skills. Today commercial FPS game engines became extremly complex, it's almost impossible for one man to write something like the latest Doom/Quake or Unreal engines. But even a simple, small FPS engine that is useing DX7, like Blitz3D does, can be fun. In the real world you'll find a lot of game engine projects (besides the big ones). Don't be too impressed by lists of tech features as long as there ain't no playable (and I really mean PLAYABLE, not only a walktrough thing) Demo around - most projects are only 50% or less finished/ready. As far as I know all popular FPS games used a game engine. But the level designers still need to be very creative and use a game engines possibilities to (and often beyond) it's limits. |
| ||
| Thanks. |
| ||
| I'm waiting for xors3d for my 3d game project. Probably will use it with BlitzMax, but I don't like the BlitzMax IDE. Hopefully, I will also find a comfortable BlitzMax IDE for Blitz3D veterans (BLIde?). I still like coding in Blitz3D, but it is just getting too old for what I need to do! Also would like to use a script language, like Lua. http://www.rubux.net/ http://www.lua.org/ |
| ||
| ..I think Xors3D (im waiting it too) + b3d+winblitz3D v2.0 will rock..really cant wait Xors3D to integrate in to my thingy especially ebcause its already blended with Ageia im using.. |
| ||
| Yeah, I strongly disagree with Malice. I agree with that "Write Games not Engines" article (which was my point of view anyway =P ). Whether intended for universal application or not, any 'game' wriotten with Blitz iunvolves writing the engine for it. It may be the 'engine' coded is exxtremely specific and inflexible, but it is STILL an engine. Regardless of the intent for the final product, it's impossible to wrrite a game without an engine because at the core of the code are all the commands and functions etc. that will make the game 'work' which is essentially an engine. I was not suggesting that a more flexible engine was necessary, only useful and actually easier to modify, although I agree, involves ore planning and work, but this extra effort can pay off in the long run. |
| ||
| I agree with you on the point that actually getting to write an engine (whether it is universal or specific) is crutial. You'll always end up having a loop where you will constatly update the game based on player input; that point of stability denotes that you have an engine running. But I would definately write a specific engine for each game I would make; that's just a matter of personal opinion :D |
| ||
| Sure, it also deopends on what sort of game you're making. For example the codebase for a FPS game would be mostly useless and require a HUGE amount of modification to change in order to produce say, a space-sim. However... considering the elements and functions contained withion your FPS game, syuch as, say vehicles and more basic operations for the HUD, Front-End, methods of Data-storage/Saved Games etc. etc. Can all still be universally applied. Personally, I tend to write things in a modular approach with separate functions and wrappers for functions for almost everything. Sure, it probably takes ten times longer, but I can access the iseful bits anytime from anywhere and steal them for other projects as and when necessary. |
| ||
| I'm writing a platform game engine now, once the engine's done, I'll write my game using it, I'm putting as much into external files and the level structure as possible to allow for varied gameplay. I'm also releasing the engine for free on my youtube videos: http://www.youtube.com/amcadam26 |
   |