Archduke

Members
  • Content count

    8
  • Joined

  • Last visited

Community Reputation

177 Neutral

About Archduke

  • Rank
    Newbie
  1. You're arguing two things here: that having the same core mechanism (in the Burgunian sense) means having the same game, and that having the same systems means having the same game. To the first, chess and checkers are both "physically moving tokens to capture enemy tokens and avoid losing your own", but they're different games. To the second, we would be missing information if we distinguished games only by the systems that facilitate them. Speedruns take place within the same systems as standard play, but the rules and win condition are changed, making them different games.
  2. Didn't mean to sound confrontational, if I did. Just exploring the topic, maybe something actionable falls out of it. That would be pretty jarring, and would be a totally different skill. Seems like that may be the answer, then. Adding games that practice unrelated skills is jarring, but adding games that use subsets of the broader game's practiced skills is less jarring. I wonder how different you can make the games before they start to feel disconnected.
  3. I don't think that's always true. In Soccer for example, penalty kicks are a different game included within the broader game, but I would expect most players don't find them very jarring. A handful of pinball games also have upper playfields with different rules. Are they only jarring if the added game requires different skills?
  4. Like people have said, the real reason is dev time. Extensibility generally wins out over variety. This might not be such a bad thing, though. If we look at it from a skill atom point of view, extensible systems allow us to build wider and more dense graphs of skill chains, as opposed to having a sparse graph of skill atoms. Having said that, there are sometimes justifications for adding extra games within a game. The game I'm currently developing switches between text adventure and 2d action/adventure sections. The main reason for this is because different parts of the story require more or less authorial control. Though it disconnects the skill chain, it's important to the overall skill that I'm trying to teach the player, and I return to each section multiple times and allow the skill chains to continue to be built.
  5. Outside of school, most of your learning is going to be from studying (or even copying) examples and looking up documentation. Figure out what you want to make, break it up into pieces, then look for examples of how to make each of those. Want to make a tetris clone? You need to be able to draw shapes, move them based on a tick, and clear lines. The first and second can be learned by googling around for a framework or library (JavaFX, Swing, LibGDX in Java), the third is a straightforward programming problem.
  6. I have noticed some odd speed issues while (supposedly) compiling small cpp files in my own project. The build output will say that it's compiling a 20-line file with few includes, but it will hang for 10-20 seconds, then speed through the rest of the build. Either things are being processed that it isn't outputting status on, or there are improvements to be made.
  7. Google around, there are flags that you can set to speed up compile times (at the cost of space for caching files). My build times are consistently under a minute though, even when I'm building from a clean project. Edit: Are you talking about compiling the engine itself from source? Of course it takes forever, engines are big and complicated. You shouldn't have to do it more than once in a long while, though.
  8. Are you sure that you enjoy programming? Programming as a job is very different from doing it in school or for side projects, you really gotta be fine with mundane problem solving to stick with it. Taking your current skills and working for a year might help you make a more informed decision. I can only speak to the U.S., but getting a 4-year Computer Science degree is really the best bet (if you're sure that you want to program). From there, you can either get a regular programming job and work on games on the side, or do games-related side projects during the degree and go straight into the games industry when you graduate. Also, you'll always have the degree as a fallback if you do go straight into games.
  9. If your issue is just keeping things organized, you could use a modified dependency chart. They handle huge puzzles really well, people have even built out the puzzle flow of entire games using them. http://grumpygamer.com/puzzle_dependency_charts   I like to use yEd to build mine. Kind of an old tool, but its free and handles graphs nicely.  https://www.yworks.com/products/yed
  10. If you want to be a better storyteller, find some resources on writing and start practicing writing stories. Not really a game design thing. For game design, you aren't going to find any courses, because it's too broad of a subject for short courses to be useful. Though, you can find people talking about their games and what they've learned. Search through Gamasutra's blogs and GDC's youtube channel.
  11. More game assets, like you said. Also, once you get those assets, do some more sub-sectioning (Game assets, characters, landscapes, etc). You have good art, but it's a bit hard to build a consistent story in my mind, since the things that I'm interested in are scattered around.
  12. I don't think we can really help much. It's your game, find what you think is cool and start building it!   If you get specific questions about whether a particular system or idea will work, then we can give some input.
  13. Goals and planning are really what keeps me going. I work full time as well, and the only thing that gets me to spend time on my game when I get home is already having a list of small tasks that I can work on and see progress.
  14.   They aren't neon green in World of Tanks, either. Most of the weak points are unknowable unless you do a lot of testing. Guess what fans did? They cared enough about figuring it out that they did the testing and made the pictures.   I think you're worrying about something that hasn't yet proven to be an issue. If you give the player enough fidelity of control and get them to care about becoming proficient at the game, they'll figure out the weak points. What you should be doing is giving them the tools to know that a hit to the weak point was more effective (either through visual cues on the model, or telling them how many points of damage it did).
  15. World of Tanks has the same system, certain tanks have small weak points in their armor. Here's an example, notice the small areas of green.   Whether players can actually hit the spots or not is just a matter of how your controls handle. If players are going to be asked to hit very small weak points, they better be able to control their attacks easily and precisely.