View Full Version : Biting off more than you can chew
Ramperkash
02-05-2009, 06:34 PM
I'm wondering thesedays whether I'm biting off more than I can chew, or more specifically: is it worth going through all the trouble, programming in C++, programming from scratch (ok ok using the SDL graphics library) and testing my basic skills on too complex games instead of making the most simple of games to get to those complex ideas later when I'm more used to it all.
Programming language: I'm kind of lost on this one, I love programming in C++ since I'm pretty used to it by now, and I understand that it's 'technically' so much more powerful than using something like gamemaker. Ever since I came here though, I only saw people programming in gamemaker or XNA.
The thing is, I know it will save me so much time, but will I get the same feeling of accomplishment every time I 'finish' a game? and will I be able to do everything I want to do (and have plans for doing)? and is the efficiency increase worth it?
Engine based vs from scratch: I know much less about this topic, and I don't know exactly how to get hold of (or use) decent engines for games, but is it easy to customize those engines to tailor to your specific needs? and can't I write a basic engine and in the end just re-use it?
Game complexity: As any aspiring game programmer, I have some great ideas, that are extremely complex, or are thought of so far ahead, I don't even know if some of these things are possible with today's technology (not to mention a lone indie programmer). My problem here is, these ideas are the only thing that really keeps me motivated. It's fun to make the same ol' simple game, but only to a certain extent. What I really want to do is experiment with concepts and ideas.
Is it possible? or should I first start with the really basic stuff? Note: my current project is a RTS, basic in the sense of, I'm not pushing any awesome concepts into it, but complex in the sense of not making it grid-based, and building a gigantic object hierarchy that will be extremely convenient with larger games, but for the moment only complicates programming a simple game.
So if you made it this far, what I ask of you is this:
How am I supposed to start? (Considering I have technically already "started")
-Ramperkash
PS. My apologies for the wall of text :)
Necrolis
02-05-2009, 07:43 PM
I think alot of it depends on the ultimate goal of your project(and its capabilities to a very small extent), I do all my stuff in C\C++ and asm, cause I enjoy the coding and the complexity(and I like to learn as well, one can never know enough). I've started things using SDL and allegro, and for me found them very unrewarding in the "sense of accomplishment" field, even though my goal(s) where achieved. I think you'll found the best will be that which gives you something that makes you feel warm inside even though it isn't even near completion(else one might never get round to actually finishing it), my 2c anyways...
dislekcia
02-05-2009, 09:02 PM
The answers to your questions are all deceptively simple:
Programming language: I'm kind of lost on this one, I love programming in C++ since I'm pretty used to it by now, and I understand that it's 'technically' so much more powerful than using something like gamemaker. Ever since I came here though, I only saw people programming in gamemaker or XNA.
The thing is, I know it will save me so much time, but will I get the same feeling of accomplishment every time I 'finish' a game? and will I be able to do everything I want to do (and have plans for doing)? and is the efficiency increase worth it?
Use what you know. However, you will not be able to do everything you want to do in C++, more on this later.
Engine based vs from scratch: I know much less about this topic, and I don't know exactly how to get hold of (or use) decent engines for games, but is it easy to customize those engines to tailor to your specific needs? and can't I write a basic engine and in the end just re-use it?
Never re-invent the wheel. Ever. You can make as many arguments for learning skills by building engines, but that's bull****. You do not understand what a game framework (let alone an engine) needs until you've built an actual game. The way to learn is build games using all the tools available.
Game complexity: As any aspiring game programmer, I have some great ideas, that are extremely complex, or are thought of so far ahead, I don't even know if some of these things are possible with today's technology (not to mention a lone indie programmer). My problem here is, these ideas are the only thing that really keeps me motivated. It's fun to make the same ol' simple game, but only to a certain extent. What I really want to do is experiment with concepts and ideas.
Have you built Tetris yet? Try it. You'll learn a lot. Think that's too simple?
Mwahahahaha.
Is it possible? or should I first start with the really basic stuff? Note: my current project is a RTS, basic in the sense of, I'm not pushing any awesome concepts into it, but complex in the sense of not making it grid-based, and building a gigantic object hierarchy that will be extremely convenient with larger games, but for the moment only complicates programming a simple game.
So if you made it this far, what I ask of you is this:
How am I supposed to start? (Considering I have technically already "started")
-Ramperkash
PS. My apologies for the wall of text :)
I wouldn't aim at an RTS yet, not on my own. Just so you know. Also, no. No to the whole object hierarchy, just... No. Not until you've got some actual games done. No matter how small.
The basic rule of thumb is that you cannot start too small.
AndrewJ
03-05-2009, 12:05 AM
Hey Ramp. I was/am in a similar situation. I thought that I'd do something nice and "simple" (http://forums.tidemedia.co.za/nag/showthread.php?t=9027) to start out with, adding complexities later. Like dis said, start with something very, very, very simple. Simpler than what I am doing (also my first game - learn from my mistake! [And read my thread to learn from a few others])
Try the framework approach. I did mine from scratch because there is no framework that I know of to easily develop WM games, as well as doing it the way I am doing it puts all the logic in a DLL so that I can implement the front end for WM, then XNA and then WPF so that I can learn a little bit about the latter two.
Use what you know. However, you will not be able to do everything you want to do in C++, more on this later.Please could you elaborate on that one? I assume you meant "you will not be able to do everything you want to do easily in C++?"
dislekcia
03-05-2009, 01:47 AM
Please could you elaborate on that one? I assume you meant "you will not be able to do everything you want to do easily in C++?"
Nope. I meant exactly that: You won't be able to do everything you want to do in C++. Then I left it hanging so that people would ask me, this is a very common topic that we deal with at Game.Dev every year or so and I'd like to get everyone that needs to hear this in one go this time around ;)
When you try to learn a new skill, do you jump right into doing it the hardest way possible? You don't start trying to skateboard on a ramp designed for Danny Way or Tony Hawk. You don't start learning to juggle with knives. Game development and design is not just code, it's a lot more than that, insisting that you not learn the basics of building games and instead try to learn how to build a game and how to code a game at the same time, you're not going to get anywhere...
I know this probably sounds stupid, but the watershed is this: Do you have something to play? Yes or no?
It's very simple: Barring the fact that you don't KNOW exactly what you want a game to do yet (no matter how detailed your design, you don't have the experience to be able to take apart a game and know which systems you're going to need to write); As soon as you try to write a game AND an engine or framework at the same time, the game doesn't happen. Every game development forum or group online is littered with this story, it happens again and again.
It really isn't a simple "the more time you put into it, you'll do it eventually", no matter which low level language you try to use. The core experience of making something playable that is ALSO fun is the hard part. It requires so much learning and understanding that the more time you spend trying to write that pixel-perfect collision system or that fast way to scroll a tiled map is literally wasted time in the face of the important stuff you need to learn by building something playable. If your goal is to learn how to make games, then focus on the game and learn the art of building game systems when you're good at making the games that need them.
"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
-Antoine de Saint-Exupery
Kensei
04-05-2009, 12:30 PM
Have you built Tetris yet? Try it. You'll learn a lot. Think that's too simple?
Mwahahahaha.
QFE
I think my version of Tetris is gathering dust in my Dev Games folder -_-*
I second dislekcia's words on never re-inventing the wheel - there are some smart cookies out there that have made some great engines and frameworks; never be ashamed to use them. Same goes for tutorials, I think I spend more time doing tutorials than actually creating games from scratch, tutorials are great because they give you something tangible to work with - so you don't sit at a blank project and think 'Now what?'
So persist, you can do it :D
Korax
04-05-2009, 04:17 PM
Programming language
Use the language you know best, unless the language is not suitable for game development. I wouldn't put GameMaker and XNA in the same sentence though. It depends on your perspective. From your point of view you are thinking first "language" then "game" which you are thinking about the technology used before you think of the game mechanics. If your language of choice is C/C++ you'll be better off using OpenGL or DirectX. If your language of preference is a .NET language like VB.NET, C# or Managed C++ then its a no-brainer... XNA. XNA is to .NET like DirectX is to C++.
If your perspective is that of thinking first "game" then whatever "language" gets you to the answer quickly, then GameMaker and related are what you are looking for. I don't know anything about GameMaker, so I won't comment much on it.
Ultimately it depends on your project scope and your ability to take advantage of the required technology/language. Don't under estimate XNA though. It won't have the performance that C++ have, but the benefits outweigh the issues. I think .NET/XNA are now at the performance stage (software vs hardware) where C/C++ was at back in 1998, thats if its not beyond that already. Relatively speaking.
Below is a screenshot of a project I'm working on thats pure C#/XNA.
http://forums.sagamedev.com/files/attachments/090D42D3-94F4-4B07-B9F4-6102EC70BE6C/fs_q2bsp01.jpg
Large Shot: http://forums.sagamedev.com/image.aspx?imageid=197&type=attachments
Discussion: http://forums.sagamedev.com/topic.aspx?topicid=599
The full source code of this project will be released under the GPL license within the next week or so. Take a close look at that frame rate. This shot was taken on our test-rig here at the office which was a average to high-end machine back in 2004. I would suggest you use C#/XNA. I had my reservations too.
Engine based vs from scratch
If you are planning on using C++, I would suggest using an opensource engine or buying an engine that satisfy your project needs. Using an engine or building from scratch is a double edged sword though, both have their PROs and CONs. If you are using C# it is very possible in decent time to build an engine from scatch.
The word "engine" is a very deceptive word to begin with. ANY game has/is some sort of engine, nomatter how complex or simple your game is. The real thing to look out for is the complexity of the project and you need to ask yourself: Is the engine that runs the game you are designing tailor-made for the conditions required for your game, or are you trying to make it too generic to cover issues thats not present in your game.
Game complexity
The one fact you DO know is you are a lone developer. Try keep developent realistic. Your capibility to code the needed technology shouldn't encompass your (others?) to produce art/content for the game engine. The sum of a game project doesn't begin and end with the source code. Most projects trip on the artistic side and not so much the technicalities. Look at the opensourced Quake engines.. there are little to none actual original projects built on that proven technology after they were GPL'ed (forget the ageing-factor). What you should consider is imagining that tomorrow your game code is finished completely and exactly the way you intended... whats next?
dislekcia
04-05-2009, 05:01 PM
XNA is to .NET like DirectX is to C++.
Uh, no? That doesn't really make sense... XNA is XNA. DirectX is DirectX. Managed DirectX is written for .Net platforms. XNA is something completely different.
If your perspective is that of thinking first "game" then whatever "language" gets you to the answer quickly, then GameMaker and related are what you are looking for. I don't know anything about GameMaker, so I won't comment much on it.
This is the crux of the matter: Do you try to write technology first or try to write a game. To me and many other people, the point is moot. You have to have a game, so you need to write that part. The "technology" is irrelevant and doesn't matter without the game. Dice without rules are useless. Anyone who think that they should start writing tech before they have a game isn't ever going to have a game, no matter how neat their tech eventually gets. Anyone who thinks they can write tech and a game at the same time is simply deluded.
Below is a screenshot of a project I'm working on thats pure C#/XNA.
http://forums.sagamedev.com/files/attachments/090D42D3-94F4-4B07-B9F4-6102EC70BE6C/fs_q2bsp01.jpg
The full source code of this project will be released under the GPL license within the next week or so. Take a close look at that frame rate. This shot was taken on our test-rig here at the office which was a average to high-end machine back in 2004. I would suggest you use C#/XNA. I had my reservations too.
No offense, but 58 FPS with just over 1500 primitives? What's that engine doing most of the time it's running? There's no way you should be spending that much time rendering triangles, especially not with pixel shaders doing most of your heavy lifting like lighting. Where does nProf tell you your cycles are going?
What you should consider is imagining that tomorrow your game code is finished completely and exactly the way you intended... whats next?
Agreed. So what's next for you? When do we get something playable? ;)
Fruzz
04-05-2009, 08:28 PM
I think another angle to consider is where you want to go with your games career. If you want to get into one of the bigger more mainstream companies overseas then c++ experience is great because the majority of these companies seem to look for solid c++ knowledge. I got a job spec from an agent last week and the top requirements were adanced c++ and STL knowledge. So if thats your goal then you can't go wrong with c++.
I'd definately suggest a framework too. I tried building up an engine a few months ago but it really does take too much time. I've also done some stuff with allegro. Its pretty easy to get going with. That way you get to learn how to make fun games quicker...as people have said above :)
xyber
05-05-2009, 10:22 AM
dis, why do you always attack Korax on these forums?
Use what you know. However, you will not be able to do everything you want to do in C++, more on this later.
You still did not tell us what you mean with this statement and just went off rambling in the 5th post. I think the AAA titles out there are proof that you can do what needs to be done with C++.
@Ramperkash,
I'm wondering thesedays whether I'm biting off more than I can chew, or more specifically: is it worth going through all the trouble, programming in C++, programming from scratch....
It depends on your skill level. Someone who has never written a game before but who is a very skilled programmer can do this. When I got started with gamedev I was relatively new to coding, so I started with simple things like tetris and other such games. Still, it was easy enough to code and soon I was looking for ways to improve. At that time I was still working in Pascal and started learning and using ASM so I could get better graphics modes and finally I learned C++ and found the Allegro game library to create my games in. I've learned a lot of languages and technologies through the years and especially likes working with the Torque range of engines from GarageGames. Today I am lead programmer at Web&Circus SA where we primarily work with the Unity game engine.
Programming language: I'm kind of lost on this one, I love programming in C++ since I'm pretty .....
Yes it is way stronger than trying to make the game in gamemaker, but, it depends on your skill. Are you at that level to actually create the code.
If you want to go the XNA route you will have to pick up C#, but don't worry, its an awesome language and fun to work in. Seeing as you are starting with all with this you could perhaps even look into going with XNA and C#. There are frameworks and engines available for XNA but XNA is really easy to use as is. You will also learn C# which is a plus and there are even game engines using this as their scripting language.
The thing is, I know it will save me so much time, but will I get the same feeling of accomplishment every time I 'finish' a game?....
The feeling of accomplishment is to get it done, no matter how you do it ;) And its best to try get it done as quickly as possible, you will run into a point where you just don't feel motivated anymore and might drop the project. You have to seriously look at the scope of your project and your skill level and decide if it is within your reach to complete the project and with which technologies. Seeing as you made this post it seems that you are not aware of all the technology available out there. Perhaps we should be giving you pointers on that?
Engine based vs from scratch: ....
Is your game 2D or 3D? I know it is an RTS game and I belief there are some engines made just for that, can't remember the URL right now, but I'll look it up and reply later.
[edit] Just do search for 'RTS game engine' on google. You'll find a lot of into ;)
Game complexity: As any aspiring game programmer, ....
Anything is possible ;) Improve your skills and you will get there.
Is it possible? or should I first start with the really basic stuff?..
Seeing as you are not sure you obviously can't see the end of the project and how to get there. Start with something simpler if your current idea is out of your reach.
So if you made it this far, what I ask of you is this:
How am I supposed to start? (Considering I have technically already "started")
How much have you done so far?
dislekcia
05-05-2009, 12:07 PM
dis, why do you always attack Korax on these forums?
Sorry? How am I attacking anyone?
Managed DX and XNA are completely different beasts. I think I should know, having built engines and games in both. XNA is much, much friendlier and easier to use (I'm having that driven home right now - revisiting an older project in MDX), but it's still a technical API, not an engine that's ready to go from day 1.
I'm pretty sure that if Korax gives us his nProf results we can help with his engine. Either Aeq and myself (or Coolhand if he's got the time) could provide a lot of insight, seeing as we know where the pitfalls in XNA are - even if that screenshot's only bumping up against vsync and losing 2 frames to garbage generation due to the BSP traversal. There are some simple ways to fix that, like not using foreach statements in critical loops.
So, again, how is that attacking? "I'm going to HELP YOU RIGHT IN THE FACE, mother****er!" ;)
You still did not tell us what you mean with this statement and just went off rambling in the 5th post. I think the AAA titles out there are proof that you can do what needs to be done with C++.
Bugger. I thought I'd managed to get it out... Sorry, it's a bit of an abstract concept that I've been trying to put in words for the last few days. It goes like this:
To make a game, you need a few things. Everyone seems to think that one of the things you need is a system for the game to run on, the technology that makes up the game. This is true, but often people confuse the act of producing the game's systems with producing the engine's systems, probably because they're both programming tasks.
However, in reality that single perception of a "programming load" can be broken down into several things. At the highest level, it splits into game system (the rules, processes and eventually code that make the "fun stuff" happen) and the supporting system (the technical interfacing with hardware that makes things appear on screen, move around, captures input, etc.)
In simpler game media, like boardgames, this distinction being lost doesn't cause too many issues: The supporting systems aren't difficult to create seeing as all we're doing is using pre-existing technology to make things work... We'll use dice to provide random input into the game, cards to store event information, a board to track progression and tokens for resources, for instance. We don't have to invent how dice work every time, unless we want a 314-sided die, then we'd have to not only get it molded and cast, but we'd also have to calculate the number progressions and such to ensure even distribution (or not, if you wanted the ability to weight rolls).
The issue is that the game system has to come first. In a boardgame scenario, we pick and choose support systems based on what we need to make the game system work. In video game development we should do the same, but far too frequently we don't. Especially as indies or hobbyists just starting out. The lack of perception that the game system and the support systems differ means they get lumped together under the act of "programming the game" which means that there are no guidelines and goals to aid the creation (or picking) of support systems.
Now, the building of coherent game systems is a skill in itself. One that many people interested in game development don't necessarily want to learn (they like the technical production of support systems more), this is not a problem, unless they're stuck flailing around without a game system to base their efforts on. Pick a project that you know of that didn't reach completion... Was there a solid game system there? Laid out, understood, playable in some form or another (even if it's just in your head via a design document)? I would hazard that while not all failed projects may not have had a game system (games can fail for a ton of reasons), every single successful game has a game system first and support systems produced to match.
So, starting off with the idea that C++ is all you need to make a game may be technically correct - you're right, studios do it - but it's a flawed model because the mental exercise of programming seems to sacrifice the game system for increasingly complex support systems 99% of the time. We've all seen that happen, right? Often, all it takes to change that skewing is to emphasise the need for a game system before people start on all the support stuff. The game elements can exist independent of the support tech, as we see in ports of games between platforms, boardgames built of PC games, etc.
There are many ways to produce coherent game systems, ranging from full-blown design bibles (which is the tool that allows large studios to produce AAA games without falling into the "single programming task" trap) to rapid prototyping or even abstract prototyping. I'm trying to point out that it's this game system creation that's the limiting skill in solo/hobbyist/indie game development, not the production of code.
I agree with your point that if Ramperkash can't see the end of the project, he needs to aim at something smaller. To me, that means that the game system isn't solid, if it was he'd understand what the completed game would look/play/feel like. So first step: Build that game system (I'd recommend rapid prototyping, it's the most organic method I've found because it lets people comment and give input very early compared to a design bible) and then when it's done, the support systems you'll need will be obvious and you can pick your tech from there.
01DT!m3r
05-05-2009, 01:08 PM
@ Dis : I completely agree with you , more often than not you can see large companies using other engines and code from other companies or previous code(Unreal Engine 3 ,Havok Physics Engine , Euphoria,etc).It is handy to know C++ but from a realistic view it would be more helpful for your project and future work if you learnt to use a specific Engine,Framework(XNA , Irrlicht,Panda3d)as you would then be able to realize your game with more time , money and stress saved . I mean with XNA you can always write your own class ,or what have you,to be able to add the functionality that you need. It's better at the end of the day to have a FUN-ctional game than a fancy way to render models.Cause I for one Don't find fancyly rendered models fun :) . Just my opinion not meant to hateful or anything , It's just what I thought on the matter :) Happy Devving
AndrewJ
05-05-2009, 01:38 PM
So, again, how is that attacking? "I'm going to HELP YOU RIGHT IN THE FACE, mother****er!" ;)LOL!
However, in reality that single perception of a "programming load" can be broken down into several things. At the highest level, it splits into game system (the rules, processes and eventually code that make the "fun stuff" happen) and the supporting system (the technical interfacing with hardware that makes things appear on screen, move around, captures input, etc.)
...
The lack of perception that the game system and the support systems differ means they get lumped together under the act of "programming the game" which means that there are no guidelines and goals to aid the creation (or picking) of support systems.
...
Now, the building of coherent game systems is a skill in itself. One that many people interested in game development don't necessarily want to learn (they like the technical production of support systems more), this is not a problem, unless they're stuck flailing around without a game system to base their efforts on.If you don't get it, what dis is trying to say is that there is at least one very subtle difference in what the developers (note: I didn't say programmers) are trying to do: code the "engine" (think of the literal engine in a car) and code/develop the "game system", which includes the UI (think of the rest of the car - the drivetrain, the wheels, the dashboard and the rest) There is something that the user interacts with - the game system, and there is something that powers the game system - the engine. It's still a car, it's still called "making a car", but there are two sub-projects that are inside that car.
Pick a project that you know of that didn't reach completion... Was there a solid game system there? Laid out, understood, playable in some form or another (even if it's just in your head via a design document)?Once again, if the game concept is good, it can be done in ADA and still be fun to play. Do the developers want the user to have a fun game, the code to be perfect, or both? The latter can sometimes be a tad difficult to do within "normal" resource bounds.
To me, that means that the game system isn't solid, if it was he'd understand what the completed game would look/play/feel like. So first step: Build that game system (I'd recommend rapid prototyping, it's the most organic method I've found because it lets people comment and give input very early compared to a design bible) and then when it's done, the support systems you'll need will be obvious and you can pick your tech from there.I understood the concept of my mobile game entry for Competition 21 (http://forums.tidemedia.co.za/nag/showthread.php?t=9027), I knew what I wanted it to feel like, I knew what I wanted it to look like, but I didn't know how to rapid prototype it. dis, how would you have rapid prototyped a mobile game for which one had to create the engine from scratch? I didn't want to use something like GameMaker because I didn't know how to use it and because I thought (wrongly, I now know) that to prototype a mobile game on a system like GM would be, well, just plain wrong.
I created (and am still busy with) my engine first so that I could use it not only for Windows Mobile, but for whatever front end I wanted. However, I am making progress on my MW UI. (now, just to tell Real Life to chill for a bit so that I can work on my game... :-)
Overall, despite what I did with my Mad Robot Maze project, I still agree with dis, prototype your work - experience counts a little bit sometimes...
microdot
05-05-2009, 01:54 PM
Interesting, the way I see it a guy posted a topic, everyone tried to help contribute to the thread with ideas and examples, Korax being one of the contributers, right after, he's ideas and performance of his personal project get slated for performing sub optimal? How does this make sense in a forum that advocates education of games development.
01DT!m3r > Irrlicht is natively a C++ graphic rendering framework. You wont last 2 minutes trying to get it running without a solid understanding of C++ and class structure for Irrlicht itself. There may well be wrappers for other languages, but the base of Irrlicht stems from C++, if a wrapper doesn't support what you need to do, you're going to get your hands dirty in C++ code.
Dis > You done some projects in XNA / an engine? Can we get an example or two? never seen these yet.
To the first poster, either way you look at it, game development can be achieved in a multitude of ways. Re-using exisitng tools or writing your own, you're either a game developer or an engine writer (and in rare instances both). Stick with something you're comfortable with, no one said you have to write your own engine either.
Torque3D, Unity3D, Ogre, Irrlicht and NeoAxis are worth having a look at. If you want to write your own asset managers, sound processors (or plug in existing ones) etc, look at Ogre, Irrlicht or NeoAxis, NeoAxis being the easiest. If you want a full featured engine at a decent cost, try Torque3D or Unity3D - both have multi platform support too, XBOX360, iPhone, OSX etc.
dislekcia
05-05-2009, 01:57 PM
I understood the concept of my mobile game entry for Competition 21 (http://forums.tidemedia.co.za/nag/showthread.php?t=9027), I knew what I wanted it to feel like, I knew what I wanted it to look like, but I didn't know how to rapid prototype it. dis, how would you have rapid prototyped a mobile game for which one had to create the engine from scratch? I didn't want to use something like GameMaker because I didn't know how to use it and because I thought (wrongly, I now know) that to prototype a mobile game on a system like GM would be, well, just plain wrong.
What you felt is simply a disconnect between the understanding you had of your game system and the ability you had to translate that into support systems. In your situation I'd have separated the game from the engine that needed doing, made sure the game ran and worked first, then drawn up a list of exactly what the engine needed to do and built it piece by piece (doing research as needed on specific subsystems or solutions) until it could support the game. The first part is a constraint-definition exercise, the second part is a pure programming exercise - not very different from a "normal" coding job. (That "normal" angle is probably why many people don't do it that way, they want to make the building of the game fun and entertaining coding)
Have you tried paper prototyping before you hit some sort of rapid framework? Use whatever you know that's simple to use and gives you results, even if you have to be there when other people play to interpret the rules. I know people that prototype game concepts in HTML ;)
For Mathstermind we first did a rapid prototyping session on paper, toying with different maths-based gameplay ideas. Then we moved on to a GM prototype that we kept polishing and throwing at user testing sessions until the game worked the way we wanted it to. Then I sat down and wrote everything we needed to support the game logic in Flash Lite and built the game on top of that... That was the first time I'd used Flash and the first time I'd worked for a phone, so I learned a ton and had to figure out new ways to implement certain things (our tree-based puzzle generator kept running out of memory, for instance). But because I knew exactly what the game system was, I could focus on getting the support implementation right without having to make the game work at the same time.
I created (and am still busy with) my engine first so that I could use it not only for Windows Mobile, but for whatever front end I wanted. However, I am making progress on my MW UI. (now, just to tell Real Life to chill for a bit so that I can work on my game... :-)
Overall, despite what I did with my Mad Robot Maze project, I still agree with dis, prototype your work - experience counts a little bit sometimes...
I would ask you a simple question: Do you know what a general game needs, in terms of support systems? The best way to gain the understanding you need to be able to implement support systems (at least, the best way I've found so far) is to build games on other people's support systems... Sure, sometimes you hit snags and can't do what you want, but that's when you learn the most about different implementations.
dislekcia
05-05-2009, 02:18 PM
Interesting, the way I see it a guy posted a topic, everyone tried to help contribute to the thread with ideas and examples, Korax being one of the contributers, right after, he's ideas and performance of his personal project get slated for performing sub optimal? How does this make sense in a forum that advocates education of games development.
Well then you're seeing it wrong. On this forum we maintain a healthy attitude and the ability to question anything, lest we fall into the trap of hubris and ego. If something looks like crap, we expect people to point it out. If there's a possible solution to a problem, we expect people to offer it up. If there's a way to make something better, we damn well expect people to do everything they can to make it reality... That's how Game.Dev works, further OT posts will be deleted. If this is a problem, take it to PM.
Dis > You done some projects in XNA / an engine? Can we get an example or two? never seen these yet.
Spacehack (http://devmag.org.za/articles/49-SPACEHACK/): XNA, DreamBuildPlay, own engine.
http://www.youtube.com/watch?v=N97PHIb7HCA
http://www.dreambuildplay.com/main/Top20.aspx
Molecules (http://forums.tidemedia.co.za/nag/showpost.php?p=53628&postcount=57): MDX9, built on proprietary Ovid3D engine.
These have been in news and local community events quite a lot, actually. Even, y'know, TV (http://www.youtube.com/watch?v=KWgQcp7lhJw)... This is why you should go to rAge ;)
Edit: On topic, these two threads that popped up while searching the forums should be helpful to this discussion:
What do you use to dev games? (http://forums.tidemedia.co.za/nag/showthread.php?t=2827)
Your current list of games to create (http://forums.tidemedia.co.za/nag/showthread.php?t=2199)
Kensei
05-05-2009, 03:49 PM
Please correct me if I am wrong, but isn't the point of making an engine to streamline some of the more repetitive tasks? In which case, you would need to KNOW what those tasks are before you can stream line them, right?
The whole engine vs. game thing seems to be kinda like chicken and the egg story. ^_^
More on topic: Most of the time, as Gamer_geek said earlier, the big game companies are looking for people who can program stuff for their engine, rather than for specific games. Hence why skills such as C++ are in demand in the commercial sector since most game engines are created using C++ (yes? No? Someone who does engine programming tell me)
But, and this is a big but, if you want to actually make games and get your stuff out there to the world, as dislekcia said, there is a sacrifice for making a kickass engine, usually at the cost of other elements of a game, such as storyline, gameplay, sound or even how long it is. You 'can' do both (make engines and make games) - but I prefer to just make the games and leave the heavy lifting for the frameworks I use.
Later, when my game prototype is working, I will return and see how I can optimize it and assess if it is viable to make into an engine.
:: fades into the background again ::
Fallen
05-05-2009, 03:49 PM
Programming language
Use the language you know best, unless the language is not suitable for game development. I wouldn't put GameMaker and XNA in the same sentence though. It depends on your perspective. From your point of view you are thinking first "language" then "game" which you are thinking about the technology used before you think of the game mechanics. If your language of choice is C/C++ you'll be better off using OpenGL or DirectX. If your language of preference is a .NET language like VB.NET, C# or Managed C++ then its a no-brainer... XNA. XNA is to .NET like DirectX is to C++.
If your perspective is that of thinking first "game" then whatever "language" gets you to the answer quickly, then GameMaker and related are what you are looking for. I don't know anything about GameMaker, so I won't comment much on it.
Ultimately it depends on your project scope and your ability to take advantage of the required technology/language. Don't under estimate XNA though. It won't have the performance that C++ have, but the benefits outweigh the issues. I think .NET/XNA are now at the performance stage (software vs hardware) where C/C++ was at back in 1998, thats if its not beyond that already. Relatively speaking.
Below is a screenshot of a project I'm working on thats pure C#/XNA.
http://forums.sagamedev.com/files/attachments/090D42D3-94F4-4B07-B9F4-6102EC70BE6C/fs_q2bsp01.jpg
Large Shot: http://forums.sagamedev.com/image.aspx?imageid=197&type=attachments
Discussion: http://forums.sagamedev.com/topic.aspx?topicid=599
The full source code of this project will be released under the GPL license within the next week or so. Take a close look at that frame rate. This shot was taken on our test-rig here at the office which was a average to high-end machine back in 2004. I would suggest you use C#/XNA. I had my reservations too.
Engine based vs from scratch
If you are planning on using C++, I would suggest using an opensource engine or buying an engine that satisfy your project needs. Using an engine or building from scratch is a double edged sword though, both have their PROs and CONs. If you are using C# it is very possible in decent time to build an engine from scatch.
The word "engine" is a very deceptive word to begin with. ANY game has/is some sort of engine, nomatter how complex or simple your game is. The real thing to look out for is the complexity of the project and you need to ask yourself: Is the engine that runs the game you are designing tailor-made for the conditions required for your game, or are you trying to make it too generic to cover issues thats not present in your game.
Game complexity
The one fact you DO know is you are a lone developer. Try keep developent realistic. Your capibility to code the needed technology shouldn't encompass your (others?) to produce art/content for the game engine. The sum of a game project doesn't begin and end with the source code. Most projects trip on the artistic side and not so much the technicalities. Look at the opensourced Quake engines.. there are little to none actual original projects built on that proven technology after they were GPL'ed (forget the ageing-factor). What you should consider is imagining that tomorrow your game code is finished completely and exactly the way you intended... whats next?
Jeez awesome work ;)
I have worked with the md3 and md5 format and I'm a big supporter of John Carmack's engines, would love to see more of your work!
I do agree that propriety engines are the way to go and also reusing an engine. But why not work in C/C++?
I'm behind XNA 100%, but what if you want to develop a game for the ps3, iphone, ds, wii etc? C/C++ is unfortunately standard at game companies. If you look at the community games stats you'll see that the XNA companies are really stuggling at the moment. People aren't taking XNA seriously yet. I mean look at the amount of managed games that have been published? Whilst guys just making mods for some of the big tiles (eg. portal) have been scooped up.
I do agree you need to know the other aspects of making a game, but working in the lower level languages will only be beneficial to you if you want to make a career out of game dev.
dislekcia
05-05-2009, 04:09 PM
Jeez awesome work ;)
I have worked with the md3 and md5 format and I'm a big supporter of John Carmack's engines, would love to see more of your work!
http://www.quake-engine.com - Korax's engine-related site.
The post you quoted also links to a forum topic on SAGD about what he's currently up to.
I do agree that propriety engines are the way to go and also reusing an engine. But why not work in C/C++?
What makes you say that? So far everyone that has spoken about developing an engine from scratch in this thread has mentioned that it's extremely hard and not something you would generally want to do to start out.
I'm behind XNA 100%, but what if you want to develop a game for the ps3, iphone, ds, wii etc? C/C++ is unfortunately standard at game companies. If you look at the community games stats you'll see that the XNA companies are really stuggling at the moment. People aren't taking XNA seriously yet. I mean look at the amount of managed games that have been published? Whilst guys just making mods for some of the big tiles (eg. portal) have been scooped up.
That sounds like an argument against developing entire engines and rather using existing frameworks to make your own takes on particular games? Sorta clashes with your previous point...
I do agree you need to know the other aspects of making a game, but working in the lower level languages will only be beneficial to you if you want to make a career out of game dev.
There's a lot more to developing on a console than simply using C++... Learning a language is easy. Knowing what to do with it and learning the hardware you're working on are much more important.
A programming language is a tool. Nothing more... Demonstrating a preference for a particular tool in all situations makes you inflexible.
xyber
05-05-2009, 04:15 PM
So, starting off with the idea that C++ is all you need to make a game may be technically correc....
heh, long reply ;)
Think I misunderstood what you meant with the C++ statement. Code tech side you can do it all with C++, obviously you gonna need design , dev environments, art, etc. But as a programming language it is more than capable.
dislekcia
05-05-2009, 04:30 PM
heh, long reply ;)
Think I misunderstood what you meant with the C++ statement. Code tech side you can do it all with C++, obviously you gonna need design , dev environments, art, etc. But as a programming language it is more than capable.
And no different from any other programming language in that respect.
No programming language, no matter how spiffy/fast/simple/clean/typed/dynamic will help you learn to make better games. Starting out thinking that all you need is your leet C++ knowledge and an infinite supply of caffeine to turn your game concept into Crysis is horribly misguided.
I don't get the obsession some people have for C++... Perhaps I should point out this simple fact: Learning C++ is easier than learning to make games. The hard part isn't knowing a syntax or being able to prevent stack overflows, that's for sure.
Fallen
05-05-2009, 04:45 PM
What makes you say that? So far everyone that has spoken about developing an engine from scratch in this thread has mentioned that it's extremely hard and not something you would generally want to do to start out.
Sorry, I stated this completely wrong ... what I meant is I am all for using existing propriety engines. I agree developing a new engine is too difficult and time consuming. If other people did it right ... why redo it?
There's a lot more to developing on a console than simply using C++... Learning a language is easy. Knowing what to do with it and learning the hardware you're working on are much more important.
A programming language is a tool. Nothing more... Demonstrating a preference for a particular tool in all situations makes you inflexible.
Exactly what I'm saying ... I don't want to get limited to XNA and the XBox ... I want to learn and use tools from other companies / other consoles ... that's why I believe in rather working in C/C++ where I am able to develop for any console and operting system. And as I am hoping XNA will become a new standard, in case that doesn't happen you have that background.
AndrewJ
05-05-2009, 04:58 PM
I do agree that propriety engines are the way to go and also reusing an engine. But why not work in C/C++?
What makes you say that? So far everyone that has spoken about developing an engine from scratch in this thread has mentioned that it's extremely hard and not something you would generally want to do to start out.It doesn't sound that way to me...
Anyway, to sum it all up: get the GAME part of the idea, the part the player cares about, sorted and then concentrate on the tech part of the idea, then plan, then get all hot and sweaty on your keyboard.
Agreed?
Necrolis
05-05-2009, 05:08 PM
[incoherant brain stream]
I think alot of people tend to lean towards C\C++ due to its over exposure and delusions of grandure(on thier side as well as the "marketers" sides), and the fact that XNA(atleast in my mind, never looked at it much so i'm probably wrong here) is xboxish teritory. At the end of the day the language should fit the game, not the other way round, why build memory managment systems when you game will gain no performance etc increase(and your just gonna copy paste it, struggle with it,and not learn a thing...).
but alot of this is subjective, as not everyones brain works the same way(nor do people code the way way either), all the advice in the world won't stop you from doing X if you really wanna do X, only the experience of succeeding/failing will determine your next step.
also these days you can get alot of the modules/systems ect that started as C\C++ projects for the other languages with ease, just look at Lua, so one isn't limited by availabilty of extendability, and alot of people tend to ignore that and just look at the core language/system/framework...
[/incoherant brain stream]
Fallen
05-05-2009, 05:10 PM
Jeez ... ok ... what I'm saying IS that you wanna make games.
- Other blokes already did it .. playing around with the ID engines, UT3 engine and their scriping etc. is available ... hell id provides the source and they both even provide models in maya and 3ds max ... you can even go download the marcus (gears of war) model for 3ds max from epic's website.
- Why not mod / reuse these engines and maybe you even get noticed by one of these companies? And if you want, buy the Orge3D licence or which ever you prefer ... all your technical work is done and it's top notch ... you just make the game.
I am agreeing with you okes ... focus on the game ... leave the tech to another company but stay in the standards and the mainstream technologies. These engines are unfortunately not written in c#. That's why I think korax's work is so awesome, he has done alot of research and effort.
AndrewJ
05-05-2009, 05:19 PM
I created (and am still busy with) my engine first so that I could use it not only for Windows Mobile, but for whatever front end I wanted. However, I am making progress on my MW UI. (now, just to tell Real Life to chill for a bit so that I can work on my game... :-)
Overall, despite what I did with my Mad Robot Maze project, I still agree with dis, prototype your work - experience counts a little bit sometimes...
I would ask you a simple question: Do you know what a general game needs, in terms of support systems? The best way to gain the understanding you need to be able to implement support systems (at least, the best way I've found so far) is to build games on other people's support systems... Sure, sometimes you hit snags and can't do what you want, but that's when you learn the most about different implementations.
By "support systems" do you mean things like menu structure and good UI practices? That's what I thought you meant initially with
Do you know what a general game needs, in terms of support systems? but then you said
is to build games on other people's support systems... Sure, sometimes you hit snags and can't do what you want, but that's when you learn the most about different implementations.
dislekcia
05-05-2009, 05:27 PM
Sorry, I stated this completely wrong ... what I meant is I am all for using existing propriety engines. I agree developing a new engine is too difficult and time consuming. If other people did it right ... why redo it?
Ah, undersood :)
Exactly what I'm saying ... I don't want to get limited to XNA and the XBox ... I want to learn and use tools from other companies / other consoles ... that's why I believe in rather working in C/C++ where I am able to develop for any console and operting system. And as I am hoping XNA will become a new standard, in case that doesn't happen you have that background.
To be dead honest, if you can only learn one programming language, there's something wrong with you. The methods of thought and reasoning that are employed while coding game systems are not exclusive to C++. An implementation of a polygonal edge finder is the same in C++, GML or Ruby. Network code has to perform certain functions and guarantees no matter what it's written in.
A programmer who cannot easily assimilate a new language given a syntax document and an API reference isn't a professional. There's no reason to think that knowing C++ will make you able to develop for any hardware, rather do a proper university course and learn the logic behind ALL imperative languages.
There's no mistique to C++, it's just a way to shunt data around and do maths. If you want special, learn LOLCAT.
I am agreeing with you okes ... focus on the game ... leave the tech to another company but stay in the standards and the mainstream technologies. These engines are unfortunately not written in c#. That's why I think korax's work is so awesome, he has done alot of research and effort.
I would argue that anyone that had made a completed game would have done just as much research and/or effort ;)
dislekcia
05-05-2009, 05:41 PM
By "support systems" do you mean things like menu structure and good UI practices? That's what I thought you meant initially with but then you said
Well, then you don't know ;)
A support system is anything that isn't about playing the game. If you take away all the support systems and exchange them somehow (say by translating the game to a boardgame, a text-only parser or a social party-game) then what moves between those two projects is the game system.
Typical support systems are things like collision detection, input handling/routing, graphics, resource management, etc. (By no means an exhaustive list, BTW) Sure, menus and UIs can become part of that support if you don't need them elsewhere in other systems, but then they're supporting the game's options that need to be set or altered. If that's done via a coin flip, a remembered rule in the player's head or a radio button, the game system doesn't care.
...
There's an interesting example: Tetris as a text parsing game...
The L-shaped block decends downward, long side pointing up.
> rotate block right
The L-shaped block spins to the right, the long side points to the right.
The L-shaped block decends another notch.
> look bottom
The bottom row has two gaps, one to the extreme left and the other exactly in the middle, 4 spaces from the left of the board.
The row above that has 2 filled spaces, one at the 2nd slot from the left and the other in the 5th slot from the left.
The L-shaped block decends another notch.
> move block right
The L-shaped block now occupies the 2nd the to 4th columns.
The L-shaped block decends another notch, it is now 3 spaces away from coming to rest.
> move block down
...
You get the idea ;) That "Tetrisness" that you're imagining there, that's the game system.
Fallen
05-05-2009, 06:01 PM
http://www.quake-engine.com - Korax's engine-related site.
The post you quoted also links to a forum topic on SAGD about what he's currently up to.
What makes you say that? So far everyone that has spoken about developing an engine from scratch in this thread has mentioned that it's extremely hard and not something you would generally want to do to start out.
That sounds like an argument against developing entire engines and rather using existing frameworks to make your own takes on particular games? Sorta clashes with your previous point...
There's a lot more to developing on a console than simply using C++... Learning a language is easy. Knowing what to do with it and learning the hardware you're working on are much more important.
A programming language is a tool. Nothing more... Demonstrating a preference for a particular tool in all situations makes you inflexible.
Ah, undersood :)
To be dead honest, if you can only learn one programming language, there's something wrong with you. The methods of thought and reasoning that are employed while coding game systems are not exclusive to C++. An implementation of a polygonal edge finder is the same in C++, GML or Ruby. Network code has to perform certain functions and guarantees no matter what it's written in.
A programmer who cannot easily assimilate a new language given a syntax document and an API reference isn't a professional. There's no reason to think that knowing C++ will make you able to develop for any hardware, rather do a proper university course and learn the logic behind ALL imperative languages.
There's no mistique to C++, it's just a way to shunt data around and do maths. If you want special, learn LOLCAT.
I would argue that anyone that had made a completed game would have done just as much research and/or effort ;)
I agree with you 100%. A programmer should be able to jump between languages and the the logic + math is usually easily ported to another language.
I use the same collision math in my c++ engine as in in xna engine .. the only difference is they way I load the vertices. In XNA I save it as a tag in the content processor whilst in c++ I get it directly from the model object.
I just want to defend the fact that working in C/C++ has alot of benefits, and to not deter any devs that want to go for that route. I know it is a harder language to work with, but directx/opengl will always be around and it's nice to have these skills.
I basically just mean ... if your writing something great ... maybe do it in a recognised engine and you just might land a job. These days it's so hard to get into game dev and the big time companies seem to be ignoring XNA. Which ****es me off ... but what can we do ;)
Ramperkash
05-05-2009, 06:19 PM
Thanks for all the advice, but at the moment I can't read it all, especially since half of it has become a debate (which I should've seen coming though). The thing is, I've wrote 1 game so far, it was really simple, and I have more plans for bigger types of games (like RTS's).
I started my RTS game, as a very basic game. There was no object hierarchy, everything was hardcoded etc. That version of the RTS game is now at the point that there are four teams (very basic ai for the three computer teams), only one type of unit, and one type of building, which you start with (you can't build more). I can make new units, but because that version uses no objects, I can't add them into the list of units efficiently.
I realized (wrongly maybe?) that I couldn't really go much further into this project without utilizing an object hierarchy, and implementing linked lists and the like... So I remade it.
The newer version is now at the point that my whole object hierarchy (except for technologies/upgrades) is complete, and I've put in units, and can move them around much more flexibly (linked list of target destinations yay) and can make new units even more easily.
Thats how far I am in the RTS now, and I feel I'm making good headway with it.
@Dis
Some of the things you said is nagging at me though: You talked about using only the things you need for a game, (or something like that, unless I misunderstood) but the problem with using someone else's engine is exactly that. You'll have implemented an engine that might have some things you don't need, and might lack some things you do.
Don't get me wrong though, writing a complete engine from scratch each time will get over the top, but thats why I'm planning to copy, paste and adapt the code I'm writing here for future games.
Also, I still don't get exactly what you mean with "C++ won't be able to do everything you need". Isn't it more like "C++ will always be able to do what you need, but might take way too long to incorporate"?
Last thing: I think I'm experienced enough as a programmer by now (not as a game devver yet though). I want to make games, and love thinking about how some mechanic would affect gameplay, or thinking about cool mechanics for games, but I do love the coding itself as well, and figuring out how to implement some seemingly basic mechanic etc.
Maybe I'll be one of the rare cases (Game maker + Engine coder)
Edit: Oh I even like making my own pixel art and animations for my games, though I'm still inexperienced there too
ShadowMaster
07-05-2009, 08:54 PM
I started my RTS game, as a very basic game. There was no object hierarchy, everything was hardcoded etc. That version of the RTS game is now at the point that there are four teams (very basic ai for the three computer teams), only one type of unit, and one type of building, which you start with (you can't build more). I can make new units, but because that version uses no objects, I can't add them into the list of units efficiently.
I realized (wrongly maybe?) that I couldn't really go much further into this project without utilizing an object hierarchy, and implementing linked lists and the like... So I remade it.
The newer version is now at the point that my whole object hierarchy (except for technologies/upgrades) is complete, and I've put in units, and can move them around much more flexibly (linked list of target destinations yay) and can make new units even more easily.
So if I'm not mistaken you are writing your own data structures? Because you sound awfully happy for having linked lists.
If so I recommend you look up the language's reference and learn the built in ones. C++ has STL and C# has something similar as well. Not programming your own has 2 benefits: Firstly you don't have to test them you are basically assured they are correct and secondly they have some features you might not even be able to implement.
This is true for any programming language and programming situation: Use the tools the language provide and only make your own after it has been proven that the tools provided are inadequate.
Believe me your time is much better spent learning what features the language has and learning when to use what feature. Don't fall for the guise that your home grown version of a data structure will be faster and thus better. Premature optimizations are the root of all evil.
Ramperkash
07-05-2009, 10:32 PM
True, (I know there are built in structures) but I decided to implement a linked list myself, firstly as practice (I'm doing Computer Science at uni as well) and secondly so I could implement only the things I need to use. (I'm also not exactly sure on C++'s structures, the course is in java)
The reason I'm "awfully happy" about the linked lists (besides from, "they work!") is because the simpler version of the game's units only stored single targets and destinations, which wasn't going to work for pathfinding.
Last thing: Most of the advice you seem to be giving is that I should implement existing libraries etc. and basically only define the details myself, which sounds a little too close to something like 'making a war3 map'. I kind of -want- to have my own system, (note I might use existing physics engines, or graphics libraries) I want to be able to say: "I wrote that game". My questions are mainly about the tools I'd use. (And yes, to some extent, existing engines/libraries)
Ehm, last, last thing: This is a learning experience, I'm writing this program to learn about how things work in the code of a RTS (for example) so I could later improve on this, or use another existing engine more efficiently.
ShadowMaster
08-05-2009, 07:04 AM
Ramperkash: People won't say the game you wrote isn't yours because "OMG You used the language's linked list instead of totally writing your own!!!1!!". The difference between writing everything you need yourself compared to using libraries that exist already is that by using the libraries will cause you to actually finish your game.
People won't care that you wrote everything yourself, they'll just say gimme your game I want to play it. The point dis is trying to make is that although it might be educational to go and write everything yourself, the truth is that you probably won't get to finish your game. Focus on making a game first if that's your goal, if you want to learn then it's fine to go play around and code everything, just don't be surprised if you never get to make a game because you wanted everything to be written by yourself. There is enough coding in a game other than systems programming to keep you busy for a long time.
dislekcia
08-05-2009, 10:48 AM
Last thing: Most of the advice you seem to be giving is that I should implement existing libraries etc. and basically only define the details myself, which sounds a little too close to something like 'making a war3 map'. I kind of -want- to have my own system, (note I might use existing physics engines, or graphics libraries) I want to be able to say: "I wrote that game". My questions are mainly about the tools I'd use. (And yes, to some extent, existing engines/libraries)
Ehm, last, last thing: This is a learning experience, I'm writing this program to learn about how things work in the code of a RTS (for example) so I could later improve on this, or use another existing engine more efficiently.
There is enough coding in a game other than systems programming to keep you busy for a long time.
This.
Why do people never listen when you tell them that they're effectively trying to learn to swim by jumping into the sea during a raging storm, off a cliff, in shark-infested waters? They'll be fine, they read a magazine about swimming once... Sculling around in safe pools first so that they can find the joy of swimming, maybe take a couple life-saving courses, that's always "beneath" them somehow :(
Ramperkash: Good luck, you're going to need it. I hope you have a really high drive to learn all this stuff, because you're not making it easy for yourself.
Ramperkash
08-05-2009, 05:49 PM
It's not about what other people will say about my game... I want to know I made most of the things in (at least one) my game, but I understand what you're saying.
One thing I can say with absolute certainty though, is I've learnt a lot about how to make the basis of a RTS (and game making in general) by just trying to make it like this so far, despite barely having time to work on it.
FuzzYspo0N
09-05-2009, 06:18 PM
Good topic, amusing replies.
I dare go into anything thats been argued , hell im all for special olympics but i think driving an opinion into personal-choice valley is just unhelpful.
Programming language :
This one is up to you, and the project. And your boss. And your platform. And your skillset, etc. There is no definitive language, some are just more widely used (namely c++)
Engine based vs from scratch
Ramperkash, fire up the unity engine (just download the free trial).
Install it, go into #unity3d on freenode, and "start concepting". I rate, you could rapid prototype almost any kind of game in a matter of days. Within the trial period , 30 days, if you actually try to, you will be able to prototype a full working RTS game, with gameplay and full mechanics (and good looking graphics provided you have assets)...
At the end of this process, take a step back, and reask YOURSELF "that question". That question every single experienced developer with actual games behind their name is telling you the OBVIOUS answer to.
It boils down to the end goal, do you want to make games? Coolhand said once, "we are content creators, we make games." Just evaluate what it is you want to get out of the whole process, and see where you can get to.
I wish you luck with your games though, cant wait to see some playable demos.
dislekcia
09-05-2009, 11:26 PM
I've been meaning to give Unity a go for a while now. Just haven't had the time to leap into it... Probably bad memories from similar "web-3D" applications back when I was still in my first job.
Coolhand
10-05-2009, 12:08 AM
I did?
lol :)
Kensei
10-05-2009, 01:18 AM
I did?
lol :)
Shhh, Coolhand, go back to your cave and continue your role as all knowing hermit ;)
We will bring your virgin sacrifice soon.
::fades again back into the background::
Fengol
10-05-2009, 06:37 AM
Virgin sacrifice? I thought I was the Grand Vizier, only I can order virgin sacrifices. Off with her head!
Powered by vBulletin® Version 4.2.4 Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.