Please note that all screen shots displayed in this blog are works in progress and in no way represent the appearance of the final game. Check out the main site here.

Be sure to follow us everywhere with these links!

Sunday, June 27, 2010

Moving along

So I eventually capitulated and decided to re-write the whole dungeon generator object. I originally started writing the first version as a proof-of-concept anyway, so I guess the move isn't really THAT drastic. However, it's a big job as my virtually un-commented, disorganised "rough draft" first version was over 22,000 lines long.

The new version that I've been writing for the last eight days is all very nicely laid out, modular, and split into neat functions, etc. It is also extensively commented and explained in detail at every step. I'm actually finding it a real joy to work on this way. I guess when I first had the notion of making a game which writes its own levels intelligently, I figured I'd get about a third of the way through development and come to my frikking senses ;-P but no, when it first started to actually work I got over-excited and decided to see the whole thing through to the end, and hey, the game is now going to be totally awesome because of it, and it has actually redirected the development process in a whole new direction.

So now that this dungeon generator is working, I'm re-doing it the way that it should have been done in the first place. By doing it in this new, neat and organised way, I will hopefully be able to find, fix and sort out the one or two nasty bugs that were sticking with it the whole time that I couldn't quite find. Mind you... Looking through the code in version 1, it's a miracle that I was able to find anything at all... So messy!

Anyway, I'm about a quarter of the way through the re-write, so as I get further I'll keep the updates posted.


Tuesday, June 15, 2010

It's a bit difficult...

So after a whole day of working on the stair problem, it's still not solved... My main problem is finding precisely where the bug is. You see, when you write adaptive - or polymorphic, as they call it - code, you don't so much as reprogram it as negotiate with it to make it do what you want. It's what happens when you give control of a program over to a computer... I have half a mind to call what I've done so far a proof of concept and start over with a neater, nicer version of the program...

It may come to that, but then again it may not. Time will tell...


Sunday, June 13, 2010

What's this?

Well well well! What's this? A treasure chest? A low-detail temporary model of a treasure chest, yes, but it IS a treasure chest. What does that mean for the game? It means that I can randomly place objects of any sort throughout the dungeon. Just in case you still haven't figured it out, this means that the dungeons won't all be empty rooms and corridors. Now I can fill them with all manner of objects and items. Chests, tables, chairs, wells, cages, you name it!

Of course, this means that there is a long process of asset creation for me in my near future. I have to create and texture dozens of new 3D objects to fill the dungeons with, but it might be a nice break from all the coding I've been doing to get the collision working.

On that note, I've gotten collision working 100% now. The player can't walk through walls and can run up and down stairs with no problems. I DID record a video of that working, but I'm having some encoding issues, so I'll have to get that to you later.

I also put in the proper loading screen with the progress bar. I always thought it took far too long to load and generate a dungeon, but now I have the loading screen in place, I've realised that it only takes about 15 seconds. Considering the technology we're working with here, I don't think that's too long to wait. What do you guys think?

Anyway. It was a real pain to have to quit and re-load the program every time I wanted to generate a new dungeon, so I put in a dungeon reset function so that with a simple key press I can load a whole new dungeon without quitting the application. This makes testing a lot easier, however, it has highlighted a bug. In very rare circumstances, the dungeon generator still manages to build corridors THROUGH staircases instead of around them, so I need to hunt that bug down, which is a pain. I thought I'd solved all of that...

Anyway, shouldn't take too long to fix up. I'm having a bit more of a relaxing day today, playing some games with a couple of mates and the missus. Back to it tomorrow!

See ya later!

Thursday, June 10, 2010

A quiet one...

Well... Bit of a quiet one tonight, sorry. Not much to report. I got LOTS done, but it's all boring background work integrating the new collision system into the game.

Nothing to show for it tonight, but not long and I'll have some very cool videos to show! Woo!

Nighty night!

Wednesday, June 9, 2010

The problem with stairs...

So yeah, loooooong break between posts... Sorry about that. I've been incredibly ill of late and haven't had much time for work on MSoA. That's about to change, however.

So the main problem for the engine at the moment is collision. Walking around the dungeon, one can't be allowed to walk through walls, or, in the case of a multi-level dungeon, be allowed to fall through the floor.

When it comes to walls, the collision is fairly simple; if a player is standing in north/south facing corridor segment, they are only allowed to walk forward if they are facing north or south. If they are in a corridor segment, it will also only allow them to walk in one direction or the other. So, understandably, this part of the player collision is quite straightforward. Likewise, in-level objects such as tables, etc, can be detected easily with an algorithm something like "player wants to move forward - check in front of player - is there an object there? - if so, do not allow player to move forward - if not, then move player forward in accordance to dungeon segment collision".

So yes, that side of things was working swimmingly, but in MSoA, the dungeons are multi-storey, and thus I had to deal with stairs - ever a problem with me. The main problem when dealing with them is this (and it gets a little hard to explain, so please bear with me): any given staircase has two openings; one at the top and one at the bottom. If you are standing at the top of a staircase and you enter said staircase, you will be going down. If you enter the bottom of a staircase you will be going up. Fairly straightforward. BUT, lets say you divide the staircase into three parts (which the MSoA engine does); part A is the top, part B is the middle and part C is the bottom. If you enter part A, the computer should know that you intend to go DOWN the stairs, and thus move the camera downwards as you walk, making it look like you're walking down the stairs, right? WRONG! That situation is only predicated upon you entering part A of the staircase from OUTSIDE the staircase. If you were to enter part A of the staircase COMING FROM part B of the staircase, technically you should be traveling UPWARDS and not DOWNWARDS.
I warned you it was hard to explain.
Anyway, this COULD be overcome by processing the last section you were in and comparing it to the section you're moving into, however, that would require hard coding data relating to the various sections of the level, and I can't do that because the level isn't being designed by me. It's being designed by the COMPUTER.
So it was a pickle. A very difficult to solve pickle. And while it HAS been a long time since I've done some serious work on the engine, I have actually spent the entire time pondering how to solve this problem.
And, ladies and gentlemen, tonight I managed to solve it. The answer? Sliding collision :)
What's that you ask? An excellent question. Basically, I have thrown together some code that creates invisible platforms in the base of every dungeon segment generated by the computer. Most segments such as corridors, corners, crossroads, etc, simply have a flat square segment covering their floor (invisible to the player, but it's there) and staircases have slanted segments that follow the path that the stairs make in the level's 3D model. Hidden from the player, these invisible platforms act as a sort of guide rail for the player's view, so every time a player enters into a segment, the camera follows the slope of the invisible platform for that segment. Most of the time that platform is totally flat, so the camera just slides along normally, but when entering a staircase, whether it runs up or down, the camera is guided by the invisible platform running JUUUST under the 3D model of the staircase. Since these platforms are only a few polygons each, it doesn't make a big difference in terms of memory usage, and the player can smoothly and easily run up and down stairs (and so can the beasties mwahahahahaaaa)
I have this working in a separate test application at the moment and it works a treat, so now I just need to integrate the code into the game engine proper. Once that's done I'll probably do up a video showing off the new tech.

Anyway, that's enough ranting for me. Good to be back, guys!

Au revoir!