Hello! I have an Associates in computer science and am months away from a bachelors degree in math. I have a moderate ammount of programming experience, and I worked two 6 month internships as a programmer in networking and numerical methods for differential equations. My math, particularly linear algebra and understanding of 3 dimensional space, is solid. I speak fluent C++, Java, C# and Python, and I understand newtonian mechanics quite well.
I have done a small ammount of game programming before on game-maker and some java applications. I read most of the OpenGL red book to learn about graphics programming, and put together a few demos written in C++ that used models created with Milkshape. I'm now 2/3 of the way through "Game Physics Engine Development" by Ian Millington.
I have a friend who is a skilled and talented at 3d modeling and animation with 3d Studio Max, ZBrush, and several other 3d modeling and animation programs, and we are interested in collaborating to learn more about game development.
I have heard a lot about "Unity", but as I would potentially like to pursue game development as more than just a hobby, and so I have been interested in creating my own engine at least once, even if its just stitching together a handful of existing libraries.
My goal is for me and my friend to learn about the modern game development process as much as possible.to gain enough experiance to potentailly work in the game industry.
Here are my current plans for the engine:
Language: C++
Platform: Windows
IDE: Visual Studio 2008
Graphics: OpenGL
Physics: Cyclone (developed in my game programming textbook)
3d model creation: 3d Studio Max
Sound: Irrklang
any other details are still up in the air. Such as DirectX for input/output for example.
I would be happy to hear everyone's oppinion on this plan, particularly as it relates to my goals for the project. Also, I'd be interested in hearing your thoughts on the compatibility of the features of my proposed engine. For instance, integrating OpenGL, the Cyclone Physics Engine (which is not super well known, allthough has been used in a commercial game) and 3d Studio Max.
Thank you all!
Game Development
So I see a lot of technical details but nothing about a game.
What's the game you want to make?
What's the game you want to make?
Author
So I see a lot of technical details but nothing about a game.
What's the game you want to make?
Me and my buddy have a variety of ideas but right now we're interested in programming a 3d fighter using an innovative control scheme I came up with. I feel like a fighter would not be overly ambitious. I'd rather not spill all the details here if that's not crucial information but something along the lines of Soul Calibur.
Alright, now we're talking ;-)
The problem with technical design is that it is never separate from game design. The purpose of a technical plan is to realize a game design - that's it. If you get lucky, you might find a technical design that can be used for many different yet similar game designs, and then reuse that; but that's a level of mastery that takes a lot of practice and experience to reach. You'll probably also find that the low-hanging fruit in that arena has already been plucked clean by people who make licensed engines.
Past that... it's extremely hard to critique a technical plan without knowledge of the game that you're aiming to create. Software development isn't like chemistry; it's not as if certain combinations of things will explode if you mix them together. (There are technologies that will pair easier than other sets, but it's more about how much plumbing you're willing to create to link them up than about whether or not it can be made to work - at least, most of the time.)
I can understand if you don't want to give away your ideas, but there's a couple things to realize:
One last thought: I find that too many people get into a sort of analysis-paralysis where they worry too much about "will this work" or "is this the best way" or whatnot. All the speculation in the world won't get your game made, so just jump in and give it a shot! If it turns out you did something suboptimal, you can fix that later. The great thing about software is that it is malleable. You don't really often get into situations where you invest months of work that turns out to be entirely wasted, for instance; if nothing else, you will understand your goals much better, and be able to restart with a leg up on the problem. Ironically, in my experience, for most of the cases where people waste a lot of time on something that doesn't pan out, the problem was over-analyzing to begin with! Stay nimble, stay flexible, and listen to that tiny itch that says "there's got to be a better way."
Good luck! :-)
The problem with technical design is that it is never separate from game design. The purpose of a technical plan is to realize a game design - that's it. If you get lucky, you might find a technical design that can be used for many different yet similar game designs, and then reuse that; but that's a level of mastery that takes a lot of practice and experience to reach. You'll probably also find that the low-hanging fruit in that arena has already been plucked clean by people who make licensed engines.
Past that... it's extremely hard to critique a technical plan without knowledge of the game that you're aiming to create. Software development isn't like chemistry; it's not as if certain combinations of things will explode if you mix them together. (There are technologies that will pair easier than other sets, but it's more about how much plumbing you're willing to create to link them up than about whether or not it can be made to work - at least, most of the time.)
I can understand if you don't want to give away your ideas, but there's a couple things to realize:
- Ideas are worth nothing. Execution is worth everything.
- Without knowing your goal, nobody can really help steer your towards getting there.
One last thought: I find that too many people get into a sort of analysis-paralysis where they worry too much about "will this work" or "is this the best way" or whatnot. All the speculation in the world won't get your game made, so just jump in and give it a shot! If it turns out you did something suboptimal, you can fix that later. The great thing about software is that it is malleable. You don't really often get into situations where you invest months of work that turns out to be entirely wasted, for instance; if nothing else, you will understand your goals much better, and be able to restart with a leg up on the problem. Ironically, in my experience, for most of the cases where people waste a lot of time on something that doesn't pan out, the problem was over-analyzing to begin with! Stay nimble, stay flexible, and listen to that tiny itch that says "there's got to be a better way."
Good luck! :-)
Author
Thank you for your response! That was all very clear.
Now when you said:
I agree, but as you say, execution is everything and I don't want to release my ideas freely into a realm full of people who CAN execute them. I generally discuss my ideas freely, just not online or with programmers.
In your second point, I said in my original post that "My goal is for me and my friend to learn about the modern game development process as much as possible.to gain enough experiance to potentailly work in the game industry" so I'm really looking for general advice on that. I want experience and I want to know some of the tricks and tools of the trade. I assume by "goal" you meant the specific game I'm working on, but at the moment I'm more seeing this as being a means to achieving that greater goal of learning. That being the case, I will accept advice on what types of goals I should set for the game itself.
As for critiqueing my technical design, I see your point. But I suppose I was mostly asking about if anyone saw my design as requiring a heavy ammount of "plumbing" as you put it. I mostly wanted to see if anyone had objections such as "Don't use openGL with 3dStudioMax, it will make your life hell!" or something to that effect.
Honestly, I am more used to people having strong oppinions about these sorts of things. I have received criticisms by many programmers in the past about choices of language, libraries and whatnot. Like when you go to them with an OpenGL problem for example and their answer is "don't use OpenGL, use DirectX". I'd just like to start on the right foot and not start barking up the wrong tree.
Now when you said:
[/quote]
I can understand if you don't want to give away your ideas, but there's a couple things to realize:
- Ideas are worth nothing. Execution is worth everything.
- Without knowing your goal, nobody can really help steer your towards getting there.
I agree, but as you say, execution is everything and I don't want to release my ideas freely into a realm full of people who CAN execute them. I generally discuss my ideas freely, just not online or with programmers.
In your second point, I said in my original post that "My goal is for me and my friend to learn about the modern game development process as much as possible.to gain enough experiance to potentailly work in the game industry" so I'm really looking for general advice on that. I want experience and I want to know some of the tricks and tools of the trade. I assume by "goal" you meant the specific game I'm working on, but at the moment I'm more seeing this as being a means to achieving that greater goal of learning. That being the case, I will accept advice on what types of goals I should set for the game itself.
As for critiqueing my technical design, I see your point. But I suppose I was mostly asking about if anyone saw my design as requiring a heavy ammount of "plumbing" as you put it. I mostly wanted to see if anyone had objections such as "Don't use openGL with 3dStudioMax, it will make your life hell!" or something to that effect.
Honestly, I am more used to people having strong oppinions about these sorts of things. I have received criticisms by many programmers in the past about choices of language, libraries and whatnot. Like when you go to them with an OpenGL problem for example and their answer is "don't use OpenGL, use DirectX". I'd just like to start on the right foot and not start barking up the wrong tree.
In my opinion, it seems like:
- there is already an idea for a game to make and probably how it would play
- both you and your friend want to learn as much as possible about game development and what it is like working in the industry and want specific tips and tricks.
Firstly I agree fully with ApochPiQ.
The game engine in the end of the day is just a tool to make a game. Ie without a game, there is no game engine. My advice is just start making the game. Open up Visual studio and start coding hehe. Get a window running, load up a 3D mesh. Get your friend to make the backgrounds. Get some sound in there. Maybe add input too. Just start doing something. By adding stuff in small steps, you would start to learn at a rapid speed. You will start to see how it all connects together. Some stuff that cant be thought, it can only be experienced. There will be a lot of mistakes and failures that both of you would fall into, then sources like GameDev can help you to fix them.
Additionally while working, you would realise that somethings you could do better (ApochPiQ touches on this at the end of the post). Eg your input class can be made more generic, and still work with the game. I bet, this will happen in other places. By following that voice in your head, by the end of the project I am quite sure that you would have a game and some generic classes/libraries. These generic classes/libraries can then be used for other projects. After 2/3 projects those libraries would be more polished and look like a game engine libraries.
Making games is challenging, hopefully by incrementing the game at small steps after understanding the existing code, some problems could be avoided. Just rush to get something on the screen (its not very motivating to work on something and all you can show for your effort is a black screen which you have been looking at for weeks...) then improve the code until you are confident with it to add the next step.
I would go like this:
- Get the widow running and graphics device
- Add simple gui + maybe scripting(for more rapid prototyping - get the stuff running in the script first then move to C++)
- Add background/terrain + meshes
- Add sound
By the end of the project both of you would understand more about project development, teamwork and your respective fields and how they connect together.
Sorry that I cant give you specific answers. Partially it is because they don't really exist. Nobody would really care what graphics library you have used as the end result is King. Also most studios probably would not use the low end graphics functions of Direct3D/OpenGL, rather they would be hidden by another layer. So in the end of the day it doesn't really matter. A prospective employer wouldn't really care if you can use OpenGL, he would be interested what projects you have made, ability to work in teams, willingness to learn new things and your passion for games.
PS Specific tips:
- comment your code as you would forget what stuff does
- it would be good to use some type of notation eg m_ (for member variables)
- keep it stupid simple
- take breaks, don't burn yourself (ie get so tired and sick of programing)
- figure out what motives you / how you function. eg waking up early in the morning. This would help to better structure your days and just being happy about yourself. => improve quality of your programming.
- work out from time to time
As stuff happens, you would understand better what kind of tools you need and mechanics such as proper game entity manager. But these things come with experience. Just hack it initially then polish hehe
So just start codding, it would be quite overwhelming but stick with it ;)
Good luck and all the best
- there is already an idea for a game to make and probably how it would play
- both you and your friend want to learn as much as possible about game development and what it is like working in the industry and want specific tips and tricks.
Firstly I agree fully with ApochPiQ.
The game engine in the end of the day is just a tool to make a game. Ie without a game, there is no game engine. My advice is just start making the game. Open up Visual studio and start coding hehe. Get a window running, load up a 3D mesh. Get your friend to make the backgrounds. Get some sound in there. Maybe add input too. Just start doing something. By adding stuff in small steps, you would start to learn at a rapid speed. You will start to see how it all connects together. Some stuff that cant be thought, it can only be experienced. There will be a lot of mistakes and failures that both of you would fall into, then sources like GameDev can help you to fix them.
Additionally while working, you would realise that somethings you could do better (ApochPiQ touches on this at the end of the post). Eg your input class can be made more generic, and still work with the game. I bet, this will happen in other places. By following that voice in your head, by the end of the project I am quite sure that you would have a game and some generic classes/libraries. These generic classes/libraries can then be used for other projects. After 2/3 projects those libraries would be more polished and look like a game engine libraries.
Making games is challenging, hopefully by incrementing the game at small steps after understanding the existing code, some problems could be avoided. Just rush to get something on the screen (its not very motivating to work on something and all you can show for your effort is a black screen which you have been looking at for weeks...) then improve the code until you are confident with it to add the next step.
I would go like this:
- Get the widow running and graphics device
- Add simple gui + maybe scripting(for more rapid prototyping - get the stuff running in the script first then move to C++)
- Add background/terrain + meshes
- Add sound
By the end of the project both of you would understand more about project development, teamwork and your respective fields and how they connect together.
Sorry that I cant give you specific answers. Partially it is because they don't really exist. Nobody would really care what graphics library you have used as the end result is King. Also most studios probably would not use the low end graphics functions of Direct3D/OpenGL, rather they would be hidden by another layer. So in the end of the day it doesn't really matter. A prospective employer wouldn't really care if you can use OpenGL, he would be interested what projects you have made, ability to work in teams, willingness to learn new things and your passion for games.
PS Specific tips:
- comment your code as you would forget what stuff does
- it would be good to use some type of notation eg m_ (for member variables)
- keep it stupid simple
- take breaks, don't burn yourself (ie get so tired and sick of programing)
- figure out what motives you / how you function. eg waking up early in the morning. This would help to better structure your days and just being happy about yourself. => improve quality of your programming.
- work out from time to time
As stuff happens, you would understand better what kind of tools you need and mechanics such as proper game entity manager. But these things come with experience. Just hack it initially then polish hehe
So just start codding, it would be quite overwhelming but stick with it ;)
Good luck and all the best
I agree, but as you say, execution is everything and I don't want to release my ideas freely into a realm full of people who CAN execute them. I generally discuss my ideas freely, just not online or with programmers.
Actually, that's probably the first time I can remember someone having a sensible and totally agreeable reason for not sharing their concepts here ;-)
In your second point, I said in my original post that "My goal is for me and my friend to learn about the modern game development process as much as possible.to gain enough experiance to potentailly work in the game industry" so I'm really looking for general advice on that. I want experience and I want to know some of the tricks and tools of the trade. I assume by "goal" you meant the specific game I'm working on, but at the moment I'm more seeing this as being a means to achieving that greater goal of learning. That being the case, I will accept advice on what types of goals I should set for the game itself.[/quote]
That's certainly a good approach to take; I suppose I glossed over that a bit hastily in my previous reply.
The fact of the matter is that the best way to learn about the process is to go do it. The best way to get experience is to go do it. You might be seeing a pattern here ;-) I appreciate the desire to make sure you're not wandering down a blind alley in your approach - that's a good instinct, and I certainly don't mean to say that you should stop worrying about such things! Rather, here's the bottom line from my point of view: you've got the right direction, now the next step is to start walking.
Honestly, I am more used to people having strong oppinions about these sorts of things. I have received criticisms by many programmers in the past about choices of language, libraries and whatnot. Like when you go to them with an OpenGL problem for example and their answer is "don't use OpenGL, use DirectX". I'd just like to start on the right foot and not start barking up the wrong tree.
[/quote]
People often hold strong opinions for weak reasons. The most experienced and insightful advice will usually seem borderline wishy-washy because it will be trying to take into account many factors, variables, perspectives, unique situational elements, and so on. By the same token, the best way to get experience is to embrace as many different approaches as you can, and learn for yourself when each is applicable and when it is not. This is stuff that is extremely hard to communicate verbally; I hope it doesn't sound like "go learn it yourself noob!" but rather "you will appreciate it much more firsthand than if you are simply told ahead of time."
There are two things that jump out at me about your suggestion, by the way:
- Why do you need a full physics engine in a fighting game? Simulating the physics of martial arts is extremely hard and beyond the scope of most physics engines. A hand-rolled solution that centers around convincing animation is probably going to look and feel a lot better than something that tries to recreate that experience analytically via mathematical modeling.
- If you use OpenGL for graphics, blending it with DirectX for input/etc. seems wasteful. There are other ways to get input, and if you have a DirectX dependency, why not do rendering with Direct3D? This is probably the only case where it seems like you're setting yourself up for building excessive amounts of plumbing.
Hope that clarifies things a bit!
Author
Hello gents! I've been busy with school and haven't stopped by in a while, but I've also been studying game-dev in my free time. Specifically, I've essentially finished my game physics book (pending a couple short chapters on miscelaneous topics).
I also learned a lot about skinning, and skelatel animations, and i've been using ASSIMP to load models. So I intend to build a rag-doll simulator as one of my first demos. My book builds one from boxes so I'm going to try to just extract the skelaton of an existing model, connect rigid bodies to the bones, and maybe a few spring forces on some of the joints.
Anyway, thank you for your helpful response, ApochPiq. I see your poin about DirectX so I'll definitely give that some thought.. not sure what other input system i'd use but I can explore that.
As for featuring a full fledged physics system in a fighting game, yeah my book emphasized that for specific types of games we would want to trim down the physics system (if its featured at all). Right now I'm just kind of keeping it handy while I'm still getting comfortable with its use.
I'm really glad I went through this textbook because I have had a lot of people tell me to just use a pre-existing physics engine and treat it as a "Black Box". But from what I'm seeing, there are so many design desicions in a physics engine that need to be tweaked depending on the particular features of your game. I saw an overview of a lot of the algorithms, various methods and pros and cons, so I think this will greatly benefit me.
I also learned a lot about skinning, and skelatel animations, and i've been using ASSIMP to load models. So I intend to build a rag-doll simulator as one of my first demos. My book builds one from boxes so I'm going to try to just extract the skelaton of an existing model, connect rigid bodies to the bones, and maybe a few spring forces on some of the joints.
Anyway, thank you for your helpful response, ApochPiq. I see your poin about DirectX so I'll definitely give that some thought.. not sure what other input system i'd use but I can explore that.
As for featuring a full fledged physics system in a fighting game, yeah my book emphasized that for specific types of games we would want to trim down the physics system (if its featured at all). Right now I'm just kind of keeping it handy while I'm still getting comfortable with its use.
I'm really glad I went through this textbook because I have had a lot of people tell me to just use a pre-existing physics engine and treat it as a "Black Box". But from what I'm seeing, there are so many design desicions in a physics engine that need to be tweaked depending on the particular features of your game. I saw an overview of a lot of the algorithms, various methods and pros and cons, so I think this will greatly benefit me.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
