ABYSSUS!!!!! Woohoo!
 |
| The beautiful certifacte we won |
zaterdag 1 februari 2014
And the winner is...
Rejoice! Our game was nominated for the projects Best Game Award among 4 games made by other university students. Therefore, on January 31st a jury consisting of a member of Abbey games (of Reus fame), a member of Digital Dreams, known for the upcoming game Metrico, and a former teacher at the university of Utrecht took a good look at all nominated games. A bit later in the afternoon every team had to do a short 5 min presentation about their game. After a long debate the jury voted unanimously for.....
ABYSSUS!!!!! Woohoo!
ABYSSUS!!!!! Woohoo!
maandag 27 januari 2014
The end is nigh
At last, our little journey has come to an end. The technical side of it, anyway. This morning we committed our last-minute bugfixes, most notably Alex who fixed a little bug at 14:00 exact (not knowing this was the deadline).
The game can be downloaded on this page. Just download the zip and run the installer, and let us know what you think!
Wednesday we will have to present our game to the jury and our fellow students, and we might just have a chance to get nominated for an award. The accompanying award ceremony is on friday, during the symposium.
For now though, Abyssus rests among its new friends.
It looks like it belongs there
zondag 26 januari 2014
vrijdag 24 januari 2014
Panic. PANIC!
Time for another blogpost! When looking at the schedule detailing when you should make a post, it becomes apparent that whoever made the schedule, probably picked the dates very carefully to match certain phases in the project.
The 6 December blogpost(s) were meant for us to prudently show our baby steps in the world of game design. 20 December was a good time to chat a little bit about our (probably technical) progress. Next up, 10 January (split up into 1, 2, 3) was just after the holidays, when we had begun to realize the scale of the project we had taken upon us.
And now comes 24 January. Conveniently positioned just before the weekend that's just before our deadline. We are probably expected to write about how much we still have to do in so little time, or show our intelligence by reflecting on our progress. Or maybe write a panic-post about how we'll never get it done.
But here at Graile Games we're different. We carefully constructed an illusion of (almost apathetic) professionalism, and we mean to uphold it, until the bitter end. Because of that, this blogpost will be about boring technical details. You can't make us write a panic-post!
When we began developing Abyssus (or Roguelike, as we called it back then) we had to start from the scratch, and obviously, we'd need a collision system. We could have opted to just blatantly copy Tick Tick's, but this would most likely create more problems than it would solve, since it was made for a platform game, and its pixel-perfect collision checking was what a gamer might call 'overkill'.
Using a set of light-weight methods we were able to implement all the bumps and impacts that were necessary.
The aspect 'light-weight' was important, because our game needed to do a lot of collision checks. While this may not seem necessary in a simple topdown game, in the end it was probably for the best we didn't go for pixel-precise collisions. Otherwise we wouldn't have been able to implement the destructible enviroment the game has now, or projectiles hitting each other in mid-air.
We are in luck because as it turns out, all squares in our game are axis aligned, which makes collision checking a lot easier! Essentially, first we check whether moving to (position + velocity) will result in a collision. If not, all good! If it does result in a collision though, we can do a seperate checks for the component of the vector that is parallel to the square.
Since the square is axis aligned we don't have to worry about splitting the velocity, we can just check the X and Y components! One of them has to be parallel! So if adding just the X component, or just the Y component will not result in a collision, we'll do that. The result is that the player slides smoothly along the walls.
Combat collision checking brought it's own problems though. We can't just check if the distance between the player and an enemy is under a certain arbitrary limit when the player presses the left button, and then apply the damage. After all, the game has to make sense, we need to uphold suspension of disbelief.
Because of that, the weapons of the player and enemies get their own collision checks and protocols. This is where the line-circle intersection script you saw above comes in handy: we'll just run it for the circle that represents the player/enemy, and the line that represents the weapon! But here comes the trick: Every weapon is different.
We can't use the same line for the halberd as we use for the dagger, or the same line we use for the mace as for the sword. The 'stick' part of a weapon shouldn't do any damage, only the pointy ends. For that, we used simple dictionaries that 'described' what parts of the weapon actually did the damage (i.e. had to be checked for collisions), and what parts could just be ignored.
Maybe you're now sitting there "well that's inefficient" or "it makes no sense to do it that way", but hey, we're just a bunch of rookies, after all.
The 6 December blogpost(s) were meant for us to prudently show our baby steps in the world of game design. 20 December was a good time to chat a little bit about our (probably technical) progress. Next up, 10 January (split up into 1, 2, 3) was just after the holidays, when we had begun to realize the scale of the project we had taken upon us.
And now comes 24 January. Conveniently positioned just before the weekend that's just before our deadline. We are probably expected to write about how much we still have to do in so little time, or show our intelligence by reflecting on our progress. Or maybe write a panic-post about how we'll never get it done.
But here at Graile Games we're different. We carefully constructed an illusion of (almost apathetic) professionalism, and we mean to uphold it, until the bitter end. Because of that, this blogpost will be about boring technical details. You can't make us write a panic-post!
To the point!
So what are we going to talk about? Ah, how about the collision checking? Sounds good? Let's do it.When we began developing Abyssus (or Roguelike, as we called it back then) we had to start from the scratch, and obviously, we'd need a collision system. We could have opted to just blatantly copy Tick Tick's, but this would most likely create more problems than it would solve, since it was made for a platform game, and its pixel-perfect collision checking was what a gamer might call 'overkill'.
The basics
Instead, we decided to make a simple yet effective collision engine using very simple shapes: squares, lines and circles. After all, that's all we needed. We could represent walls and other decoration in the game using squares, players and other entities using circles, and weapons as lines.Using a set of light-weight methods we were able to implement all the bumps and impacts that were necessary.
Live footage
The aspect 'light-weight' was important, because our game needed to do a lot of collision checks. While this may not seem necessary in a simple topdown game, in the end it was probably for the best we didn't go for pixel-precise collisions. Otherwise we wouldn't have been able to implement the destructible enviroment the game has now, or projectiles hitting each other in mid-air.
Smoooooth
So collision checking is one thing, but handling it is another. You can't just do something like:if(collisionAtCurrentPosition()) { position = previousPosition; }.. as that would result in the player getting stuck in walls, which is especially a problem in a game with lots of tunnels, like ours. Because of that, we do it a bit differently. The problem with the above system is that it fails to compartmentalize the velocity into components orthagonal with the object we are colliding with, and parallel to it. Let me explain it using this image:
Evidence no. 1 as to why I am not this teams graphical artist
We are in luck because as it turns out, all squares in our game are axis aligned, which makes collision checking a lot easier! Essentially, first we check whether moving to (position + velocity) will result in a collision. If not, all good! If it does result in a collision though, we can do a seperate checks for the component of the vector that is parallel to the square.
Since the square is axis aligned we don't have to worry about splitting the velocity, we can just check the X and Y components! One of them has to be parallel! So if adding just the X component, or just the Y component will not result in a collision, we'll do that. The result is that the player slides smoothly along the walls.
Combat
Obviously there are other checks that don't require us to handle collisions like above. For example, when doing checks for the combat, all we have to do on impact is do damage, apply a little knockback, a few gore particles, and that's it.
More live footage
Combat collision checking brought it's own problems though. We can't just check if the distance between the player and an enemy is under a certain arbitrary limit when the player presses the left button, and then apply the damage. After all, the game has to make sense, we need to uphold suspension of disbelief.
Because of that, the weapons of the player and enemies get their own collision checks and protocols. This is where the line-circle intersection script you saw above comes in handy: we'll just run it for the circle that represents the player/enemy, and the line that represents the weapon! But here comes the trick: Every weapon is different.
We can't use the same line for the halberd as we use for the dagger, or the same line we use for the mace as for the sword. The 'stick' part of a weapon shouldn't do any damage, only the pointy ends. For that, we used simple dictionaries that 'described' what parts of the weapon actually did the damage (i.e. had to be checked for collisions), and what parts could just be ignored.
Trust me, it makes sense
vrijdag 17 januari 2014
Join us in the Abyss!
We are proud to announce that we now have a final name for the game we're creating. We left "Roguelike" behind, from now on it's called Abyssus and it is set to be released on January the 29th.
donderdag 9 januari 2014
Stop. Graphics Time!
Hello world!
A few weeks ago in the Midterm Update, we mentioned that we had to continue this game-project with only 4 members left. Unfortunately, the guy who left Graile Games was responsible for creating all the graphics. In the same blogpost, we also said it would not be too hard to think of another option regarding the graphics. However, this turned out to be more difficult than expected. I came up with the idea to ask my brother for creating graphics, since he has always liked drawing. With crossed fingers I asked him, and it was a huge relief when he said he wanted to do it. From now on, my brother will be creating sprites on his iPad, and I would be responsible for editing (scaling, disassembling image parts, etc.) the multilayered images he sends me and getting them into the game. Graile Games’ Art Department has been founded, only consisting of two twin brothers. This had some serious consequences...
Positive ones to be precise! Over the past few weeks, because new sprites incessantly kept coming and coming, we were able to add a lot of content. Enough said, there is A LOT to show, so here it is (saved the best for last):
First, dungeon decoration. Until now, the dungeons felt very empty, static and repetitious. We needed dungeon decoration, and lots of them, here some stuff you will see while discovering dungeons:
We also created the first few "templates rooms", which is an extra option featured in Emile's Generation system. This let us design our own rooms in a textfile which will randomly appear in some dungeons. An example of a template spawning-room:
We have also added some interactive objects in the dungeons, like turrets that spit fire:
Puzzles also had a makeover: (also, more types of puzzles have been created, but I will leave those to discover them on your own)
The dragon, partially seen in the previous post, now fully visible. It already has some nice special unique attacks but it's not completely finished yet...
A few weeks ago in the Midterm Update, we mentioned that we had to continue this game-project with only 4 members left. Unfortunately, the guy who left Graile Games was responsible for creating all the graphics. In the same blogpost, we also said it would not be too hard to think of another option regarding the graphics. However, this turned out to be more difficult than expected. I came up with the idea to ask my brother for creating graphics, since he has always liked drawing. With crossed fingers I asked him, and it was a huge relief when he said he wanted to do it. From now on, my brother will be creating sprites on his iPad, and I would be responsible for editing (scaling, disassembling image parts, etc.) the multilayered images he sends me and getting them into the game. Graile Games’ Art Department has been founded, only consisting of two twin brothers. This had some serious consequences...
Positive ones to be precise! Over the past few weeks, because new sprites incessantly kept coming and coming, we were able to add a lot of content. Enough said, there is A LOT to show, so here it is (saved the best for last):
First, dungeon decoration. Until now, the dungeons felt very empty, static and repetitious. We needed dungeon decoration, and lots of them, here some stuff you will see while discovering dungeons:
We also created the first few "templates rooms", which is an extra option featured in Emile's Generation system. This let us design our own rooms in a textfile which will randomly appear in some dungeons. An example of a template spawning-room:
We have also added some interactive objects in the dungeons, like turrets that spit fire:
Puzzles also had a makeover: (also, more types of puzzles have been created, but I will leave those to discover them on your own)
The dragon, partially seen in the previous post, now fully visible. It already has some nice special unique attacks but it's not completely finished yet...
And yeah, more enemies! Goblins and zombies have joined the game!
And like promised, best for last. The new HUD. We've added a compass feature to our game now, which points to the direction of where the exit of the dungeon is. Styled in the same way as the inventory and the hotbar, it looks very awesome! Exp- and lifebar are not finished yet :P
Well, I think that was enough to show you in this blogpost, stay tuned for more!
I would also like to take this opportunity to credit my brother Raymond, who made all this nice stuff. Thank you very much!
And like promised, best for last. The new HUD. We've added a compass feature to our game now, which points to the direction of where the exit of the dungeon is. Styled in the same way as the inventory and the hotbar, it looks very awesome! Exp- and lifebar are not finished yet :P
Well, I think that was enough to show you in this blogpost, stay tuned for more!
I would also like to take this opportunity to credit my brother Raymond, who made all this nice stuff. Thank you very much!
maandag 6 januari 2014
Music Monday 6: The Sound Design
Hey all! For today no music, but some details about the way we are doing audio. We are using a program called XACT, which is included with the Game Engine we are using, XNA. It provides many options for dynamic audio to further immerse yourself in the experience. All sound effects are positioned, so you hear them in surround precisely on the position they are. It also has a function that makes sound fit in the room by adding more "echo", which is better known as "Reverb". In larger rooms, the sounds echo longer, to further increase realism and immersion. Lastly it provides functionality to randomize the pitch and the volume of the sounds, so it does not sound identical all the time.
This game is also my (Emile van Krieken) first go at Sound Design. Some of the sounds I have recorded myself and others I have taken from the wild interweb and edited them to fit the game better. It has been a lot of fun, and has motivated to get a field recorder so I can record every sound for future games myself!
The music will play in a semi-random way. When there is no song playing, it will sometimes choose a random track from the atmosphere collection. Certain places in the world, however, trigger a song that is more energetic and suited for combat, so the music fits what happens on the screen. We use a nice fade-out to make everything sound smooth!
Well that is it, simple but it works. Stay tuned for more cool stuff!
This game is also my (Emile van Krieken) first go at Sound Design. Some of the sounds I have recorded myself and others I have taken from the wild interweb and edited them to fit the game better. It has been a lot of fun, and has motivated to get a field recorder so I can record every sound for future games myself!
The music will play in a semi-random way. When there is no song playing, it will sometimes choose a random track from the atmosphere collection. Certain places in the world, however, trigger a song that is more energetic and suited for combat, so the music fits what happens on the screen. We use a nice fade-out to make everything sound smooth!
Well that is it, simple but it works. Stay tuned for more cool stuff!
zaterdag 4 januari 2014
Screenshot Saturday VII
In case you didn't get last week's reference, it was from the Lord of the Rings: "The ground shakes, drums... drums in the deep. We cannot get out. A shadow lurks in the dark. We can not get out... they are coming."
Obviously a reference to the Troll you could see in the distance. Luckily, you can get a better look at it now in our blogpost about enemies.
Speaking of Tolkien, have you seen the Hobbit yet?
Obviously a reference to the Troll you could see in the distance. Luckily, you can get a better look at it now in our blogpost about enemies.
Speaking of Tolkien, have you seen the Hobbit yet?
donderdag 2 januari 2014
Grrr.. *cough* GRRRR
As you were able to see in the previous Screenshot Saturday’s, we have been adding a few monsters to the game. We figured it would be interesting to tell you a bit more about them. A week or two ago Dwight wrote this blogpost about our AI, in which you can read some of his more technical remarks on how the monsters ‘think’. I’d like to look at our monsters from a different, but equally interesting perspective: the perspective of a game designer.
As a start, we decided to divide our monsters into a few categories:
As a start, we decided to divide our monsters into a few categories:
Regular Melee units
These units will make up the backbone of Enemy Hordes. They are moderate in everything: numbers, speed and strength, but they are persistent and not to be thought of too lightly.
They are meant to keep you on your toes: while you deal with the more specialised units in the game (see below), they will be there to catch you off guard, or to prevent you from attacking that tank from behind. They will not linger in the chambers but pursue you into the tunnels.
An example of this unit is coincidentally also the first unit we added to the game: the bandit. Armed with various cheap weapons, these vagabonds use the top floors of the Dungeon as their hideout.
Ranged units
The archers and mages of the Dungeon are few in number, but still very dangerous. They can easily reach you with their poisoned arrows and dark spells, while they hide behind the melee units.
Alas, no screenshot for this unit yet.
Tank units
These often colossal creatures are slow and dumb, but incredibly strong. A frontal attack is almost always fatal - instead the player should search for their weak spots or take them out from a safe distance using ranged attacks.
Our first tank unit was also featured in Screenshot Saturday VI: the Troll.
Swarm units
Swarm units are small, weak creatures. But their name probably tells you enough: They appear in large numbers, and will surround you if you don’t watch out - leaving you demobilized and vulnerable to other, stronger units.
Our first implementation of this type of unit is the bat. Don’t let the friendly squeaking fool you - they can be fatal.
These (admittedly rather abstract) descriptions are nice, but the real fun begins when you run into a combination of the above monsters. Sure, a single troll is not that hard, but if it is supported by a mage, some bandits and a dozen of bats, you may actually have to turn off the automatic pilot and devise a strategy.
These units will make up the backbone of Enemy Hordes. They are moderate in everything: numbers, speed and strength, but they are persistent and not to be thought of too lightly.
They are meant to keep you on your toes: while you deal with the more specialised units in the game (see below), they will be there to catch you off guard, or to prevent you from attacking that tank from behind. They will not linger in the chambers but pursue you into the tunnels.
An example of this unit is coincidentally also the first unit we added to the game: the bandit. Armed with various cheap weapons, these vagabonds use the top floors of the Dungeon as their hideout.
The archers and mages of the Dungeon are few in number, but still very dangerous. They can easily reach you with their poisoned arrows and dark spells, while they hide behind the melee units.
Alas, no screenshot for this unit yet.
Tank units
These often colossal creatures are slow and dumb, but incredibly strong. A frontal attack is almost always fatal - instead the player should search for their weak spots or take them out from a safe distance using ranged attacks.
Our first tank unit was also featured in Screenshot Saturday VI: the Troll.
Swarm units are small, weak creatures. But their name probably tells you enough: They appear in large numbers, and will surround you if you don’t watch out - leaving you demobilized and vulnerable to other, stronger units.
Our first implementation of this type of unit is the bat. Don’t let the friendly squeaking fool you - they can be fatal.
These (admittedly rather abstract) descriptions are nice, but the real fun begins when you run into a combination of the above monsters. Sure, a single troll is not that hard, but if it is supported by a mage, some bandits and a dozen of bats, you may actually have to turn off the automatic pilot and devise a strategy.
In addition to the aforementioned units, we are also considering a few other, ‘special’ units that do not really fall into any of the above categories, such as units whose visibility or strength depends on the light level they are exposed to, or units that are able to navigate through walls. But more on that later.
Abonneren op:
Posts (Atom)