• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

145 Neutral

About HilljackCoder

  • Rank
  1. To be honest, a lot of your time is going to depend on your design and how sound it is.  On my project (www.open-tactics.com, for the curious), much of the churn and work has been related to trying to hammer out a good game design, with the code necessarily following, and in some cases being ripped out and reworked.  For a game like Bloons, if you start with a good design and architecture, I think that the rest of the problems should take care of themselves.  I would strongly suggest keeping your code as modular as possible...make it so that you can change out one implementation with another.  Mike McShaffry's Complete Game Development goes into this in some detail, and there is a lot of additional information out there.  Don't fall into the trap of bad OO design, where everything is normalized to death.  Study up a bit on dependency injection...it will save you a lot of grief.  Good luck and remember that the best part of game development is having fun.
  2. This is an interesting idea.  I've always been a little bugged by the research systems in most 4x games.  Real-world R&D does not really depend on a static function to produce research results and there are far more "dead ends" than useful products created.    Another model to use might be the real-world ship "arms race" beginning some time after the Napoleonic Wars and ending with WW1.  Nations were scrambling to try to figure out how to build the baddest and best designs with emerging technologies.  IIRC, La Gloire was already obsolete when it was launched, made so by HMS Warrior.  So, you could conceivably achieve an incremental breakthrough and someone else's huge success could render it useless.   The other side of the coin is that the "arms race" doesn't necessarily factor in things like crew skill and training to the degree it should.  After all, the Soviets had better tanks at the beginning of WW2, but deployed them poorly and had not developed their armor tactics as well as the Germans did.  Maybe a de-emphasis on weapon quality in combat design and an increased emphasis on how well those weapons are used would also make sense.
  3. Nice introduction to the topic.  One thing I would stress is that it is possible for naive devs to create some real headaches if they are not careful about merging changes, especially when adding files to a project.  We had a couple of people at my day job who were unable to wrap their heads around this concept and were let go for this, among other reasons, after costing some time (i.e. money) to fix their mistakes.
  4. I quit reading when the author advised the use of the waterfall method and warned against iterative or agile development.  Assuming perfect requirements is a mistake I have seen repeated too many times in the dev world and games especially suffer from this problem as emergent gameplay (both negative and positive) can frequently emerge.  You can plan and design all you want, but you eventually need to start writing code.
  5.   Everyone starts sometime.  Do yourself a big favor and learn the fundamentals of programming and how software is structured and works, though.  Good coding and memory management techniques go a long way, too.  C++ is a complex language in many ways, and things like pointers can be hard to understand, but having some good tutorials helps.  It kinda depends on what you're doing -- we have a three person team making an indie game, and are using Unity.  My focus is on getting a product finished and out the door.  If you're looking to make a game, don't reinvent the wheel.  On the other hand, if you want to get into graphcis coding, then you're building a new sort of wheel.  Just depends on your focus.
  6. I've been playing with Unity for a little while now, mostly because I decided to take the jump into developing an indie game and realized that I can either spend time putting an engine together or spend time actually working on the design.  Also, I managed to browbeat a couple of coworkers into helping me with it in return for vague promises of undefined wealth, so the fact that it is easy to learn and work with means more can be done at the end of the day.  I'm curious to see where the limitations exist and exactly how it'll be to deal with once we get into the more unorthodox parts of the design, though. 
  7.   The single best (to my knowledge) implementation of logistics in a strategy game was in Gary Grigby's War in the Pacific.  While land supply was a little abstracted, supplies were otherwise loaded onto ships which could be attacked by land based air units, subs, etc.  In fact, WITP has been called a logistic simulator with a combat engine tacked on, but that models the actual war pretty well, too.    The big problem I see with having an excessive emphasis on logistics is that it can add a lot of cruft without really enriching the player's experience.  It can also be a technical challenge to make the AI decide to load up a truck and send it out to the troops.  In practice, it seems like the most common solution is just to allow units to track back a supply line to a friendly base or area.  Hearts of Iron modifies this by the infrastructure the supply line has to travel through -- bad roads = crappy supply.    OTOH, it might be interesting to see a game modeled around trying to supply an army and let the fighting be relatively abstract.  Given the problems that the Allies had with supplying their troops after Overlord, it would be an interesting challenge to simulate the Red Ball Express.  Maybe call the game Beans, Bandages, and Bullets...start off with a small tutorial like providing supply to the U.S. Army during the Louisiana Manuevers and work through scenarios like trying to supply the 6th Army during Stalingrad and so on.  You would have to plan ahead and request supplies based on what the war situation was looking like, too -- a defensive battle would mean lots of ammo and whatnot, while an offensive battle would need fuel and soldiers. 
  8.   This, to me, is the telling sentence here.  I put in a full day of coding at my day job, then spend 2-3 hours a night working on my game project.  I live, eat, and breathe code, some of it which is as complex as game code, albeit in a different way.  I would imagine that most other coders here tend to live the same way.  If you're trying to pick up game programming at the same time you're trying to get back up to speed on coding, you're honestly fighting two battles.  You also didn't mention what your background and former work involved, so that factors into the choice of tools to use.    I would suggest looking at using C#/XNA 4.0, along with Riemer's tutorials.  I have moved on from doing C#/XNA, but it was good to learn game coding techniques, and you can explore both 2D and 3D programming.  C# is a good general purpose language, too, and while MS seems to not be supporting XNA in the future, it's still good to learn with.  C++ is a whole other kind of beast and learning it while learning game coding techniques is honestly just asking to fail.   Start out with a Hello World sort of 2D game -- my first game was a cannon, guided by the mouse, that shot a cannonball at a moving target.  Simple, but enough to get a handle on input, game logic, game loop, etc.  Text-based games aren't going to help, and something 3D is probably too much at this point, so a simple 2D game is a good start.  You could even do a Frogger clone with a reasonable amount of work.