Start of your projects
BlitzMax Forums/BlitzMax Beginners Area/Start of your projects
| ||
| Hi there, Im about to finish my very first game named Pong. Its just a learning project to get met going in BlitzMax. now its time to start daydream about my next game. I want to make my next project a bit more structured by creating some documentation for the project. My question is mainly how do you create documentation for the project? ofcourse you start with a list of all features you want to include but after that? do you map all your types and all your vars? what more documentation do you create? After the documentation part whats next? art, programming, making different test features? All advice is welcome on creating a structured project! Kind regards Vasquo |
| ||
| What drives you? Do you like being organised or do you like having fun? Complexity or simplicity? If you want to write games I think it is good to have a clear vision. Keep daydreaming and make sure you polish your first game so it feels finished, if you are 98% finished you are typically half way there (50% complete) when it comes to game development. |
| ||
| For me things unfold mostly as I go along. I don't make official documentation if nobody is going to read it other than me. I do write down a lot of ideas and to flesh out how things might work. But I don't get down to writing out specific variables and all that, that's what the program is for! I do add a lot of comments in the code, usually after each line. Almost every line usually ends up with a comment, and I put a descriptive comment at the top of each method/function. Since you did pong, how about following the path which things took, whereby pong sort of turned into space invaders/galaga by moving the paddle to the bottom of the screen and pitting you against multiple enemies. |
| ||
| Almost every line? Why? Do you use non descriptive variable/function/method names? Code should mainly speak for itself on what it does. Most of the time you don't want to know what certain code does, but why. Why? Because the "what" can be figured out by reading the code, not the comments :-). |
| ||
| I hardly ever use comments! |
| ||
| @ skidracer Well being organised causes me to finish something (that would be clear vision for me i think) + development is a lot faster. Early logic issues are resolved with proper documentation. (im a webdeveloper, so im used to work out documentation, but somehow im having trouble documenting my game idea's) @ImaginaryHuman Well my next game will be a breakout clone, not to far away from pong :) |
| ||
| Just my style, I guess. I like my code to be fairly neat and I like to know what each line is for. I do not subscribe to the `read the code to figure it out` doctrine - that takes time and it doesn't necessarily convey the full meaning of what's going on. Kind of like how you could read HTML to figure out what a page might look like but it's not exactly easy or obvious. When I come back to something months later, maybe on a bug hunt or expanding features, I don't want to have to remember or figure out what each part is doing. It really really helps to have those comments in there. Obviously you don't need a comment for `add two numbers together` type of stuff, but usually I use it to describe what's happening in the algorithm. Something like this: |
| ||
| Ok.. that kind of code needs comments. Here's some of mine |
| ||
| I used descriptive variable names whenever possible rather than trunkated achronyms and have no meaning when you are looking at the code... When there is question as to what is happening in the code then I'll add a comment. But getting back to the original question, if you are doing a fairly simple project you can get away with some sketches and a few written focus comments. Just something to look back at when your scope creaping. When the project starts getting larger though it becomes very important to have a better layed out plan. Depending on the size, that plan can be your key to success or failure. Additionally, If you are working with others on the code its a whole new ball of wax. Then you are going to need a project outline, story boards, a schema, and some kind of version control so start. |
| ||
| I'm not the best commenter but even readable variable names that are transparent when your in the code can be confusing 6 months later. The code is after all a mathermatical logical solution, but what is/was the problem and why did you opt for that solution, comments are great when they make understanding your code easy! |
| ||
| I describe everything of the game first as a draft, in a very general sense, then I grab the best parts of the draft and make a better documentation from it. I do this with each part of the game but in more detail after I finish making the general "map" of the game. But at this stage I am not worried about programming at all. Once I have the most important features of each part of the game in a nice draft, I grab another piece of paper and start writting the programing requirements, all in a very general sense, without worrying too much on how I am going to code it, that part I do it while I am programming. If I know I am going to need a method or type in the future, I just writte it on the code as a placeholder. The thing is, once you have decided on how the game is going to be, start working on it as fast as possible. I found that this is a very agile way of programming, doesn't leave time for analisis paralisis. The most important things to have in mind is to think that it is allways best to make re-usable code, so always think in modules. And also aim for getting to the prototype as fast as you can, if the game is not fun, no amount of good programming is going to save it. You have to balance this with the thought that you are going to keep building on top of your prototype though, but if you have this in mind it is not that hard to re-do parts of it to improve the prototype into a better game. Of course, experience is the thing that is going to help you the most, so don't be afraid to make things badly at first, be bold enough to make mistakes and learn from them, do not worry about making everything perfect, rather aim for production, the more things you produce, the more you'll learn in a short period of time, I'm thinking about making lots of games, the more games you make, the better games you can make in the future. I hope that helps. Good luck with your future projects. |
| ||
| I think in the hobbyist/indie world, its a good idea to cram as much of the game on one file as possible with most of the work done in a single function or two, ie brute force, and well documented. You are not writing big mmo blockbuster titles but just want to finish stuff, thats my experience anyway. |
| ||
| After you have done a couple of game you will start to find you are reapeating things, chunks of code... Now the trick is to put your Object Oriented / Pragmatic Programmers hat on and start to not just cut and paste but to build a foundation of functions and objects that you find you use a lot! Or to have a look around and see if someone has a module/object or framework that covers the features you need! Personally I found Grey Alien Games Framework very helpfull as he had already written a few casual games and his framework covered a lot of the stuff you need around and in the game, hi-score screens, login, menu... Unfortunatly he sold the writes to BFG when he started working for them, still there is the growing community framework, MGE, Playniax and TileMax are all working on similar frameworks! Why use a framework, well you can learn a lot from a framework and you also get a lot of the bits you would spend days or even weeks creating for the price of a AAA game! This is where the BlitzMax community is great as there is always someone working on something similar to what you need. |
| ||
| You are not writing big mmo blockbuster titles but just want to finish stuff, thats my experience anyway. I agree. In the old days I wasted soo much time organising my code that I never got anything done. |
| ||
| I find that if I don't write down on paper or type up in comments at the beginning of my source a precise organization for me to follow, I end up getting sidetracked and never finish what I started. Knowing exactly what you're going to do beforehand reduces the number of bugs you'll encounter and makes the tedious parts of the process go by much more quickly. For my current game project, I'm not going to release the source, so I'm applying a lot of acronymns that I always use. (for example, I always use xx and yy for going through an array of coordinates, dx and dy for drawing stuff at coordinates, rot always stands for a rate of rotation and ang for an actual angle, etc.) I don't comment a lot, but instead I keep my variable names very consistent. I've never gone back to look at code I've written since I grew out of my "newbie" stage of coding and wondered what any portion of the code did. (Yet I am truly lost when looking at anybody else's code, no matter how seemingly simple its function) However, in this game I'm making, moddability is a huge factor in quality so I've already begun minor documentation on it, even though the format's not 100% set in stone. This also helps me to remain concentrated on where I need to head. I think documentation is an absolute requirement for anything the user is expected to do - even the smallest things as immediately obvious game controls. However, if you're the only one who's ever going to see your code, just keep a constant system so that you can tell what any piece of code does in only a few moments, even if you don't comment it. Though if you do something new, then you should definitely use easily comprehendable comments. Also, if you're like me and value the fiished product over seeing the little things along the way, always start with the ground foundation and mundane code so you can focus on the actual game without worrying about coding these smaller things later. Here's what I do to maximise efficiency when I program: First, I spend no less than a week just coming up with a final technical concept on paper or in type and prototyping code. Second, I get the basics - type strucures and the like - coded so that I don't need to worry about them later, aside from minor bugfixes. Third, I get the gameplay functional. I don't know about others, but I always code the engine first, and then add the game content. I don't finalize or polish the game at this point, but I get it started and weed out all the bugs. Some of the media for the game (images, audio) gets done during this stage. Fourthly, I spend some time deciding exactly how the game should play and look and feel, if I haven't already. Then I get to work on the content, which is always the fun part, at least for me. Then, lastly, after I've finished the game, I playtest thoroughly to eliminate the last of the bugs and I try to get others to test it as well. I also polish the little things to turn it into a completely presentable game. Yea, I know. I haven't got a whole lot to show for this method, but that's only because few of my games actually end up seeing public release for one reason or another. |
| ||
| I agree. In the old days I wasted soo much time organising my code that I never got anything done. what he said ^^ |
| ||
| Yep... i tend to fly with it.. and if that takes an occasional recoding of parts to get it just right, then so be it :) Too much admin for me... reminds me of corporate projects. Games have to be more agile. |
   |