For the past week, my server seems to be getting dos’d for some reason.

It’s quite annoying, please quit it.

Also, on the work front, not much has happened other than a major shake-up with GLESGAE being rewritten in C, and adding SDL2 support.
Yargh! hasn’t actually been started yet ( on the code front, anyway. )
This is due to currently being decanted from our house, while things are repaired… it’s been an interesting experience!

I also had a telephone interview with eeGeo, which was fun. Not sure how much my anxiety came through with me gibbering a bit, though.
They had given me a programming challenge to do beforehand, which although I managed to make a bit of a mess of it due to current circumstances, I got pushed through to the telephone interview stage anyway. I do enjoy a good programming challenge, as I feel it’s a bit more constructive in seeing how someone can actually write code, and how they plan things out. I much prefer them to the SURPRISE! here’s a three page quiz for you to do at the interview, enjoy! thing I remember getting a couple of times after I just graduated. That’s just textbook regurgitation. That said, I was still given a few technical questions during the phone interview, and I stumbled about a bit from being a tad rusty.

Hopefully we get back in our house soon, and back to normality.

I need to work! And earn the pennies!

This month, we’ve been working on Yargh! for the Ludum Dare October Challenge.

The past two weeks has involved me rewriting GLESGAE in C, and adding a bunch of missing functionality. It’s almost finished – I’m just fixing up a Tiled loader – and then we can start on the game code itself.
Octopi has gone and updated a lot of the graphics from the original Yargh! already. Cleaning them up and redoing them in some cases, so it’s just me holding things up!

Currently, GLESGAE will compile and run on Android, Linux and Windows. It has (slightly puggled) OpenGL and GLES2 renderers, as well as support for SDL2 ( which is where the current work is going into. )
‘I’ve also added CMake support, to make compiling a tad easier as there’s a lot of things to turn on and off in the code now. Though I haven’t quite figured out all the options to add my super strict ANSI flags on yet, so will need to sort that out to stop me doing lazy code.

As for the game itself, we’re going to be trying to take a different route with it.
We’re going to try and get some alpha funding for it. As such, I need to actually take some time out from the code now and then, to post updates and generally promote the game a bit. And first off, a description of what we’re up to with it would be a good start!

In keeping with the Arcade Badgers’ philosophy of breaking down barriers, Yargh! is an RTS game aimed at those that perhaps can’t play traditional, often stat-heavy, RTS games.
Borrowing a bit from The Bitmap Brothers’ Z, Yargh! is stripped down to giving you one of three main tasks:

1. Capture more islands than the other pirate leaders.
2. Amass more gold than the other pirate leaders.
3. Blow all the other pirate leaders out the waters ( or just have a bigger fleet, but blowing holes in enemy ships is more fun )

You’ll have a time limit for each map, and the totals of your islands, gold, and pirates are tallied up at the end to define a pirate overlord.

So it’s quick, simple and just enough strategy to make you think without having lots of stats get in the way. Maths and numbers can be evil and scary for people, so by hiding that as much as possible we should open up the RTS genre to more people. That’s the theory anyway!

In keeping with the simple RTS theme, there are only two kinds of units – ships and pirates – and three types of building – docks, forts and mines.
Capturing forts produce pirates. Capturing docks produce ships. Capturing mines produce gold. All come out in a nice steady flow, so you don’t need to micro-manage too much. Capture all forts, docks and mines on an island, and that island is tagged as yours. Simple.
You don’t tell anything to build anything, they just do it. You don’t require resource gathering. You just capture it by sending one of your units into the building, and the job’s done.
Pirates can capture anything, but Ships can only capture docks.
Ships can carry Pirates from island to island.
Ships fire cannons at Ships and Pirates.
Pirates can fight Pirates.

And that’s about it.
Oh, and did I mention multi-player support?
We’ll be having that.
And a leaderboard.
And some achievements.

So yes, by the end of October, we’re hoping to be in a position to offer an Alpha for some funding to finish it off.
For now, I shall leave you with Peg Leg Pete.

Dance, monkey boy, dance!

So, I had an interview with YoYo on Friday.
It was interesting, being the first interview I’ve been to in a number of years, and with the added bonus of anxiety… probably came across as a gibbering monkey! And a couple of questions put me on the spot and I froze – even though they were really rather easy. Oh well, they certainly made me feel welcome enough, and I’ll find out in a few weeks if I’ve managed to get away with my cheekiness of pointing out GM:Studio doesn’t run on Linux

Not being one to take nothing away from any interview, it made me rethink a bit on what I’m doing with GLESGAE.
I’m being rather lazy and relying a fair amount on STL.

Now, STL is nice and all, but it’s a specification that each compiler has to implement… and not all compilers are created equal. Earlier versions of certain compilers had rather spotty support for some STL standards, and being aware that just a simple call like std::string myString; can allocate more than you think!
Actually, std::string is a funny one if you’re not sure what it’s up to….
It does contain a bog-standard char* buffer for quickness. But, it’s rather small, and if your string is bigger than it’s buffer, it’ll allocate a new pointer *somewhere else* instead. Where that is, is anyone’s guess but the programmer shouldn’t really care… right? Of course, not all implementations will do this optimization, you may be unlucky and have it new some memory wherever it feels like anyway.
Dealing with consoles, you have a very tight amount of memory, and you need to know exactly what is allocating where and how much it is. It’s fairly common sense to keep track of your allocations anyway, but on memory constrained devices it’s paramount – especially when the bug bear of fragmentation rears it’s ugly head; not knowing what’s where and can be safely moved around is a nightmare waiting to happen.

Therefore, to prevent such nightmare scenarios, GLESGAE is being rewritten. Again. In straight C and providing my own containers for things.
Why?
Because.
Or more eloquently; there’s some nasty template hacking going on in JESSIE due to binding things with SpiderMonkey.. and it’s not nice. The only reason is for type safety, and while type safety is nice and all, having to perform odd looking things to make it work isn’t really worth it. It makes the code nasty to read, and a right bugger to maintain. GLESGAE has a few of these mad template things as well – and this is also what made the Resource System such an arse to deal with. So let’s just ignore all that and stick with C!

Also, I’m wondering about Emscripten again… do I just leave JESSIE and focus on GLESGAE and have Emscripten compile to JavaScript for browser platforms, and push directly to native platforms from GLESGAE? It’s an interesting one.. of course, I’m more interested in compiling out to JS by Emscripten, then pulling it back in through JESSIE. But I’m a lunatic.

Of course, I still have other things to do in the mean time.
August didn’t go hugely well for the Badgers… we got our funding in, but due to schools just starting up and illnesses in the family, it’s been hard to get any work done. The Germies patch is a bit behind schedule, for instance.
It also means there isn’t anything coming in at the moment.. so to remedy that, September is going to be an interesting month for the Badgers. We’ll be working on three games – Germies, and two others – to try get something coming in.
We missed Ludum Dare, sadly.. which is a shame as we had an awesome idea for it, but hopefully we’ll get to the October Challenge instead and get something released then. And then by November, it’s back on to engine work in a mad push for a Christmas project.