   Things I learned from game project
  I made a game for a class with some fellow programmers called Star Sagas and I think that it might be useful for others to know what I''ve learned.  The project didn''t finish but I learned alot and hopefully this will help others.  I thought it would burn me out on gaming, and it did, but I actually still want to.Here''s a couple of things I found, let me know what you guys think of them.1. Make sure that the requirements document is a good one. What that means is not just that its well documented but that the design of the game is actually a good idea for a game.  Its hard to get the motivation to code a game you feel won''t be that fun to play.2. Again in the design document and requirement make sure that every module and system and funcionality of the game is well designed down to the class name and method names.  On the way of game developing I tried to make the game a different game in the middle of it and so alot of this wasn''t documented and it made it hard to figure out if I could even make the game.  Also include special effects, algo, and networking protocols have it all planned out well and see if you and your team can actually do this.3. Special effects take alot alot alot of time, not just to do it, but to make it look right.  And special effects 3d takes alot of time as well, alot more than 2d. So I''d go for a game with very small amount of special effects and concentrate on gameplay than graphics and sound.4. The team I had were great they did everything I asked them too and created a great system.  The only problem was that I didn''t have a clear idea of what I wanted to do in the game exactly.  So make sure that the game idea would be fun to play.  So integration wasn''t a problem.5.  I used a game engine from a game tutorial and this was a pitfall. Though not to say it always is but this had weaknesses I didn''t find until I understood the code very well which is too late in time to find that out. Unless your doing a mod I''d say write your own one or buy a good engine like Torque where you know it works. And also it takes so long to understand what someone else has written.6.  I used directplay and I''d avoid making network games for your first game because I added at the last minute again and it created alot of issues. One it takes a very long time to discern and read up and learn how to use direct play. Second, directplay is probably used very well but it requires alot of time to learn and documentation to look through.  I''m not saying other people haven''t done it, but I did find that it doesn''t have that great of an error checker so your system can be working but working wrong and DirectPlay won''t tell you.  But again this adds alot unless you have 5 programmers I''d avoid doing it for a small team or if doing by yourself.7.  Make sure you and your team can do all the things proposed in the design document.  Maybe this will help some people down the road.  
quote:Original post by kenjin  2. Again in the design document and requirement make sure that every module and system and funcionality of the game is well designed down to the class name and method names.There are a variety of opinions on this. Some people believe you need room to evolve along with the program. I''d agree that it''s better to err on the side of excess rather than insufficiency.quote:5.  I used a game engine from a game tutorial and this was a pitfall. Though not to say it always is but this had weaknesses I didn''t find until I understood the code very well which is too late in time to find that out. Unless your doing a mod I''d say write your own one or buy a good engine like Torque where you know it works. And also it takes so long to understand what someone else has written.Writing your own engine from scratch (unless it''s simple or you''re very experienced) is time consuming. Sure, you''ll understand it thoroughly, but your company might be out of business by then.Jaimie Fristrom says it better [GamaSutra.com]quote:Maybe this will help some people down the road.Hopefully. Congratulations on your project, though incomplete, and on what I presume is your first postmortem! ;  IMO nr 2 shouldn''t be a discussion. It''s a FACT that you need to design everything down to the class before you start implementing something. However, that doesn''t mean you can design/implement in increments. For example you first design the core, then you implement the core, then you design the base graphics layer, then you implement the graphics layer, then you design the menumanager, then you implement the menumanager. Like that.Hacking away and make a diagram afterwards DOES NOT WORK if you work in a team, and often not even when you work alone. You have to have a clear vision of what the basic structure of your application is going to be before you can even begin implementing. If not, it''s bound to fail.This goes for all software BTW, not just games.I think the "room for evolving with the game"-statement comes from the GAME-FEATURES point of view, rather than the SOFTWARE-FEATURES point of view. For example, the manner in which you are going to do memory management has to be known the second you start implementing, while you might add smoketrails to rockets when you are almost done with the game. A good design will allow this.However, if I see people here say they need "room for evolvement", I can bet that they actually plan to hack a core (memory management, object interfaces, etc etc) together instead of designing anything.THAT''S BAD!!! (talking from experience here)Anyway, I agree on most points, except point 6. Take networking into account on the initial design. Use a virtual client-server architecture or think of HOW you are going to get your data on the line (and what data). The exact structure can be devised later ofcourse after a BETA, but in a design one has to take this into account. ;quote:Original post by Structural  IMO nr 2 shouldn''t be a discussion. It''s a FACT that you need to design everything down to the class before you start implementing something.Personally I only think you need to design down to the interfaces. Some other aspects seem to be best done with prototypes rather than pen and paper.   [ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost  Asking Questions | Organising code files | My stuff | Tiny XML | STLPort] ;  Then what are you building?You might get away with that for a high level application, but if you are making some specialised modules that others have to work with it''s necesary to communicate and certainly defend your class structure. I can come up with a very exotic class structure, but if I can''t communicate and justify it to the rest of the team it''s useless for any future team to work on it. Also, I will have forgotten what it all did in a few weeks anyway.Also it will affect your portability. If you have clearly documented and justified your structure you can take one module out and put it in another project with perhaps a few minor adjustments (or no adjustments, if it was designed properly).My main concern is portability, exchangability and justification of the structure.You might claim that it''s not needed if you work alone, or with a very small team, but it will definately help in the long run when you pull your old code out of your archive and plan to re-use it. I rather have a load of class diagrams and good documents before me, than a load of source and header files from where I have to extract interfaces from functions with cryptic names. If you want to complete something quickly you will only use once, then OK, I agree with you. But if the product you are delivering has a longer life cycle (months? years?), then you can''t permit to rely on memory.I''m now doing my graduation project, and I''m learning a whole new approach in the company I''m working in (I do my project in a company, that''s custom in the Netherlands). I want to shed a bit of light on how the development trajectory is.The prototype team makes a top-down design, meaning they start from a very high level and work down.Right, so it starts with the context diagram, you take your application, but it in one box, and draw all outside interactors with your application around the box and draw arrows to or from them. Interactors for a game this would be a keyboard, mouse, screen, harddisk, memory, 3D glasses, the operating system etc etc...Then you zoom in on your application, and make a package design. This will be the initial set-up of your software. Right, so, in the case of a game, designed from scratch, you get your core, a server system, client system, graphics system, sound system. All packages, each with a specialised function. Again, connect the packages depending on how the should communicate.With this package diagram you have to justify the initial design to your project leader/boss.Then we zoom in a bit further, and define for each package the modules. For example the package core has a memory manager, a timer, a task manager.And lastly we define the classes in each module. The memory management consists of a memory managed object and a manager class for example.The design is cyclic, so, when you designed the core, you can start implementing the core. Then in a lter stage you might design another module/package and implement that. But that more a matter of software engineering than documentation deliverables.After the prototype team is done it goes to the engineering team, and they make the REAL software using the design of the prototype team.Note that this is a rather big development team.So, in short, it depends on what you plan to do with your application and the code. If the life cycle is longer than memory lasts (ie: more than a few weeks/months) then it''s essential you make a detailed design. Else you might be able to get away with more global design (or none at all) with only interfaces, but I''m not a fan of this as I like to recycle/distribute every bit of code I write in the future.Also, I take back my previous statement of it "being a FACT you have to design everything detailed", and now state that it''s a FACT you have to write a detailed design IF you plan to write a decent piece of software. ;quote:Original post by Structural  You might claim that it''s not needed if you work alone, or with a very small team, but it will definately help in the long run when you pull your old code out of your archive and plan to re-use it.Nobody ever said documentation wasn''t needed. We''re debating whether all interfaces must be completely designed and implementations laid out - set in stone, as it were - prior to code being written. One of the problems of writing to specifications across a team is that one person may encounter implementation difficulties or external factors that make an interface change logical, but he may be bound by the interface contract others are writing to.Don''t release interfaces that don''t exist yet. Document the code, not the design (understand the subtle difference; the design is documentation, and documenting that is meta-documentation at best, landfill at worst).quote:I rather have a load of class diagrams and good documents before me, than a load of source and header files from where I have to extract interfaces from functions with cryptic names.How extreme. Function names need not be cryptic, and a good toolchain can draft a class diagram from a collection of source files. You can make it a requirement that all code be checked in/submitted with complete class diagrams.I read your description of how software development works at the company you''re doing your project at. Very nice. Very common. Yet commercial software doesn''t seem to be any more elegant, feature-complete or bug-free on average. So do those methods really help? Are they always applicable?I consider "Software Engineering" to be a misnomer. Creating software isn''t really an engineering discipline, and it probably won''t be for many, many years to come. Software development is almost a craft, but with engineering elements thrown in. Consequently, no engineering dogma should be adhered to rigidly. ;  >> I consider "Software Engineering" to be a misnomer. Creating software isn''t really an engineering discipline, and it probably won''t be for many, many years to come.Then you probably aren''t going to be hired anywhere for "many, many years to come."  Software Engineering is a very important skill. ;quote:Original post by Anonymous Poster  Then you probably aren''t going to be hired anywhere for "many, many years to come."  Software Engineering is a very important skill.Now that''s a dumb statement.Software Engineering being important has little to nothing to do with my considering it a misnomer, or my awareness of what it entails, or my proficiency at applying its tenets.Thank you for saying nothing of any value. ;quote:Original post by Oluseyi    I consider "Software Engineering" to be a misnomer. Creating software isn't really an engineering discipline, and it probably won't be for many, many years to come. Software development is almost a craft, but with engineering elements thrown in. Consequently, no engineering dogma should be adhered to rigidly.   No offence but that is wrong in a few ways.Software Engineering is needed for the large scale of applications today MORE than actual computer science people (your implementation programmers).The problem with software is NOT how to code it or implementing it, the largest problem today is the design and management of the project (which IS Software Engineering), the rest can be outsourced to the lower programmers if needs be B-) [edited by - Imperil on February 12, 2004 1:48:32 PM];quote:Original post by Oluseyi  Nobody ever said documentation wasn''t needed. We''re debating whether all interfaces must be completely designed and implementations laid out - set in stone, as it were - prior to code being written. One of the problems of writing to specifications across a team is that one person may encounter implementation difficulties or external factors that make an interface change logical, but he may be bound by the interface contract others are writing to.Yes, because firstly you got a clear overview of the structure you can determine dependencies and make your code much more structured. More structured code means it''s easier to support/update (can''t think of the right word here) your code in the future.Point is, not documenting before coding results in a mess of depencies and structure.But as I said, not everything has to be laid out before the first line of code is written. You can work your way down in levels of abstraction and for example design and implement package by package.But one should know what he is going to make before a line of code is written. It helps the structure of the application and thus the managability.There shouldn''t be any implementation difficulties if the structure is well thought out. At worst you got an external depency that isn''t working as you had hoped, but your own structure should work flawless if you designed it well.quote:Don''t release interfaces that don''t exist yet. Document the code, not the design (understand the subtle difference; the design is documentation, and documenting that is meta-documentation at best, landfill at worst).agreement++;How extreme. Function names need not be cryptic, and a good toolchain can draft a class diagram from a collection of source files. You can make it a requirement that all code be checked in/submitted with complete class diagrams.OK, it was a rather extreme example. But I wouldn''t rely too much on documentation generators, as even though you have a class diagram handy and function listings, it doesn''t mean it''s managable code.I downloaded tinyXml last week, and it comes with doxygen generated documentation. Even though I managed to do with it what I wanted to, it still took me more hours than I expected to work out the exact structure of the DOM. Ofcourse, it could be me just being daft  but I think that if it was accompanied with a clear documentation of the thoughts behind the structure I would have worked it out much quicker.quote:I read your description of how software development works at the company you''re doing your project at. Very nice. Very common. Yet commercial software doesn''t seem to be any more elegant, feature-complete or bug-free on average. So do those methods really help? Are they always applicable?Yes, it assures they can manage the code in the future and have a reliable, extendable design.Hacking away and say "if it works, it works" isn''t how it works . A company will try to recycle as much code as it can because that code has been tested, and is reliable, and doesn''t have to be rewritten. Less money that goes into developement there. If the software is poorly structured because the guy implementing the package didn''t know what he was exactly making, none of the classes can be detached from an old application and put into the new one.quote:I consider "Software Engineering" to be a misnomer. Creating software isn''t really an engineering discipline, and it probably won''t be for many, many years to come. Software development is almost a craft, but with engineering elements thrown in. Debatable. If you see the way the really big software factories make software (wanted to name Microsoft, but I better don''t), it''s hardly a craft. Every little detail is specified before they actually code. Even the exact algorithm for a function in pseudo code. No programming skill needed to code, just the discipline to follow the intructions.I guess software development varies in engineering as it varies in furniture building: You have the hobbyists, who make everything by hand and tweak and tune during production and the big factories, who first define every little detail and then mass produce.quote:Consequently, no engineering dogma should be adhered to rigidly.   Fully agree. Everything should be seen in context.Perhaps I''m being too optimistic about the value of documentation prior to implementation.I''ve been attending this school for nearly four years now, and the last year and a half I''ve really gone into this software engineering thing, and I really like it. I can make bigger programs now because writing down my design on beforehand helps me making a better structure. And the more detailed I go, the better managable my code gets. Last project I basically designed everything down to module level, and some things down to class-level. I now can extract whole modules and place them in another project without problems. This project I''m going to try to design down to class level and hope to be able to put a few classes in my archive.And if I encounter a bug, I can easilly track it down by going down the levels of abstraction and pinpoint it to a certain class.