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.
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... ;-)
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!
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.
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 E
xeSoft 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 t
hey 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...