Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About hn17

  • Rank

Personal Information

  • Interests
  1. hn17

    Content of dungeons?

    Maybe simple riddles or logic puzzles? Must not be complicated (push a stone a platform -> triggers the opening of a door or the appearance of a treasure chest). Just to add more variety. And maybe secret passages or doorways, that are opened by not obvious buttons or actions.
  2. hn17

    Vulkan Resources

    Another list of resources: https://github.com/vinjn/awesome-vulkan
  3. Thanks Hodgman! It's reassuring to read that this is somewhat common. Thanks for the DIP example! I think I understand now how introducing a new layer that way could be used to decouple a class. I guess in practice SoC and SRP are not so much rules, but rather guidelines, right? I think that confused me quite a bit. Yours and frobs comments are helpful to put that in perspective.
  4. frob, thanks for your comment! I get what you said about Input Handling, Events and the "global structure instance" (I call these things "ContextObjects"), and I kinda use these patterns or techniques. But I have problems with splitting the functionality of the mentioned "RoadTool" into smaller objects with less coupling. I try to explain: When the player starts to build a road, the mentioned RoadTool has to use or query the Input to register mouse movements, the CollisionManager to check for existing geometry, the RoadNetwork to check for other logical constraints, the Scene and UI to give feedback. All these operations build basically one "logical block" to determine whether the road can be build. So far I thought the same as you say: "No matter how you do it, the various systems will always need to interact." and I coded it the way I described (depending on all these systems) and that works. I'm basically ok with that: the class uses and depends on a lot of systems, but the logic for the task of "building a road" is bundled in one place, and that's helpful for me when I think about the code. But then I read about the SRP and SoC and SOLID and ask myself: how would a good OO-Programmer solve this situation without deteriorating the readability and comprehensibility of the code? What is a good practical solution to this according to the OO principles? I have no idea how to do that, and since it's usually rather hard to explain this, I have also a hard time to find resources about problems like these. Maybe my brain works better with procedural code. Thanks again!
  5. I have a question about the "single responsibity principle". I'm a hobby-gamedev. I try to organize code into different systems, but I often end up with a few classes that know a lot about other classes, and I'd like to know if there is a way to avoid this. As an example: Let's say, I work on a citybuilder (like Cities:Skylines, but really crappy) and I want the player to be able to build roads in the game. To build a road a lot of different systems have to be used, for example: InputHandling: handling of mouse input (clicks, movements) to start and end roads and determine the position and shape of the road MeshBuilder: generate and constantly update a mesh for the road (or a mesh for a colored "proxy road" to visualize whether the road can be build) Geometry/CollisionHandler: to find closest roads/junctions for "snapping" and to check whether the new road collides with existing geometry RoadNetwork (a directed graph of all roads and junctions, used for pathfinding and more): to determine whether the road can be build (there may be some "logical" restrictions, e.g. only a limited number of roads can connect to a junction) Scene: to add/update the new Mesh/Model UI: to give feedback to the user in case of errors (in the sense of "You can't build here.") and more I have no problems to separate all that functionality into the mentioned systems or helpers. But then there is a level "above" all that where I usually end up with classes (here a "RoadBuilderTool") that use all these systems to implement the "stuff that actually needs to happen" = the logic of building a road, and those classes depend on all the lower-level classes. "Separation of concerns", "Single responsibity principle" and similar guidelines tell me that I should avoid that, but I don't see how to do it here. Perhaps Events/Messages could be used to avoid coupling here, but I think Events also hide the flow of the execution and that's not great. This is just one example of many. I manage to organize and separate code into different systems, until I don't, and I'm not sure what would be a better way to do this (or even if there is a better way). Thanks for advice!
  6. So, you regularly post spam in forums until you are banned? How about not posting "improperly" in the first place? THAT would be fair and useful behaviour on your side. There are a lot of things wrong with reddit, and I can understand that this ban made you feel like an idiot. On the other hand, if you regularly post stuff in forums that makes mods ban your posts, it's only fair that you should feel like an idiot for some time.
  7. hn17

    Game I'm making is not fun

    Hi, my two cents: - all you basically can do right now is run around and shoot, and shooting doesn't look fun. Instead of just a ball(?) show a gun on the player, show projectiles and let shooting have more impact. It needs to go !!!BOOOM!!!, things should splash around and be destroyed, a visible and audible reaction to the bullets and explosions. And show the aftermath, let bodies and gore lie around. Check this: - it doesn't look as if it's hard to evade the enemies. Perhaps add more types of enemies, a few faster ones, a few that explode close to the player, a few that can shoot, the usual stuff. Also let the player move into confined spaces, so that it's actually harder to avoid enemies. Good luck!
  8. FYI: There already is a game around called Nowhere by duangle: http://www.duangle.com/nowhere
  • 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!