• Content count

  • Joined

  • Last visited

Community Reputation

18826 Excellent


About Orymus3

  • Rank
    4th Place - The Week of Awesome 2014

Personal Information

  • Interests
  1. Spellbound: October Update

    Nice! For any engineer, falling in love with the feature is a constant danger. I a a fierce believer in JBGE (Just barely good enough). Everytime I start drawing up a new system on paper (something complex enough I need to put my thoughts on 'something') I always start with JBGE in caps at the top, to always remember that if I'm over-engineering things that do not have immediate value, then I'm doing it wrong. Games are different than other softwares in that developers are 'illusionists'. It is not necessarily about giving player choices, but the illusion of choice. If the illusion is good, then the illusion is real. If you hardcoded an AI in such a way that it plays well within your own game rules, then you probably can't SAY that this is a great AI, but you can let the AI show for itself what it can and can't do, and that might just be enough! There would be value in creating machine learning AI as part of an engine, as you could hope to decrease the feature's dev costs over multiple games, but as a startup, it is incredibly hard to rationalize this strategy (at least, unless you are VC-funded or something). Good job on cutting your losses here. Whatever you've learned from the experience has value, never doubt it, and whatever you do next will be in the game's best interest. So while it may feel like a loss (not actually developing the feature the way you intended), you've most likely made the right call here. I wouldn't say you're an idiot, it is however one of our biases as developers, and one we need to constantly keep in check (I've seen it first hand in developers from other industries 'migrating in', and it is a hard nut to crack, oftentimes creating so much frustration they eventually quit).
  2. Material for game developing

    Ironically enough, possibly 'never', but that truly depends on the type of games you intend on developing. Once upon a time, I was a GameMaker user (I think they were known as Animo back then) and little did I know the progress they had made until, a year or two ago, I stepped into a studio that actually intended on using the latest installment of Game Maker professionally (we're talking teams 5-10 people strong!). Some of these 'authoring tools' have really come a long way. In a way, Unity, one of the most popular engines out there, is a bit of an authoring tool in itself, and Game Maker (along many others such as Construct, etc.) caters to a crowd that's a bit less acquainted with the programming part by providing a visually 'simpler' solution. Granted, to a seasoned programmer, it probably takes longer to actually do something in Game Maker, but it enables non-programmers a chance to develop games from scratch without having to know about pointers, etc. A few super hits were made in Game Maker too (Hyper Light Drifter has exceeded the 500k units sold if memory serves, you can do the maths here!). It used to be that these authoring tools were a means to entertain a younger audience (rpg maker 2000 is a big offender here) and that they provided a fairly limited framework that could simply not be bent in any way shape or form. But those that survived found a market in the indie dev sector, and adapted accordingly. While authoring tools certainly used to have a negative connotation to it (as a kid's toy would on grownup turf) I find that, more and more, they provide viable alternatives to actually release games, and moreso than just on itch.io. Unity 3D actually dumbs this down quite a bit with built-in physics. Moving around an object could be as simple as: Rigidbody2D rigidbody = //get it either through GetComponent<Rigidbody2D>() or assign it through an inspector [SerializeField] or (I don't like that) use a public variable to see it in the inspector. And then, in your update method: private void Update() { if (Input.GetKey(KeyCode.W)) { rigidbody.AddForce(Transform.up); } } That's about the ugliest simplest implementation of allowing you to 'throttle' the speed of an object in a given direction. That being said, Unity has one of the largest library of GREAT video tutorials on their website. They take it slow, start with the basics, and work you down the path of becoming a great developer. If you can watch all of the beginner's lessons and survive, there's hope for you yet (and by then you can pretty much start making the 'simple' gameplay side of most games, though probably not yet a multiplayer FPS). It is a book about Game Design essentially. It does not cover (as far as I can remember: let me know anyone if I'm wrong) the programming aspect, but it is definitely worth a read. That and A Theory of Fun by Raph Coster (don't mistake its simplicity, elegance and playfulness for lack of content, it is probably one of the most influential books amongst recent publications).
  3. Material for game developing

    That's a tricky question. For programming, one would start with knowing how to actually code, but that tells you very little about the specifics of game development. Then, you have game design (Jesse Schell's book comes to mind) but that tells you very little about how to make it happen. A good gameplay programmer has quite a background under his belt. The technical know-how, the understanding of how to architecture their code (using 'contexts' for example instead of boiler-plating everything, etc.) Doesn't seem to fit your requirement here. On the other hand, using a tool like Construct might help you a bit. It is 'relatively straightforward' and will allow you to get results swiftly. At least, that'll bring you one step closer to understanding how things get made, all the while actually producing results.
  4. Starting Out

    Construct comes to mind. It may be limiting, but it is a powerful prototyping tool. I believe Game Maker 2.0 has made progress towards that as well (and has some of the most avant-garde 2D animation tools I've seen in a long time!) Don't judge before you try, I can confirm both are used professionally
  5. I would suggest to start with C++. It might take longer to get results, but it might also teach you a bit more about the 'behind the scenes'. Once you know one language, jumping to another gets easier (and incrementally easier with each successive change as you start thinking in terms of how this language is a bit like language A using some concepts of language B with a syntax that feels like language C). That being said, I abide by the rule that it's better to 'start somewhere', so either works. OOP in and of itself is a mindset. You could start making C++ and C# and break pretty much every precept of OOP, so make sure you teach yourself about that as well, not jut syntax and script.
  6. Dynamic world framework

    That's really 'just' a feature. A system that does a lot of the 'grunt work' and expose it to a middle-man, possibly in the form of Scriptable objects (unity) or similar. In and of itself, it is not a game, and it would be hard for people to fully grasp the potential of the system without having a game that adapts to it. My take on this is it would not see nearly as much use as rendering and physics these engine leverage, but you might find an asset on the Unity asset store that does something like this if you dig long enough.
  7. Unique Resource Ideas for RTS Game

    This is true of 1v1 games, but in RTS that have more players or AIs involved, this can be diminished by the fact perfect micro-balance is not a requirement. In the very rich world of Planets Nu for example (once again, a TBS, sadly), some species simply can't fight others as they're at a disadvantage, but they have ways to force an uneven fight, and other species will have an incentive to take care of the seemingly overpowered threat early on so that even an inferior species may end up a fierce contender for the win in the late game.
  8. Unique Resource Ideas for RTS Game

    I like to think that Dune 2 (the grandfather of all RTS) did this brilliantly. Unlike late C&C entries (inspired by this game), the harvesters were actually rather vulnerable and slow. In addition, you could lure a force of nature (the sandworm) towards one to have it 'eaten' without actually engaging much. Trikes and Quads could run from the scene whereas the harvester was as good as dead. As for balancing, I don't think this is any more a nightmare than balancing units. You're adding variables, but you're also adding tools. It all falls down to your process for analyzing imbalance, and dealing with it. Then, you need to have some heuristics in place about how 'easy' it should be for a particular species to have access to a specific resources, and balance unit acquisition accordingly, considering their actual offensive and defensive capabilities. If a species has a 'harder time' economy-wise (less 'hit-and-run, and more 'established' for example), you need to err on the side of natural defensive bonuses so that its moving army has more value when mobilized to protect a site than it has when actually attacking. This way, you confer it a situational advantage without making them 'OP' in open conflicts or offensive ones. Think of the Terran Siege Tank in SC for example, it packs a serious anti-ground punch against small unit groups or clustered enemies, but only while it is in siege mode, which prevents it from running amok. It is much trickier to use offensively (except if you're a combined arms expert) but provides a relatively straightforward bonus to forward positions. If you'd need to build a proxy base and needed ground support, you'd probably have a similar unit that's slow to move, require some 'investment' from the player to actually maximize, in such a way that it can't just steam-roll the enemy on an all-out attack. You get something similar in spellcasters, where they require a lot more micro, but when used well, are more efficient. If their skills are decently matched and tailored to such situations, then you can 'make it work'. The idea here is to have a holistic approach to unit design, making sure the units a species have (and more importantly don't have) support their economic and tactical doctrine. A particularly interesting game for this (although turn-based) would be VGA Planets (dated back DOS era, but with a reboot still active to date in Planets Nu). Each species has varying needs, some are fuel guzzlers, others lack Duranium by essence, and though they share relatively the same resources (although in wildly different ways sometimes), the fact they were built in such a unique way made for a particularly challenging experience. It is true the game is not entirely balanced (the Cyborgs are a threat in the early games for all other players) the devs have progressively managed to balance the most hideous quirks of the original design, while still embracing some of the imbalance (which somehow does not decrease the fun or sense of fairness, quite ironically). I'll agree the 'food system' used in Blizzard games (farms, supply depots, pylons, overlords) was always a bit lackluster and could be revamped in such a way where a 'static resource pool' could be used. I think some RTS games used it intelligently in the past, but I can't quite remember the names right now. I think there was a game in particular (mech commander?) where it would also directly affect the speed at which you could build units, etc. Kind of like a dynamic budget where, if you incur debt, everything gets harder to handle. In a more 'meta way', I'm a big fan of worker allocation systems (RimWorld, Dwarf Fortress, etc.) where, if you assign tasks poorly, certain things will 'never get done' due to priorities, etc. In this case, the resource is the priority allocation of the workers themselves, which is a bit abstract, but nonetheless critical.
  9. What game types require zero animation

    Some arcade titles only require circles and squares. I've nearly made best game of the month on Kongregate with 'prog-art' in one. Of course, not a very profitable game though!
  10. Weapon Design Document Suggestions

    I'll say this: There's nothing the document should or shouldn't have. A template would be about the worst way about doing game design (in my personal opinion). There are a few constants that are considered good practice in how the macro GDD is laid out (from general to specific, and then broken down) but everything else about the GDD's form and content should reflect the game product, and as such, is as infinitely variable as the amount of game concepts that could exist (close to infinite). If there are few weapons, and their stats are critical to how your game scales, you could include a short table of something like: NAME - small icon - Attack power - Price NAME - small icon - Attack power - Price NAME - small icon - Attack power - Price etc. If that doesn't sound like the first thing someone looking at the concept would need to go, probably best to leave it to an appendix. A solution that rises in popularity (and with which I agree) is to do as jbadams says - one pagers. You start with a GDD that is as concise as possible, giving the general ideal, and then breaking down the absolute CORE mechanics of how that game functions. Then, for every 'satellite' mechanic, and especially content, you make shorter side-documents. So, for example, the GDD would explain what weapons are, how they're used, how to equip them, etc. (possibly outlaying the UI ramifications of that) and THEN a standalone short document would be a list of weapons. If you work in something like Gdrive, the need might be less pressing, but for anything that's not inherently shared across the team during production, it really helps to be able to make 'localized revisions' (if only because the files will be less likely to be opened by other people, etc.) 'Satellite' (or secondary) mechanics also belong there because they're not required to 'get it' so people don't want to read about them until they understand what it is you are setting out to do, but by the time they do, they'll want to know how that feature works with 'everything else'. So a one-pager satellite feature does not just contain what the feature is, but also how it interacts with every other core feature. Hope that helps a bit.
  11. Unique Resource Ideas for RTS Game

    I like Dramolion's thoughts simply because they focus less on theme and more on function. Every RTS resource is more of the same and differs primarily in: - How it is collected - How it is amassed - How it is used - It's unique restrictions Half a lifetime ago, I built a framework for asymmetric economies in an RTS (forget Starcraft here!). Some species would use the 'same' resources, but in different ways (and not just for different purposes). For example, while one could harvest crystals from the ground, with a truck, and bring them back (C&C style) another would need to build a structure with an AoE that would progressively (and passively) burn crystals within a vicinity, Since it didn't matter to the latter what burnt (as long as something did to generate some energy) it became a decision of how to best 'burn' the other species' resources. If someone takes the lead, start burning THEIR resources instead, etc. Some species simply had no overlap. For example, one of the Ch'tau's primary resources was water, which 'nobody else cared about' (except for the fact it altered the land topography for combat). You could deny them oasis, but doing so with an actual economic gain was inherently inefficient. The Ch'tau's also turned out to have the weakest natural defenses, meaning it was best to attack them head on than to try and deny them resources (for which they needed complex logistics to begin with). Another interesting difference was that while some simply tallied their resources 'directly to the hud' ($$$ comes to mind), others had 'localized' resources. The crystals, for example, were stored at a particular building. Think of it like in Rimworld, where if you want to build something out of wood, you need to pick the wood from your stockpile zone (I'd bring up Dwarf Fortress as a better example, but very few people have the heart for its visual!) Technically, localized resources are as old as the RTS genre (in the way refineries refined spine in Dune 2 at least) but it has been fiercely under-used until Dwarf Fortress clones came about, and given these are less RTS in nature, there's an open spot there. So, I think it matters more how the resources are collected, how they're stored, how they're utilized, than what they are. But that's my Game-Designer-Hat speaking there
  12. Designing the optimum skilltree system

    Ori and the Blind Forest uses a simple solution for that. Like other games, it is tiered.
  13. You make the former, with the illusion of the latter. Everything you can 'visit' has a function. Everything on the 'outskirt' (may be visible but not even accessible) hints as the fact everyone has a house, but is purposefully left out of main gameplay. Somewhat similar to Lut Golein in D2.
  14. RetroPie Console

    I am running retropie on a RP2+ Works great except for N64 titles.
  15. WoA V - The Competition Thread

    Don't give up!