Beginnings are interesting times. They can also be a bit scary too, bringing with them unknown territory and new things to be learnt and used. I think it’s always been like that, as far back as I can remember, when I’ve been faced with new systems and new things to accomplish with them. There’s often a twinge of trepidation too – when you first crack open the documentation sometimes it’s impossible not to feel a bit of overload at the sheer volume of new stuff that has to be crammed into your head and brought to bear on the new task at hand. I’ve felt it many times in the course of my career – the first night spent with the Commodore 64 poking around in BASIC to figure out how to get the sprites and sound working; the time I sat in a pub just off Carnaby Street drinking a pint and skimming through the new 68000 programming manual I’d just bought; arriving jetlagged and weary at Atari’s secret inner sanctum in Sunnyvale to code up some demos on the prototype Jaguar system…
But having been there and done that a fair few times you also get a feeling of confidence too, that although it seems like a lot at first you’ve always got through it in the end. The C64 yielded its secrets fairly easily. 68K assembly came to feel so natural that it felt like God’s own programming language, and after a few days Jack Tramiel himself came round and told everyone that the demos I was making were the best things he’d seen so far on that Jag prototype.
So it was when we got the Vita devkits from Sony. A ton of documentation (all of which it must be said is excellent quality) and a lot to learn – but at the end of the day the things you need to be able to do are well defined, you have to be able to set up geometry, run shaders, read controls, make sounds. I’m not about to break my NDA by giving out any actual technical details about the Vita dev environment; suffice to say that everything you need is in the documentation and examples.
Giles is pleased to get his devkit up and running.
The first step is just getting everything out of the box, installed and working to the point where you can compile and run the example code. Here you can see Giles being pleased upon reaching that first stage.
Example code is great too – in fact coming to an established system rather than a prototype is something of a luxury as you tend to have a lot of well thought out example code to study. Good example code is a godsend, as it is reassuring and demystifying to see some of the things that you read about in the manuals actually working in live code that you can fiddle about with. I think all of us pretty much do the same thing, fiddling about with sample code for the first day or two, just getting a feel for it and modifying things here and there, the very first beginnings of actually taking control.
With two of us on the case we were able to work pretty nicely in parallel to get ourselves up to speed pretty quickly and painlessly. Giles concentrated on bringing up the core of the latest version of the “Neon engine”, focussing on the parts that let us do the aforementioned geometry setup and rendering, while I covered some of the other parts – getting so that we could load and play sound and tunes, read the sticks and buttons, handle the touchscreens and accelerometers and such, starting to lay out a structure that the game will hang on. Within a few days we were able to put our pieces together and have the core of our game dev environment.
With those ducks in a row I could move on to the first makings of actual game parts. I’d already sketched out a few ideas in Processing while waiting for the devkits to arrive. Processing is a very handy tool – it’s a simple programming language that anyone can pick up in a couple of hours, and which contains all the bits you need to effectively jot down ideas in code really quickly and easily. It’s simple to hack stuff together in Processing and get stuff working, and then have something you know that works that you can work from when you actually come to do stuff for real.
An idea for the player animation sketched out in Processing.
Here you can see a sketch I did for the animation of the player graphic as it “walks” around the top of the playing surface. In Processing it’s dead easy to bang out this kind of stuff in a very short time, and it proved useful as I started to implement actual game objects such as the player craft and the game surface. And so before too long we had this.
The player object and playing surface with some simple baddies.
It’s always important to me to get some basic game stuff in there and working as soon as possible. There’s nothing at all fancy being done with the graphics yet (although even in such a simple state it still manages to look stunning on the brilliant Vita screen, and it’s deliciously fluid and quick even at the Vita’s highest resolution; it’s plain that GPU limitations are not going to be an issue for us at all in this game, and the Vita’s evidently a superbly capable machine. I’ve flooded that surface with far more stuff than is ever likely to occupy it in normal gameplay without so much as a stutter) – but already I can be working on how the game feels to play, which is pretty much the most important thing of all. It has to feel great in the hand and under the thumb and so far it’s feeling positively delicious.
In this little video you can see something of it in motion. Already to me this is old stuff and some of what you are seeing is outdated, but you can see that it’s lovely and fluid.
(One thing that always bugged me about T2K and T3K was that the player object animations were always a bit choppy. In both those games the animations were basically done like sprites but made of vectors, a series of frames that were run through as the position of the player moved along the top edge of the playing surface. It made the thing seem a bit disconnected from the playing surface somehow, and when the player moved quickly you’d get a kind of spasming look to it that wasn’t particularly pleasing. In TxK when the player is moving slowly the player entity actually “walks” from point to point on the edge, picking up and placing its “feet” precisely. This looks great at slow speed but if you do the same thing when moving quickly you still get that kind of “flailing” feeling. So I’ve made it so that the entity transforms into a kind of “gliding” state as the speed of motion increases, and it blends between the two states during the course of play according to how fast you’re moving. It ends up looking pretty good at both high and low velocities).
And yes, that is actual music that’ll be in the game. We’re really fortunate to have a great community of musicians over at the Yakyak forums, and a bunch of them are contributing music tracks to the game. It’s evident that this game is going to sound absolutely great, and every time I stop by the relevant thread in the forums I come away excited and smiling. Plus it means I have great tunes blasting out my Vita all the time I’m working, so that’s a bonus too.
My main focus now is getting a lot more necessary game bits in there and working – more enemies, more shot types, between level transitions, different surface shapes. There are a lot of areas where new stuff is going in, fairly subtly because above all I want to preserve something of the spirit and feel of T2K, but I do want to add in plenty of new things that’ll extend and make more varied the gameplay. As an example of the kind of thing I’m talking about, one of the things I’ve done in the last few days is make it so that the front and back edges of the playing surfaces no longer have to be flat. They can have high and low points and gradients – and this can be allowed to affect gameplay in a number of ways. Enemies arriving at a point where the front and back edges are closer can move to the top and become a threat more quickly. But a player can sit in a similar point on the top edge and actually be safer, because his shot stream will more completely fill the smaller distance between the front and back edges than if he were sat atop a longer channel. The player can go and sit on a “higher” part of the top edge and see more of the entire surface than if he sat at a low point. A jump from a high point to a low point yields more “hang time” – and thus more opportunity to safely fire down on enemies below – than one from low to high.
Little things like that don’t detract from the pure nature of the game, but they do extend it nicely and give me the opportunity to design enemies and situations that allow the player to take advantage of the newly more subtle topography.
I like little things like that in game designs.
With something that is recognisably starting to look like Game happening we’re feeling nicely confident moving forward. While I’m forging on with gameplay stuff Giles is working in parallel on geometry and shader tricks that we’ll use to make particular gameplay events and environments look particularly pleasing, and no doubt you’ll be seeing reference to those in future dev blogs here. We’re happy to be through the initial bringup stage and actually on to creative and useful things, and delighted with the system and its performance. Everything is looking and feeling great at this stage.
I’ll finish off with a shot of the top secret Vita devkit alongside a natural Vita, and tell you all about what makes it so powerful.
Stock and dev Vitas.
As you can see the two systems are pretty much identical except for the small black bull attached to the bottom of the development machine. This bull is vitally important, for without it the development system cannot load and run code at all. Each byte is inspected for purity and security by the bull as it passes into the development Vita. Any unsuitable code elicits loud and continuous mooing and the immediate shutdown of the device, requiring the acquisition and feeding to the bull of special Sony reboot hay from top-secret laboratories in Japan.
Right, that’s it for now. I’ll write more in a few weeks and we’ll see how things are going. So far I have every reason to believe that they will continue to be going well 
.