Game DESIGN
Blitz3D Forums/Blitz3D Programming/Game DESIGN
| ||
| Do you carefully design games before sitting down and programming? If SO, Do you find it helpful? Do you find it time beneficial in the long-run? Do the aspects of your game come together better? If NOT, Are you able to find motivation to continue your projects in their later stages? Can you program a complete game without having to write and re-write its code several times, in order to tie everything together? |
| ||
| Are you able to find motivation to continue your projects in their later stages? Can you program a complete game without having to write and re-write its code several times, in order to tie everything together? 1) these days, no, but thatl be the case anyway. 2) I rewrite things when they get messy- but with Supernova, its almost done and only on code revisin 19... i mean 1. :P |
| ||
| I usually make a basic frame of my game, such as an FPS with no story, one level, and just one gun, and then I start developing plots, models, music, etc. I find it useful. It's beneficial. And, yes, the aspects come together better. |
| ||
| I tend to have my idea, and then try to put something on paper (mainly so I don't forget it later). Then I code a couple of little bits to see if what I am thinking of will actually work (eg: pathfinder). I find that it is beneficial to have some design documentation, partly because I would forget half of the stuff, but also so I can get the project to look as close to the original idea as possible. Only once I've got something close to the design do I start to allow "feature-creep". |
| ||
| If you don't mind a broader answer... When I have an idea which is new to me and off on a tangent (for example, the idea of a 3D Solar System sim) then I'll just bang away at it any old how, but knowing that at some point I will probably decide 'yes, this is working' (or no, it's not) and know that I will have to stop, go back to the beginning and restructure and properly design the code. 'Proof of Concept' is an important, but can be a very quick, stage. |
| ||
| plan plan plan and as ipete says pie as well:) the olny thing you get from going headlong is problems honestly i know,,im starting from scratch and still havnt a clue...plan plan and pie:) 1: main character, decide what he has to do run,jump crawl,ladders, bad guys then model,rigg,animate and code all aspects 2: pess Escape for your head back but how do you plan a game ?... i think the old story board might be a way to go...but hell this is new to me so what do i know: btw:good question |
| ||
| I never have really carefully designed a game, but I do take time to dot down a brief outline of the story/gameplay and steal some images for concept art, I modify my so called 'design doc' as I go. With it, I can assess game engine and tool requirements. I have found that most of my programming problems have already been solved. With a little online research you can find a variety of solutions (sometimes better than you expected). You would be surprised at how many code snippets from other programming languages I've translated to blitz for my own needs. I save time, and learn in the process. Taking the time to lay out your game helps you identify the tools that are needed to build it. Using available tools definately increases productivity. Otherwise, you can find yourself stuck working on tools, not the game and eventually lose interest.. |
| ||
| i have a little different way of planning. i make lots of very small test programs of things i want to happen in the game. once i know how to do a particular thing, i store it, so when im coding the full thing, i can call back on it. |
| ||
| I design as much as i can on paper, test it out in theory and then set a frame to prevent "feature creep". I usualy have a lot of long design documents with a lot of theoreitcal situational testing to see if everything is balanced. Then i stick to the plan and try to focus on code only, otherwise i might have to rebuild a whole part at one point if i only change a single idea. |
| ||
| I have the hardest time coming up with a game plot... I start with an Idea, See if I can program that Idea.. Then Keep adding... I then realise that there is not plot to the game and quit. What makes a game fun? I did a 3D Lunar lander game, where you were supposed to Land, exit the lander and do some excursion. There were bad guys roaming around tagging cargo containers... but that is all I have done. For the past month, I have been tweaking the code to make it run faster. Making the graphics a little better. Playing around with a little landscape editor designed specifically for the game. I just Need Ideas, for game flow and conclusion (A Goal). That to me is the hardest Part of Making a game..The Goal. and the stages to complete to get to that goal. Regards, Eric |
| ||
| Interesting replies. It seems that everyone has their own unique way of doing things that best suits them. I'm asking because I'm in the design process of a game I started a year ago. I started coding last Christmas break, and everything went slowly, but surely, until it completely fell apart some time later. Because I wasn't set on exactly what I wanted the game to do, my program didn't allow for new additions very easily. I never really got past the tile editor... once I tried to incorporate the tile editor into the actual engine, nothing worked properly. This time around, I'm trying to think of every single aspect of the game I want to create. I also identify any hurdles I might encounter along the way, so I know where I might get stuck or frustrated. I've spent the past week writing down ideas on paper every day, without writing a line of code. Since I'm going for a very open-ended game engine, it will require me to code in a modular way, so as to allow more of a "sandbox" game design. I've also been playing several games I've drawn inspiration from to see exactly everything involved in making my game. |
| ||
| This is interesting as this is the type of post I usually post in other forums ;-) Traditionally i'm a seat-of-your-pants kind of guy. I realize that at first your game probably isn't going to be that fun, unless you're very very experienced. So generally I start with an idea, jot a few notes, and dive into coding, making sure not to worry about graphics until I get something that works. Then I test it out if it's not fun I tweak it 'till it hurts ;-) I used to do this alot, until just lately I started on a new game http://www.games-afoot.com/touchtiles.html So I started by making a design outline and a mock screenshot, so far it's helped me in deciding what I want to do and how I want to do it. Although I haven't gotten to a point of actually making it a game yet. It's still in the early stages. Once I had an idea for a robotron/berserk style clone and I tried to code the collision stuff for it, unfortunately I got nowhere, so I figured hey maybe I *should* design everything I possibly could. So I spent days writing out everything that would happen in my game, how it would look, how it would act, etc. In the end I got so tired of planning it I didn't want to do it anymore. Moral of the story is - planning is good as long as it doesn't result in burnout. Currently with the game I mentioned above, i'm planning on an evolutionary planning process even though I did some design work early on. Basically once I get this into a working "game", i'm going to test it out, see if it would actually be fun. Then I will decide if i want to add anything, if I do, i'll write a new doc based off of the old one with my changes, then code it and test it and tweak it, and so on. It may turn out to be totally different than I started with. Another idea i'm toying with... I'm a nut for anything to do with retrogame development, and I mean actually reading and learning how the pioneers started. Most of them being programmers and not all into design and art (especially with what they had to work with originally) would code a cool feature they liked, like one would do with a demo effect in demoscene-style graphic/music/art demos, and then they would base a game off of it. Well I know there are several different things I don't know about programming, say pathfinding for instance - I'm actually trying to learn how to implement that right now, but say when i'm done, i'll build a game around it. Or basically any concept you don't know about programming, you create it and test it then attempt to build a game around it. It might turn out decent, but it's just an idea i'm toying with at the moment. |
| ||
| Gee, what a difficult question... Sometimes, what I do is I get out my notebook and begin planning things out. The first thing I do is make a flowchart to get everything laid out. Or, if I'm really confused, I'll sit down and make a list of all of the things I want in the game. (I've found that planning out what you expect in the game is of EXTREME IMPORTANCE -- otherwise you'll get "feature creep" and continuously add things and and things until you realize that you aren't getting very far.) Then, after the flowchart, list, and other basic planning, I'll begin sketching all sorts of items -- characters, weapons, landscapes, and collectibles. Then I attempt a sort of sketch of a level, which really sets up mood, lighting, and general look of the game. I can then branch off from there to other levels. After that, I switch hemispheres in my brain and begin working things out logically, because when I look at my plans, I generally think to myself -- HOW ON EARTH AM I GOING TO DO THIS? At this point I'll make a testbed so I can figure out how characters move and such. Then I go into more detail with levels and involved modeling. However, what's odd is that one time, I completely ignored this entire system, and created one of my best games yet just by sitting down and designing. Hmm... I'm still up in the air about which is the best. Personally, I would give much more planning to large games with multiple levels, but arena battles barely take any planning at all. |
   |