GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
About this blog
Random thoughts on C#, Windows NT, VoIP, and whatever else crosses my mind
Entries in this blog
Step 2: Use System.Data.OleDb and watch all hell break loose.
Definitely one of the weirdest bugs I've seen.
A bit of background
In our apps, all of the different components are divided into groups such as 'Shutters' and 'Services'. Services are the bits of code that sit in the background and listen to telephony events, or manage database connections, or keep track of contact lists, and so on. Shutters are the GUI components. Shutters tend to rely on services to figure out exactly what needs to be displayed. For example, the contact shutter asks the contact service for a list of contacts to display. Each of these components consists of a primary class, plus various helper classes as necessary.
Because shutters depend on services, it makes sense to initialize the services before initializing the shutters.
We want our application startup code (known as the 'boot manager') to be as generic and reusable as possible - it shouldn't have to know about the details of each particular shutter or service, and of course the lists of necessary shutters and services shouldn't be hard coded. So the question is, how can we ensure that the services are started before the shutters are initialized, while maintaining genericity? Wouldn't it be nice if, say, we could pass an assembly to the boot manager, and have it automatically initialize any services and shutters inside the assembly? How can we pull this off?
Attributes to the rescue!
As mentioned above, each component consists of a primary class. These primary classes contain the initialization code that needs to run when the application starts up. So let's take each one of these primary classes and tag it with an attribute indicating that it is a service or a shutter. We'll call this attribute 'Bootable'.
public class MyImportantService
public class MySuperImportantShutter
On startup, assemblies get passed in to the boot manager, which examines the assemblies for any classes with these attributes. It groups them into services and shutters, and initializes them one after another.
Problem solved! We can now be sure that services are initialized first. But this leads to another problem - dependencies between services. It is quite conceivable that one service might depend on another; the contacts service mentioned above might use the database service to talk to the DB where the contacts are stored. We need a way of ensuring that the database service is initialized before the contacts service. At this point we have to make the assumption that the programmer writing a service knows what other services it depends on. Given this, all that is needed is a 'Prerequisite' attribute that indicates which other services need to be running before the service in question can start.
public class MyImportantService
public class MyOtherService
public class GDNetJournalService
After the boot manager builds the lists of services and shutters, it then orders them based on prerequisites, and starts them as above. (If our intrepid programmer decides to code in a circular dependency, he will be greeted with an exception on startup)
So there you have it - a way of using attributes to ease the pain of initializing your application.
In my never-ending search for a decent Java IDE, I recently decided to install Borland's JBuilder 2005 Foundation. What a mistake that turned out to be. I simply can't comprehend how such shoddy products can actually be released. The forms designer is so slow and buggy as to be beyond useless. The entire IDE is a train wreck of miserable performance, astronomical memrory usage, and sheer ugliness.
I guess it's back to Eclipse for now.
D'oh! This one was caused by some weird interactions between our keyboard shortcut handler and our new localization code. Apparently some strings that weren't supposed to be localized were, which broke some of our accelerator actions. But hey, it's early in the product development cycle. Things are allowed to break.
(And no, this bug wasn't my fault!)
I recently looked at writing some code to integrate with ACT! 2005. ACT! is a personal information management application along the same lines as MS Outlook or Lotus Notes. When I installed the demo and found that it was a .NET application, I was intrigued. When I found that there was an SDK available, I was even more intrigued. Did I finally find an application that makes integration simple and relatively painless? (None of Outlook, Notes, GoldMine or previous versions of ACT! fall into this category).
My hopes were crushed when I actually looked at the contents of the SDK. Some 20-odd megs of assemblies, a few samples, and some incredibly pathetic documentation. The documentation consists primarily of short snippets demonstrating how to perform very specific tasks. Nowhere is there any indication of what any of the assemblies actually do. A high-level design overview or detailed description of the class heirarchy? Nah. We obviously don't need those. Browsing the ACT! discussion groups shows that I'm not alone in my disdain for the SDK.
The moral of the story: If you want your app to be extensible, don't underestimate the value of good documentation. All the functionality in the world isn't worth much if nobody can figure out how to use it.
Incidentally, ACT! 2005 is also one of the slowest applications I've ever used. And I use the term 'used' loosely; it's barely tolerable on my P4 2.8 Ghz dev machine.
In other news, Outlook 2003 uses some undocumented MAPI properties for new contact fields such as 'IM Address'. Thank goodness for OutlookSpy, and no thanks to MS for once again making it unnecessarily difficult to write code that integrates with Outlook.
ReactOS 0.2.4 was released a few days ago. Download it here, or have a peek at the changelog here.
-Projects I'm working on at school
-Interesting technial issues I come across at work (I write .NET-based software for corporate VoIP phone systems)
-Various graphics & systems programming projects that I am working on
That's all I have to say for now ... the real point of this post is just to test out the journal system.