Hey guys, finished The Release this week! It is going to be used in the combat rooms of the game.
We hope you had a Merry Christmas, and wish you a Happy New Year!
maandag 30 december 2013
zaterdag 28 december 2013
maandag 23 december 2013
Music Monday 4: The Release (WIP)
Time for the next Music Monday! This is a Work in Progress version of a track that will play during heavy combat. If you have some criticism, tell me and I will improve that for the final version!
zaterdag 21 december 2013
Screenshot Saturday V
We know that you, the player, are not only a bold adventurer but also a stunning intellectual! Because of that, we have also added challenges that test your genius.
vrijdag 20 december 2013
Do not forget AI
In one of our earlier blog posts you could read about textures being very, very important. Now I do not disagree with that but another important aspect of our game is Artificial Intelligence, or AI in short. AI is a big subject, it contains every action the enemies can perform. From when and how and where to attack to a simple where do I go now. We do not think AI should be too smart but we also want it to be realistic. I do not think I have to tell you that it will be hard to make such an AI.
We will implement a system that uses the shadow casting (seen in one of the earlier blogs) to enable the player to go by enemies unnoticed or even ambush them. Now I know that this is a really big goal we are setting here. However, for our game to be successful we need a good and solid AI. One that doesn’t see you enter their room and then simply start running towards you and attack. At the moment that is exactly what they do because I have been busy making an algorithm for our path finding.
That is right, meet the new lead AI programmer: ME.
We need pathfinding for navigating the tight corridors in the levels. I want to make pathfinding work first because we cannot have enemies trying to look for the player while they get stuck every time. Now there are a lot of powerful pathfinding algorithms but our game does not need an algorithm that strong so we agreed to use the A* algorithm. While I will shortly explain the A* algorithm.
We will implement a system that uses the shadow casting (seen in one of the earlier blogs) to enable the player to go by enemies unnoticed or even ambush them. Now I know that this is a really big goal we are setting here. However, for our game to be successful we need a good and solid AI. One that doesn’t see you enter their room and then simply start running towards you and attack. At the moment that is exactly what they do because I have been busy making an algorithm for our path finding.
That is right, meet the new lead AI programmer: ME.
We need pathfinding for navigating the tight corridors in the levels. I want to make pathfinding work first because we cannot have enemies trying to look for the player while they get stuck every time. Now there are a lot of powerful pathfinding algorithms but our game does not need an algorithm that strong so we agreed to use the A* algorithm. While I will shortly explain the A* algorithm.
We begin at the Playertile (the grid location of the player) and we look at all the Tiles (blocks in grid) neighboring it. If none of these Tiles contain something we cannot walk through we go to the next tile. Once we find a walkable tile we calculate its F value. The F value is calculated by taking the cost of moving to that tile from the Playertile: G (we use 10 for vertical and horizontal movement and 14 for curved movement) and adding the estimated movement cost to the enemy: H. We then add this Tile to our Open list.
If all the adjacent Tiles have been looked at we add the Tile with the lowest F to a list we call Closed. We also save which Tile this Tile was looked at from (its Parent Tile) we will need this later.
Now we look at all the Tiles surrounding the Tile we just saved in the Closed list. Apart from the procedure above we now also need to check if the Tile we're looking at is in the Closed list. If it is we should look at the next Tile because we already looked at those and they are already on our path or lead to a dead end. Also we need to make sure it is not in our open list because we already have data for those tiles, however if it is in the Open list we must check if the G value of that Tile is higher than what we calculated from the new Tile. If it is higher then there is a better path to that tile via the Tile we now look from.
We continue this until either we run out of possible tiles or the Tile with the lowest F is the Enemytile (Grid location of the enemy) we then take this Tile and add it to the Path list. Then we add its Parent Tile, and the Parent's Parent Tile and so on until we add the Playertile. Now the enemy simply has to go to every location on the Path list and it will arrive at the Player.
Pathfinding is really cool and all but here in the Netherlands we have a saying "waarom moeilijk doen als het makkelijk kan" which means "why do it the hard way if you can do it the easy way". Now this also applies to Pathfinding because if there is no obstacle between the player and the enemy, then why should we use pathfinding? The answer is simple: We do not. We use a Raycast written by Timon to check if there are obstacles in the way. If there are no obstacles we simply make the enemy go directly to the player.
If all the adjacent Tiles have been looked at we add the Tile with the lowest F to a list we call Closed. We also save which Tile this Tile was looked at from (its Parent Tile) we will need this later.
Now we look at all the Tiles surrounding the Tile we just saved in the Closed list. Apart from the procedure above we now also need to check if the Tile we're looking at is in the Closed list. If it is we should look at the next Tile because we already looked at those and they are already on our path or lead to a dead end. Also we need to make sure it is not in our open list because we already have data for those tiles, however if it is in the Open list we must check if the G value of that Tile is higher than what we calculated from the new Tile. If it is higher then there is a better path to that tile via the Tile we now look from.
We continue this until either we run out of possible tiles or the Tile with the lowest F is the Enemytile (Grid location of the enemy) we then take this Tile and add it to the Path list. Then we add its Parent Tile, and the Parent's Parent Tile and so on until we add the Playertile. Now the enemy simply has to go to every location on the Path list and it will arrive at the Player.
Pathfinding is really cool and all but here in the Netherlands we have a saying "waarom moeilijk doen als het makkelijk kan" which means "why do it the hard way if you can do it the easy way". Now this also applies to Pathfinding because if there is no obstacle between the player and the enemy, then why should we use pathfinding? The answer is simple: We do not. We use a Raycast written by Timon to check if there are obstacles in the way. If there are no obstacles we simply make the enemy go directly to the player.
There is just one more thing i would like to add. We now have a new enemy: THE BANDIT
He will club you to death if you do not watch out!
He will club you to death if you do not watch out!
Midterm Update
Thom
Unfortunately, it seems Thom has decided to leave us. Though he has not ‘officially’ stated he is abandoning the project, he has been very inactive over the past weeks, did not attend wednesday’s presentation (see below) and removed all of us as skype contacts yesterday.
Since Thom had been reluctant to do anything for the last month, for a while we already spread our tasks in such a way that his inactivity would not hamper our progress. The only exception to this were the graphics. Really, none of us are any good at creating graphics so we attempted to avoid the subject and gave it to Thom.
Alas, now that Thom is removed from the equation, we will have to get our graphics elsewhere. Don’t worry though, we found we still have a lot of options left and you can definitely expect a great looking game from us!
Wednesday’s presentation
Wednesday was presentation day. We had all come early to the university campus to do a last-minute meeting about the presentation, and then headed to the .. well, some random building.
Anyway, when we got there, we were all excited that we could finally present our progress to our colleagues. When our turn came, we went to the front, and got ready to present ..
.. and couldn’t get the projector working. Well, if you weren’t yet questioning our legitimacy as computer science students, now is the time. All joking aside, we ended up doing the presentation without the game and the slideshow we had prepared, and just used images from this blog.
In the end, it went pretty well and I’d like to think we made a pretty decent impression. Even then, come January, we’ll have another opportunity.
Unfortunately, it seems Thom has decided to leave us. Though he has not ‘officially’ stated he is abandoning the project, he has been very inactive over the past weeks, did not attend wednesday’s presentation (see below) and removed all of us as skype contacts yesterday.
Since Thom had been reluctant to do anything for the last month, for a while we already spread our tasks in such a way that his inactivity would not hamper our progress. The only exception to this were the graphics. Really, none of us are any good at creating graphics so we attempted to avoid the subject and gave it to Thom.
Alas, now that Thom is removed from the equation, we will have to get our graphics elsewhere. Don’t worry though, we found we still have a lot of options left and you can definitely expect a great looking game from us!
Wednesday’s presentation
Wednesday was presentation day. We had all come early to the university campus to do a last-minute meeting about the presentation, and then headed to the .. well, some random building.
Anyway, when we got there, we were all excited that we could finally present our progress to our colleagues. When our turn came, we went to the front, and got ready to present ..
.. and couldn’t get the projector working. Well, if you weren’t yet questioning our legitimacy as computer science students, now is the time. All joking aside, we ended up doing the presentation without the game and the slideshow we had prepared, and just used images from this blog.
In the end, it went pretty well and I’d like to think we made a pretty decent impression. Even then, come January, we’ll have another opportunity.
Stay tuned, because later today Dwight will post here to tell us about the AI!
maandag 16 december 2013
Music Monday... 3!
I thought Enigma from last weeks Music Monday was a bit short, and started way too abrupt to really work in a game, so I decided to double the length with a nice new "intro". It's almost like I planned to make it like this and didn't accidentally upload only half of the song!
zaterdag 14 december 2013
maandag 9 december 2013
Music Monday 2: Enigma
Time for the second Music Monday. For today is a slightly more atmospheric track called Enigma. Check it out:
zondag 8 december 2013
vrijdag 6 december 2013
Graphics are maybe actually important
It has happened! We finally started replacing those wretched sprites used in the first test builds! As everyone knows there can't be a game without graphics, these can range from very minimal (like rogue) to very complex and high definition (like crisis), with unlimited possible styles in between.
We settled for using 2D sprites, seen this is the most doable within a reasonable timeframe for people who are all new to making graphics and aren't super artistic.
When we started this project we quickly found out that none of us was any good at drawing sprites or any other form of graphics. We were unsure if we should look for outside help on this one, seen without graphics there would be no game, or one with all the random sprites we pulled of the internet or made in ms paint (ooh the horror, all the non-transparent sprites!). But a true game studio doesn’t outsource anything they might be able to do themselves, so before we contracted an artist we figured that at least trying to do it ourselves would be the way to go. And sure thing, the next meeting we decided it would be an inhouse project, after some discussion the group appointed me (Thom) to do the graphics, seen I was the only one who was willing to do so without drawing straws or some other form of picking at random. Quickly I came to realize that I took on quite an important task: making the game look good, which is important for the immersion (which is really important for us).
So now there is a big point: we know what type of graphics we are going to use (2D sprites) but what art style (is it going to be cartoony rainbow unicorns, or realistic), what resolution are the sprites going to be (is it going to be pixel heaven, or eye melting HD) and most important: what will the main character look like?
The art style was an easy one, we wanted to immerse people in horrors of the dungeon, so we went for a grimm realistic art style. It is hard to be scared of what lays beyond the next dark corner when the ground is in all the bright colours imaginable and you are playing a cartoon character.
Choosing a sprite’s resolution seems easy enough, but is actually quite tricky, if you start out with super low resolution it looks a bit bad (to say it in the most polite way possible), if you start with super high resolution it takes ages to make, it eats away at your memory and you will most likely have to downscale it which makes it look like someone stepped on it (not desirable). To not get ahead of ourselves, we stuck with the respectable 64 x 64 resolution for standard sprites (which is the same used in many indie games). This is a very manageable format, seen it looks quite good, isn’t too time consuming to make and doesn’t cause optimization issues.
It is also important to pick a resolution that is a power of two, since some older graphics cards can only handle those types of textures. 32x32 is just a bit too small, we don’t want to force our audience to lean over so they can see what’s actually going on, while 128x128 is evidently a bit too big - the player still has to be able to see his surroundings.
Now choosing who will be the protagonist of this epic adventure down the dungeon is a hard one. And seen we do want to keep some things a suprise I can’t tell you much about the main character yet… Some say it will be a space orc, some say it will forever be Mr. Broke, all I can tell you is that you might get a sneak peak next screenshot saturday, so stay tuned for that.
We settled for using 2D sprites, seen this is the most doable within a reasonable timeframe for people who are all new to making graphics and aren't super artistic.
When we started this project we quickly found out that none of us was any good at drawing sprites or any other form of graphics. We were unsure if we should look for outside help on this one, seen without graphics there would be no game, or one with all the random sprites we pulled of the internet or made in ms paint (ooh the horror, all the non-transparent sprites!). But a true game studio doesn’t outsource anything they might be able to do themselves, so before we contracted an artist we figured that at least trying to do it ourselves would be the way to go. And sure thing, the next meeting we decided it would be an inhouse project, after some discussion the group appointed me (Thom) to do the graphics, seen I was the only one who was willing to do so without drawing straws or some other form of picking at random. Quickly I came to realize that I took on quite an important task: making the game look good, which is important for the immersion (which is really important for us).
So now there is a big point: we know what type of graphics we are going to use (2D sprites) but what art style (is it going to be cartoony rainbow unicorns, or realistic), what resolution are the sprites going to be (is it going to be pixel heaven, or eye melting HD) and most important: what will the main character look like?
The art style was an easy one, we wanted to immerse people in horrors of the dungeon, so we went for a grimm realistic art style. It is hard to be scared of what lays beyond the next dark corner when the ground is in all the bright colours imaginable and you are playing a cartoon character.
Choosing a sprite’s resolution seems easy enough, but is actually quite tricky, if you start out with super low resolution it looks a bit bad (to say it in the most polite way possible), if you start with super high resolution it takes ages to make, it eats away at your memory and you will most likely have to downscale it which makes it look like someone stepped on it (not desirable). To not get ahead of ourselves, we stuck with the respectable 64 x 64 resolution for standard sprites (which is the same used in many indie games). This is a very manageable format, seen it looks quite good, isn’t too time consuming to make and doesn’t cause optimization issues.
It is also important to pick a resolution that is a power of two, since some older graphics cards can only handle those types of textures. 32x32 is just a bit too small, we don’t want to force our audience to lean over so they can see what’s actually going on, while 128x128 is evidently a bit too big - the player still has to be able to see his surroundings.
Now choosing who will be the protagonist of this epic adventure down the dungeon is a hard one. And seen we do want to keep some things a suprise I can’t tell you much about the main character yet… Some say it will be a space orc, some say it will forever be Mr. Broke, all I can tell you is that you might get a sneak peak next screenshot saturday, so stay tuned for that.
donderdag 5 december 2013
Shadowcasting
We just implemented shadowcasting into our game, and while the funky looking sprites are still here (who cares about graphics anyway), the game looks a lot more thrilling than it did before.
And another one:
So what is shadowcasting, and why are we putting it in our game? Basically, shadowcasting is a technique were you let objects in your level cast a shadow on everything behind it (from the light's perspective), rendering it invisible to the player.
The thing with topdown games is that they give the physical player a bird's eye of view, which allows him to see things the character in the game really can't see. By using the player as a 'lightsource' in our shadowcasting algorithm, we can combat this 'visual omnipotency' by simply drawing shadows over anything the in-game character wouldn't be able to see.
This really gives a special feeling to the game. To show this to you, I have selected a few 'before' and 'after' pictures. Again, the sprites are still funky so you'll have to imagine the blood on the floor and the monstrous enemies yourself, but here you go:
And another one:
The last one is my favourite. Rather than already getting a pretty good vision on everything that is close to the door or getting distracted by some tunnel that is next to the one you're in, you have to slowly creep into the room - but wait, what if there's a monster standing right around the corner?
This selective reduction of the player's field of view turns hearing into a more 'legitimate' sense. You can't fully rely on your eyes anymore. You may not see the monster, but that doesn't mean there isn't one close to you.
Didn't you hear the scraping of claws over granite right there?!?
maandag 2 december 2013
Music Monday 1!
Oh yes, welcome to the first Music Monday! I, Emile van Krieken, have worked on some nice creepy music for this game. We're not very sure how it's going to be used yet, but we hope it'll greatly help immerse the player into our frightful dungeon crawler having a smiley as protagonist. ...Is this working? It isn't? D'aww :(
zondag 1 december 2013
Screenshot Sat- I mean, Sunday 2!
Welcome back again! Here's another screenie for you to enjoy. The sprites still need some (a lot) of work, but we managed to load in the dungeon generation from last saturday, and we added a randomized item system with sprites that absolutely have nothing to do with Minecraft.
Come back tomorrow for the first Music Monday!
Come back tomorrow for the first Music Monday!
Abonneren op:
Posts (Atom)