(Click for full-size)

Recently I constructed an ID card management app for a charity near to where my parents live. The charity is called  Thera and whilst I’m not affiliated it with it in any way or form I hope they don’t mind me mentioning them here for educational purposes.

Please note, however, that this is a purely technical / ‘shipping’ post-mortem. Thera have not explicitly selected my application for use yet – and they may well not use it at all. They’re reviewing multiple solutions (both commercial and non-commercial) but let’s hope they select the one developed entirely for free as a personal project: Because that’s exactly what it was. Whilst doing this fulfilled an assignment for my course, the assignment is completely formative. It doesn’t affect my grades or anything. Realistically I took this on because it was interesting.

So… What is it?

Previously (or currently, in fact) issuing ID cards at Thera was a manual process. The cards themselves turned out O-K but the workload involved creating them was huge – and not an effective process considering the advent of databases, automatic systems etc.

I created a small application to automate the card issuing process in about ~3 weeks. It couldn’t automate everything (you have to put employee details in it, for example) but after that it can filter and produce cards with the press of a button (with sequential serial numbers and everything)

What went right

• Spending a large portion of available time on the low-level model and testing. Any programmer knows that wiring logic directly behind a UI (‘magic button’ anti-pattern, as it is commonly known) is a cardinal sin. With this in mind, for the largest amount of time (about ~2 weeks) the project was purely data and classes. No UI. Just the model and a bunch of tests. And this worked brilliantly. Why? Because when I came to make the UI, I already knew the stuff underneath was rock-solid. It made things easy to debug, and also easy to make changes.

  You may ask “Make changes, in what way?”. A very good example is v1.1 which I just finished. One of the major irritations was that I hadn’t fully fleshed out modification detection in v1.0. Every time you closed a form (whether you changed anything or not) it would ask whether to save changes. If my logic were a bit more tied up with the UI, this could have been seriously difficult to fix (or at least, any solution would be difficult to maintain). With the well separated model, doing this was a piece of cake – especially since every database entity inherited from a single class. I added a modification counter and checker into the base class (~20 lines) and in 5 minutes it worked. It was fantastic. This also leads me onto my next point….

• ‘Rolling my own’ turned out to be a good decision. Generally, creating your own custom anything is a bad idea, unless you’re in new, unknown territory. Which I wasn’t – my application was database-backed (SQLite) so everything had a pre-made-solution that could be found somewhere. The snag is, every solution to storing POJOs in databases (Plain-Old-Java-Objects to the uninitiated - i.e. instances of class – so painless syncing between what you’ve got the code doing and what is stored in the database) was either annoying and required additional files outside of the code (which I really didn’t want) or had issues with nested objects

  ‘db4o’ was a top contender for a while – it was incredibly easy to sync in and out of the database without any external mapping or anything. But what bit it was that last point. Nested objects. It handles them, sure. But it’s a pain. You sort of have to be ‘aware’ of what depends on what and sort out the order yourself. That’s great, but since this this application was very likely to grow quickly (as I found out new things Thera wanted) this was not a good solution for maintainability. So I rolled my own…

  My base class ‘FieldMapObject’ completely redefines how derived classes declare variables. When they’re built, they call ‘delcare()’ with a variable name and type. The FieldMapObject remembers and stores it in a map along with type data and an initial value (null).

  Now this probably seems like a stupid solution, but actually it had many unexpected upsides. One of which is the modification counter in the above point. Putting that directly into FieldMapObject meant it instantly worked for any entity that derived from it. No modifications needed. And debugging was made extremely easy. With everything being programmatically ‘known’ by the class, it could automatically spit out printed lists of each variable and its current value. It even detected nested FieldMapObjects and spat out their data – appropriately ‘nested’ in the text.

  Along with this, I built ‘DataServer’ a class which derived from the raw Storage class I had built (the raw storage simply ran SQL queries via JDBC/SQLite and built the initial tables when it detected the DB as empty). DataServer turned out really nicely – because everything inherited from FieldMapObject (well, DatabaseEntity in reality, but that was built on FieldMapObject) it had simple routines that covered any object – put() get() discard() and update(). In fact, update() was private – put() could automatically detect objects with a valid DB rowid (thanks to FieldMapObject) and update() when appropriate. get() and put() even cater for nested objects as mentioned earlier. By running through the declare()d fields in the FieldMapObject, it detected the dependencies and put() them first (which chained nicely with deep nested hierarchies).get() ended up being even smarter in fact – later in development every entity was given a ‘weight’ (in memory). If DataServer was set to ‘shallow load’ it would automatically skip nested fields that were deemed too ‘heavy’. (Keep in mind the DB was storing images – photos of the employees. So that’s really where it came into play. You don’t want a list of a 1000 employees causing a 1000 nested photos to be loaded)

  Overall, rolling my own field mapping/dependency detection turned out great. You may think “this guy’s an idiot – he satisfied his own technology ego but doing this didn’t help the project” – in which case you’d be wrong. Spending this extra time on fetching and putting data made building the UI an absolute breeze. I mean it too – it was incredibly easy. There were a few rough edges to work around, sure, but 99% was extremely nice. I think making this system in this way made the end product far easier to produce – and as a result, less buggy and far more stable.

• Hand-crafted Swing code kicks the crap out of generated code. If I discarded everything I did on the project and started again for some reason, this one thing is the aspect I’d keep – and I will continue to keep on subsequent projects. Swing was kind of an unknown to me. Having used non-Java UI toolkits I was initially scared of hand coding UIs in it. Because normally, UI toolkits are horrible to hand code with. But eventually I bit the bullet and tried… and it was great. Granted, the UI is not the best designed thing on the planet. But it works, and it is easy to maintain. For one thing, I can read the code. It doesn’t depend on the stability of a poorly written UI designer either. It’s in the code. The only part of this I was so sure about – and I guess this applies beyond Java – is what is the correct way to lay out the reams of code that setup the UI? I split mine into functions which set up each respective part, but it still seems an unpleasant solution. Is there some accepted way to do this? But any way, using Swing manually was a good idea.

What went wrong

• Not thinking about how I would handle [UI] tables. The mechanism of dependency matching I used worked really nicely for a small group of objects. What I completely ignored (until I started developing the UI) is how I would get huge lists of employees into memory fast enough and efficiently enough to show in a table. My initial attempt was a miserable (and stupid) failure: get()ing every employee and dumping it into a List<>. Suffice to say that was slow as hell past ~1000 employees (Thera have about 2K employees by the way)

  I never really did ‘fix’ this problem. That is, I worked around it. I coded an SQL query and a matching function in DataServer that returned the employees as a raw ResultSet. My JTable manually stepped through the result set and used the columns it wanted. This worked nicely from a speed point of view, but it was a stupid solution. It broke the niceness of the dependency and object system, meaning it will no doubt become hell to maintain if I don’t refactor it. The more horrifying thing is…. it made it into 1.1 as well. And… I built a new filter system which also assumes ResultSets. So I think that’s next on the hit list. Retrofit speed fetching into the object system without compromising it. It’s going to be difficult, to say the least

• Not realising I would need to update databases at some point, as well as building them. One of the first things I had going on the project was a system to detect what tables existed in the database, and build the ones that were missing (so for example, building the table structure automatically on a new file). It worked great. What I did not do at this point (and what I still haven’t done) is to take stock of the fact that eventually, I WILL need to change the tables on a file that is already full of data. And I won’t be able to just CREATE TABLE. I will have to alter it. What’s more is that my format is lacking any kind of versioning information. The application has no idea what version of tables are in the database. Ack. I think I’ll be targeting this for v1.1.1 if Thera decide to use it
• Relying too much on buttons in v1.0. In the first version, there were tons of buttons. View Card, Issue Card, Queue All, Dequeue All, Queue Selected etc. It was confusing unless using a large screen (which padded them out horizontally). For v1.1 I switched to a menu bar (as per the screenshot). Which worked great – all the Queue functions were kept together and so were the filters. The problem is, v1.0 completely lacked any menu bar, and the sudden change was both jarring and confusing for anyone but myself. I suppose the lesson here is to think ahead with what you’re likely to add – because after all, I only added a menu to make space for new commands (no more space for buttons). This comes to lack of foresight I suppose

Stats

• Total physical Source Lines Of Code (SLOC): 4602  (excluding field mapping library)
• v1.0 completed: 23/04/2010
• v1.1 completed: 01/05/2010
• Libraries: Swing, JCalendar control, SQLite JDBC, Swing layout extensions
• Subversion checkins/commits: ~150   (~3 week development time from start to v1.0)

Currently I’m designing / prototyping ‘codename Spitfire’. It’s an idea I had during my ~2 years developing and maintaining a database system for a local charity (Voluntary Action Rutland). Suffice to say it is database related. And I’d also love for to be able to drop in the completed system as a replacement for the one I developed previously (with some alteration. And assuming it gets finished).

Back to my notebook for now….

My notebook. I love arrows.

For a long time, I simply ignored coding and my projects – at least in my spare time. Very quickly things became dull (yes, that makes me a sad person). But I realise now that one of the great parts of having such an involved/interesting hobby/side-project is that it fills the void when everything else isn’t very good or interesting. Rather than thinking about some benchtest I failed, or how long the term is, I can put all that to the back of my mind and hammer out some code. It gives a focus when everything else has turned to shit, effectively

Well back on topic: I forgot about all that. So I neglected my code and my projects when I first got to uni. It made for a fun, but far more depressing time. When things were looking bad, there was no light at the end of the tunnel. I’m telling you… coding is a drug. It makes everything great…

So at the first chance I got, I immersed myself in code again. And now things are back to normal. I’ve also sorted out what I’m doing code and project wise, which is why I’ve made a return to the blog (without code, what’s the point in blogging on here? It’s the entire topic of discussion!)

Java

I was initially sceptical about Java. Even in my previous post I wasn’t entirely convinced. But now I’ve ‘seen the light’. Here are a couple of reasons:

• It makes application of decent SoftEng. principles really easy
• You can make variable-argument functions with amazing ease (maybe I missed something, but I found this far from trivial in C/C++)
• It helped me understand generics, even though C++ had templates (and Java generics are in fact more limited than templates. No idea why I never made use of templates properly)
• It’s fast to develop in, but the syntax is not insulting or eye-bleed inducing (and it’s similar to C++)
• It runs fast. The VM can push along some seriously complex things at damn quick pace! It surprised me – a lot.
• You can try new (risky) things, and if they’re wrong, they’ll break immediately rather than appearing correct and breaking further down the line. (This one is difficult to explain but I would often implement something crazy in C/C++ thinking it was correct, only to find some horrible flaw in it weeks or months later. This doesn’t seem possible with Java)

All in all, these reasons mean that unless I need to work with the raw underlying OS for some reason, Java is going to be my weapon of choice for pretty much everything else (and heck, I can even code JNI libs using C/C++ and plug them into my Java apps)

Project status list

• The Hive: Dead for now. (May be resurrected in Java)
• IP summative project (BlackJack): Complete
• IP formative project (‘Wormhole’/Millipede with OpenGL): Work-in-progress. Could be released if it’s good enough / if it doesn’t become property of Durham Uni.
• ‘Project Spitfire’ (server/client ‘dumb terminal’ style database engine): Prototyping

A-Levels

I got ABBC in the end (A in Computing, B in History which was annoying, B in General Studies,  and C in Theatre Studies) which exactly matched my offer, so I’m off to Durham to study Software Engineering on the 3rd of October!

It all seemed pretty anticlimactic afterwards, but I’m pleased it’s all done and it all turned out OK. Computing coursework seemed to have melted in marks somehow (an explanation of which would be very… interesting to say the least) but other than that, “meh” pretty much covers all bases. I need to go back to school at some point and just set the place on fire. Either that or thank teachers. No idea which one is more appropriate at the moment (with the recent “hubbub” over kids blowing up schools recently, I would like to clarify that was a joke, however)

The Hive

The Hive is currently a bit… bleh. Things were really going well and the gameplay was coming together (the fact there was anything testable meant it got further than the Wormhole remake, for example). I really did want to get it done and completely out of the way by about now (real deadline was 28th – which it could have hit) but I’ve just had no time to work on it as of late – more charity database stuff, driving lessons and general laziness (oh and Alpha Centauri binges) slowly eroded the available time. And of course, the longer a project is put on ice, the harder it is to get back ‘into it’ again.

There is another issue too – before the time melted away, I was working on a very large change to the game. To make it easier and more rapid to develop, I decided to stop aiming for highly polished, epic platformer, and go for  more of an arcade theme. For example, I was removing separate levels, and made it so the levels “built themselves” over time like tetris blocks (so complete the aim and the level expands in size, rather than “changing screen” so to speak). There were tons more little tweaks which would have made it quicker to develop too, but it certainly has lost momentum either way. There are now a few options:

• Drop it. Stop development and give up. I don’t really want to do this, since a project to work on in my (now minimal) spare time is nice
• Continue. Get “back into” development again on the current version. Whilst I think this is the easiest way to go about getting it done, it still has a long way, and leads me onto my next point
• Change language. Simplification is great, but I think I’ve reached a plateau on the amount of time I have vs. the amount of time it takes to implement the game in C++. I’m leaning toward this option (explained more below) but I haven’t decided yet

Down with C/C++

One of the reasons I learnt C++ was because most of the other languages I knew had become boring and tedious. The languages themselves were no longer interesting, and I had ended up repeating the same coding tasks again and again on each project. I leapt to C++, and the freshness and challenge was invigorating – I created a few of my most complete projects immediately after this phase – Wormhole and The Hive (game projects, at least. I have tons of other complete projects but they’re mainly tools and are not especially interesting to most people). And even though these games sucked, they got done. I should have continued this path (created crap that got done - because that way the quality would gradually increase)  but I didn’t. I shot for the moon and had a string of unfinished turd balls. One game became very nice looking and very nearly finished – Rockets. It was obliterated by hard drive failure, however, so one of my most promising games was snatched from me at the last hurdle (suffice to say that nowadays I have a backup system running continually every hour)

So what does all this mean? It means I’ve become too comfortable with C/C++. I’ve stopped concentrating on the challenge presented by actually implementing the games themselves, and I’ve become hung up on the elegance of the code itself. The language itself has stopped being challenging (not to imply I know it inside out – but I know enough for the tasks I do) so I’ve created new challenges out of nothing (perfecting code which the end user never sees, ironically). The game is no longer the highlight, purely because of the language I’m using. It has become a pillar… a safety blanket, if you will. As a programmer, I think one of the best things you can do is to continue challenge yourself to learn new things – and as it is, I’m learning very little. I’m simply applying what I’ve already learnt again and again.

What I need to do is move to something where the code itself is secondary (if not simplistic) so the game shines through. This removes the safety blanket, so I keep development down to bare necessities, rather than elegance. And so the project itself (and its completion) is more important than what makes it up (the code). Hopefully, this way, my projects are much more likely to succeed. At the moment, I’m experimenting with Java. Not only is learning it a completely new set of challenges (similar syntax but a completely different build/creation process) but it also makes my time input much more worthwhile (the code is inherently portable).

So… to conclude. I want to move away from C++. Native code has been fun, but I think games are quickly outgrowing their need for it on PCs. And my game projects certainly do not need the power provided by C++  - they need the flexibility and portability offered by Java more so. I haven’t decided exactly what to do with the Hive yet, but let’s wait and see…

75 million Mac OS X users. Apple claimed that the OS X user base magically jumped from 25 million to 75 million active users in two years. But it didn’t. It jumped to 35 million users. The other 40 million are using iPhones and iPod touches. So if there are 1 billion active PC users (and that’s an old figure), than OS X usage share right now is 3.5 percent. Everyone’s onboard with the math, right? 3.5 percent. “No wonder everyone is trying to follow in our footsteps,” Apple SVP Phil Schiller said. Right.

Whilst Apple’s numbers could be dubious, this point is… pointless. “The other 40 million are using iPhones and iPod touches” -  which run OS X, yes. What’s your point, Paul? “So if there are 1 billion active PC users (and that’s an old figure), than OS X usage share right now is 3.5 percent.” Yes…?

I assume Paul is trying to purely dig in at market share percentage here… or at least I hope so, otherwise his points are rather dvoid of… point. This is an idiotic point of view to take, because it removes the perspective of that being 3.5% of one billion which is still 75 million. 75 million is an absolutely massive number – yeah, sure, it may not parallel the PC market (which is multi OS, not to mention the most popular OS having an ~8 year leapfrog over OS X) but that’s still huge for a single hardware manufacturer, assuming the quantity of “hackintoshes” is negligible (The PC market is not a single manufacturer, in case you haven’t noticed, Paul). Paul, as ever determined to make Apple look bad, however, must present it as a percentage, and forgets the context of hardware (Apple being a hardware company is an extremely significant distinction)

Macbooks magically become Macbook Pros. Apple rebranded the 13-inch Macbook as the Macbook Pro and added SD slots across the line-up. FINALLY. I’ve only been asking for this handy little feature for, what, 6 years? The batteries are non-replaceable

This is a valid point – but not really that valid. I don’t really give a damn what you want or need. How about raising the fact that by adding an SD card slot, the machines no longer match their desktop counterparts? That’s a much more useful (and objective) “beef” to raise, since the expected interopibility is destroyed. (Although it may well be a hint toward the features of the next generation of iMacs)

Windows 7: “Even more complexity is present in Windows 7. The same old tech as Vista. Just another version of Vista.”

Snow Leopard: “We come from such a different place. We love Leopard, we’re so proud of it, we decided to build upon Leopard. We want to build a better Leopard, hence Snow Leopard.”

Um. They sound the same to me. Jerk.

Here, Paul demonstrates his inability to read/listen. “Just another version of Vista” vs. “build a better” Leopard. Clearly Paul’s powers of inference are at simian levels, because it’s quite clear Apple are trying to imply they’ve improved Leopard, whereas MS are rereleasing the same OS without improvement (which is technically untrue, but the statement makes sense, and isn’t “the same thing” as Paul states it is. Learn to listen and infer, jerk)

For the record, Snow Leopard looks just fine to me. It should, after three years of development on a point release.

In a stunning case of irony, Paul forgets that Vista was RTM complete in 2006, making Win7 (assuming 2009 release) also a three year development for a point release. Epic fail.

Mac OS X is not fully 64-bit. While Windows users get 64-bit versions of Windows, Mac OS X users will, in Snow Leopard, get an OS in which most of the system is 64-bit, but many “non-major system apps” are still 32-bit.

Yes Paul, well done. That’s called a strategy. A strategy that has been going on for the last few releases. Rather than switching directly, or releasing two separate versions of the OS, they’ve made x64 a transition for OS X rather than an outright change. Also, reversing the wording of something doesn’t make it right, Paul. It was stated “Major system apps” are now 64 bit – that doesn’t make the reverse true. It may have been, and this may surprise you Paul (it being a conference and all) that this was a key point of interest for the presentation (as in, it’s an achievement that these major system apps are 64 bit, considering the pain and effort required to bump them up to that level etc.). Overall, Paul has just ignored the point of seamless transition to try and make a petty point. Boo! I say.

Snow Leopard pricing. Apple is finally charging the right price for the latest in a long list of minor upgrades: $29 to Leopard users. This is exactly right, and should serve as inspiration for Microsoft. Seriously.

Agreed (and not just because of the dig at MS)

iPhone 3.0. The iPhone is really popular, and let’s face it, it’s awesome.[...]

No comment (I haven’t used an iPhone, this may be a valid point)

Apple needs to tone down the boring stuff. Look guys, here’s another iPhone app. We get it. Move along, please.

It’s a developer conference. Hence the name. What the hell were you expecting?

iPhone 3G S. Was curious what they were going to call the iPhone 3, since the iPhone 3G was the iPhone 2.0.

No comment

Voice Control. (3GS only.) Apple copies Microsoft Sync, no one notices. And by the way, the notion of talking to a smart phone should be obvious. Just saying.

I think the copying accusation is fairly moronic – not just because voice control is as old as mobile phones themselves, but because… well, maybe I’m a minority but what the hell is Microsoft Sync? If I have no idea what it is, I doubt Apple or the audience know what it is. Oh, and the idea/concept maybe obvious, but the devil is in the details – way to try and water down what is essentially extremely complex tech. at work, irrespective of how “obvioust” the initial idea is

Next week I move onto Stalin’s Russia (again). That’s going to be more date learning I think, since the synoptic nature of the paper leaves little actual “need to know” material. Provided I ‘get’ the sources, everything should be fine. After the steady sailing of the history revision though, the blitz begins. Computing, whilst very easy, does need memorising. The mark scheme is a fickle thing, and I need to ensure I know the Welsh approved answers for everything.

Then I have to squeeze in Brecht, Our Country’s Good, The Rivals and generic synoptic stuff – yep, Theatre studies. The one A2 exam I thoroughly dislike, due its length.  After all this… who knows. At the moment, the time I have seems massive. It will soon shrink though, once I look over how much I need to do again :/

Where in the world is Waldo the Hive?

The Hive is sort of in limbo at the moment. It’s going well in general, but as exam revision revved up, the focus was lost a bit. Restarting development after exams may be tricky. Luckily though, the ‘vision’ is all worked out. I know roughly where I need to go to get from A -> Z and I know what’s missing. It’s just an issue of filling in the gaps.

Other problems have (or are going to) crop up though. I need to test on Vista. I need to create a proper sound caching mechanism, I need to get regular or semi-regular testing with newbies going,  I need to know whether the Hive is going to be of high enough quality to warrant a release party of some form (!!) or being sold (!!!) and whether it’s worth getting publisher/portal distribution (!!!!). These last few are really tricky to measure. In it’s current state it’s an instant no. But as the game starts to come together (most notable, I need to get the HUD, weapons, power ups, ‘shop’ etc. working) it may have that glimmer of awesomeness. Or it may still be incredibly dull to play. Fun is hard to schedule. But I’m excited to see where this goes…

The problem, however, is the release date. “When’s it out?”.  Deadlines are extremely difficult to construct – sure, you could take an arbitrary date, and use that. But that’s a stupid deadline: you need an informed deadline, that’s actually based upon tasks left (and gives you a bit of extra time for polishing off etc.). I could easily make a deadline like that (I think), but the big problem is life. Unlike a studio, or ‘pro’ indie developers, the effect of every day life upon my work, and my work ethic, is very hard to predict. Combined with exams, it’s also a mixture for disaster – and I don’t want to commit to a solid deadline during the summer, since I have no idea what I’m going to be doing during the summer yet.

So how can The Hive be released without a deadline? I’m not sure really. The other problem I need to contend with is the “everything but” scenario. This happens each year after exams – I find that with a big glob of free time, I actually end up doing everything but the game. Annoyingly I also think of some amazing new game ideas mid way through constructing the current game (it’s really difficult to fight the urge just to move onto working on little segments of a new game…).

But I’m a bit more confident this time around. Because the end is actually in sight. As a rough estimate (without taking into account the effects of life + exams) I would say another month and a half on actual game code (Game entity logic, weapons, powerups, UI etc.) and another month on polish (Correcting niggly problems with control, improving playability and UI flow etc.) and level construction (this is a lot harder to predict – I need to use a week or so to design the levels first, because that isn’t done yet…)

That makes the provisional release date the 28th of August. It’s likely that could be compressed quite a bit – or it may be overshot completely. It’s hard to predict what might happen during the summer. But I’m working on it..

Pre-alpha 2 (090409)

The included level gets you triggering the collapse of honey blocks (the star blocks) and then collecting them. You also get to ‘play’ with a physics-powered dynamic block (the red one). Although the exit will illuminate when you have all the honey blocks you won’t be able to go through it.

Please read the included readme.txt so you are aware of the controls (particularly for triggering the button)

Download here (Unzip and run)

Changes in this build

* Button hull fixed
* Increased cell surface friction
* Fixed kernel message pumps in Physics/World/EditorControl etc.
* Exit now provides a high degree of friction
* Routines and data for saving and loading state of triggered honey blocks
* Shield surface now uses circular physics hull and provides 1+ friction
* World actually Activate()es after load
* Made the shield blocks into a walkable surface hex, rather than a ‘canopy’ (easier to implement)
* Added new button graphic + button pressed graphic
* Body now has GetVisualNode()
* Buttons actually work and respond to ‘E’ (use key) and fire events when applicable
* All objects attach their entity* ptr as user data to their physics hulls
* FillCollisionBuffer() implemented
* Honey blocks disappear and fire events too
* World responds to button events and triggers honey block falls
* Cleaned up honey block code
* Added jump-ground sensor to player (no more double jumping)
* Found a huge, nasty linked list bug in IronSpring (Fixed)
* Added the dynamic Cell
* Cells have alpha enabled now
* Editor control skip/order change
* Exit can now light up etc.
* Honey blocks have lower density and friction (and restitution)
* Level moderator added (Works out how many blocks need to be collected, fires events to enable the exit)
* Added version details
* Got rid of lighting
* Subtle graphical changes to fix ‘black line’ corruption
* Drawing/updating only performed when active window (complete with PAUSED caption when inactive)

‘Enjoy’

“The Hive” pre-alpha (no gameplay)

Download link (Dropbox) <- Unzip, and run the EXE. It isn’t antivirus scanned, but it is extremely unlikely it contains anything nasty. Run at your own risk.

Use arrow keys to move, and space bar to jump

**THIS IS NOT FINISHED SOFTWARE. IT HAS BUGS. IT HAS ISSUES. APPROACH WITH EXTREME CAUTION**

Release notes (as per RelNotes.txt in the ZIP):

• Runs at windowed 1024×768 in Direct3D9 in 32 bit colour (by design)
• Physics is fixed at once per millisecond [1/20] by 10 iteration timestep. If you experience very fast or very slow motion, please report a bug/issue.
• The button object (a button with a downward pointing arrow) is currently ‘unjumpable’, since the physics hull is wrongly implemented as a box. Please do not report this as a bug (it’s a known issue)
• Tapping the space bar to jump multiple times can result in ‘flying’. This is because the ground contact resolver is not yet implemented (so the game currently ‘guesses’ when you’ve stopped jumping). This is a known issue.
• The exit doesn’t work (this is simply an engine and motion test)
• Falling off of the level structure will not end the game (no game over etc. just infinite falling)

Please report any and all bugs you find! (Especially if the game is unable to start)

As mentioned previously I’ve been playing with tons of ideas – and I wanted to investigate a Worms-like game

Initial playing with concept

One barrier to creating games is originality.  Whilst I’m always trying to get a game done, there’s also the thought in the back of your mind that “If this gets done, I want it to have significant impact: I don’t just don’t want a generic clone. I want something that can stand up on its own”. It sounds stupid, I know – after ages without a decent input, I should really be desperate for ANY game, regardless of how original, to get completed successfully.

Unfortunately for the Worms concept, this ideal has remained fairly prevalent – it appears I won’t be happy working on anything unless my creativity for making new concepts is satisfied. I think it’s a good quality to have, but it doesn’t serve me too well in my current position. But, having some time, and some space to ‘play’, I decided my urge to do something creative, and warp the Worms concept, could be good

Games with meaning are pretty cool – or, could be

Recently, I’ve been learning a lot about Brechtian theatre – ‘Epic’ theatre, that is designed to inspired, inform and educate. I decided, that whilst revising this, games should try and gravitate toward this idea too. This is much easier to achieve in games than Stanislavski’s ideas (see my post about that), so I thought I might actually try it out – a game that whilst fun, also presents an interesting meaning (or at least, ‘food for thought’ – it isn’t necessarily direct education, as the piece/game could present conflicting ideas, and allow the audience/player to decide)

The result of this is my idea “Bust or Bust” – my rather naive , and not fully-formed, game concept regarding the current economic climate

The concept

In this game, there are very simplistic action-based mechanics. Think pac-man – collecting objects. In “Bust or Bust”, however, these objects are more symbolic. So whilst the gameplay is extremely simple, it is a distilled meaning of a greater idea (That the economic climate sucks, and people are taking advantage of it at our expense – being my main point)

• The player starts as a ‘neutral’ person (average in appearance)
• They are surrounded by a mountainous structure composed of blocks. Each block has a dollar sign on it, and is modeled as a physics body – so they can fly around, be broken off the ‘pyramid’ structure etc. All the blocks together represent the economy.
• If more blocks are being built, the economy is improving
• If blocks are being destroyed / there are few blocks remaining, the economy is being destroyed
• The player can choose either one as a goal
• They collect ‘pellets’, which are actually ‘bail outs’ in the game (I plan for these ‘pellets’ to resemble pieces of paper, representing acts which give the player cash. Hence collecting these is a positive action, or at least, for the player)
• Once the player has collected a certain quantity of ‘pellets’, they can use them to do something. My simplistic proof-of-concept, was that 5 pellets bought a bomb (which could be used to destroy economy blocks, and somehow benefit the player) and 6 pellets bought a hammer (which could be used to create economy blocks – helping the economy, and not necessarily the player). The point here is that it makes it more desirable for the player to exploit the ‘economy’ because bombs are cheaper – they can get more for their pellets, and help themselves too. But the hammers are more expensive, and don’t help the player.
• But, here’s the catch: Whilst the ‘bomb’ provides the easiest seeming root, the hammers actually benefit the player in a more subtle way. Bear in mind that I envisage this is a single player ‘Soldat’ type game – whilst trying to get the pellets, the players can shoot each other etc. – so the hammers, could, for instance, have the advantage of giving the player more protection (shields) or better weapons to fight the other players. And the bombs, while giving the player an advantage in money, could disadvantage them in other ways – make them swell up big and fat, making them a big slow moving target etc.
• As the above point demonstrates, this probably means the best game play tactic would end up requiring ‘dabbling’ – sometimes using bombs, sometimes using hammers. If the overall point of the game is to make money though (and say, the hammer users get a very small amount of cash per hammer use) then this could encourage interesting strategy. Player’s wouldn’t want to bomb all the time, because they get big and fat, and become easy targets (maybe dying loses you money?) whilst they wouldn’t want to ‘hammer’ all the time either – because they don’t make nearly enough money.

Overall, whilst this concept is still extremely ‘rough’, I think it could provide interesting gameplay, without completely forfeiting my original intention – meaning (It’s easy to exploit the economic situation if you’re in the position to do so -but it will have dire consequences. Fixing the economy is difficult in the short term, but has a massive advantage for all)

So, off to try it out!