Friday, 8 March 2013

Starts, Ends and Wall Hugging

Although the pictures from my last post looked acceptable there were some issues that would take several generations of the dungeon to see clearly.
  • Wall Hugging.
  • No clear start or end.
  • Redrawing of rooms.
Wall hugging -

You may be able to notice in the last picture i posted that the dungeon will hit a wall and stick to it, this is because once the dungeon hits a wall it will have an equal chance to move away from the wall as it does to attempt to move into the wall. I fixed this issue with a small if statement that changes the values of Yvar (the variable that effects the probability for the next room to move up or down). If the Y value is equal to gridSize or 0 then Yvar will change from 50 to 25 or 75, reducing the probability to move in the same direction. This fix is far from perfect but it does the job for the time being and produces some interesting looking dungeons.

No clear start or end -

Visibly determining whether a room is the start or end would be difficult, however as far as my script is concerned there isn't one. This may not seem like a problem right now, and that's because it's not, but when it comes to implementing other features such as; a stash at the start of every dungeon, making sure there are no enemies in the first room or have some kind of entrance door, I would like to know which room is the start and which is the end.

To do this I used an integer variable that increments every time a new room co-ordinate is decided (roomCount). From this I know the index of the array that contain the last room's co-ordinates. I then used two if statements "if(arrayPosition == 0)" and "if(arrayPosition == roomCount)". Finally to make these rooms visibly noticeable i changed their colours.

Redrawing of rooms -

This is the biggest of the 3 problems in my opinion, from the pictures it is impossible to see this but from the code you can clearly see how this is possible. Currently if a new room has been placed by incrementing Y there is nothing saying that the next room to be placed will be on a decrement of Y, this gives the dungeon the opportunity to continuously move up and down along the Y axis and never progress along the X. This causes increased loading times and lower FPS during gameplay.

Although this is the biggest issue it isn't that difficult to fix. I introduced some Boolean variables; moveEast, moveNorth, moveSouth. My aim is to check these variables when deciding where a room shall be placed. When a room moves North (incrementing Y) moveNorth will be set to true, if moveNorth is true, a room cannot be placed by decrementing Y (moveSouth), when the room is placed by incrementing X (moveEast) both moveNorth and moveSouth will be set to false allowing the possibility for the path to move North or South again.

Here's the end result of these fixes :)


Let's get started!

Immediately after it was decided I would be focusing on dungeon generation I whipped up some code in what I'd call a mix of php and C++ (prior to writing this code i was doing a lot of php coding for my Application Development module so it was just in the back of my mind). My immediate thought is that I wanted to create a script that would produce a progressive increase in X and Y values that i could then transform some kind of prefabrication by to position 'Rooms' along my dungeon path.

The script I made would initialise a pair of variables and progressively increment or decrement either one of them but never both (this would cause a diagonal movement along a pair of axis, which I didn't want) after deciding which value (X or Y) to alter the script would then add the value to an array. This would continue under the constraint "while(X != gridSize)" this just gave the script an ending point, eventually gridSize could be any number you or I wanted.

The first 'room' to be placed into the array would start at the co-ordinates; (0,0-gridSize)  to do this I initialised the Y variable with a 0-gridSize random number generator attached to it. The next form of randomisation involves deciding whether additional room values are an increment for X or an increment/decrement to Y (There is no decrement on X because I don't want the path to go back on it's self at this moment). I did this by creating 2 addition variables initialised with a random generator between 0-100(Xvar and Yvar). I then create an if statement to decide whether X will be incremented "(If Xvar <= 25)" else increment Y (if Yvar <= 50) else decrement Y. Adjusting the numbers in the if statement will ultimately change the shape of the dungeon.

At this time i had no way of graphically representing anything i'd done so until then i spent time getting familiar with Unity3D, a few tutorials later i managed to represent the values in my array by drawing cubes into the engine then transforming their X and Z locations by the X and Y values in my array respectively.

This is what i got :)




Introduction

Hi there, I'm Joel and I'm a Computer Games Programming student at the University of Derby in the UK. I'm creating this blog not only to share the progress of my work but also to work as a semi portfolio to show future potential employers.

Currently I am working on a team project under the group name Indiecisive Studios (see what we did there?). The project is a game called 'Venture', a Hack and Slash Action Adventure Survival Game with Role Playing Game Elements in a world that is based on random terrain, item and dungeon generation, The aim of the game is to finish with the highest score possible, whether that is decided on time survived, items gained or enemies slain is still a work in progress. Venture will use the Unity3D game engine and we will be coding in C# for the most part.

My main focus so far has been to create a dungeon that is randomly generated. The methods I use to do this were up to me and for now this blog will showcase how i am progressing towards that goal. I will also mention occasionally the progress of my team and how we work together to create 'Venture'.