Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

125 Neutral

About Munchkin9

  • Rank

Personal Information

  • Interests


  • Steam
  1. I've got a problem and I'm not happy with the solution I found, looking for input. Commands, which serve as passable functions are stored into a queue that gets pulled from on regular intervals. Then they are stored in an EnquedCommand object and placed into a different queue. EnquedCommand contains some info such as where the command is being run from. The second queue is also pulled from on regular intervals. The objects that submit the commands and each Queue are kept separate so they have no easy means of communication. This has worked fine so far. The problem is I now have a command that is supposed to have the original object that enqued it do something when that command is run in the final queue. But it has no easy means of knowing when that happens. The solution I found is to embed a callback parameter into EnquedCommand and have that passed through the queues so that the callback is called when the command is run. What I don't like about the solution is that this requires a fair bit of refactoring and, so far, this is the only command that needs one. Seems like overkill. Are there any other solutions anyone can think of?
  2. So the problem you might have with the approach you took is being able to guarantee that a specific object has a specific module. So what would happen if a Crate Object was attacked but you hadn't given it a 'health' module? Sure you could go ahead and give it one but when you start entering things like: 0 health 100 damage reduction, into your modules just to avoid things crashing you are hacking your away around an issue. Like wise, Unity provides functions for searching and checking for components being present: SomeScript script = gameObject.GetComponent<SomeScript>(); if( script == null ) { // error out } But that, while good coding practice to handle errors, is writing special exception cases for things you should be handling a little more consistently and smoothly. Also if the above code was to appear everywhere an entity tried to attack another entity, you would have a lot of redundant code that is prone to introducing errors. So my suggestion would be to find some way of generalizing what actions can be taken in game. For example if you dictate something like "ALL objects that are physically present in the game are a subclass of class X" then you can place all your interactions that are possible in class X: hit, push, pickup etc. That way no matter what tries to 'hit' any object, for example, you know that it is an action that can be handled. Now of course you want to have every object act differently when interacted with. So that is where you could use the Strategy Pattern to 'attach' different behaviors to objects. Ask me directly later if you need help with the Strategy Pattern itself. There are other ways to solve this problem of course, as is the way with programming, but this would be my specific recommendation.
  3. For the levels themselves one option would be to create a class Level. And make different instances of that class for each level. This class could then keep track of all the information you want. So in a circumstances that you were to leave and then return to an area the information would still have been saved. As to how you organize keeping track of the different Level Instances that is up to you and the game you are making. If the areas represent sections of a map, a 2d array would allow you to access each Instance by its position on the grid. If the areas represent separate levels entirely than a simple array would do. If you know before hand how many areas there are then creating and naming each one on initializing the game might be preferable. I guess we just need more information about your game to give you more advice. But yes I agree with the above, definitely keep menu states and levels separate. You will avoid a lot of headache if you do, trust me. Hope this helped.
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!