Jump to content
  • Advertisement

fortia

Member
  • Content count

    71
  • Joined

  • Last visited

Community Reputation

276 Neutral

About fortia

  • Rank
    Member
  1. fortia

    Life is ironic

    How come the more you learn, the more you realize that you are not an expert? I mean... if you think you know how something works in the beginning and then really dive into it, you always end up thinking "how could I say that I knew something about this before I learned all this?". You define that you know everything about for example a programming language and environment after having worked with it several years. Then you get into a series of problems that cause you to open your books again searching for a solution, and wow(!)... you learn something new. After several problem solving tasks you have learned so many new things that you just laugh out loud when you think back on the time when you thought you knew everything. Isn't this ironic? Doesn't the process of learning ever end [rolleyes]? Are humans constructed to learn all their lifes about everything and everybody? I think so. Why else would the term "science" exist?
  2. The last few days I've been trying to solve some major problems with my old design. One of these is the fact that you were limited to 4 simultaneous collisions per object and the collision detection shader was always run 4 times the number of objects. Now I have a new solution in which an object can have an arbitrary number of simultaneous collisions and no irrelevant pixels will be processed. My current best solution still has broad-phase collision detection on the CPU, which requires a read-back of the position texture (128x128 32-bit FP). However, the alternative would be either to test every object against every other one, which is a REAL performance killer!!! I tried to find a way to do broad-phase CD on the GPU, but always ended up with expensive or impossible-to-implement-on-GPU algorithms [totally]. I've not given up on this yet, but will put it on ice until everything else is done so I don't get stuck... This evening, I also created a simple scripting system so that I can define all textures and passes in a text file and not have to hardcode them in the program. This will really simplify testing of different configurations and it will not be such a pain in the *ss to test a configuration anymore... Now it's 2 a clock in the morning and I think I have to go to sleep so I don't kill myself working [smile]. Good night!
  3. fortia

    Still around lol

    Another thing... You asked by which segment you should start. My advice for you is to start with the graphics part so you can quickly get something on screen (just when drawing an interface in a normal app [smile]. After that you could implement some basic game mechanics like what happens if you move the mouse (in an FPS you should look around) or press a key. Then some collision detection and physics system would be great so you don't start walking through walls. The next step for an FPS I think would be to implement AI with pathfinding etc. Then try to implement shooting mecanisms and place objects in your world that will affect health, ammunition etc. Things to leave for later that don't affect the game very much are sound and music as well as menus and other user interface and configuration screens. After all this is done you can refine everything by adding special effects, animations and more proffessional game content as well as optimizing(!!!). A good thing is also to implement some kind of level editor if you're not directly exporting from some modeling program. Hope this helped...
  4. fortia

    Still around lol

    First: I'm not exactly agreeing with jjd. If you dive into programming without thinking about the technical design of what you're doing you will be fine in the beginning but you will always get to a point later when you realize your code is a mess and start having trouble even understanding what you're doing! Don't forget that a game is usually a rather big project if it's not just a simple one like tetris [smile]. I've been going through far too many projects that have exploded quickly and have always gotten to a point where I had to rewrite my code (yes, rewrite!) because I didn't know any more what I was doing. This is an example of what happens if your design and code organization is bad (which it usually gets if you don't think about it before starting). Design is time well spent and can spare you a lot of headache! Second: There are two ways (that I can think of) to get started developing a game: 1. Bottom-Up-Development: Here you start by developing all the engines and their details and later put together everything to a game. 2. Top-Down-Development: Here you start by writing a game prototype focusing on the game as a whole using only *extremely* basic engine features (in fact just as much as you need to "play" the game). For example: don't care about animations - let your characters be cubes moving around etc. You implement details later. I would say the second is easiest if you want to get started quickly. I say this from my own experience and because I know it's a common way to do in game studios during a preproduction phase (but not only for the get-started reason). The prototype does not have to form a basis for the finished game - that is you don't have to build your game extending the prototype code (although you can probably do a lot of cut and paste work). Except the advantage of getting something on the screen you will also probably have figured out what is the best way to design your subsystems and classes for the real game. Just remember to keep it as simple as possible or you will end up with a half-finished game as a prototype - which is not the purpose! The first alternative can have you get stuck on developing a single engine without getting anywhere with your game [sad]. It's a great way to learn a certain area of development, but it's a trap if you want to create a whole game!!! Don't forget that technology advances and that there will always be new things that you want to add to make your engine as flashy as possible - you are then stuck... I know I'm not the best of explaining things but if you have any questions please feel free to send a private message. Good luck!
  5. fortia

    GPUPhysics: Case study of ODE

    I have completed a quick case study of an existing physics engine (ODE). This gave me a better overview of how a physics system works. Up til now I knew how the details worked but not how they might work together in an engine. I got some things to think about now regarding how to make my GPU system more useful for more than just a dumb rigid body simulation (one of the main requirements for the project is the ability to communicate with other systems like AI and animation also running on the GPU*). * The project is a part of an investigation of using hardware instancing to draw agents with physics, animations and simple AI (group movement and decision trees).
  6. fortia

    Fortia: Game Architecture

    Exactly what I meant [smile]! My engine served for learning but it would take too long to have it completed to the point that you can actually create a game from it...
  7. fortia

    Fortia: Game Architecture

    Came across this article (written by Jeff Plummer) by chance yesterday while I was browsing through Ogre tutorials to learn Ogre. It treats a somewhat different architecture for putting together a game from subsystems such as graphics, physics, AI, sound etc. For people like me -- who have at *least* basic knowledge in most major areas of game subsystems/engines but no real experience of putting together a full game -- it is easy enough to use one single engine in an application (like when creating a graphics demo you don't use AI for example). But when you have an application rendering a scene and want to turn it into a game you get stuck!!! Where are you going to add that extra code? How to organize it? This is where you should have thought twice in the beginning regarding the architecture that defines how different subsystems work together. Jeff describes a very easy-to-implement, easy-to-extend and easy-to-upgrade architecture. I found his idea interesting and started a design and implementation of it today in my spare time (I did some major changes compared to his prototype). What I want the most of all for Fortia right now is to start development of the Game itself. So I think I'm going to move over to use engines created by other people (Ogre, ODE etc) for use in Fortia as well as Jeff's architecture. It will speed up the development significally compared to having to reinvent the wheel [smile] (especially since the team is very small). I learned a lot working on FortiaEngine and it has already served as a significant portion of my portfolio, but I have to be realistic if I want to get the game done!!! It also helped me understand Ogre and Nebula in just a few days! I just want to finish this topic with a tip to all people working on their own game: Consider reading the article and move to use finished libraries/engines! For me this took years to understand and I'm sure I'm not the only one! Like a big group among game programmers I have had the ambition to code most things myself! If you're not in this group you're lucky! [smile] Til' later!
  8. fortia

    Fortia: Game Architecture

    Came across this article (written by Jeff Plummer) by chance yesterday while I was browsing through Ogre tutorials to learn Ogre. It treats a somewhat different architecture for putting together a game from subsystems such as graphics, physics, AI, sound etc. For people like me -- who have at *least* basic knowledge in most major areas of game subsystems/engines but no real experience of putting together a full game -- it is easy enough to use one single engine in an application (like when creating a graphics demo you don't use AI for example). But when you have an application rendering a scene and want to turn it into a game you get stuck!!! Where are you going to add that extra code? How to organize it? This is where you should have thought twice in the beginning regarding the architecture that defines how different subsystems work together. Jeff describes a very easy-to-implement, easy-to-extend and easy-to-upgrade architecture. I found his idea interesting and started a design and implementation of it today in my spare time (I did some major changes compared to his prototype). What I want the most of all for Fortia right now is to start development of the Game itself. So I think I'm going to move over to use engines created by other people (Ogre, ODE etc) for use in Fortia as well as Jeff's architecture. It will speed up the development significally compared to having to reinvent the wheel [smile] (especially since the team is very small). I learned a lot working on FortiaEngine and it has already served as a significant portion of my portfolio, but I have to be realistic if I want to get the game done!!! It also helped me understand Ogre and Nebula in just a few days! I just want to finish this topic with a tip to all people working on their own game: Consider reading the article and moving to use finished libraries/engines! For me this took years to understand and I'm sure I'm not the only one! Like a big group among game programmers I have had the ambition to code most things myself! If you're not in this group you're lucky! [smile] Til' later!
  9. (Finally, after having been sick for more than a week I'm back and ready to work.) I have a lot to do on GPUPhysics now so i think that will be the center of attention for i while when creating the collision detection on the GPU. It's the hardest bit of all and I'm not as sure of that solution as of the integration shader i've written earlier. In short: it's a wild-card and can be done in a day or in two weaks, who knows? I also had some problems getting a test system up and running because it took too much time with basic stuff and hardly kept me motivated.
  10. fortia

    A resting day

    After having been away for a few days I was really tired and today I've just been playing games and resting. Who doesn't want to do that sometimes?
  11. fortia

    ChessGame: DirectX docs make me angry

    Also Microsoft recommends not to use DirectPlay anymore...
  12. fortia

    Conference

    I just came home from Stockholm where I was at the "ATI Nordic Technical Day" (thursday). This was a conference where ATI, Microsoft, AMD and Havok worked together and held different presentations for Game Developers. I'm glad I went there because it resulted in an employment interview with the Swedish game development company Avalanche (just released the game Just Cause). But I didn't have a chance to work anything... just conference and party... [smile]. And now I will have to put together some demos to send to Avalanche...
  13. fortia

    Joined zEROx on his project

    After some thinking I decided to join zEROx on his RPG project Elium. So I'm kind of freezing the development of my engine for a while. It would not be the first time [smile]. As a hobby programmer you have the choice to do what you like, at least with projects on which you are the only developer and don't have deadlines! That's life! But I'm going to finish the chess game now because it's such a small project (more like a demo...) and I almost got the network done by now. Didn't work on it today though because I tried to get the Nebula Device 2 Engine (the one that is used in the project I'm to join) to work on my computer. Really nasty process!!! And no tutorials or samples... but will have to learn from the existing game code.
  14. fortia

    Fortia: Help wanted!

    Now posted a thread in the help wanted forum here. EDIT: No longer searching. Joined zEROx on Elium.
  15. Ok... so I have some time over here. I think I will do some things on FortiaEngine now (I like to switch my projects when I get tired of the one I'm doing...). I think an introduction of the game Fortia for which I write the engine is in place... **************************************************************************** "-- You cannot see anything but light. Suddenly you realize that you are inside a deep mist or cloud and figures start to appear in it. Figures whose likes you never saw before, figures with a God-like appearence! They seem to be in a state of panick and look like they search for something. You are then transported into some kind of cave under ground and monsters are all around you, but... don't seem to know you're there?! They are celebrating! You see their leader holding up something, but you cannot see what it is. Everything gets dark. You hear people scream and the sound of soldiers fighting in war. But a calm voice seems to come from a point close to you... -- You wake up and realize everything was just a dream. But something inside you has changed, and when you look up you see a priest standing next to your bed. Things start to get strange when he tells you that he wants to teleport you to Fortia, the Gods' Reach... Fortia will be a roleplaying game in 3D where your main quest consists of getting back the stolen item to return peace and as well as solve the mystery of how it landed in the wrong hands. You can do this two ways: By becoming a priest and fight openly or by becoming a spy and fight in secret. But to be able to do the main quest you will need to gain experience by adventuring. This is done by exploring the world, doing quests and fight any enemies you may encounter..." ****************************************************************************
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!