Ludum Dare 50%

It’s now over halfway through, and I’m finding myself not only well rested and unstressed, but also reasonably confident about the game (it’s even kinda fun!). I uploaded the source to Github last night, and test build 2 is available from dropbox here.

Most of my progress has been ideasmanning it up as well as tweaking and polishing before I get down to the serious business of level generation and UI. I’ve come up with and discarded a bunch of minor feature ideas, and slowly the game has morphed into something much more playable than what I had last night. Main things I’ve been tweaking include the goo interaction (with other goo). The current state is that it slowly moves off other goo, and periodically merges with them to form bigger goo. They also cancel out enemy goo (like matter/antimatter). Also of note is that there is a basic menu screen, a spartan (but functional) UI and a “Win” condition (but no lose condition).

There’s been some ripper gameplay bugs, but thankfully I cleared them out without too much trouble. Unity’s convenience of allowing me to focus almost solely on gameplay coding is really coming out, but I miss working in C++.

Advertisements

Ludum Dare 25% mark

I’m in, and a quarter of the way through! This is both my first Ludum Dare and my first 48 hour Game Jam, so I’m taking things a mix of lightning fast and slow + steady. The theme is Minimalism, and despite a bit of grumbling I thought I could do some neat stuff with it. My first playable build is complete (nothing fancy like menus/start buttons/win messages, that’s planned for the last few frantic hours).

Build 1 screenshot

Download from dropbox here.

Github API and task automation

A few weeks ago, one of the open source projects I’m following moved from Google Code to Github (and switched from SVN to Git simultaneously, which is a whole barrel of fun in the Dwarf Fortress sense of the word). The process was bound to happen sooner or later (despite the inevitable community drama), but there were a couple of semi-major issues which were holding back progress. The first was, obviously, transferring the repository history from SVN -> Git. This turned out to be easier than expected, as Git can actually convert to and from SVN natively, and all that was needed was for some poor soul to actually create a blank Git repo and import several years of active development, then push it back up to Github.

In the end, the imported SVN history had to be pushed directly upstream by one of the developers, as the pull request was to large to automatically merge. Turns out the hardest part was leaving Git running to transfer the data overnight. The process was made slightly faster by virtue of an existing Github repo containing most of the pre-existing revs (from the last attempt to leave GCode/SVN a year ago), conflicts between were solved by the simple expedient of preferencing all the newer code.

The second issue was literally, importing the issues from Google Code. In the end one of the developers ended up copying the open issues by hand, but not before some effort was spent screwing around with scripts designed to automate the process. Open source is a wonderful thing (because it took five minutes to find half a dozen scripts designed to transfer issues between the two repos), but many were out of date or relied on out of date technology. I did some experimenting of my own, and after installing half a dozen libraries managed to get a simple Python 2.7 script working – until I discovered the script timed out after importing around 50 or 60 issues. I was saved from having to tear it apart to work out the issues (fortunately or not), but I am endlessly struck by the ingenuity and usefulness of the open source community in making some things easier by making other things more complex (I guess that’s just coding in general though?).

The Github and Google Data APIs are neat though. Through JS and HTTP requests (Google supports numerous additional languages, including some API-specific) with data transfer using JSON, developers are able completely replicate and interact with Github’s interface remotely. I gather it’s mostly used for tedious task automation (such as migrating source repositories) rather than rewriting the respective interfaces though – I quite like Github’s Spartan feel, anyway.

Shuriken wrap-up

The project has concluded now, and the final handover has been finished. At some point, I might write up a proper post mortem but I think the main thing I took away from the game is that now enough prep work was done to familiarise myself and the other coder with the technology – and thus to determine whether we made the right choice early in development (or even before it starts!).

I say this, because looking back on the project the main pitfall was that milestones were consistently delayed or missed because the underlying technology wasn’t behaving as expected, or there simply wasn’t time to familiarise ourselves with some minutiae of function to achieve the desired result. The main culprit for “not behaving as expected” was the physics engine, or rather the physics wrapped – we were using the OgreBullet wrapper around an (eventually) out of date version of Bullet, the initial idea of which was to smooth out and speed up development of the core gameplay. Just “slot in” Bullet physics to get character control fairly polished early on, then focus on pathfinding / AI / graphics for the majority of the rest of the project.

The main problem with OgreBullet (apart from it’s outdatedness quickly becoming a problem) was that some functions (raycasting) simply didn’t work, or behaved completely unintuitively (rigidbodies locked the parent scenenode to their position, and did not nicely handle any form of manual transforms to be applied). The icing on the cake was that only by digging through the OgreBullet source and constant testing of different implementations was any real progress made as documentation was non-existent. Apart from that, Bullet was nicely featured and I’ll definitely use it again in future (in fact, I am using it right now).

It should be noted that a lot of time was also spent mucking around with Recast, and getting NPC movement to mesh nicely with the character controller of the week. This one was more a fault of “not enough time familiarising with the technology” than “in hindsight this tech was not the right choice.” Dynamic navmesh generation is pretty complex, but we managed to get it working and tweaked a couple of months into the project (as evidenced from various demo pictures I’ve posted earlier).

I’ll discuss different implementations we tried, and particular methods we ended up using in a later post, but this project really rings home the mantra “You learn more from your failures than your successes.” No-one would say that this project was a complete success, but I don’t think it was a failure either. We produced a sharp, good looking game with mostly smooth gameplay, and given that we were absolved from the requirement to produce a commercial success (Shuriken was a final year university project) at the end of the day the goal was to produce a game, and target it for commercial release.

0.100000 != 0.100000

Or, screenshots taken of some of the notable, broken or just plain weird things we’ve encountered using the Ogre engine. In (approximate) chronological order;

The Windmill bug:
Windmills for everyone!
We’re using Unity to lay out level geometry and objects instead of developing a level editor from scratch, and it’s worked reasonably well so far. The one major hurdle we’ve had to overcome however was 3DS Max’s up-axis – Z, as opposed to the almost universal Y. FBX files exported from Max came in on their sides in Unity. A variety of compensations at various places in the pipeline were used (using various different methods). The image above was a result of multiple such corrections having been applied simultaneously to the various structure sections – half of which had been applied early on and forgotten about later!
We eventually fixed the error and resolved the axis issue by using an exporter which auto-corrected the mesh, then removed the corrections, but for a while this caused a lot of grief.

The myth of ‘acceptable’ placeholder assets:
March of the fireants
As seen in the previous image, the twisted green creature on screen was an example of the player mesh, v2. Funnily enough, v1 actually looked much better – a shopstore dummy in T-pose instead of a gremlin from the depths of hell. It’s too bad I can’t upload the walk animation it was using, because that thing was ungodly. The image above is a screenshot of animated v3, which is v1 but with the animation of v2. Not sure if it’s an improvement, but at least it looked more human. I’d been constantly asking for placeholder assets to replace the ones I’d used to concept proof various features, so in future when you ask for placeholder assets, don’t expect them to be better than programmer art 😛 Also seen above is the ground texture used for an early test of parallax mapping.

Skeletal minions
Skeletal miniones
Setting up instancing on the meshes resulted in some interesting things. Apparently the player and guard meshes had been exported from Max with material ids not being set properly, which resulted in various, seemingly random submeshes disconnecting and flying around the map – they seemed to group up into two separate ‘groups,’ one composed almost entirely of joints (as well as part of the wrists, soles of the feet and the top of the head) which behaved approximately correctly according to physics and AI, and the other which was composed of the rest of the mesh and flew in a zig-zagging pattern around the center of the map… in a flock.

88 miles-per-hour
Unfortunately, I don’t have a screenshot of this one as it was quite intermittent, and we still haven’t exactly pinned down the issue (although it’s popped up with a couple of different models, so it’s probably an issue with the way the models were created). Basically what happened was that some random vertices were detaching themselves from the model and… moving away, resulting in hugely stretched faces intersecting and moving randomly around the map. Some of the memorable occasions when it occurred included when part of a guard’s fingers suddenly jumped twenty metres into the air and hovered above him as he patrolled around the map – it was like a gigantic piece of cloth was suspended from an invisible balloon above his head. Another time, a line of vertices detached themselves from parts of several buildings and moved in sync with the player across the map. That one was weird.

Finally, on a lighthearted note, here’s a stark reminder we received not long ago of why you shouldn’t use direct compares on floating point numbers.

0.100000 != 0.100000

Maybe next post I’ll show off some mroe of our experiments with parallax mapping… or maybe not.

the Base of the Learning Curve

We’re now over the halfway mark of the first half of development… so somewhere around a quarter complete, and it’s been a wild few months. We’re getting close to alpha, but there’s still a lot of work to go on most of the core systems, but we’ve essentially prototyped all of them now. At every corner though, we received unpleasant reminders about how things always take longer than expected.

You’d think we’d have learnt after the third panicky, last minute preparation for a client meeting, but oh well xD

Some of the more hilarious bugs we’ve tackled over the last few weeks include 88 miles-per-hour skins, the Windmill bug, Tony Hawk’s Shuriken, and of course ‘Let me show you the dance of my people,’ not to mention Nicholas Cage and David Hasslehoff turning up at the most unexpected times. I don’t think any of us have had a normal desktop for longer than two weeks straight.

Shuriken, a Ninja Game (day one keeness)

One of the people who saw the pitch yesterday just described it as ‘Batman, but with only the batarang.’ I think that’s a pretty apt description, considering you’re a ninja who throws an uber shuriken around killing mooks and big bosses. Day zero preparation was nerve-wracking, a combination of technical problems and late culmination meant that the prototype was barely prepared in time, and in the end all the frantic last minute code-wrangling to get it to compile came to nought as we pitched without it, but got green lit anyway. Moral of the story: get code-related sections of presentations running in advance. A long time in advance. Then don’t touch it. Or something. We’ve had gameplay, art and mechanics discussions going constantly since then, and some very cool things have been coming out of it.

As to the prototype, maybe it’s better if we just… forget about that code.

Here’s some background: at my university, the students dong my degree spend the final two thirds of the final year developing a full, commercial scale video game. My team concepted up a stealth-assassination game, where the player is a ninja that has to sneak around to the ultimate sniping spot, then throw a shuriken to kill the target – and the shuriken can be steered to avoid obstacles (and even avoid being seen, which will reveal the presence of the player!). The game is a #D, third person rpg-shooter combination both styled after and inspired by PS1 and PS2 games such as Shinobido and Tenchu, but draws gameplay elements from more recent games such as Batman (Arkham City and Asylum), Hitman and Assassin’s Creed.

The team pitches their concept on day 1 of the project to a panel consisting of senior lecturers and local industry representatives, who 9throughout the course of the porject) form a combination of assessor, teacher and ‘client,’ who alternately give us feedback / assistance, tell us whether we should cut back or have room to upscope and demand us to have features implemented by a certain date. That last one is a fun one, according to previous year’s graduates.

Our progress has been great so far, steaming ahead with greyboxing and prototyping from the get go, so only the next 26 weeks will tell whether we can maintain this pace 😀

One thing was for sure though, after a long day our level editor was working and more than capable of greyboxing. It’s a great feeling when your level editor is working from day one (see blog for his more indepth post about the editor).