Programming A Discussion on Making a Game

Discussion in 'Video Game Development' started by Drak, Dec 10, 2012.


Was this helpful?

Yes 3 vote(s) 75.0%
No 0 vote(s) 0.0%
File Not Found 1 vote(s) 25.0%
  1. Drak Wensleydale League

    Had an interesting chat with a friend over lunch. We were talking about programming and stuff like that since we're finishing up with finals, and she had mentioned that she had wanted to make a game before. She had gone through the trouble of getting ideas and details about the game, but when it came time to actually code anything the project seemed too massive and she had given up already because of the staggering nature of it. I wound up explaining to her some stuff and here's the closest I can remember to what I had explained:

    When you're making a game often you'll feel like you want to create something super massive full of content and goodies and whatnot, and thats fine. You should definetly write these sort of ideas down to have them for later, but when you finish put the document into a box and put the box away. Don't touch it. The problem is, if you set out to make a game and you have that huge project looming overhead you might get more pressure and anexiety on making it and wind up quitting because it seems impossible for one person to do alone.
    Really though, instead of taking on a project head on like that it's sort of best to think about game design as an RPG:

    Start out small with very minimal code, and eventually build up. Sort of like, you start out coding something simple like a program that displays a view to a user based on tile data. Next, you add the ability to control a camera that looks at parts of that map based on your input. After that, you add the ability to control said camera by more conventional input like arrowkeys and the like.
    Once you've achieved a successfully working camera and such, why not add a player to walk around? And maybe even attach the camera to the player so you can follow it? Eventually, you start adding little things like collision detection and terrain effects. Before you know it, you have an overworld engine. Now, simply save what you've got, and start on something new. Why not look at creating an actual unit, and giving it attributes such as gender, hitpoints, etc. Add some functions to the unit, like unit.equip() or such. Keep adding little things that each unit might be able to do, and eventually you wind up with a "living" character who actually can do things based on input you give it, and has numbers that it needs.
    It might seem like a lot of work, but if you just do small things and "what-ifs" then you can build stuff over time. And the way coding like this relates to an RPG is that you gain experience over time from coding small stuff, and eventually challenge yourself to write better and more complex code. You learn how to handle small issues that arise, and better yourself against anything you might run into in the future.

    Simply put, coding is like an RPG in the sense that:

    You are the player, who levels up by casting spells (code) to create stuff to eventually make it past the gate guardians (syntax compiler) into the dungeon to hunt monsters (programming bugs). Eventually, you defeat the dungeon and move onto another dungeon, repeating the steps of getting past the gate guardians and fighting monsters, while the entire time you are gaining experience and becoming a better programmer. The stuff you've conjured from your spells is materials to make equipment. But what equipment? The equipment is those ideas you've got stored in the boxes that you now have working engines and code to apply to, and the experience to fight any bugs that arise in the process of turning the ideas into a reality.

    So yeah, if you start with small stuff and slowly build on existing structures you wind up with some really awesome engines that you can apply to your ideas. Assuming you've made your code modular (as in able to be broken down into pieces) you can simply pick and choose what parts are required for any of your past, present or future ideas. Suddenly when you have the tools that you made yourself, you have the experience, know-how, and stuff to make your ideas a reality.

    Video game development isn't super-duper hard so long as you don't try to climb mountains with one leap - take that in steps and you'll do alright.
  2. ZippyDoo Monterey Jack League


    Seriously though I find this to make total sense. We have all been in the position where we have a big huge idea that we really want to do. It's impossible to actually go through with the idea without the dedication and skill to do so. All about taking it easy.
  3. God American Swiss League

    I like to think of programming like a puzzle with infinite solutions.
  4. Ren Limburger League

    I completely agree with the original poster. Anybody can talk about creating something and make as much plans as they want. But when it comes right down to it, you'll never get anywhere if you don't actually put any effort into creating that product. You shouldn't just plan the features of the game, you should also plan your technical structure.
    It's not just about wanting this feature and that feature, you should be able to know how it should be implemented and can you do it?
    Now, I hate Java programming, but I will use it as an example, because it's one of the best examples of an OOP language I can think of at the moment. Each class created makes up a specific part of the game. You have your main file which calls on those classes, such as a class for a shop, battle, or chat system. It is about steps, start off with something useable first, then polish it off with features and better code later.

    If it's your first time learning how to program or doing video game development, start off slow, try emulating other products that have already been made. Become comfortable with programming first and create something that you can say "Yeah, this isn't so difficult... I can definitely improve my skills from this point onward."
  5. jonyfries Casu Marzu League

    I would add that when making a video game start incredibly simple. Ren mentioned OOP programming, which is essential to making anything, but it is pretty much impossible to know how to design classes until you start writing them. The first video game I made was terrible code! When I started the second I knew better what concepts to include in different classes.

    Personally I believe it is best to never write anything complex or challenging structurally. If it is then you don't have the right classes built up already. To add that to the original post, the classes that you write are your gear. Once you have the right gear to create something it becomes easy.

    Oh, and know math. Seriously, its important.

Share This Page