#%£@!!!

We've run into a bit of a problem here...
Unfortunately, the idea I had for the level intro sections is impossible without use of an extra module and a shizelload of manual pixel-by-pixel fiddling to make it fade in. See, in SDL (the C++ module PyGame uses), there are three types of alpha: colourkey, surface and per-pixel. Colourkey is the 1970's-reminiscent idea of having one colour in an image that is converted to transparency, so you'd put your non-rectangular image on a purple background for example and that background would be removed by the program. It's not particularly useful when you want smooth edges. Surface transparency makes an entire image (rectangular of course) have a certain alpha value - so, for example, every pixel in the image would be half-visible. This is what I use for fading in scenes. And finally, per-pixel is where every pixel has its own alpha value - this is necessary for the spiffy transparency effects on the level intros text box.

And here's the thing - you can't use surface alpha and per-pixel alpha on the same image. So to have it fade in, the text box needs to be completely opaque and rectangular. And to have the cool alpha effects and rounded corners, I leave myself unable to utilise the benefits of surface alpha for fading in. Without the fading, the text box's entrance looks particularly rubbish; and it's just disgusting as a rectangle. So, it's back to the drawing board.

I've decided after some deliberation, collaboration and thinkingination that actually the level intro sequence might look better without a text box. If I implement a text box, I know I'll end up making it draggable simply because draggability is so cool and it's always enjoyable to code, and then the continue button will be attached to the text box, and suddenly we have Microsoft Windows in game form. It'll almost certainly be better for Slipslide (and the player) if I actually design a unique interface for it, as I've done with the main menu.

But meanwhile, on the brighter side of things, Slipinator (the level editor) is now underway again. I'm working on a drag-'n'-drop method where you drag objects onto the level, and it's actually been very successful so far. Not only does it not crash now that I've done away with the 500 buttons approach, it also means that holes and other things can now be added as well as just blocks. And it's only taken me 200 lines so far!

Level intro text box demo

I've now finished a working demo of the text box system that will be used in the level intros module. Using a bit of nifty programming, I've created a system that builds a text box from four images; the two top corners, a 1*24 pixel image to tile between them and a 1*2 pixel image to tile across the rest of the area. I also coded a spiffy effect that makes it fade in whilst expanding when the intro scene first starts - and although this is impossible to properly show through screenshots, I'll have a go...

When the scene starts:


When it's finished fading and expanding:


To see the box properly you really need to view it full-size by clicking it; the scaled-down versions above lose all the detail and look almost plain blue, whereas full-size there are lots of nifty details. There's also a transparency effect that'll be visible when I put the animated clouds in the background (coming soon!).

Many, many bugs fixed

The original fade-in method turned out to be very buggy; firstly, when fading levels in the character appeared on top of the fading level. Also, the fade was incredibly jerky at times, as the algorithm was particularly inaccurate. And on top of this, the scene was completely frozen whilst fading was taking place, which to be honest looked rubbish - for example, this meant that if you moved the mouse whilst the title screen was fading in, the text would remain still and then jump to the right place once the fade was finished.

So I completely re-coded the fade-in method so that instead of capturing the screen, altering the alpha value and then blitting it each time, it now uses the parent object's update method so that the scene you're fading into runs normally. Meanwhile, it blits in a plain black square with an alpha value on top of the scene, so that it's really just a black square that fades out with the scene behind it. This is now working perfectly, with no glitches at all so far!

As well as bugfixing, I've also been redesigning the filesystem some more. At the beginning of development, it was decided that music would be put in the level folders so it could be easily loaded with the level by supplying only the folder name. But this means that there needs to be a music file inside every single level folder, and with the average file being around 2 megabytes, 25 levels will take up a massive amount of space. So instead of that, I'm now storing all music in the engine's Data folder, and and the level controller has been modified so it takes the path to the music as an argument. I'm going to have a total of ten tunes, one for each main area in the game, so the final game's file size will be a lot smaller this way.

Now I'm moving on to designing and coding the level intro sequence module. Screenshots to come!

The joys of fading

Today I've started writing a new class for Penuine that can be used for fading scenes in and out at an arbitrary speed (and the fadeout end colour is also variable). So far the fade in method is working, and I've implemented it in the main menu scene and the level controller. The difficulty with this new class will be not overusing it to the point of it becoming annoying; it's very hard to resist making almost every scene fade in and out simply because it looks cool!

The superawesome menu of awesomeness!

Finally, the main menu is complete. And I have to say, I'm incredibly proud of how it turned out! Take a look for yourself:

Unfortunately, a screenshot can't do it proper justice - that's not just a cloudy background image you see there, it's actually four layers of fully animated clouds moving in real-time with the text in between them. And the options at the bottom aren't static either; move your mouse to the right-hand side of the screen and they'll all slide over to the left to reveal the options on the right.

All this has resulted in a 250-line file, making the main menu module the largest module in the entire engine - larger even than the level controller! It's been incredibly complicated to program all the effects and get them running at a reasonable speed, but I can honestly say it was worth the effort.

Anyway, I'm off to spend the next few days patting myself on the back.

The finished pause menu

And now it's complete!
It now renders text, and has clickable options for continuing and quitting. Also, it's draggable so you can place it in any part of the screen. This could be useful when you want to look around the level while the game is paused. It also looks incredibly cool, which is the main reason I developed it that way - now Slipslide has a Windows Vista-esque interface! Yaay!
But my words probably mean nothing to you without a screenie, so here you go:
Unfortunately the scaled-down image above doesn't do proper justice to the menu; click it to view full-size with all the subtle yet nifty effects visible.

With this done, we just need a proper character and animation to be implemented before we can finally release gameplay screenshots outside of this development blog. And at that point, it'll be less than a month before the final game is complete!

The countdown begins...

Pause menu now working - with perfect alpha!

After many an epic duel, I've finally got the pause menu to display. Well, the background anyway. The rest will come in time. For now, behold the screenshot!

As you can see, the character and level are partially visible through it! That's the incredible power of per-pixel alpha in action there. Thanks go to Pash for the making the amazing image of course.

The per-pixel alpha didn't come easily unfortunately; it's taken a lot of faffing to get it to work. For a long time it was drawing it with absolutely no alpha whatsoever, and there were nasty pixellated sections everywhere. However, it turned out to be caused by simply forgetting to update the background behind it each frame - so the pause menu was being drawn on top of itself again and again, which naturally would eliminate all transparency after a few frames. I fixed it by adding one single line to the pausemenu module. That's programming for you.

Latest Slipslide 2 progress update

At the moment, development's completely all over the place; we're stuck in the twilight zone between the basic engine being complete and starting work on levels, characters and sounds. There's still no character sprite, there are broken test levels scattered everywhere, and the engine has a lot of holes in it. As well as this, we've had to temporarily stop soundtrack development due to a disagreement over how to do it.

However, on the positive side, the story is almost finished, and it grows more interesting by the day. For example, Dan's going to end up skating around the surface of Pluto by about the middle of the game! My idea is that once the story is finished we will agree on a plan for finishing the rest of the game; possibly beginning by designing the character. However, this will need to be discussed when we next meet.

Level Layout Design

Hey, well I have been doing some level layouts for the game and I have quite a few different difficulties ranging from hard to.. well, erm hard. I am finding it awkward to design a level easier than what I have already. in my second post I will maybe show you a couple of layouts that I have designed to see whether you can crack them. if you can then I will continue to make more and if you cant... I will continue to make more.

The engine redesign is complete!... or is it?

I say this as a strange new bug has cropped up - when the level is restarted, the player simply won't redraw! So now we have a secret, "not actually programmed at all" multiplayer mode appearing every time the level's restarted. Luckily, it can still redraw when the player hits a block (bye bye, second player) but it can be very confusing having two iterations of the character on-screen at once.

But fear not, as this bug is balanced out by lots of superawesome goodness! Firstly, look closer at the screenshot above. Click it to view it full-size if you need to. Or, better still, I'll stick in a close-up shot on the left. Done. What's that odd brown thing then? That, my friends, is a hole; a bottomless chasm leading to instant death. Touching one of these will make you restart the level (the result of many a battle with Python). Impressive, no? Well, yes, the image used there doesn't work all that well. But it's just a place holder of course; any 24*24 tile could be used.

And, as mentioned in an earlier post, non-rectangular layouts have been made possible by a new system that reads the wall from a file. A text file in courier font speaks a thousand words in the Trebuchet font, so here's an example:
WWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWFWWWWWWWWWWWW
WW00B000000000000000000WW
WW0000000000000000000B0WW
WW0B000000000B000000000WW
WW000B00000000000000000WW
WW000000000000000000000WW
WW000000000000000000000WW
WW000000000000000000000WW
WW000000000000000000000WW
WW000000000000000000000WW
WW00000000000000000B000WW
WW000000B00000000000B00WW
WW00000BCB0000B00000000WW
WW00000B0B0000000000000WW
WW000000000000000000000WW
WW00000000000000000H000WW
WW000000000000000000B00WW
WWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWW

Those of you who were paying attention during the last paragraph will probably have guessed that the W's denote walls. The more intelligent among you will have inferred that the B's represent blocks and the 0's are for empty space. But the other two may confuse you slightly, so I'll explain them - C is the character start point and F is the level goal (or finish). This method means an end to complicated *.DAT files that had to be stored in a level's folder to explain where the walls are and where the end is, and as the area doesn't need to be rectangular it is now possible to have a level goal that is actually within a path leading out of the level boundaries.

With any luck, you'll now have forgotten all about the disastrous bug I mentioned earlier so we (I actually - no-one else understands the arcane engine design yet) can go back to trying to fix it. Enjoy your blissful ignorance, fools!

Mwahahaha.

Major design shakeups

It's now been a full month since we first began Project Penuine (that's Slipslide 2). Still no in-game screenshots to show. However, a lot's been happening, despite the fact that the blog activity may suggest otherwise. The story's now in progress, and without giving too much away I can say it's going to be epic. Dan (the main character) has moved house this time, so the next-door neighbor's dogs are now gone. However, there twenty-five brand new levels full of risks far worse than just dogs. For example, there will now be holes in the ground for Dan to fall through, made possible by a redesigned level system.

Whereas the level loader just used zeroes and ones when the project began, it's now undergoing heavy redesign to allow for many more features. For one thing, the levels no longer have to be rectangular. The new system uses letters instead of numbers, and has removed the need for putting in extra files into each level's folder telling it where the walls are and where the finish is. It can be stored entirely in the layout.slf file, with the only other necessary files being the level's images.

Another thing that's being redesigned is the file system structure - all the game levels are now being put into one folder called "Levels", with sub-folders for each level located inside. Data such as the character images and saved game files are being stored in a folder called "Data". This is mainly to make the game simpler for me to organise, as the number of folders getting a top-level directory before was verging on ludicrous.

Of course, all the redesigning work that's going on at the moment is causing a lot of problems with the test levels. Once the work is finished I'll be going back and converting them all in case they're used in the final game, but at the moment the only one that works is the very first one (which I've been updating in order to use it to test the new system). I also had to fix a major bug this afternoon that meant the character was being drawn at the position (-1, -1). Now although this wouldn't seem too odd using a normal Cartesian co-ordinate system, in computer programming it's generally not a good sign. In Python, "-1" denotes an unspecified value - for example, if you passed this as an object's ID this would make it automatically generate a new ID; or if you supplied it as the number of times to loop a sound, it would continuously loop forever until you killed the program. So it was essentially drawing the character everywhere, anywhere and nowhere all at once. Eventually I found it out to be caused by remains of the old system conflicting with the new one, which was quite easy to fix once I'd narrowed it down.

There are still a lot of things needing added to the new loader (and the character file NEEDS some comments to explain the convoluted coding). Luckily however, we have a new member on the team, which will make it a lot less difficult to get it up and running. Also, the blog just surpassed 100 hits! Now wouldn't it be nice if we actually got a comment or two at some point... ;-)

Just in time!

I suddenly remembered that it's actually bad luck to have decorations up after Twelfth Night yesterday, and with but minutes to spare I leapt into action and took down the Christmas banner. The luck of ExeSoft is saved! So don't worry, Slipslide will probably be released on time!

What do you mean 500 buttons is too many?

So I started on the level editor today, and it's actually been going quite well. However, it turns out that my method of programmatically adding in a grid of 25*20 toggle buttons to represent the grid squares isn't really going to work apparently - I didn't think the idea through long enough to realise that adding five hundred individually functioning buttons, each with two 16*16 pixel high-quality *.PNG images to load, would crash the computer.

But on the bright side, it was a very spectacular crash. First I got the classic sandtimer cursor to appear and then freeze mid-animation, so it was actually sitting sideways, then the application's window appeared in two places at once - half was in the normal position and half was in the top-left corner of the screen, with funky black and white lines attempting to hold them together. Then a window appeared saying "Error: Out of system resources!" before promptly disappearing under a wave of long-awaited buttons which proceeded to draw themselves very slowly, one after the other. At this point, I quickly killed the process using the Windows task manager. And with all the speed with which the carnage had arrived, everything fell silent.

So, yeah, computers aren't meant to handle 500 buttons. Which means I'm going to have to look for a different approach; maybe I'll write a custom GUI grid thingy myself at some point. It can't be that hard to do anyway; Microsoft had something similar in their Minesweeper game that comes with Windows and it loads in milliseconds whilst using almost no system resources at all.

Another year ends, another begins

Once again, it's time to make unreasonable promises to yourself, break them within the hour, drink obscene amounts and set off spectacular explosives all in the name of tradition. 2007 is now last year's thing, long live 2008!
For ExeSoft, the last year was an eventful one. For one thing, ExeSoft didn't even exist until just after the halfway mark. So, to celebrate the year's success, here's the year in JPEGs (with a couple of PNGs thrown in for good measure of course):

First, there was the long-awaited release of Slipslide 1. This one had been delayed for months, and unfortunately didn't end up being as good as had been hoped. It was ultimately too glitchy and had only five levels, one of which was a slide-downhill-avoiding-obstacles affair thrown in to stretch out the length and difficulty. However, the lesson was learned. That style of puzzle game does not work in 3D.

Then, much later in the year, David's Random Programs, inc. and David's Random Games, inc. were merged and renamed (thankfully) to ExeSoft, as the old names were terrible to be perfectly honest. The newly formed company began by re-doing programs made by David's Random Programs, inc., beginning with Txtinator.

Version 4.0 was almost 1000 lines in length and utilised the powerful wxPython module for its GUI. It had hundreds of extra features, and also included the 1337-speak translation system which had been originally developed as a standalone application by David's Random Programs, inc. near the beginning of the year.

Overall, the best ExeSoft application that year (in my opinion) was Converzion 2.0, an extremely fast unit conversion program with pretty much every unit you could possibly think of implemented. It also had a fully customisable interface, and a customisable toolbar that let you access the conversion types (money, weight, length etc.) that you use most often.

Towards the end of the year, it was decided that they would make a sequel to Slipslide, but this time using the PyGame module to write a specialised engine from scratch so that the game could be developed faster, use more levels and have less bugs. So far it's lived up to that hope (and then some), and with luck it will be released around February or March of 2008. Only time will tell, however...