All of our games

This is a discussion on All of our games within the Game Programming forums, part of the General Programming Boards category; Well, pretty much everyone in here is working on making a game of some sort, and most likely it is ...

  1. #1
    l'Anziano DavidP's Avatar
    Join Date
    Aug 2001
    Location
    Plano, Texas, United States
    Posts
    2,738

    All of our games

    Well, pretty much everyone in here is working on making a game of some sort, and most likely it is their own personal project. I know a couple people on these boards have actually worked for game companies, but the majority of us are making our own projects using SDL, OpenGL, DirectX, Allegro, 13h, etc., etc. etc.

    I have noticed a common thread, however, between all of our little projects.

    Except in the case of a text-based game or a simple game like pong or one of those little 2d flying games a couple people here have posted, it seems most of us here are stuck at the game engine portion of the development process. We are always constantly working on doing stuff with graphics, or implementing audio into our "game". That is all part of the game engine part of the development process.

    The game itself actually starts when you create characters for the actual game, when you start to hammer out the storyline, and create the levels for that specific game. It seems as though creating the game engine is the largest part of the project and if that could be finished then making the actual game itself would almost be a breeze.

    I know I myself have been working at making my own game projects for years now, and every time I learn tons of new things, but in the process of learning those new things I find thousands of mistakes I have made in how I have structured my code and end up restarting on a new project, learning new things, then trashing that one when I realized I have done some stuff wrong, and the cycle continues.

    It seems that many others here cannot get past the engine stage either. Many times we excel at one part of the engine, but then we start working on other parts and quickly get discouraged.

    Maybe it would be smart to download a basic game engine and create a game using it so maybe once we could get the satisfaction of having a finished product on our hands instead of a lot of incomplete game engines lying around?

    Just a thought.
    My Website

    "Circular logic is good because it is."

  2. #2
    Confused Magos's Avatar
    Join Date
    Sep 2001
    Location
    Sweden
    Posts
    3,145
    My problem is that I aim way too high. I plan so many things the engine should do and it ends up with me not being able to do them all.
    I dunno about using existing engines. Part of why I make games is the satisfactory of building a game from scratch up to the final product. Also, such engines are most likely generalized (so they can be used in many types of games) so they will lack in performance.
    MagosX.com

    Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime.

  3. #3
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    Hmm. What exactly *is* a game engine? I mean, some games just need minimal graphics support, while others focus on one aspect or another. And does a game engine necessarily go as a whole set, i.e. interdependent, or can it be composed of a set of independent modules from various projects that you just toss in a pile and duct-tape together? Is there any hard and fast rule for what *is* a game engine and what *isn't*?
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  4. #4
    Shadow12345
    Guest
    oh come on we all know what a freaking game engine is.

    programming a robust game engine is extremely difficult. There is no perfect design first of all, it's very difficult to even develop a 'robust' design that doesn't have hacks or holes in it. Programming an engine to get crap working is so damn exhausting that there's often not enough motivation left over to actually make a friggin game.

    Plus, once you gain some experience, it gets more and more difficult to really be immersed in programming junk...stuff is only cool the first time you do it, then it becomes easy, then seems stupid.

    Another thing, it's very easy to find things that your engine lacks, despite all of the hard work you put into it. The more experience you get, the more you expect from yourself, but then you encounter more and more and more problems trying to make a game with sweet graphics and sweet physics and all of the crap.

    For me, personally, I haven't even completed a real game. I haven't programmed much at all lately. However, I've restarted on a relatively simple 3D hovertank game. I'm setting attainable goals, i.e I'm only using simple OpenGL vertex based lighting (Im working on a system for that right now, so that data for lights is read in from the file, then non visible lights are culled) instead of having to worrying about |337 fragment shaders, and simple impulse based physics that can mostly be taken care of with swept volume collision detection instead of overly complex ragdoll physics.

    So, yeah, this is stuff I've been thinking a lot about lately.

    EDIT:
    I'm silvercord btw. Kermi let me have both accounts for the time being because this account was my first one and it has 'nostalgia' value

  5. #5
    The Defective GRAPE Lurker's Avatar
    Join Date
    Feb 2003
    Posts
    949
    Quote Originally Posted by Magos
    I dunno about using existing engines. Part of why I make games is the satisfactory of building a game from scratch up to the final product. Also, such engines are most likely generalized (so they can be used in many types of games) so they will lack in performance.
    Ditto.

    I don't really care about having a working game on my hands. That would invole creating artwork, sounds, and storylines. When you work for a game company, would you really be doing those things (with possible exceptions in storyline). Creating the engine and learning from it is much better, in my opinion, than creating a huge working game.
    Do not make direct eye contact with me.

  6. #6
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    >>oh come on we all know what a freaking game engine is.
    Sorry, but I don't really understand your explanation. Could you use simpler words please? j/k, OK I get the point. Well, I have an idea of what a game engine is, but the concept is still kinda fuzzy to me. People talk about using this engine and that, using this engine's code for a game or whatever, and then say that modding a game is basically just using the game's engine to make your own game, or something to that effect - i.e. Counter-Strike, they consider it a separate game from Half-Life, and say that it uses Half-Life's game engine. But then, Half-Life uses Quake's engine or something?.. but CS is a Half-Life mod. So is there more than one level (for lack of a better word) of game engine or something?

    >>I'm silvercord btw.
    Hah, when I saw that line, my opinion of that post suddenly shot up a few notches
    Last edited by Hunter2; 05-08-2004 at 05:01 PM.
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  7. #7
    Shadow12345
    Guest
    Okay, think about ALL of the code stored in all of the executables and dlls of counter strike, half life, and all of the 'half life' modifications...the stuff that is the same for each one is the engine. The engine is what does all of the house work. All an 'engine' knows how to do is load data from a file, perform collision detections, render stuff, take care of windows and gather input, stuff like that. It is technically incorrect to say 'counter strike is a half life mod', because like you mentioned, half life uses the glquake game engine. It's probably totally modified anyway though, so you can get away with saying half life is its own engine. An 'engine' doesn't think about good guys or bad guys or monsters and stuff like that, it is just concerned with gathering data and setting stuff up so that a game can be played. The actual monsters you create goes into a different program that uses the game engine. That's the game itself, and it is the game code that thinks about good guys and bad guy sand monsters and stuff like that.

    EDIT:
    I included a screenshot of how my engine is setup. You will distinctly notice that in the same workspace I have a section called 'engine', which expands into many other folders, then I have a section called 'game' which contains the folders and code for the game project I am finally coding. In reality I should be compiling these in two different workspaces, with the engine crap compiled into dlls, but this is easier. you will also notice a folder called 'export'. This is essentially the interface to the game engine itself. Every single object in the world is a 'worldobject' (except for lights, which are thought about slightly differently by the engine), and every single worldobject can access the main game engine whenever it wants to do something.

    EDIT1:
    In order for a 'worldobject' to be interfaces with the engine, it overrides some virtual functions that supply its functionality (so that interactive stuff happens). The 3 basic components that I found I needed were:

    a TouchFunction
    an Update function
    a BeginPhysics function
    and an ActonPhysics function

    The TouchFunction determines how the object behaves when another object bumps into it. Doors Open, and Elevators raise upwards.
    Update just gathers input and calculates an ideal velocity
    Ideally BeginPhysics tries to move the object, and ideally ActOnPhysics respondes to the collision by modifying the velocity and entering the collision response loop, but im finding I do everything in BeginPhysics.

    Here's the complete file for Bert. Update just determines where the player is, and calculates the pitch and yaw so that bert faces the player. The begin physics tries to move towards the player. Everytime you see something like "Export.something" bert is accessing the main game engine.

    Code:
    #include "Bert.h"
    #include "GAMEEXPORT.H"
    #include "Render.h"
    #include "GLext.h"
    #include "Matrix.h"
    #include <windows.h>
    #include "UNITS.h"
    extern	GameExport	Export;
    extern	HWND	hWnd;
    
    extern PFNGLACTIVETEXTUREARBPROC			glActiveTextureARB;
    extern PFNGLCLIENTACTIVETEXTUREARBPROC		 glClientActiveTextureARB;
    
    extern PFNGLGENOCCLUSIONQUERIESNVPROC		glGenOcclusionQueriesNV	;
    extern PFNGLDELETEOCCLUSIONQUERIESNVPROC	glDeleteOcclusionQueriesNV;
    extern PFNGLISOCCLUSIONQUERYNVPROC			glIsOcclusionQueryNV;
    extern PFNGLBEGINOCCLUSIONQUERYNVPROC		glBeginOcclusionQueryNV	;
    extern PFNGLENDOCCLUSIONQUERYNVPROC			glEndOcclusionQueryNV	;
    extern PFNGLGETOCCLUSIONQUERYIVNVPROC		glGetOcclusionQueryivNV	;
    extern PFNGLGETOCCLUSIONQUERYUIVNVPROC		glGetOcclusionQueryuivNV;
    
    Bert::~Bert()
    {
    	
    }
    
    void	Bert::Attack()
    {
    
    }
    
    /*
    	
    */
    void	Bert::VWOTouchFunc()
    {
    
    }
    
    void	Bert::VWOUpdate()
    {
    	Vector3	to = Export.mpPlayer->mPosition - mPosition;
    	to.y = 0;
    	to.Normalize();
    	Vector3	toplayer(Export.mpPlayer->mPosition.x-mPosition.x,0,Export.mpPlayer->mPosition.z-mPosition.z);
    	mYaw	=	VecToYaw(&toplayer,&Export.mpPlayer->mpCam->mZAxis);
    	if(Export.mpPlayer->mPosition.x < mPosition.x)
    		mYaw = -mYaw;
    	Vector3	dirdir = Vector3(mVelocity.Dir.x,0,mVelocity.Dir.z);
    	dirdir.Normalize();
    	if(DotProduct(&dirdir,&to)<0)
    	{
    		mVelocity.Dir *= 1-(2*Export.mFPS.TimeFrac); //apply break
    	}
    	
    	if(GetKeyState('Q')&0x80)
    	{
    		mVelocity.Dir.x += to.x * FOOT(15)*Export.mFPS.TimeFrac;
    		mVelocity.Dir.z += to.z * FOOT(15)*Export.mFPS.TimeFrac;
    	}
    	else
    	{
    		mVelocity.Dir.x += to.x * FOOT(5)*Export.mFPS.TimeFrac;
    		mVelocity.Dir.z += to.z * FOOT(5)*Export.mFPS.TimeFrac;
    	}
    }
    void	Bert::VWORenderModel()
    {	
    	RenderRedBall(mPosition+mMins);
    	
    	mpModel->Draw(&mPosition,mPitch,mYaw,0);	
    }
    int	Bert::VWOFrustumTest()
    {
    	return	Export.mFrustum.BBInFrustum(mPosition+mMins,mPosition+mMaxs);
    }
    void	Bert::VWOBeginPhysics()
    {
    	mVelocity.Dir.y -= FOOT(32)	*	Export.mFPS.TimeFrac;
    }
    void	Bert::VWOActOnPhysics()
    {
    	Velocity	to;
    	int	tries = 5;
    	Vector3	original = to.Dir;
    	while(tries--)
    	{
    		to.Dir = mVelocity.Dir;
    		float	IncomingMVELLength = to.Dir.GetLength();
    		to.Mag	=	IncomingMVELLength*Export.mFPS.TimeFrac;	//base it on time 
    		if(IncomingMVELLength > .0001)
    		{
    			to.Dir	*=	(1/(IncomingMVELLength)); //Normalize
    		}
    		else
    		{
    			WOReLink();
    			WOMakeBrush();	
    			return;	//Not enough to even bother tracing 
    		}
    		Export.mpBSP->TraceRay(this,&mPosition, &to,&mMins,&mMaxs,HITWORLD|HITENTS|RUNTOUCH); 
    		if(Export.mpBSP->mBSPColInfo.closestFraction == 1.0f)
    		{
    			mPosition	=	Export.mpBSP->mBSPColInfo.mIntersect;
    			WOReLink();
    			WOMakeBrush();
    			return;
    		}
    		else 
    		{
    			if(Export.mpBSP->mBSPColInfo.mpClosestEnt)
    			{
    				Export.mPhysics.ApplyImpulse(this,Export.mpBSP->mBSPColInfo.mpClosestEnt);
    			}
    			else
    			{
    				WOClipVelocity(&Export.mpBSP->mBSPColInfo.hitNormal,0);
    			}
    		}	
    	}	
    }
    Attached Images Attached Images  
    Last edited by Shadow12345; 05-08-2004 at 05:20 PM.

  8. #8
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    Ah. So a game engine can be built completely separately of the game itself and linked in later, and it can also be built into the game at the source level?

    **EDIT**
    Hmm, I see. Thanks for the explanation
    Last edited by Hunter2; 05-08-2004 at 05:28 PM.
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  9. #9
    Shadow12345
    Guest
    yeah, but like I said, it's better to compile the engine into dlls instead of keeping the engine and the game itself in the same workspace. that's the route i should eventually take

  10. #10
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    Then you'd need to completely write the engine beforehand instead of just expanding it as your game requires?
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  11. #11
    Shadow12345
    Guest
    heck no, I just need to add the code in there that exports the engine to dlls. shouldn't take too long, maybe a day. the functionality of the engine all gets exported to a dll, and then in the game project instead of you seeing the implementation, all you get to see is that all of the classes of the engine itself is imported from the dll. you have to know how to use dlls to know what im talking about. i haven't worked with them in a long time though

  12. #12
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    Oh, from your wording, I'd assumed that you meant 'develop the engine in a separate workspace then compile it into DLL's so you can use it in your game'. What I meant was isn't it awkward having to flip to another workspace, do your updating, compile there, and then copy your DLLs to the game's directory before you can test it - rather than compiling and running the whole batch with a single button click?
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  13. #13
    Software Developer jverkoey's Avatar
    Join Date
    Feb 2003
    Location
    University of Waterloo
    Posts
    1,904
    yes, compiling dlls does require another project. I've worked with them A LOT in the making of OpenScript and my whole language runs off of DLLs actually. Every function in the language is custom-made in C++ and compiled as a DLL, then the OST2 compiler/interpreter interface scans both the current directory (that the compiler/interpreter was loaded in) and also the installed path. This allows you to customize the language to your needs as much as you want.

    Now, when it comes to doing this with a game, the best way to probably go about doing it is to have 2 projects in the same workspace. One project would be the engine DLL. The other project would be the game itself. That way you could modify the engine, recreate the dll, and not have to actually recompile any part of the game itself. Like (shadow) said above, the engine itself has no idea what it's actually going to be used for, it just does stuff, and usually cool stuff too

    Also, one cool thing about DLLs is that you can swap out a DLL with another DLL that has the same function signatures and everything, but could be a completely different engine altogether. So theoretically you could have a game that has all of its "modules" compiled in to separate DLLs and then that way you can make Mods just by swapping the DLLs with different ones! Half-life, case in point.

    Another thing that comes about when talking about game development is that not every game out there has the most stunning engine in the world. If you think about it, there are TONS of games out there that everyone loves to play and aren't modable at all! For example, super mario, dig dug, pong, the new Gladius game (I just saw someone playing that today), Command and Conquer. I could go on, but i might die or something.... But anyways, what I'm getting at is that you don't necessarily always have to focus on the engine. I've finished 3 games up to this point, and they've all been coded in <=2 months (EFFF being the longest at 2 months, RoboCafe being the shortest at 3 days, from scratch). Note that these games were in 2D, minus PongFX, but that wasn't too hard of a game to make.

    The way I made those was I layed out the concepts for the game (what I wanted them to do) and just started coding. For most of them I'd start working on getting the basics rendered, like backgrounds or tile systems. Then, I would start working on the game itself. You have to just remember that games aren't always about graphics :d

    -embraces self for giant flaming from everyone who plays FPS's-

    and like i usually say, these are just my opinions, i might be wrong, i might be right, but whatever the case, they're just what I think, so feel free to argue with 'em :d

  14. #14
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    >>not every game out there has the most stunning engine in the world.
    Ah, yes. Actually I guess what I was getting at when I asked what the 'definition' of a game engine was, is that I've made 2 games that work decently well, and are popular enough at school... but all they have is 2D graphics that have the capability to draw a fixed image (with transparency, of course) - no animation, no Sprite class or whatever Does that count as a game engine?
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  15. #15
    Software Developer jverkoey's Avatar
    Join Date
    Feb 2003
    Location
    University of Waterloo
    Posts
    1,904
    all depends on your definition of an engine :d a robust engine would allow you to go back a year later, take the code out, swap it in to a new game (with only minor adjustments) and then just work However, most engines don't work that way. A lot of the times as you get deeper and deeper in to making the game, things start to intertwine because of some way you programmed something a month before, now causing you to either rewrite/move all of your code around, or just continue with it.

    Most engines, however, are designed for just one game, and tend to really only work for one game. However, some engines can be reused in later releases of games (sequels) and that always isn't too hard of a thing to do. The problem there is that because of the way our field of expertise works, things are always changing and we're always learning, so we tend to find different ways of doing things and end up rewriting the code anyways

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. When done right, PC games are amazing
    By VirtualAce in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 08-13-2008, 06:32 PM
  2. Violent video games?
    By VirtualAce in forum A Brief History of Cprogramming.com
    Replies: 58
    Last Post: 04-26-2006, 02:43 PM
  3. c++ games comparable to psx games?
    By anarchyhollow in forum Game Programming
    Replies: 17
    Last Post: 01-08-2003, 08:49 PM
  4. Video Games Industry. 5 years left.
    By Cheeze-It in forum A Brief History of Cprogramming.com
    Replies: 26
    Last Post: 12-10-2002, 10:52 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21