Jump to content


Member Since 08 Feb 2008
Offline Last Active Sep 08 2015 01:17 AM

Posts I've Made

In Topic: Do you comment Above or Below your code?

21 June 2015 - 09:56 PM

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.

In Topic: [Petition] Allow fan games to be created

26 January 2015 - 10:08 PM

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. 

In Topic: Why You Should Never Take Criticism Personally ...

17 January 2015 - 10:49 PM

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.

In Topic: Best C# engine for beginners

03 November 2014 - 02:46 AM

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?

In Topic: Dual-Purpose Transform Hierarchy (2D)

03 November 2014 - 01:58 AM

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.