Jump to content
  • Advertisement


  • 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. HilljackCoder

    "Research" System in 4X Games

    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. HilljackCoder

    The Infinite Game

    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. HilljackCoder

    Am i too young ?

      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. HilljackCoder

    Poking around Unity

    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. HilljackCoder

    Logistics in a Strategy Game

      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. HilljackCoder

    Anyone else run into the "idk what programs to make" issue?

      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.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!