Program Planning?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Program Planning?

      Hey there, this is more of a General Question. I am a Geophysicist by profession, and took a few extra computer science classes, and programmed in my spare time. Did some game devving for fun, and it actually got my a programming job for the summer with a Seismic processing company. I have done some projects and things, but I am wanting to start a bigger project. I am the type of person who likes to have it planned out before I go into the project, is there any books or anything anyone can recommend? This book actually helps quite a bit, I think the architecture is very smart, and I used it when i made my small 2d game. The program I am wanting to make is something called full waveform inversion and it is quite a big, math heavy thing, so I am wanting to plan something with a good trade off of speed, but not be horrible to look at. I know this is a long winded post, but I am wondering if anyone has any suggestions.
    • It really depends on what you mean by planning, if you mean planning out the architecture of the code, I would say you can approach it in many different ways such as mind mapping, whiteboard, technical design documents, etc, however if you mean the actual project planning, I would recommend to you the book 'Agile Game Development with Scrum', although this deals mostly with team development, it has helped me with my own projects in the planning phases, I'll explain why.

      I used to plan out a project in one massive chunk of documentation which would take forever to do, and eventually end up obsolete by the time 20% of it was planned. This is partially due to what the book calls 'the waterfall method', if you plan out step A, B, and C, and implement your project in step A, B, and C, you could realize in step A that B and C need drastic changes, so now you have to re-document/plan everything. Taking a more agile approach will allow you to understand a general idea of what B and C entails, however you won't need much more than 'As a user, the waveform inversion interface needs a <insert need here>'.

      I highly recommend that book even if you aren't going to use it for games initially (or even a team), and it can explain how to make your project a success much better than I can here.
      PC - Custom Built
      CPU: 3rd Gen. Intel i7 3770 3.4Ghz
      GPU: ATI Radeon HD 7959 3GB
      RAM: 16GB

      Laptop - Alienware M17x
      CPU: 3rd Gen. Intel i7 - Ivy Bridge
      GPU: NVIDIA GeForce GTX 660M - 2GB GDDR5
      RAM: 8GB Dual Channel DDR3 @ 1600mhz
    • Whenever I plan a project I tend to take it from the top-down, starting with how the user interacts with the software at each and every moment.

      For a game, this will typically start from the very first screen, like a title screen or intro, completing at the main menu where they can start a new game or continue an old one.

      From each of those interactions I begin to create a major components inventory, such as a UI system that can lay out screens and define actions to take when certain inputs are detected, or a video playback system that can show my amazing prerendered cinematic sequences. As I imagine each and every interaction I drill down into what code I need to write and what other assets (art, sounds, animations, etc.) will be needed.

      Now, that said, it is extremely easy to take this too far, and attempt to create your software mentally down to the last semicolon. I know very well that for games, this simply doesn't work. I suspect that it can also be true for many other types of software. The reason it doesn't work for games is that a static screen or storyboard of any interactive game sequence can sometimes be unfulfilling once it is actually produced and installed into the game. For this reason, it can be extremely beneficial to create very rough prototypes, simply to test the idea without having to spend four to fives times the money and time to completely produce a fully shippable system.

      So, I suggest doing a shallow dive into the major subsystems of the software to realize the scope and skills required to build it. Then, identify the core components and/or components with high risk and build them in the roughest manner possible to prove the concept. In doing this you will likely bring into clarity many details of the subsystem and how it must interact with the users or other parts of the software that you never imagined before. This in turn will inform you if the prototype can be accepted and taken into full production, or it must be altered for another attempt, or an entirely different approach is required.

      Think of it like flying an airplane over unknown terrain at high altitude - and slowly lowering the altitude to discover more and more detail until you know for sure you are landing in a fertile area.
      Mr.Mike
      Author, Programmer, Brewer, Patriot