You'll probably have noticed we now have a new banner image! And, for once, Blogger.com hasn't completely buggered it up! Whereas the last image I uploaded was cropped ridiculously to fit a required size that seemed to get smaller every time I uploaded it, this one is actually displaying at its original size. It seems their server is finally getting into the festive spirit or something.
Anyways, as promised I have absolutely no news on Slipslide 2. I did the start of a tune that I might use in it, but the engine itself hasn't really changed at all unfortunately. But fear not; I'll start work on the level editor program soon. Firstly however, it's traditional to burn your eyes out with a ridiculously over-emphasised festive message. So, without further ado...
*M*e*r*r*y* *C*h*r*i*s*t*m*a*s*!*
Monday, 24 December 2007
Saturday, 22 December 2007
'Tis the season to abandon game projects
I'm afraid blog posts here will be sufficiently less sufficient for the much-hyped holiday next Tuesday (and the rest of the week), but don't worry as I will still be continuing work on Slipslide 2... well, I'll be planning bits out in my head at times of boredom.
The game's release will probably come very soon after New Year; possibly even late January, as development's been going very well. The time which I'm calling the up-spike, when the game engine will be complete and all I need to do is churn out levels, is drawing near with all the acceleration of a disgruntled rhinoceros. And when that time comes, the game could be finished within the fortnight. The only real blockage slowing development down is the character sprite, which is proving incredibly difficult to do as none of us have any experience drawing top-down sprites (or any sprites whatsoever).
Development updates? Well, pausing in-game is entirely possible. The demo file now has a function which makes the game pause for a short period of time (music and all) when the player presses P. So once the pause menu is constructed it should slot right in to the main program. I still haven't fixed that bug with restarting that doesn't erase the old character position, but then it shouldn't be that hard. *coughs*
*nervous shuffling*
The game's release will probably come very soon after New Year; possibly even late January, as development's been going very well. The time which I'm calling the up-spike, when the game engine will be complete and all I need to do is churn out levels, is drawing near with all the acceleration of a disgruntled rhinoceros. And when that time comes, the game could be finished within the fortnight. The only real blockage slowing development down is the character sprite, which is proving incredibly difficult to do as none of us have any experience drawing top-down sprites (or any sprites whatsoever).
Development updates? Well, pausing in-game is entirely possible. The demo file now has a function which makes the game pause for a short period of time (music and all) when the player presses P. So once the pause menu is constructed it should slot right in to the main program. I still haven't fixed that bug with restarting that doesn't erase the old character position, but then it shouldn't be that hard. *coughs*
*nervous shuffling*
Friday, 21 December 2007
The basic engine is functional!
About 500 lines into the project, we now have a fully functional engine demo! This can quickly and easily load levels and their music, sounds and images with the programmer only having to specify the name of the folder containing those files. The physics are working perfectly, the music is playing and we even got it to recognise when the player has completed the level and send a message back to the main program. There's also a restart function, but unfortunately there's a slight problem with that - it absolutely will not redraw the screen no matter what. Even if I explicitly tell it to completely redraw the entire screen (which always works), it still won't clear the old sprite from the screen. So there are temporarily two players, at least until the real player collides with something and by extension forces a full-screen redraw. I don't really know how to solve this, but... umm...
*waps out (now very worn-out) thinking cap*
Tuesday, 18 December 2007
The beginnings of Penuine
"Penuine? What on Earth is that?!?", shout surprised readers (much to the annoyance of people nearby). Well, I decided the new Slipslide game engine needed a name, so I held a brainstorm with the ExeSoft staff. One of the ideas suggested by Oblenob was "Penguin", but he mis-typed it and ended up putting "Penuine". And it managed to stick. I actually think it's quite a good name; it's unique anyway. The pronunciation's still pending though. I'm thinking it'll be something like "pen-oo-een", with the "oo" sound being said very quickly.
So, now to address the "beginnings of" section of the title. Basically the level loader, updater and block sections are working, as proved by this simple demo:
Yes, it looks like it's exactly the same as what was going on in the demo, but it's actually what's called a black triangle - it doesn't look like much but the fact that it's not crashed down in flames shows that a complex system is functioning behind it. In this case, it's the inter-module communications and the data management. Now all it needs is a character and the basic game system will be complete. What I plan to do once that's done is take a break from the main game programming for a while so I can concentrate on designing the level creator application, and then I'll try using it myself to create some levels for the game.
So, now to address the "beginnings of" section of the title. Basically the level loader, updater and block sections are working, as proved by this simple demo:
Yes, it looks like it's exactly the same as what was going on in the demo, but it's actually what's called a black triangle - it doesn't look like much but the fact that it's not crashed down in flames shows that a complex system is functioning behind it. In this case, it's the inter-module communications and the data management. Now all it needs is a character and the basic game system will be complete. What I plan to do once that's done is take a break from the main game programming for a while so I can concentrate on designing the level creator application, and then I'll try using it myself to create some levels for the game.Monday, 17 December 2007
The hardest part of game development
With the pre-alpha done, I'm now going to start on what I believe to be the hardest part in the development process - writing the engine. The main reason this is so hard is because it's impossible to test it until almost the entire structure is complete; so I'm just writing out several individual sections of it just now in the hope that they'll function together when it's finished.
Slipslide's engine currently consists of nine separate parts (its design has changed a bit since I made that flowchart some time ago). There's the main file (which is only there to bring everything else together, and will probably be under 100 lines in length), the character (which will be massive), the blocks controller (which only generates blocks so is fairly simple), the level intros generator (completely separate from everything else and will probably be the last part I write), the level loader and manager (which will be MASSIVE), the main menu (which will do a lot of data juggling with the main file but is otherwise separate), the media loader (which loads media, funnily enough...), the pause menu (one of the trickiest to write I think), and the sound controller (which will be easy).
I'm also designing an application which will go with the game that allows users to design their own levels, using wxPython. It will then be possible to load these levels from the game's main menu simply by selecting them from a list which user-created levels will be added to. I've got it planned out in its entirety, but the main thing that might stop this from being included is time - I'd prefer not to have this game's release be pushed back by months as the last game's one was, so I may have to drop this extra feature or release the level editor at a later date. But if developing it turns out to be as easy as I think it will be, I could well have it finished in time to use it myself to build some of the game's levels.
Slipslide's engine currently consists of nine separate parts (its design has changed a bit since I made that flowchart some time ago). There's the main file (which is only there to bring everything else together, and will probably be under 100 lines in length), the character (which will be massive), the blocks controller (which only generates blocks so is fairly simple), the level intros generator (completely separate from everything else and will probably be the last part I write), the level loader and manager (which will be MASSIVE), the main menu (which will do a lot of data juggling with the main file but is otherwise separate), the media loader (which loads media, funnily enough...), the pause menu (one of the trickiest to write I think), and the sound controller (which will be easy).
I'm also designing an application which will go with the game that allows users to design their own levels, using wxPython. It will then be possible to load these levels from the game's main menu simply by selecting them from a list which user-created levels will be added to. I've got it planned out in its entirety, but the main thing that might stop this from being included is time - I'd prefer not to have this game's release be pushed back by months as the last game's one was, so I may have to drop this extra feature or release the level editor at a later date. But if developing it turns out to be as easy as I think it will be, I could well have it finished in time to use it myself to build some of the game's levels.
Subscribe to:
Posts (Atom)