Monday, June 15. 2009
Wednesday, June 10. 2009
It makes sense to have a track centered on the creative side of game development, and it makes sense to have a track covering the business side of game development. I can even see some logic in not inviting programmers to a conference like this, the same way that there are sometimes events that are less interested in the business side of making games, events specifically for programmers, and so on.
But I'm a bit hung up on a conference that separates a conference based on lateralization of brain function such that marketing is a left-brained activity. It also seems to convey that, since they are covering the entire brain somewhere in the conference, they are covering the entire development process, and all the different tasks people do in making a game.
Perhaps it's just my left hemisphere insisting that everything adds up correctly, perhaps it's seeing my discipline left out in the cold with the implication that it doesn't even exist... but the good news is that I don't have any reason to put effort into a proposal for the summit, nor do I need to consider attending. :-)
Wednesday, June 3. 2009
Plus nobody commented here, so I didn't feel like I was pulling the rug out from anyone!
Tuesday, June 2. 2009
I'm primarily a server programmer, but I still end up doing UI work every once in a while, and that's been true for the majority of the last three weeks. Not being an experienced old hand at UI design, I find myself falling back on first principles and decade-old books. I'm mostly happy with the results, but the code that results in implementing the interface... well, it's not the kind of code that I like to write.
One of the basic principles of interface design1 is coherence:
Internal consistency means that the program's behaviors make "sense" with respect to other parts of the program.... One should strive towards the principle of "least surprise".
If one part of your interface shows that your sword gives you a skill bonus, everything that displays information on skills should incorporate that bonus.
Put another way, each individual part of the user interface that displays information will grow to depend on both the information it ostensibly displays, plus what every other part of the interface ever displays. Very little code is left loosely coupled to the interface: data hiding obstructs coherence, singletons and global variables spring up, even the code that takes actions based on user input gets more context-sensitive (making it hard to avoid keeping that code loosely coupled and non-repetitive), and so on.
Is this bad? Nah, not really. It's just one of the many pressures that (in the short term) pushes against loose coupling, DRY code, and good code architecture. A good UI is an important aspect of good software, including games. But sometimes... sometimes, the things I do to the code in the name of users just seems awful. :-)
EDIT: Edited for clarity based on early feedback.
1. Per A Summary of User Interface Design Principles. See? All my references are a decade old...