I tried implementing the sound wave generation looping through hard-coded samples rather than algorithmically, but I have issues with the current implementation. The basic approach is straightforward but it took a couple of days to debug and the result still doesn't sound right. Apart from the output sounding lower quality, it is clearly out of tune. Not sure what is going on there - whether it's a discretisation thing, something with converting floats or merely another bug.
I decided to go with samples because it's very easy to add new wave forms. Create an array of floats for one wave period, plug it in, and you're done. AFAIK its the way sine waves were done in hardware due to how computationally expensive they are to calculate. Plus if I get around to adding normal non-looping sound files to this system it's done in the same way.
My gut feeling is that it is better to go back to implementing the core of this system as if it was on a hardware chip - using simple hard-coded algorithms, different for each tone, based on bit registers with different purpose per waveform - and then add a layer on top of that to convert instructions like "channel 1, triangle wave, 440Hz, half volume" into the right register values.
Eventually I want to play around with phase modulation, like what was used on the Yamaha chips used in Adlib sound cards or the Sega Genesis/Mega Drive, once I get my head around how the operators worked in hardware.
While implementing the tone generators in software I figured there's little reason not to simulate the actual clock speed of the hardware, at least to begin with. It means doing about six times as many calculations, averaging out the half a dozen sound values to the single one at 44100Hz rate sent to PortAudio. But when we're talking about a few odd million calculations per second with today's processors it won't hurt to add in a few million more. I really doubt any CPU bottlenecks of the future will be in the audio subsystem.
The three tone generators and noise generator are up and running. I'll need to play around more with the noise generator to learn how to properly use it, but the tone generators seem straightforward enough. I hand-coded in a short music demo to test how it sounds:
Three Square Wave Moonlight Sonata (no voltage drop-off):
(I'm going to have to find or figure out a good way to represent sound data as commands, as hard cording everything in a big ol' integer array isn't the best solution.)
I've been playing around with simple ways of moving the sound beyond pure square waves to give the sound a bit of a more hardware generated sounding feel. So far all I've tried is a simple voltage drop-off, a method suggested in the Sega emulator page from the last entry. In hardware, the voltage when held will drift back towards zero. If you're using a float based internal representation for your sound data, it's pretty simple to mock that up by storing the output and multiplying by a fraction close to one (0.99...) every cycle.
In terms of effect, the multiplier morphs the square waves more towards being sawtooth, affecting lower tones more than higher ones (they have longer wave periods so the voltage is held away longer). And it also dampens the overall volume too, more noticeable for the stronger values:
Three Square Wave Moonlight Sonata (0.999 multiplier per cycle):
Three Square Wave Moonlight Sonata (0.99 multiplier per cycle):
Three Square Wave Moonlight Sonata (0.9 multiplier per cycle):
I think I like the sound somwhere between three or four nines: it's close to the original but with some more interesting edge to it. But two nines has an interesting hardware sound too, and the crappy hardware sound of one nine is a nice effect.
For my little retro-sounding software audio system, the sound chip I'm looking for inspiration is the Texas Instruments SN76489. It, its variants and various clones were used in a lot of hardware from the eighties, like the Sega Master System and the Game Gear, the ColecoVision, the BBC Micro and the IBM PCJr/Tandy 1000. I'm not trying to directly emulate the SN76489 as closely as possible, but it will help to start by looking at how this chip works so I can make something that sound appropriately "retro"-ish.
The SN76489 features three mono square wave tone generators and one white noise/periodic noise generator with 4-bit (16) volume settings. I'm picking it as a starting point because it's one of the simpler sound chips in terms of operation yet can still make some nice tunes. Plus I grew up playing adventure games on a Tandy 1000 HX so I've got fond memories of those triple square wave tunes.
Useful SN76489 links:
Wikipedia page for Texas Instruments SN76489 (links to chip datasheet in footnotes)
SMS Power page on the SN76489 with info for Sega emulator developers
Sierra AGI specification for the sound system, including IBM PCjr
The links go into the details, but I'll sum up the basics:
The chip has eight internal setting registers which are set with byte sized commands to the input pins. The setting registers are:
3 x 10-bit frequency settings for the square wave channels
3-bit control mode for the noise channel ("periodic" or "white" noise with one of four speed settings)
4 x 4-bit attenuation (volume) registers for the four channels
The chip gets a clock signal which it then turns into a internal clock. Different varieties of the chip allow different input clock frequencies - some allow up to 500kHz and divide by 2 for the internal clock, but the ones used in the consoles and computers appear to be the type that allow up to 4MHz and divide by 16. Either way ends up with an internal clock of up to 250kHz. But "up to" is the critical point - both the Sega and the Sierra links above say the standard operation was to tie the clock to the NTSC TV colour subcarrier frequency of 3.5795MHz, which gives an internal clock of 223.7kHz. The clock frequency directly affects the output frequencies so it will make a difference.
Each square wave tone channel has a 10-bit counter and an output bit. They work by resetting their counter to the value in their 10-bit frequency setting register until they reach zero, where they flip their output bit and reset their counter again.
The white noise generator uses a 15 or 16-bit linear feedback shift register, where the output is the bit that is shifted out the end and the input bit at the other end is determined by XORing two bits together (usually on the shift register). These are described in detail in the SMS Power page above if you want the details. It seems this is the part that varies the most between different chip designs, which might be important for anyone wants a characteristic noise generator for a specific system.
Each of these four channels outputs 0 or 1, which is set at their volume attenuation levels and combined in a mixer to get the analog output.
There are a lot of further subtleties that are better explained in the linked pages (especially the SMS Power one for Sega emulation), but the basics are fairly straightfoward: counters and shift registers.
Something I'll have to design for is the difference in clock speeds between actual hardware and software (semi-)emulation. My software is (probably) going to output audio at 40-44kHz, rather than the internal clock speed of 220-250kHz.
I'm going to have to think of a good way to get info from my program to the sound generation code. PortAudio's documentation says to avoid using mutexes in the callback function. I haven't done much tinkering with threads but I think as long as I keep the data transfer small and simple it will be fine, as the worst that could happen if the callback happens mid-data set is a brief sound spike.
Going to have to think of a way of encoding this type of audio in a more human understandable way than raw register settings, but that can wait until after I get the basics done.
I think the SN76489 was first used in 1979 or 1980 but it was used all throughout the 80s. I have to pick a year from somewhere in the decade. IBM PCJr and the Tandy 1000 came out in 1984, along with the garish 16 colour wonders of EGA - somewhere else I might be going.
I've been looking deeper into the audio system of Allegro 5, looking to see if I can do some tone generation for some retro-sounding bleeps. It turns out that Allegro 5's audio system isn't the best for this kind of thing.
Generating waveforms is simple enough. What I needed was a way to get my raw data from my own data structure to the OSes sound system. That's the sort thing a framework like Allegro 5 was designed to hide, not give easy access to. I also found the documentation on the audio system tends to gloss over the advanced features.
There is a callback function for Allegro's mixer data structure, which is designed for post-processing but can be used to set the values directly. And it works - mostly. The problem I found is that there is no way to manually set the update rate that the callback function is called. For my system and the audio settings I was trying (mono 16bit int sound) the function was fixed at 2048 samples per call. At a playback rate of 44100Hz, that's roughly a twentieth of a second per call which is a noticeable amount of lag. As far as I can tell from sifting through Allegro's source code there isn't any function calls or config settings to alter that short of putting them in the library myself. Which seems more trouble than it's worth given I'll probably break everything trying to make Allegro do more than it's supposed to do.
The better answer to me is to look for an audio library that is designed for this kind of thing. I'm trying out PortAudio. I haven't had much time with it yet, but so far I've got it running and outputing square wave beeps with a callback function running on my own set number of samples per call. 256 samples and the beeps sound instantaneous.
Given that's all I need PortAudio to do, I'm happy. The downside with a low-level library like PortAudio is that is all it does, so if I want to extend this to working on wave files I'll need to write my own loaders. Right now, I'd like to see how far I can go with old-style tone generation.
Additional: I've noticed these journals have tag functionality, which I'm currently not using. Is there a standard for how tags are used on GameDev.net?
I've got a simple "try all the basics" program running using Allegro 5 - bouncing bitmap with sound effects, playing music with an on-screen FPS counter using the font system and outputting keystrokes to the debug console. Nearly everything seems to be working fine. The only thing I haven't got working is tracker music formats, but since I'm not sure if I need that I should be fine with Ogg Vorbis. Bitmap-wise I know Allegro can read PNG files and that's all I need. From my brief look at Allegro 5 so far it seems like it will do everything I want it do. It's quite straightforward and simple enough to integrate with whatever I wish to do. I'll need to try it out on something proper to get a better feel of it of course, but so far it feels nice enough.
The only real hassle was getting all the libraries compiled and linked correctly, especially when I wanted to move from the standard defaults. Make sure there are separate debug and release libraries. Do you build for 32-bit only or also 64-bit, and maybe PowerPC if you're on a Mac? Do you go with dynamic linking, where you have to make sure you bundle all the libraries with your game and link them correctly, or static linking where you have to make sure the compiler links with the right libraries instead of defaulting to the dynamic ones.
It wasn't particularly difficult, but it did involve heaps of retries and fiddling with settings to get it done right. I must of recompiled and reinstalled the Allegro libraries about fifty times.
I'm going with static linking BTW, because I think I'm less likely to screw up including the right libraries at release time. I'm not sure about the 32-bit vs. 64-bit decision. I don't think it will make much difference to compile for both, but I also don't think it should make much difference for the sorts of 2D games I want to make to stick with 32-bit only. I had a check of all the games installed on the iMac I'm developing on and all the games appear to be 32-bit only (or older, PowerPC and/or 32-bit games; no 64-bit at all) so I assume there is some reason behind that.
Hey all. The GameDev journal is out of mothballs once again, rebadged and back in circulation. I'm hoping to post more often here in the immediate future, keeping things informal and the posts short so I don't get distracted by blogging instead of ending my game development hiatus. It will be good to be lurking around the journals and forums.
Right now I'm getting back into gamedev basics by playing around with Allegro 5 using my old friend C. I've only had a very preliminary look at Allegro 5 so far, but my overall impression is that it's a pretty sweet, simple framework for doing everything I would like the library do with a very straight-forward, C library way.
I've been struck with the dreaded lurgy, so I'm working somewhat sporadically. Still working through the basics.
Setup I've got a new Windows 7 PC which hasn't had much set up on it, so the first thing to do is load up everything I need. Sounds straightforward, but it always turns out to be more hassle than you think.
Version Control I probably won't need version control for the simple stuff I'll be working with in the first week or two, but if the point of the exercise is to rekindle decent game programming habits then it's best to start early.
While I'm working solo on these projects, I'd like to be able to sync code between computers. I've got a Win PC and a Mac and I like to do things on both. Previously I've been using SVN on a single computer, so I tried to come up with a straight-forward way for two computers to share the repository. But everything I tried was ugly. So I've decided to try a distributed source control method instead and switched to Mercurial. I've only played around with tutorials so far but it looks like a much better approach for my work flow; it's a lot easier to set up repositories whenever and where-ever I like.
Mercurial was very easy to set up on both Windows 7 and Mac OS X, so no problems here are all. It was surprisingly simple actually - version control usually has a lot of setup pains. I'm looking forward in seeing how Mercurial operates.
flixel Next stop was to flixel's site. flixel is a great open source ActionScript library that I briefly looked at last year. My thoughts at the time was that the structure was eerily similar to my ideal simple game architecture that I'd been playing around with in C++, except in Actionscript. And the site is aimed for beginners, so it's got links to all the resources I need.
For now, my exercise is to rekindle some basic game programming techniques, so I'm going to be working from scratch as a learning exercise. However flixel itself is a great resource for learning how to do things while I learn. And once I'm up to speed with ActionScript, I'll probably dump all my crappy learning code and switch to flixel.
I haven't yet used or even looked at flixel's code, so no judgement calls yet - other than I really liked the look of it a year ago.
Flex SDK Now for the actual development tools itself. Flex SDK is the free development kit from Adobe. Simply grab the latest copy and unzip. Pretty straightforward setup.
FlashDevelop Next thing to install is FlashDevelop, the free open source IDE for ActionScript development for Windows. As well as the program itself, FlashDevelop says it requires Flex (already got), the .NET frameworks (already got previously) and the latest Java JRE.
Despite saying it needs Flex as an external prerequisite, when installing FlashDevelop through the online install doohicky it downloaded another, slightly out of date version of Flex. Which is annoying when its about 200Mb on a slow crappy internet connection. Grrr.
Oracle doesn't make it easy to install Java JRE. Their site is a mess, and their installer makes it a pain to change install directories (I had to manually make the directory structure myself). Nothing too major, but it's by far the most annoying install of all the stuff I've had to do so far.
On to the code! And now, checking it all works!
First gripe: FlashDevelop makes it hard to change the default editing font. The option is there, but it's under Syntax Colors for some reason. Annoying.
Second gripe: The syntax checker crashes. Clearly I haven't set something up right. Looking into it, I think there's an issue with using the 64-bit version of Java JRE 6. So annoying. One uninstall, download and install of 32-bit Java JRE later (including going though many hoops to disable the Java Update Scheduler and replace it with my own scheduler: sorry Oracle, I don't want to constantly run your code merely to check for your monthly updates. And Oracle doesn't make it easy for you), and we're back in business. Grr.
Third gripe: FlashDevelop has this weird autocomplete that doesn't seem to like the default Flash objects as options for import packages. I think it's aiming for a work flow where it automagically adds them as you include them in your code.
Gripes aside, everything else was fairly plain sailing to get that first program running:
Hello, Flash Player!
Overall impressions thus far: Mercurial - looks promising! FlashDevelop - need to learn the kinks Java JRE - SO ANNOYING
Hey everyone, I'm back! Looks like things have changed dramatically over in Journal Land. It's going to take a while to figure out the kinks with the new system. After (too long) a hiatus, I'm back at game development, looking to shake off the rust.
My plan to reboot is to teach myself game development in ActionScript for the Flash Player. My impression is that Flash is a neat method of making small games or prototyping neat ideas and sticking them on the internet for all to see. There is also a bunch of great libraries now, like flixel and FlashPunk.
What I'll be posting here is an informal journal of my progress as I work my way through ActionScript programming: what's neat, what's problematic, and what bone-headed mistakes I make along the way. Enjoy!
This is the wrap up of my week long game dev experiment, cross-posted from my blog.
The week is over, and technically I failed. Bummer.
What I did get done was a tile-based prototype, shown above in the screen shot. It's an experiment for what a tile based puzzle game would be like if the tiles consisted of two colours, split at the diagonals. In the version above, the coloured sections get highlighted if there's a connection chain of four or more tiles long. Unfortunately, it's currently just a toy. I didn't think of a good way to make a game out of it. I was on my way to experimenting with a Tetris-like mechanic - matched tiles disappear, replaced with tiles above - but I ran out of time.
I might continue working on this at some stage, but I'm doubtful. Coloured tile games don't excite me as a developer, mostly because I suspect every single gameplay combination has been done to death by now. I'm also not sure if it's worth posting the prototype: it's not fun, dead simple, Mac OS X only and spits log files into a subdirectory in your Library folder that you need to clean up after. Maybe next time. Part of the point of just having a week is that if I need to walk away, it doesn't feel like much of a waste.
I'll need some time to evaluate what went right and wrong from this exercise, but I've got some ideas of how things went off the top of my head.
First: I need to organise my time better. I just dove in, and while the time pressures helped me stay focused to begin with I went a bit all over the place with my focus. It would have helped to spend an hour or two at the beginning figuring out exactly what my objectives are, the best way to achieve them in the time available and pitfalls to avoid. With the haphazard approach I can get focused with deadlines, but I'm easily distracted by non-essential things. I also lost a lot of energy at the end which is part of the reason why I only got a prototype done.
Second: prototyping in C is a pain. Having a better set of in-built functionality at my fingertips would give me a lot more flexibility. I wouldn't have to waste hours of work trying to think of a C friendly way to do the tile connection counting algorithm.
Third: prototyping puzzle game ideas in a short period of time is hard. I suspect if I just did a simple action game I'd have got something finished in the time. It's easy to kludge together something amusing in the action game genre, but puzzle games live or die on their core mechanic. I don't know if this is inherent to the genre or just my lack of practice with the area.
Fourth: if I'm not excited by the idea, then it's really hard to crunch development. I didn't exactly go "full out" in developing this one, a conscious decision to see whether it could be done with a sensible workload. But I confess it also meant I slacked off the pace in the last couple of days when minor issues reared their head and made completion all that more challenging. Maybe if I really loved the idea I might have sweated through the headaches (metaphorical and literal), the random Xcode crashes (grr) and the heat. But in the end, yesterday I effectively waved a white flag when it was clear I was out of time. I feel bad about that.
So... where to from here? I might have not completed an actual game, but it was a good exercise. My feeling is I should repeat the process until I get good at it. There's one week between now and Christmas; that's plenty of time for another small game attempt. This time, I'd like to give Python a whirl as a comparison. I need a theme though. I'm happy for any suggestions, otherwise I'll take something at random in the next few hours.
Brief update for the GDNet+ journal: I'm about three days into my week, which has mostly been spent familiarising myself with the tech. I've assembled a very basic functionality set from old projects of mine, built on top of SDL, OpenGL, PhysicsFS and probably several other libraries I've forgotten right now. It's basically a gutted half-completed game layer tied together by a thousand hacks, but it does all the basics and is "prototype-ready".
All I need now is a game idea. And that's proving difficult.
Mostly I blog over at my own site, but I'm posting this as I've been in a bit of a rut lately of which I need a good virtual kick to get out of. I'm setting myself a deadline of one week to make a game, no matter if it turns out very simple or crud, in order to give my brain a kick start. The point of the post here is put it on public record so good ol' guilt will keep me fired up to meet the deadline.
So by midnight UTC Thursday 17th December (11am local time), I should have put a post here with a downloadable version of the game as it stands, lest I be shamed.
The theme I've picked for myself is card-based gameplay. I'm leaning towards using SDL and C as my tech, mostly because I've used it before and I've got a hankering to use it again (despite part of me thinking a higher-level language might be wiser).
This is a cut-and-paste copy of my latest blog post over at my own website. It's a summary of the lessons I learned from Freeplay 2009, the indie game conference/festival/thing that was just held in Melbourne on Friday and Saturday. Hopefully videos of some of the panels and workshops at the event will be up at tsumea in a week or two. I've got very brief summaries of my thoughts of the panels I attended that I typed up the night after each day, but they won't hold a candle to the info you'd get from the vids.
I've put together a summary of some of the main points I learned at Freeplay 2009. Most of these aren't lessons from any one person, but are a collection of the impressions I got from the panels and workshops I heard, the discussions I had with attendees, with possibly a fair chunk of my own opinions subconsciously working their way in (so if any of this turns out to be a faulty recollection of Freeplay 2009, blame my brain).
Prototype, prototype, prototype!
By far, the most common thread in talks was the need to build prototypes. Half of Petri Purho's keynote was on how moving to the game-in-a-week model best shown by The Experimental Gameplay project. Conor O'Kane's How to make games on your own, for free talk included the importance of making prototypes and how this can easily be done (incidentally, you can grab his slides from his website). And throughout the other presentations there were themes of how prototypes are important for both fostering creativity and as a way to see if your ideas have legs before you invest too much time in them. The common wisdom is pretty much unanimous that if you don't first start investigating your idea with a prototype (or two or three), you're doing it wrong.
Can't code? Can't draw? You can still make a game.
Another common theme I got from the talk is that there's loads of material out there to help making your game very easy. If you really are passionate about making games there isn't really any excuse for you not to. For only a couple of hundred dollars a developer can get an indie license for Unity or Torque. You can get XNA for free. Flash is a bit more expensive, but you can get the Flex SDK command-line compiler for free if you're prepared to work in ActionScript with an engine like Flixel. With just a bit of scripting and some simple graphics, you can easily built a prototype with these tools all by yourself regardless of your skill level. If you're savvy about your graphics style, you can make a full game that still has a quality feel. And with the not-really-that-expensive outlay of a Mac Mini, an iPod Touch and an iPhone Developer License, you could sell a game for the iPhone.
With access to the internet, you've got access to a top training resources. If you get stuck, there's heaps of forums out there to help you. There's tutorials up on the web, and entire university lectures available onlines (MIT apparently has every one of their classes up on YouTube; that's pretty amazing). In short, if you can read this, then you've got access to all the material you need to gain the skills you require for game development.
So if you think you have the next great game idea, there isn't anything stopping you from building that prototype. If you can't, well maybe that game idea isn't so great after all. Try another.
iPhone is really popular with indies...
Out of the available indie game platforms I felt the biggest buzz was for the iPhone. About half the people I spoke seemed to be either working on the platform or were planning to. I can see why. It's pretty cheap to launch a title on the iPhone, there's only one main sales channel that everyone can access, and the platform is very well suited to small games that can be made in a couple of months. It's perfect indie fodder. Of course, that also means the platform is now flooded with developers and is now garnering attention from mainstream publishers, but I don't think that's necessarily a bad thing. You can't make a mint with a novelty flatulence app these days, and with the big developers now muscling into the space it's becoming a lot tougher to crack the top of sales lists. But that's true of all the other platforms. I think it's still viable a platform as any other with the right sort of innovative game. And let's face it; being able to play your game on a sleek handheld device is just cool.
...desktop games, not so popular.
There were still a fair number of developers aiming for desktops (Windows, Mac and Linux), but the vibe was a lot cooler on this. Most of the panelists thought that the traditional pay-for-copy-of-game market for the desktop was too tough these days due to over saturation. Most of those still developing for it were into making free games, either just for fun or for other purposes (self marketing, running paid servers, etc). It seems there's more excitement about getting your game on the iPhone or Xbox Live than the PC.
I'm not sure how valid the strength of that opinion was. Most of the attention for paid portals seemed to be focused on Steam, which is from what I've heard quite difficut to get your game onto. There's also the casual portals, although my feeling is they're starting to become less attractive as they play cut-throat price wars. And there's always the option to sell it through store fronts like BMT Micro; the big downside being you need to market yourself, but the way I see it there's no avoiding that.
Other, miscellaneous stuff
A few more thoughts from the festival talks that I'll summarise. Some of these had some expressing the counter argument, but the notes here was the general feel I got from the indie developers in the panels:
Ideas are cheap. While people will politely listen to ideas expressed in words, you really need a prototype for them to "get" it. As mentioned above, prototypes are easy to make, so make them.
Share your ideas. While the lawyer presentation stressed the importance of using NDAs in formal discussions (say with a game producer), with other indie developers you'll just be wasting their time. Sharing your ideas, even in prototype form, can get vital feedback as to what works and what doesn't.
Don't be afraid to abandon an idea if it isn't working. That's what the prototypes are for.
Move fast. This seemed most important for the iPhone developers, where a few made it big just by being the first mover. A small developer can sense changing industry directions and put out a game before the larger publishers take notice.
Don't skimp time on the polishing and testing. This is counter to "move fast", but you need to make sure your game doesn't have any obviously detracting rough edges. The rule-of-thumb I heard was to spend a third of your dev time on this.
If you're aiming to be a full-time indie, be prepared for a hard slog to gain sustainability. You generally need multiple games before you break even. The sensible indies seem to have either an alternative source of income while setting up (another job or someone to mooch off ;)) and a timeline where you can call it quits without facing complete ruin. Note though that even in this worst case scenario, if you really put your heart and mind into it you still won't be a failure, as you'll have developed some important skills that other employers should appreciate.
I'm expecting videos of the talks to be up at tsumea sometime in the next week or two; when I find out they're up I'll post a link.
A quick summary of my first few blog posts over at my new website:
Brand new site with a brand new blog: where I lay out what I plan to do with the site
Self-interview: where I ask myself some hard hitting questions in an attempt to get to understand my motivations better (sometimes this is easier in the third person).
Reviewing my strengths and weaknesses: in which I try to figure out what I need to work on via some more self-analysis
Python - the winter warm-up: in which I outline how I'm kicking the whole game development process off - by learning Python.
It's the latest blog post that may have some interest to GameDev.net. Python is one of the popular languages recommended to beginners. I'm already proficient in more traditional game development languages like C - or rather "was procifient", which is part of the problem. I'm as rusty as anything and so an easier to approach language will be beneficial. But beyond just flaking off the rust, my instinct is that Python should be a really useful language for full-fledged game development, at the very least for tools and prototyping, if not actual production code.
Over the next month or so, I'll post some results both at my blog and here at GameDev.net. If Python does prove to be a real godsend, I'll write an article about its merits.
It's run a bit late, and to top all the difficulties off I've contracted my third cold in two months, but my new site is ready to go.
Currently it is just a blog site, much like my old website. Unlike my old website, I'm planning on expanding on this one. If indie game development goes to plan eventually this site at www.trazoi.com will be my main storefront. For now, I decided it was best to put all the blog entries and gameplay experiments I'll get up to this year under the one banner.
There's a good chance things will break, but given it's currently just a blog and I'm only informing my journal readers right now it's good enough to go. At the moment there's known issues with the style sheet and Internet Explorer, but my quick test proved it was still usable, just a bit out of kilter. I'm hoping to fix that today, but I figured it was a minor enough issue to go ahead with the announcement anyway.
Things have got a bit delayed with the roll-out of the new site. This was partly due to unforeseen problems - somehow it took two full days to debug some of the glitches with the email system, simple though it is - but also because web server administration is a big and somewhat fascinating topic. If you're new at it like me you can get sucked into learning a zillion tricks to do anything and everything. And if you're overly paranoid like me you kind of thing you have to. [wink]
I'm now up to the point where I've got all the basic systems working. Web server, email, basic log reports and the all-critical backup systems seem to work fine. The daily backups are what I find most reassuring. Even if I need to do a complete rebuild of the entire system, I should only lose at most two days worth of data (worst case is when my daily backups are completely out of sync; time zones are hard to get perfect!). The only caveat is that at the moment I still need to get the backups manually. I'd going to set up an automated system on my local machine but since I don't have a computer online 24/7 there's always going to be weak point there. I either need to set up a local server, some other form of online backup or just be prepared to eat losses if I'm away from my desk for extended periods of time.
The main thing I need to do now is figure out what content I should launch with. I'm thinking "launch" might be too grand a word for what it's going to be. Probably an effectively empty home page and a developer blog, really. It's something to build on, sure, but it's not exactly the sort of material you could see balloons and streamers being released for.
Apart from that, I've got a few tweaks I need to make to my blog theme to make it look slightly less spartan. I've also got to test the thing in Internet Explorer as I know it's broken (again! stupid IE). And, possibly more expensively, I'm going to rebuild the whole system again from scratch. Part of me doesn't like having to go through all the hassle of rebuilding the system again, but I told myself I was going to do it when I started. There's a bunch of fundamental changes I want to make to the setup - partitioning and so on - that's easier to do at the beginning. Plus I need to make sure I can actually do a complete rebuild if I'm forced in the future to do it.
All in all, I know I'll have a new blog to post in by the start of next week at the very latest. It will probably be much earlier, but Popcap just released Plants vs. Zombies today so this morning I'm doing a bit of market research. [smile]
Yesterday I plunked down the cash for a VPS over at Linode. I'm moving a step up from shared hosting. My service at Dreamhost for my current site isn't bad per se for what I am doing with it currently, but for a site that I want to grow into a small business I felt I needed to move away shared hosting to something a bit more solid.
Linode has a good repuation and a very nice price for a VPS, but the caveat is you have to administer everything yourself. For the last couple of days I've been slowly working my way through my checklist, filling in the gaps where I go. Actually getting everything working has been dead easy, really. It's knowing enough about what I'm doing to make it reasonably secure that's the hard part.
Currently I've got the basic LAMP (Linux, Apache, MySQL, PHP) installation up and running, with a bit of security screw tightening. Most of this was getting used to how Debian differs from Mac OS X's flavour of BSD, which I think I'm getting the hang of. Today I've got WordPress installed with a few basic security measures in place. If all's going well, I should get the basic blog up and running for internal testing tomorrow.
Then after that: some kind of logging and statistics, email services, and the all important backup system. I'm not sure how to do most of that. That all needs to be tested too.
Then after that, once I've got backups, I'm debating whether I should just nuke the whole thing and see if I can restore it from scratch. Best I find out whether I can do that now, before I lose anything of value.
I'm hoping this will all be done by next weekend, when I can go live.
It's slow going and possibly overkill for where I am right now, but I figure if I do a good enough job now learning and setting up the basics, things will go far more seamlessly later and I'll be up to speed when I need to be.
This is a special, transitory journal post. My weblogs are currently in a state of limbo. I've been prepping the new site for a while now and with a new blog about to start at a different location it's felt too awkward to blog at the old sites.
You may also notice (if you've been here before) that the colourful comic theme is gone. That's part of the new process too. Don't worry, I'm still planning on keeping this journal alive for some time yet. However I feel this is best run as a satellite blog, drawing attention to very GDNet specific things or a summary of what I'm up to over at my main blog. Since this is going to be more GDNet oriented, I felt it was best to give it a GDNet look. The header will need to change too, although I'm not sure what I'll put there.
The future of my current off-site blog at trazoi.net is uncertain. My current inclination is that it will retire in the near future. My original plan, way back when I created the site, was for the trazoi.net blog to be more personal and start a more business-like site with a business-like blog over at the commercial address (trazoi.com, currently redirected to trazoi.net). But I now feel this isn't a workable strategy, and I should just have the business blog. Indie game business blogs work best with the personal touch anyway. The only things I wouldn't post there would be really private or unprofessional details... but I wouldn't post those on the internet anywhere.
With the creation of a new site, trazoi.net doesn't have much of a purpose. I'm not fully sure what I'll do with the site. I'll be keeping the domain name, obviously, but for the current blog I'm not certain. I think I'll lock it down and leave it as it is for a while, however I'll probably not renew the Deamhost space it's stored on and I'm not sure if it's worth transferring the old blog across.
So in a month, I'll have two active blog sites:
The main blog at trazoi.com.
This journal, as a sort of subsidiary GDNet post place. A sort of "Your Announcements" zone just for me.
Just FYI. [smile]
For the last week I have either been sick, had no internet, or both. If I am able to post this, then I am currently in a "sick with internet" stage. Expect grammatical errors.
While the level of this cold or whatever I have fluctuates along with my on-line connection I have been working on my new website design as an appropriately straightforward task. Thankfully I'd already set up my own internal server so I can work on a prototype off-line. Unfortunately as a lot of this is new to me it's been a pain not having internet resources to help me through the hard spots
I'm basing my new site off WordPress, the blogging software. I was debating whether I should just use WordPress for the blog part of my new site, but I decided it was probably easiest to just manage the whole website under the system to get the same look and feel and universal search over the whole site. The tricky part is that I want to have a bunch of subdirectories for different things - games, experiments, tutorials, blog, etc. - which involved extending plain WordPress somehow to get this functionality. But I'd like to do this leaving the core files intact so I easily do updates. That's something I'm working on, as it involve some in-depth WordPress tweaking which requires a stable connection to their wiki to solve.
I have got a semi-decent CSS style done though. That's probably taken me the best part of last week to finish, mostly because there's so many options you can tweak. There were some things I'm set on, such as having my favourite colour orange being featured in the logo badge of the site. But then there are other options that required experimentation. Should the site colour scheme be based on azure, violet, lime or a mix of the three? How much orange should I use? Is it better to have a thematically interesting background site to make everything look fun, or should it be very simple to emphasise the content?
Fonts are a big issue too. It's amazing how few fonts are web safe. I think only Arial, Times New Roman and Courier/Courier New are dirt common over every system. Verdana, Georgia and Trebuchet are great for Windows and Mac, but their Linux support is low. Tahoma is an interesting font but has patchy Mac support. Arial Black and Impact are fairly common on Win/Mac but is only useful for headines. And apart from Comic Sans that just about wraps up all the web safe fonts. Of course, you should set multiple fonts in your style sheet so if one is missing then it finds a suitable replacement. Unfortunately though, many of the fonts have rather unique looks that make finding a common replacement difficult. And I've got no idea what fonts are common in Linux variants (apart from Arial, Times New Roman and Courier).
And then there's Internet Explorer. I've read how web designers hate IE, but I never really felt exactly why until I tried testing out my design in Windows after building it on a Mac. As a novice designer, I thought it was plain sailing with my design looking the same in Safari, Firefox and Opera on the Mac. I was wrong. It seems Internet Explorer likes to play by different rules to every other browser in existence (biggest offender appears to be the calculation of box widths). Internet was down most of that day so progress was slow, but I did manage to use a brief window of connectivity to find a site with a shortlist of hacks to fix the problem. But it is annoying, and I sympathise with those who wish IE to drop in popularity.
All in all, the website is coming together nicely, if slowly. The internal prototype should be finished this week, and the new website will be up by the end of April. Slowing me down is this headcold or whatever bug I've caught, together with my tendency to spent waaaay too long on minor details (like shades of azure), but these issues will be conquered soon. Once I've got a full prototype working on my computer I can move to setting up a new server somewhere, which will take anywhere between a few days or a few weeks depending on the frequency of disasters.
Then I can post a link and ask you try it out!
P.S. Creative work including that Flash game will recommence shortly. I'm debating whether it's best to do this over at the new site once it's done, but the decision is moot until I'm a little bit better.
P.P.S. Am I the only one who is getting an animated ad appear slap back in the middle of my subject table cell when I post comments? I've noticed it once or twice before in the last week.
I've been putting off making this post, as it's a bit embarrassing. It's more than a week later, and still no game. I guess this counts as a failure! What happened?
After I made my post last Monday, I did some soul searching to figure out where I was going wrong. My conclusion was I made a mistake in jumping straight into working on game projects the instant my thesis was complete. Heck, I started work as soon as it was at the printers. However, with my write-up dragging on and on and me being at least four months behind on my pencilled in schedule for 2009 I felt I had to make up for lost time.
My biggest concern is that I seem to be entirely motivated by guilt. I feel guilty I'm this far behind, that I'm not up to speed, and that I'm not putting in enough effort. Guilt can be a powerful motivator, but it's entirely negative and really not the best motivator for anything creative. So I decided to try a motivational experiment, and told myself I didn't need to feel guilty last week. Work on what I feel like, if I feel up to it, but if I want to dabble with other things, feel free.
The results were.. somewhat expected. I ended up doing very little on Project Protos. I did however feel a lot more relaxed. I caught up on a bunch of chores I'd been putting off for ages. I spent some time pondering the whole whys and wherefores of me going into games. I also drank a lot of tea and spent too much time surfing the internet, which is a real problem. I think I needed a break, but I can't even relax properly.
I'm not sure if this impromptu break was wisdom or just weakness. I'm not that happy I wasn't able to keep up with the game-a-week progress that everyone else is doing. I'm also unhappy that it's near the end of Q1 2009 and I'm not even out of the gate yet. But I also don't want to burn myself up in a few months due to a misplaced priority of quantity over pace, which I feel is a real danger. It's a quandary. I feel like in the last couple of years I've pieced together a winning plan for this, but instead of a beautifully arranged dot-point list it's taken the form of a 10,000 piece jigsaw puzzle designed by Escher. I've got all the pieces but it's a challenge to even start putting them together. And I don't know if my plans all hinge on me being a superman who can work productively for sixteen hours a day, seven days a week. There's too many unknowns.
My gut feeling, which I've come to rely on, is that the Flash game that is Project Protos is a wonderful start point, but I should continue to work on it at a relaxed pace. I was going to say I'd aim to have it finished by the end of the month rather than in a weeks time, but I notice that for today that doesn't make much difference! My real goal is to switch into a sustainable, professional, productive mindset. I'm giving myself a week to settle down, clear out the mental cobwebs and find my focus. When April comes round, I'll be ready, and in a much better position mentally to work on experimental microgame projects.
My first big change is to curb my internet procrastination habit, which may be difficult. I've got a nasty habit of just heading to a random site whenever I get stuck on anything, which is an easy way to waste a day's work. I'll try tweaking my mindset each day until I find something that works.
I'm back on the project again today. Technically I was supposed to finish off by now, but I had some change of plan:
I decided on Saturday I was too exhausted to burnt myself out, so I decided to take the weekend off.
Hours after that decision, I was struck a series of headaches that forced that decision. [wink] Not sure what the problem was, but I was in various grades of useless all weekend.
Monday was better but I wasn't able to pull it all together. I did spend some time playing with the music, but organisation was a bust.
Stuff like this happens, but I need to knuckle down and consider this project with more gravity than a pet project, if I want this to be my job.
My new target is to finish the Flash game by the end of the week, using the weekend as spillage time if necessary. For it to be finished, it needs to be playable and have a modest amount of polish, and generally be good enough to sit on a website with pride. This gives me four days to learn the Flash development pipeline well enough to get the job done. However I expect I'll spend some of those days doing other tasks, so it reality it's a lot less than that.
Today I will get the proper basic prototype working, even if its ugly and unbalanced. I'm aiming to post a prototype screeshot tomorrow, as well as a description of the game.
Next time I do one of these, I think I'll step down the daily updates to just key milestones. Sometimes, even if I get stuff done I don't have much to talk about.
The good so far: I've got the basic cannon working. The bad: still havent got anything resembling a game. Things are moving a bit too slowly. There's a bunch of pesky little annoyances that are taking longer than expected to sort out.
Case in point: I've worked on some new graphics in Inkscape. Unfortunately, Flash doesn't import SVG files, but luckily I do have a copy of Illustrator which does. Illustrator has some strange ideas about what to do with the SVG primitives though, swapping out the colour palette for some strange muted version and completely messing up the stroke (the outline) on shapes. Grr. If I have to I'll export as raster images, but it's a bit of a waste to have to use raster in a vector driven tool like Flash.
The other big problem is more mental. I think I'm a bit burnt out. Strange to be burnt out before I've really begun, but I'm essentially doing the same thing I've doing for the last few months: sitting at my desk typing at my iMac. My focus is shot, which may be why I'm constantly stumbling over things and not spending my time wisely. My hunch is that I need to regulate my time a bit more, so I can spend my time at the computer focused at the task at hand and then relax guilt free. It's the latter bit that's important: I've spent the last year feeling guilty about not working when I'm away from my desk, and all it does is fuel your procrastination and make you slow down to a crawl.
I think I'll take the pressure off myself to get this finished within a week. It's an internal deadline after all. If I need to spend a extra few days to polish it up, then that's okay. I can then spend significant chunks of the weekend doing other vital things without much worry, and calmly finish the game by Wednesday or so. I can take a step back for a little bit, review where I'm going wrong, then try to fix it for the finish.
I haven't yet quite got the basics running yet. I've got a gun turret and a crosshair cursor working, but the bullets are still broken. I haven't yet figured out a good Flash way to implemenet them yet. It's the memory management aspect that's the issue. Flash's Arrays appear to be sparse, which means it's not straightforward to just delete a bullet, and I haven't found Flash's equivalent for a linked list yet. I might have to improvise something out of arrays.
Most of the delays come from my need to get up to speed and my unfamiliarity with Flash. I don't yet know all the library functions and variables, so I have to look everything up. Occasionally I'll hit something odd that takes a while to find the right fix.
I'm also a bit hamstrung in that it's been a while since I've written game logic, so I'm trying to remember all those little details like the best way to manage my code and deal with frame rate independent logic. For this project I've cut back on the planning and an just piling all the logic into one file, but there's a few cases where I've had to spill out into separate classes (and hence files; ActionScript is a bit like Java that way) for the sake of sanity. It's not pretty, but it doesn't need to be pretty.
Oh, and Flash's drawing tools are a bit crazy. This is a gripe I have with all of Adobe's tools, actually. I shelled out mad money for Adobe Creative Suite CS3 (well, I saved a bundle by getting an education discount, but it was still expensive), but the tools are some of the least intuitive I've used. Each tool seems to have multiple functions, and I don't get when each one is in effect. I admit I haven't given these tool enough time to do them justice, but that's usually because I've got a task to complete and if it's quicker to do it in GIMP, then that's what I'll fire up. Which is ironic, because GIMP's interface is no slouch in the WTF department itself. Inkscape's the only art tool I feel really at home with.
Back to Project Protos: at this rate, I figure I'll be up to designing the gameplay today. I haven't fully decided which direction to take this. The curret art is a placeholder and I don't know which style I'll end up using. I'll probably just knock together something a bit more vector-y in Inkscape and use that; see what works.
This week long game project is markedly different from the week I spent on Pierre and the Fish a couple of years back. Back then I felt like my mind was on fire, and threw everything I had at the project. This time, a bunch of minor ills have made me feel a bit more sedate. Nothing serious ( add indigestion to lack of sleep), so I'm not actually sick, but it means this project is more about pace and perseverance than passion. That's not a bad thing; I won't burn myself out that way. And I'm sure I can rekindle and regulate the necessary fire once I've got back up to speed.
Day 2 was spent relearning the basics of Flash and game development in general. I've got a copy of the book ActionScript 3.0 Game Programming University by Gary Rosenzweig, which is a good primer. It's even got the code for a turret-based shooter game within it, so I'm virtually guaranteed to get something working on time.
I spent the day working through the basic examples: "Hello World" and all the little demos that show how to do each core element of game-related functionality in Flash (display, input, sound, timers, animation etc.). This wasn't so much to rote learn the specifics (I've got references for that), but to prod my neurons into remembering how to make games. I'm very rusty, so this took all day.
The best thing I remembered about Flash and ActionScript 3 is that it uses an event-driven programming paradigm very similar to the one I developed myself for my own 2D framework. For those unfamiliar with event-driven programming, it's where the program flow is dictated by when key events happen; i.e. when someone presses a mouse button or when a second has elapsed, then do this. You typically do this by linking functions (called listeners) to events, such as myButton.addEventListener(MouseEvent.CLICK, clickButton);, where myButton is the object that you want to deal with mouse clicks and clickButton is your listener function. Event-driven programming is perfect for GUIs and I find it works a treat in games too.
Today (start of Day 3), I'll get to work on building the playable prototype. Having some source code as a base will help, although I plan to write it again to help jog my game development memory. My current checklist for the day goes like this:
Read through the bits of the book that describe the turret shooter game and take notes. Look at the reference code within Flash as well.
Roughly plan out the basic core of the game on paper.
Write the code and get it running with crudely drawn placeholder art
If I have extra time, I'll look at the game as it stands before deciding what to do next.
Day 1 was... uneventful. A complete lack of sleep doesn't do wonders on my concentration. I ended up spending the day working on my website revamp, shifting shapes and colours around my mock up. I've got a good idea what the website will look like in shape, but not so sure about the colour. All I know for certain is that it will feature my favourite colour orange somewhere, and that lipstick pick works surprisingly well in a varied colour scheme.
Today I'm going to put all the HTML stuff to one side and get cracking on the Flash. My plan is simple, in that there effectively isn't one. I'm just going to get a bare bones system up and running today without much thought into how it will come together. Once that's in place, I'll take it in whatever direction seems best.
Ugh. Didn't get much sleep at all. It's a spate of insomnia this week. I probably need to cut back on the coffee. Well, can't do much about that now. Despite not being in a more suitably chipper mood to start a creative project, it's time to get cracking on my first game project of the year.
Lab Project #1: Protos
Codename: Project Protos
Goal: Game Development Warm-up
Technology: Flash CS3 for Flash 9
Concept: Turret based arcade game along the lines of Missile Command or Paratrooper
Duration: One Week
I'm starting my year of game development with a series of little microgames. This week I'll work on my first of these. I always start my game projects by thinking of a unique code name, so I'll come up with one right now: Project Protos. That's "protos" as in Greek for "first", not "protos" as in "those high-tech dudes from Starcraft". It's not the most original project name, but it'll do for this one until I need a real title. I'll save the creative stuff for when my morning coffee kicks in.
The sole goal of this first project is to dip my toes back into game development again. No fancy extra objectives required. Get a game idea roughly sketched on paper, get it roughly implemented, clean it up as much as possible given the time, then call it done. Pretty straight-forward. This is just about getting me to work on a game than it is about any other objective.
Since the sole goal is to make a game, I'm picking Flash as my development platform. Out of the options available to me, it's by far the quickest to get up to speed. I never got too deep into Flash last year, but given the scope of the project and the nature of ActionScript this should not be an issue. At least I think so; I'll have to see if I'm right about this by making the game.
Game concept wise, I'm not going with anything too complicated. A classic arcade style game should be sufficient. I've got a hankering to make one of those games where you control a gun turret and blast things, kind of like Missile Command or Paratrooper. This should be pretty suitable for a mouse controlled Flash game.
For time, I'll give myself a week. I don't want to get bogged down on the warm-up game, and a week should be plenty for this type of game. With Flash making things easy, I should be able to get the basic gameplay running in a day or two. The rest of the week can be spent polishing it up and adding in new gameplay features.
That should be a good way to start. A nice and simple warm-up arcade game in theory, but I'll have to see how it goes in practice. Once Project Protos is complete, I can post-mortem it and use the experience to plan the next little microgame project.