Game development
Blitz3D Forums/Blitz3D Programming/Game development
| ||
| Hi, I'm currently not doing programing, cause i need some tips on how to start game projects, i'm not sure what order game development starts, like brief, ideas and what not, please could anyone help me so i dont need to keep coming back for help, cause this should give me all the answeres i need. thanks. sorry if this message is mucked up. |
| ||
| Personally with me its: 1. New Idea 2. Write code 3. Find all kinds of problems with your first approach. 4. Throw code away. 5. Write new code. 6. Find all kinds of problems with your second approach. 7. Throw code away. 8. Write some ideas down. 9. Write new code 10. Throw away written stuff 11. Write more code 12. Find all kinds of problems with the code. 13. New Idea forget all about project you're working on. 14. goto 2. |
| ||
| 1.Rip off rob's reply. 2.cAn't be arsed to rip it all off. 3.Realise what a mistake this was and quickly and cooly walk away. Err seriously, Goober, just be realistic about what you can achieve(I.e don't sit down and start to write a real life version of Hal9000, the super intelligent computer from that space thingy set in the year 2001, I forget the name.) and then go at it. the best tip I can give once you do that, is to think ahead when coding, and if possibly always avoid hard-coding solutions in. Think of every problem/need as a series of smaller tasks. For example, you have a player, a alien and a car in your scene/game. Firstly, you want the player up and running. Do you code this directly? Cool right? It'll be up and running in minutes. Now, come the alien's turn..uh oh, you have to do it all again.. But, with the power of module-based coding you could instead group them all together, think of them as actors...Now you have an actor class, a type...object. Write once, work for everything in the future. If not? Improve it, and it's improved for everything already in and that will be in. Retroactive coding. :) I never used to do this, and always without fail projects died. Now, they still die, but it's not because of that...;) |
| ||
| Actually that's good advice there... Modular programming is by far the best way to go, my first game I wrote (and released) was bad bad programming and spawned from one idea to the next. Always try to think ok, I've got this player control code, what else could use this code? As Spaced said, don't hard code stuff, or at least try not to, it just makes life damn tricky if you need to expand or change. |
| ||
| 1. Find an idea 2. Write the storyline 3. Write down a to-do list 4. Check off everything you have finished. That's how I'm doing it. |
| ||
| Modular coding is great when you've already got a broader understanding of a project. However, don't discount the advantages of hardcoding things for learning purposes. If this is seriously your first project ... you won't be able to think of every solution before hand. There's no reason not to code it to get the logic flowing in your mind and just see how things work. I do that all the time and I get games done. Anyway ... that's all about code and you said you're looking for a beginning. Just get a notbook ... write down the general idea of the game with rules, screen prototypes, maps, controls, etc... That should get you started. |
| ||
| 1. Come up with new idea 2. flesh out the idea into a plan 3. start coding 4. get new idea 5. put old idea on back burner and begin developing new idea. 6. get another new idea 7. put last idea on back burner 8. return to idea #1 9. realize I could've done it better and start over. 10 get new idea 11 put #1 on back burner 12 play new game I bought 13 get new idea but forget it before i finish the game 14 get some sleep 15 read all the forums and post about how great a programmer I am but never actually complete anything 16 finish this list. |
| ||
| 1. Have an Idea, almost an obession 2. Create clear Goals 3. Code each. 4. Keep going 5. Dont feature creep 6. If a part is hard, break it down to smaller chunks 7. Create something you like and want to play. 8. Enjoy what u do 9. Be passionate 10. Get drunk often and Eat Pizza. Regards. Ion. www.arxspace.com |
| ||
| im a firm believer in Flow charts :) |
| ||
| Yep ... just did one to help me organize Leadfoot GT more tonight. |
| ||
| ckob: Same. That said, first thing I did with my current project was come up with a basic idea of what I wanted to do with it. Then I expanded upon it with a rather large document (something like 50 pages of mindless crap that only I could understand because it happens to use loads of terms that I made up during my last projects) detailing all aspects of the project, what would be required, and priorities. I code in a modular way, so everything is essentially a sub-object of the core (upon initialising the engine [yes, it's an engine] you are given the option to initialise its sub-systems, for example, the GUI, shader system, scripting engine, etc. so only what's neccessary is created- you can, of course, initialise sub-systems after the engine is initialised in the case that you need to start up one when needed). All of these sub objects rely upon information provided by the core system (which handles math, input, and the window), and typically they do not rely upon any other system outside of the core. Anyhow... back to how I organize my projects. After writing up the documents on what's what and goes where, I design a few flow charts to illustrate how the systems work, what their relations to the core/other systems is, and what they need to handle their operations efficiently. Then comes the part I enjoy quite thoroughly: coding. This consists of creating a project group in Protean and working on the highest priority systems first (the core being at the top, obviously- in the case of my latest engine, it goes core system, stack, math, string, buffers, and so on and so forth) until I get to the last and most insifignifigant piece of the project and finish it. Throughout these steps I revisit the documents and flow charts to see if there's a way I could revise them to make them better and more descriptive. Appropriately changing code where neccessary. It's a bit of a messy way of organizing a project, I think, but so far it has worked fine for this project. |
| ||
| Sorry for taking so long to reply, thanks for all the help, i'll be able to plan a game properly now, thanks :- Rob Farley SpacedMan Digital Fortress Jeremy Alessi TomToad Ion-Storm ckob Noel Cower thanks again, you all helped alot :) . |
| ||
| Keep everything type and function based - IMHO its the best way to write code that is : reusable modular easy to add to easy to tweak Example : say you have a car game. Make a type called 'tcar' Now you have a function to update the physics : Function Updatecarphysics() For car.tcar=each tcar do stuff next End Function You can now add as many cars as you like and update them ALL with a single function call Now think about AI. Your function becomes : Function Updatecarphysics() For car.tcar=each tcar If car\ai=1 then doAI(car.tcar);if the car is an AI player do stuff next End Function So you have to write a single AI function and all the AI cars will be updated by it. An approach like this means that when you decide to make a massive change in the direction of your game (which happens a lot) you only have to alter the bits of the functions that you don't like. So imagine you now want your AI cars to fire rockets - all you do is change the doAI() function and its in :) |
| ||
| "Goober" - I admit this is slightly not what you are asking but why not just do something that has already been done - a clone (preferably a popular clone). In a nutshell, you now have an end result - there is no reason why you cannot add your own touches. If you do a clone, you already know how the game will play and could (technically) pre-empt how it was put together. You can then just break down the gameplay. Something like Pac-Man is good. I think a clone is a good idea as you have a clear goal - it doesn't mean it is easy to do, you'll just know what you have to achieve. Plus, it will make it easier for you to get help - coz other people have done clones - so just pick a popular clone (pac-man, space invaders - you get my point). |
   |