Thread: Game Components - final year project

  1. #1
    Registered User gazsux's Avatar
    Join Date
    Mar 2002
    Posts
    72

    Game Components - final year project

    Hey,

    I'm currently on a degree in Computer Games Programming and have a year and three months before my final year (I’m on placement next year). I thought it a good opportunity then, to start working towards a few ideas for my final year project. I don't have much information on what I can/can't do for my project but I’m assuming we're allowed to make a game. With this in mind I plan to make a basic game engine (its pushing it a bit to call it an engine but you know what I mean) that covers the main components of a game and have easy to use interfaces. The aim is to simplify and speed up the production of a basic game world. I thought I could perhaps ask for some advice on what aspects to cover. These are the areas I have thought of:

    * Per object material support.
    * Texturing. BMP, JPG and TGA file formats.
    * Picking support for user interaction.
    * Frustum and visibility tests (use of BSP trees)
    * Lens-Flares.
    * Sprites.
    * Support for sound. Probably OpenAl (though I haven't looked into that yet)
    * Bill boarding.
    * Terrain support using height maps.
    * Support for .3DS, .X and MD3 file types.
    * Light maps.
    * Fog.
    * Skybox.
    * Collision Detection and response.
    * Animation system with quaternion support.
    * Flexible camera system - implementations for both FPS and 3rd person views.
    * Environment mapping.
    * Cell-Shading.
    * Particle engine. Perhaps full implementation of a few common uses of particle systems: rain, fire, explosions etc.
    * Menu system both at start and in game.

    Do you have any ideas for further areas? Or perhaps think some of the areas listed aren't worth implementing? Any advice will be appreciated.

    Thank you,

    Gareth.

  2. #2
    'AlHamdulillah
    Join Date
    Feb 2003
    Posts
    790
    just how big of a project are we talking about here, if you use all the stuff your talking about, your talking a job that usually takes 4-5 people 2-3 years to fully implement and work, unless you already have all your other stuff setup

  3. #3
    Pursuing knowledge confuted's Avatar
    Join Date
    Jun 2002
    Posts
    1,916
    Don't do cell-shading. I hate it myself. It makes something that could look good look bad. Lens-flares are cool, but pretty optional as well.
    Away.

  4. #4
    cell-shading has its place where it looks good. On games that are supposed to look animeish. But a lot of people believe that if their game looks cartoony at all that cell-shading will be good.

    Dark Cloud 2 does an excellent job on its cell-shading. Wild Arms 3 (the game that really brought cell-shading to popularity) sucks at it.

  5. #5
    Registered User gazsux's Avatar
    Join Date
    Mar 2002
    Posts
    72
    thankyou guys

    I think i may drop the cel-shading then. and i'll see about lens flare, it may work well in the project I have in mind.

    As for the amount of stuff, I have alot of it implimented but in specific examples. What I propose to do is rip these out and make them into more generalised forms.

  6. #6
    Registered User gazsux's Avatar
    Join Date
    Mar 2002
    Posts
    72
    some initial feedback from lecturers aired caution to the idea of going for a full engine type approach. As cos of the sheer amount of work the project is often left shallow. I'll perhaps take an in depth look at some of the topics listed. So a slight change of tack, which areas listed have the most scope for an in depth project?

    Collision detection, particle systems and terrain could fit together quite nicely...

  7. #7
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    how bout an editable terrain engine. one that can build terrains (height map) then in an ortho viewport the user can select and drag vertices to edit the terrain. then adding things like sky boxes, particle engines for rain, snow, etc.. should be easy. This is the type of project i have planned for myself. the user can basically create worlds by editing terrain, choosing weather, picking sky and lighting conditions, etc...

  8. #8
    Registered User gazsux's Avatar
    Join Date
    Mar 2002
    Posts
    72

    Talking

    yeh sounds good. but would that not involve alot of setting up for the program itself? for my needs as im on a games programming course it may take a little too long to develop the software needed to edit the game features. but i do have over a year... good idea

  9. #9
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    but would that not involve alot of setting up for the program itself? for my needs as im on a games programming course it may take a little too long to develop the software needed to edit the game features
    yes, it definatly wouldn't be a simple task. however if you come up with a file format to export (the height map, weather specifier, light settings, etc...) then it would definatly make a good game development tool.

    maybe you should start with something you know you can finish in a year and add more features as time allows. its hard to judge how long these things will take.

  10. #10
    Registered User gazsux's Avatar
    Join Date
    Mar 2002
    Posts
    72
    yeh i could do it like you described. perhaps start with a terrain tool, then add features like you said, when time allows.

  11. #11
    Banned
    Join Date
    Jan 2003
    Posts
    1,708
    As for the amount of stuff, I have alot of it implimented but in specific examples. What I propose to do is rip these out and make them into more generalised forms.
    what have you already actually implemented...and for the things that you haven't how much reading have you done on the topic(s)
    Last edited by Silvercord; 06-12-2003 at 12:24 PM.

  12. #12
    Registered User gazsux's Avatar
    Join Date
    Mar 2002
    Posts
    72
    implimented:

    * Per object material support.
    * Texturing. BMP, JPG and TGA file formats.
    * Skybox.
    * Collision Detection and response.
    * Animation system with quaternion support.
    * Flexible camera system - implementations for both FPS and 3rd person views.
    * Particle engine. Perhaps full implementation of a few common uses of particle systems: rain, fire, explosions etc.
    * Menu system both at start and in game.

    the rest... not a great deal of reading. ive looked at height and light maps quite thoroughly tho. but yeh it appears to be abit too much... i like the terrain tool idea.

  13. #13
    Software Developer jverkoey's Avatar
    Join Date
    Feb 2003
    Location
    New York
    Posts
    1,905
    well, i made my own terrain generating program that would generate some really nice terrains that had full collision detection on 'em and everything, and i did that in about 2 weeks (most of the time i spent trying to find the equation of a point on a polygon given 3 x,y,z coordinates ) but yah, it's not really that hard to make, and then particle engines are usually pretty easy (depending on what type of engine you want to do.....) I've made a rain and a snow engine so far...but i haven't really spent much time on particle engines lately.

  14. #14
    Banned
    Join Date
    Jan 2003
    Posts
    1,708
    I honestly think you've already implemented the bulk of the hard stuff, i.e collision detection and response using BSP trees. I'm not too sure how hard it will be to implement all of the other stuff though.


    I'm working on collision detection right now for my project as a matter of fact, but I'm having problems with it. Did you do yours recursively (like the way it is done in the quake2 engine)?

  15. #15
    'AlHamdulillah
    Join Date
    Feb 2003
    Posts
    790
    I'm working on collision detection right now for my project as a matter of fact, but I'm having problems with it. Did you do yours recursively (like the way it is done in the quake2 engine)?
    recursively? like camera hits an object, a function recursively goes through different groups of polygons to see if one has been hit? Like i hit a polygon of say section 4 of a map, section 8 of that section, etc. it will just look to see if a polygon in a section has been hit, instead of looking at all polygons through the map?

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. What project for my graduate year?
    By chottachatri in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 10-28-2008, 03:12 AM
  2. beach bar (sims type game)
    By DrKillPatient in forum Game Programming
    Replies: 1
    Last Post: 03-06-2006, 01:32 PM
  3. 2D Game Project with DirectX and C++
    By VMJC in forum Projects and Job Recruitment
    Replies: 4
    Last Post: 12-23-2004, 12:28 AM
  4. Calendar Problem
    By wordup in forum C Programming
    Replies: 7
    Last Post: 10-29-2002, 03:36 PM
  5. cant get code to work
    By duffy in forum C Programming
    Replies: 13
    Last Post: 10-20-2002, 05:23 AM