Hey all;
Its me again, Adrian! Also known as Ductomaniac. I'm not dead! Seriously!Feels like it sometimes though. Directing a group dedicated to making a game is hard work. You gotta keep things organized, make schedules, make lists, make funny diagrams that help people visualize how every piece of the puzzle fits together, talk to people one on one, talk to the group as a whole, make meeting agendas, organize meetings, run meetings, determine ways to help people get more work done, find tools that make production easier and smoother, keep track of where different assets are and in what stage of development they are, among other things. If something above doesn't make sense to you or you don't know what it is, don't worry, neither do I ;) At least not fully. Every day I've learned new things about managing/directing a group, and this has helped me realize that there's EVEN MORE things I don't yet know.
So here's one thing I've learned about: the existence of resources that can't be measured. Invisible resources. I assume you all know about regular resources you CAN measure, such as money, time, number of people, etc. However I'm coming to suspect that that's not the whole picture. There's stuff like creativity, motivation, and dedication. Those are the resources that actually get the game done. Money, time, everything else is secondary to them.Now you're probably thinking "Wait a minute Adrian. That's an oxymoron! Part of what makes a resource a resource is that it comes in limited amounts! If you can't measure it, how do you know its a resource and not just a tool or something like that?" I won't get into semantics with you, and resource may or may not be an accurate name for something like creativity, but I do call creativity and that other stuff I listed as resources. Why? Because I know firsthand that they can run out ;)So what do you do to NOT run out? I've thought of a few ways.
... read more
Gentle readers, Dave is here to write for you again. It has been too long! Much progress has been made on this little game engine of ours since I last wrote you. Let's see... the last news from the tech team was from Elliot regarding XML asset loading. Well then! Let's talk about how we tidied up that asset loading system, and then I must tell you about timers and the message system, as well as the custom level editor on which Elliot has been cranking away lately.
Let me begin by describing the structure of a Chronoscient level. It's not very complicated: a level is simply a sequence of events. Each event has a name, and lists those events which immediately follow it. Each event has some sort of content as well, which begins, lasts for a while, and then ends. In this way, every Chronoscient level flows along.
The structure is simple enough, but it took some figuring to set up communication between the code and the data. First we had to learn the differences between the .NET Framework's XML Serializer and the XNA Framework's Intermediate Serializer. (A serializer, if you aren't aware, is something that turns instances of logical objects in your game code, such as levels, into data files that can be saved and later read back in, or "deserialized", to reconstruct those same logical objects.) One XNA developer called Shawn Hargreaves was a big help here -- his blog has a lot of helpful articles about the content pipeline. We ended up using XNA's Intermediate Serializer, largely because it supports polymorphism very well and can handle abstract types. For instance, our levels' events contain abstract EventContents objects that define what actually happens in each event, and there are a number of concrete subclasses of EventContents, such as PlayerSpawnEvent and EnemyWaveEvent. The key things to note are that PlayerSpawnEvent and EnemyWaveEvent have different sets of properties, and that since their superclass EventContents is abstract, EventContents instances cannot be created directly. Now, a serializer serializes by using reflection to read the public properties of an object and outputting those values to data, and it deserializes by constructing an instance of an object and writing the values in data back into the object's public properties. If we were to use the .NET XML Serializer, we would have to make two changes to EventContents: we would have to make it concrete so that it could be instantiated during deserialization, and we would have to annotate it with the names of its subclasses to help the serializer figure out what properties it needs to read and write. This would mean that creating, removing, or renaming EventContents' subclasses would require updating EventContents itself... which is icky. Using XNA's Intermediate Serializer, we were able to leave EventContents abstract and resilient to changes in its subclasses. Hooray!
... read more
Being a greenhorn game developer in college is (big surprise) a lot harder than it sounds.
And it sounds pretty damn hard.
To recap, since this dev blog has been silent for quite a while, we are on about the fifth art team roster and the fourth team of programmers at the moment, not counting the core of Ductomaniac, Mix3d, and myself who have stuck around for most of the game. We have gone through Python prototyping, a switch over to XNA, and a slew of software in the pursuit of a process that works. This latest team is very skilled and passionate about games; save scheduling and the stressful life of summer, we are doing well.
... read more
