• Content count

  • Joined

  • Last visited

Community Reputation

725 Good

About NathanRunge

  • Rank

Personal Information

  1. Almost all comments go before the code they're describing. Small notes offering simple clarification may go alongside a line of code. The only comments that I place after a line of code are when I feel I need to swear at something at the end of a block.
  2. Firstly, no. Secondly, who is this actually for? Thirdly, IP law in most developed countries makes such a blanket pledge impossible. Fourthly, are you actually surprised that products which are in direct competition get shut down more than products that are not? Fifthly, do you know else wouldn't make money? If I ripped the next Nintendo game and gave it away for free. After all, if it's not generating money it couldn't possibly be damaging.   Game developers produce content for you to enjoy, and it is by their grace and their grace alone that fan games are permitted. Kudos to those that allow it, but don't act like you're entitled to do what you want with someone's work just because you enjoy it. 
  3. Actually here is an example of why a developer sometimes shouldn't lash out in public. Let's be generous and take this sample size of one and apply it to reach the reasonable conclusion that developers shouldn't, generally, lash out in public. Taking criticism personally has, at best, a tangential connection to this example. You can take every word of criticism as a personal affront to your dignity and still take it on the chin and maintain your composure, or you could disregard every word of it without pause and still react poorly out of intellectual arrogance or simply from pressure.   Most criticism isn't personal, and you shouldn't take it personally. However, some criticism is personal, and a good deal of criticism has personal implications. It would be far wiser to consider each piece of advice on its qualities, rather than make blanket assessments. When it comes to taking criticism personally it would be my advice to consider how equipped the source is to judge your personal qualities and their motivations for doing so. I do understand, however, that making such distinctions becomes more complicated when the criticism is directed toward your work, ideas, or words.
  4. I want to second HappyCoder's recommendation to look at MonoGame. It will allow you to get to grips with the technology as you need to use it, without presenting you with a flood of options. It will, however, require more work and an appreciation for working in the code. It will also require you to consider how games are put together, from an underlying technology standpoint, rather than simply how you can implement your mechanics and content.   However, if you want to work in 3D and use C#, then Unity is a good choice. It has some idiosyncrasies, many of which I dislike, but it's a solid piece of technology that can help you create almost any game idea and will, at least, help you learn how such technologies work. Just being able to identify the aspects you like and dislike will be a great advantage in considering game development.   Otherwise, I have heard that you may be able to use Mono with Unreal now. Does anyone have more knowledge about this?
  5. Hi HappyCoder,   I have thought about this approach and, instinctually, I don´t like it. However, it does seem like a good idea at this stage. As it stands, the GameObject class keeps track of a a GameObjectID (name and hashed integer ID), a handful of flags, and a velocity.  I'll almost certainly add an optional collection of collider components, and I'm considering adding an optional physics component, but I may keep that away from the base class and simply have objects which require physics to instantiate their own component and subscribe to the physics system. So the overhead shouldn't be too high.   The reason I don't like the approach is because I will certainly create a number of object types, most often GUI devices, which need to track a number of sub-objects such as labels or frames. Some of these could be achieved easily without a Transform, but in many cases a Transform would be easier. Certainly I could make these sub-game-objects, but conceptually I prefer them treated as a single object. However, considering I don't currently have a better solution it may be that this is the approach I'll need to adopt.
  6. I simply wished to comment that you appear to be seeking to impose the stages of grief upon the player. This is an interesting concept that I've played with before. However, it is important to note that the 'five stages' Kubler-Ross model has drawn some very valid criticism. Most importantly, not all people experience the same stages nor is the order necessarily consistent. Furthermore, it is quite possible to move back and forth between stages, rather than progress in a linear manner.   This doesn't invalidate presenting the stages sequentially, but it does raise some problems for any attempt to impart those same emotional states onto the player, as the player may react differently to the events of the game than would be predicted by the model. As general recommendations, I would recommend attempting to impart the stages vicariously, rather than by, or in concert with, observation of the character's emotions or by emotive techniques such as music.   People react very differently to the emotional state of others than they do to direct emotional stimula. As noted, we also cannot necessarily predict a player's reactions to direct emotional stimuli, at least with respect to complex reactions such as the 'stages of grief.' So, I propose two possible solutions. Firstly, attempt to engender in the player a direct connection with the character or, secondly, break down the stages of grief into their components.   People react differently to emotional stimuli because they process that stimuli in different ways. They have different thought processes, memories and learned behaviours that they use in processing stimuli and formulating both an emotional and practical response. One way to overcome these differences is to attempt to standardise them by providing the player direct insight into the character's "emotional pipeline." If you can convey to the player the reasoning behind the character's response, and the factors being considered in concert, then the player will have a lens through which they can respond, and very closely empathise with the character. This can be done using a variety of reasonably simple techniques. Cutscenes and flashbacks, for their flaws, allow the player to construct a narrative and emotional context. Techniques can be more subtle, such as flashed imagery, voice over, momentary audio cues or even as simple as demonstrating changes in expression in response to stimuli. Text, diegetic or otherwise, can be quite effective.   The alternate approach is to break down the response you wish to illicit into its components. Bargaining, for example, requires the player to have accepted the fact of an imminent problem. The player must be emotionally motivated to avoid the consequences of that problem. However, the player must maintain a (tenuous) illusion that this fate is avoidable. In short, the three primary requirements are a belief that, in this case, death is imminent; some frustration at the failure of efforts to change the course of the game; and a belief that there remains some option to pursue. This last point might have significant game-play implications. By attempting to construct the response you desire, rather than provoke it, you can once again somewhat bypass the differences between people. I believe that game-play will have a much larger role in this approach, as the stages of grief require a perceived degradation of agency.   Anyway, my apologies for such a long post with only a handful of actual (obvious) techniques. I hope that it might be somewhat helpful.
  7. If you can't say what you don't like about Unity then there's no guarantee you won't equally dislike the alternatives presented here. It would be worth devoting some thought to the matter.
  8. Good day everyone.   Over the past couple of years I've worked, on and off, on a 2D game development framework using C# and Mono for cross-platform development. It's been a great learning experience and definitely useful. I've recently begun a new iteration in order to implement a number of lessons I've learned.   The current focus of my attention is implementing the game object model and transform hierarchy. Currently I have a Transform2D class which keeps track of local transform data (translation and rotation only for now) in addition to keeping track of its parent and children transformations. This is used to propagate 'dirtiness' as needed and to calculate the world matrix. I am now implementing the GameObject class. Every GameObject has a transformation. GameObjects are similarly arranged in a hierarchy and this is where things get tricky. It seems highly problematic, on many levels, to manage two hierarchies. Furthermore, it is important that the GameObject hierarchy is the same as the GameObject's transformation hierarchy. That is to say, the GameObject's Transform's parent should be the same as the GameObject's parent's Transform. So, it seemed like a good idea to simply allow the Transform to dictate the hierarchy.   However, I also need the ability to use Transforms independently of GameObjects. That means that a Transform may, potentially, have no attached GameObject and this would introduce 'gaps' into the GameObject hierarchy. There are certainly ways to work around that problem, but most of them violate violate the contract offered by the Transform class. It has become quite apparent that I am trying to use one class for two distinct purposes, and that is a problem.   One solution is to drop the notion of a GameObject hierarchy entirely. Another is to create multiple types derived from Transform2D, but that hardly seems ideal. I could also make a GameObject's transform private and control parent-setting access, but that introduces a number of irritating properties to GameObject.   Anyway, I though I would ask if anyone can offer some insight on a good way to approach this problem or suggest an entirely different structure if necessary. The framework is not going to employ a pure entity-component model, but I'm looking to create shallow inheritance hierarchies with a good degree of composition.
  9. We can't fix it. The problem extends all the way down to early education and pervades all aspects of all modern cultures with which I'm familiar. The truth of the situation is complex. It's nuanced. That is something that people despise. Each camp seeks desperately to cling to a simplistic picture of the situation in which they are right and their opponents are wrong. The debate is, and will be, framed in such a way that only idiots or monsters could possible disagree with the position being proffered. Most people simply lack the objectivity and maturity to discuss the situation in a productive, reasonable manner and doing so, among those who lack those qualities, will make you the enemy of all sides.   As for what we CAN do, it's simple. Rather, it's a simple principle but exceedingly complex in practice. We do what is right and treat people fairly. When we see others failing to do so, we call them out on it. We don't generalise and we don't promote different treatment on the basis of gender. Instead we seek to correct those who act inappropriately, and exclude them if they refuse to change. Beyond that all I can recommend is that we don't inflame the situation and seek a solution rather than vindication or rhetorical point scoring (this isn't aimed at anyone in this discussion).   In my view, sexism in the industry and, just as importantly, the consumer base is a huge problem. However, the response has often been unreasonable and damaging. People also try to attach a range of other issues in order to add credibility or, alternatively, label all criticism as misogyny/SJW in order to avoid dealing with it.
  10. Ideologically I'm opposed to Scottish independence. I can see little benefit in creating a new state justified primarily on the basis of near ancient grudges and meaningless nationalism. Self-determination, rooted in 19th century European nationalism, has much to answer for in the world. Frankly, the fewer states the better and the only good reason to divide states is significantly different core values. The differences between the Scottish and the rest of the UK, insofar as these core values are concerned, are so infinitesimal they don't even warrant mentioning in the context of global differences.   Other reasonable justifications for dividing states exist, mostly rooted in misdeeds, but these act to address an immediate concern and don't constitute a good long-term justification and, in most cases, are better served by insurrection rather than secession. In any case, these don't apply to Scotland. Then there are the enormous practical considerations...
  11. I think that voting to secede would only prove that they shouldn't. After all, there's nothing more English than hating the English.
  12. A single function should work perfectly well, but it might be wise to change the name to something like 'modifyStat' or 'changeStat' rather than 'increaseStat' if you intend to use it for both purposes or, in fact, if it is possible to use the method for both purposes.   EDIT: That said, I have been known to create both methods when it comes to things like 'damage' as opposed to 'heal.' Even when it's not necessary, and probably introduces a small degree of complexity, I like to map the public interface to logical actions that could be taken with the object. Still, I think one method is probably preferable in most circumstances, unless significantly different steps need to be taken for increases and decreases.
  13. EDIT: Retracted. I took a cue from your post and filled in the blanks. My apologies.
  14. Chris hit it on the head, the question is: why? The answer to your question entirely depends on your answer to that question.
  15. There are a number of approaches. The best approach is one that suits the context. The biggest complexity is how to handle saving data. If players will not wish to manage their own saved games, or are otherwise restricted from doing so, then it's reasonable to auto-save the game when exiting in most circumstances. If automatically saving the game is not a reasonable option, then a prompt might be a solid choice.   After reading this, one approach I considered to avoid cases of accidentally exiting the game would be to impose a time on the interaction of instructing the game to exit itself. Rather than allowing the player to tap/click the exit button, and then implementing something like a timer, make the exit button a 'hold button.' The player would be required to depress the button for a minimum length of time, such as 1.5 seconds. The interface device would then provide visual (and possibly auditory) feedback to indicate the progress toward exiting the game. This minimises the risk of accidentally hitting the wrong button, and diminishes the likelihood of exiting without thinking. Simultaneously it provides feedback to the player and does not require the player to wait, inactive, while a timer expires. Implemented well, it should be a satisfying interaction.