Now that I have my video recording working 100% (and at a higher quality I might add–thanks Borsty) I figured I would start posting videos of our progress. Not only is this interesting for anyone following our work (which is probably a very small group) but it will be fun to look back 6 months/1 year/5 years from now and see what it all started from.
HD link (recommended to read text)
Even though most of us are slightly derailed with real life shit, Arcadium Software has continued to progress on our flagship game, Zinger.
One interesting thing I keep reading on different sites is people referring to XNA as a beginner language for writing games. Although it can be interpreted this way, I have to disagree. In my opinion XNA (or C# w/ the XNA Game Studio… whatever) isn’t as much of a beginner language, but more that it has the possibility to be a rapid development language.
Yes, working with managed code is always easier than unmanaged code, but that doesn’t mean its anymore beginner friendly than the next. There is just as much of a learning curve writing C# applications as there are C++ applications. In the first few steps of writing a C++ application you echo “Hello, World!” to the console… and in C# its pretty much the same thing except you’re printing “Hello, World!” to a windows form.
Aside from that, coining it as beginner tends to assume it lacks the ability to be mastered… that there’s a skill cap on it. I’ve only been working with XNA a few months now and have already learned things I wish I knew at the start. Which is a perfect segway into the meat of this post…
When we first started writing Zinger it was with the mindset of “hurry! go go go go! do it! do it!”. We didn’t pay much attention to anything other than making leaps and bounds of progress. And it worked really well! We accomplished goals and milestones we could only dream about in the past. Only problem was the code became so concrete in its current application it made us worry. What if we want to use this code in a different game? Would we need to tear it all apart? Would it even be worth the effort?
About that same time we also started to notice a few issue with some of our implementations. There we limitations on features we knew needed adaptability down the road. Things like the GUI scaling properly as the resolutions changed while in-game… or the XML based menus requiring tricks and hacks for displaying screen resolutions. If you’re writing anything from scratch, you should NEVER have to use a trick or hack to make something work. Yes, I am personally responsible for most of the problems but hey… I’m new to the language and we didn’t set out to make an engine. That had to change.
After exploring a variety of artist styles, we’ve designed a new style of graphics we want our game to use, and we’re going to write an engine tailored to it. Why? Because we absolutely love the style and its very unique. Once we’ve completed the engine and Zinger, you will forever recognize the style to be an Arcadium Software product. Sort of how you can play almost any Source Engine game and say “yea, this is totally the Source Engine”.
As much as I would like to refrain saying we’re rewriting what we had from scratch, that’s exactly what we’re doing. Except now we already know how to do everything and have our code right in front of us to reference, which speeds things up tremendously. This time we have the right layout and I can’t even begin to explain how much better its already turning out.
In before tl;dr
The other day someone asked me why I haven’t really spoke about the game engine lately. The thing is, we’ve been doing plenty of work, and there’s a lot to talk about… but I’ve been sharing all the juicy details on our development blog, instead of this blog. We even have our own Twitter which is why much of my tweets about it are gone too.
He was right, I should sorta split it up. I’ll keep my personal tales about my work on this blog and save the big, more official updates for the development blog.
Where is this blog and Twitter? Well, oddly enough we’re not ready for people to be following our progress so we haven’t announced anything publicly yet (you could probably find them if you tried hard enough…). Which leads to another question you might ask: If no one is following your development blog or your Twitter, whats the point in having it? Its a fair question but our answer is simple: How many times do people come out publicly with some project their working on and have some website that you go and visit and all you find is “HEY WELCOME TO OUR NEW HOMEPAGE!”. Its pathetic really, there’s no point in going there at all.
What we’ve done is started populating it with information so when we’re ready to start discussing it, people will have some sort of content to read (plus the site itself isn’t really finished). In the next week we hope to do this, because we want to get a benchmark demo distributed. Our primary goal is to ensure what we’ve worked on so far works on everyone’s machines, not just ours.
Imagine you’re driving a new car, and you go to work one of the controls for the air conditioning. You look down and figure out how it all works (because fuck the user manual) and you manage to figure it out. But there’s just one knob placement or setting adjuster that is just… strange in your opinion. You can use it the way it is, but if you’d designed it, it would have been somewhere else. Now imagine if someone reminded you that YOU designed that controller… and yet you don’t like it. Pretty stupid huh?
So we’ve brought our engine to a good place as far as progress, but neither of us liked the architecture! We both knew how to work everything, but we didn’t enjoy doing it like that. So it came to mind… WHY THE FUCK DO WE LEAVE IT THAT WAY? We have all the time in the world to make this the way we want to make it, so why rush through and not fix it. Plus its easier to fix now than later. So we created an empty project and we’re slowly moving stuff into a new design of the engine. I sound like a broken record but we’ve learned so much so far, we’re already trying to use this knowledge in the layout of the engine. It will be for the better and probably only set us a half day behind.
Oh and we’ve dropped the name “Gadget”. We don’t want to brand the game engine as a product, because its not. Its just a tool for us to make games with. So now its just “game engine”, which makes a lot more sense in the code as well because we had a class like CGadget and other shit like that, but when you look at the Source SDK you never (I might be wrong with “never”) see the term “Source” reference to the engine itself.
OH! For those of you who don’t follow me on Twitter… our game engine play its first sound yesterday! I was sooo fucking excited when I heard it I about shit myself. I know it seems like a small feature, but its like seeing your child take a first step.
And for those who haven’t picked up on it; after a bit of discussion we wanted to have our name be a little more unique and stick out. Previously I mentioned we were working under the name Backburner Interactive, but we’ve since changed it to Bakburner/Etc. Yes its missing a “C”, yes its a slash and yes its “etc”. It makes total sense in our heads and if you need more of an explanation let me know.