I’ve decided to move all the Dragons at Dawn development posts to my main blog, thinking about it in hindsight it didn’t make much sense to create a separate blog for it. Perhaps when Dragons at Dawn becomes full game I can go back to having a separate website to keep track of high scores, change logs and I am sure many other things.
As for actual development of the game, I haven’t worked on it that much in the last week as I have been watching a lot of the Olympics which has distracted me from coding but what little work I have managed to do has been on the ability points system. I’m currently working on the best way to allow the player to upgrade their character. This is pretty much the last feature that I want to implement before designing levels and eventually releasing an Alpha version of the game. So watch this space.
Yesterday I managed to implement an entirely new section to the game, previously when you completed a level the game would just load the next level and you would be off on another adventure again, now the game loads an end level screen that displays some stats to the player.
Currently the game displays the following stats; Score, Total Kills, Level Kills, Attack, Defence and Speed, I’m also going to include other stats such as maximum health and total rage. I’m having a bit of an issue with displaying the speed stat as I am using a Vector2f rather than an integer, so it displays as “Vector2f(5.0F, 5.0F) rather than just “5”. I think I know how to solve it but making the screen look nice isn’t a concern right now, I need it to be functioning how I want it to first.
The next section I want to add to this screen is a levelling up part. I’m thinking of adding EXP to the game, which you will receive for killing enemies, completing levels and maybe some things that I am working on. Once the level is completed you’ll gain levels which will reward you would ability points, these points can then be spent on upgrading your character.
I haven’t got a screenshot of this screen to show you today as it really isn’t much at the moment, I’m going to continue to work on the screen over the next few days and get it working how I want it to and then I’ll release some images.
I got back from France yesterday and took the rest of the day off to settle back into things at home, I woke up early this morning and decided to crack on with some more Dragons at Dawn coding. I decided to ease myself back into the routine by doing some less taxing work and thus today I worked on the HUD.
As you can see from previous posts the HUD was really quite awful, a grey box with a horrible magenta colour. I took out that chunk of code and made a separate class for the HUD, this gives me more control over what I want to display and when I want to display it. The HUD now consists of an avatar for the player based on what character they choose (only red and blue are currently implemented), a health bar for the player and a rage bar.
The health bar obviously keeps track of the player’s health but the rage bar is more interesting to talk about. In the browser version of Dragons at Dawn, the rage bar built up each time you destroyed an enemy, once full you could release a seriously powerful attack. I really liked this feature and so I wanted to implement it into this incarnation of the game. In my previous post I talked about working with bullet patterns and one of the things I am going to use them with is the rage powers.
I’m not sure how I am going to use the different patterns yet, whether each character will have their own unique move or if you will be able to pick and choose. For now I am not thinking about that too much and I am just trying to get the game to a basic state that I am happy with, and then I will add on all the extra features. For now you can enjoy some screenshots of the new HUD and a rage power in action.
Image of the new HUD for Dragons at Dawn.
An Example of the rage power being activated.
There was only one change I made to that game yesterday and that was to implement a scoring system. If you manage to shoot another creature down with your fireballs you gain 10 * the creatures max health. If you fly into the creature and destroy it that way, you don’t gain any points. I’m also thinking about implementing additional points for completing the level quickly.
The reason why I was only able to make one change to the game yesterday was that I got carried away with the bullet physics, at the moment your character only fires a single shot in a single line and it moves forwards until it hits something, this is quite boring. I decided to take some ideas from bullet hell type games and implement some pattern shots. I won’t reveal all of them now as they’ll be a nice surprise when you play the game, but here are three that I made yesterday;
(Due to moving blogs I have lost all of the original images)
As mentioned earlier in the week, I am going away to France today, so there won’t be any Dragons at Dawn development going on for about a week, maybe a bit longer. I’ll use this time to reflect on what I’ve already made so far and to think about where I can go from here, for example what ideas to implement next.
I didn’t really get much achieved yesterday as I kept getting distracted by various things such as Breaking Bad and the Steam Summer Sale; I’ve played A LOT of The Binding of Isaac. I did manage to implement some big changes to the game code though, for example when the player dies it now resets everything and takes the player back to the main menu screen, at a later date when I’ve made one, there will be a game over screen. Hopefully I will be able to incorporate some kind of online leaderboard for people to rank their scores on, maybe post their score to Twitter.
I’ve made improvements to the FireballAI so that it now causes damage based on the players attack, previously I was just doing a set number of damage for testing, the next step for this is to make a damage calculation method that takes in the entities defence and deducts that from the players attack. Although what will happen when the defence is of a higher value then the attack I do not know, perhaps I will default it to doing one damage.
I’ve also successfully implemented another factory class, this one is for items. Currently the only item in the game is a health pack which restores a set value of health, I’ve made sure that if the player picks this up they cannot get over healed at all, currently there is a 10% chance that a Dragon will drop one of these health packs but only when destroyed by a fireball, if the player collides into the dragon then it doesn’t drop anything.
As I said, I really didn’t achieve much yesterday but I am getting closes to the stage where the core of the game has been built and then all that is left is level and item editing. Then I have the fun task of balancing the game, that’s always fun! This is my last day of development before heading off to France so I want to get as much done today as possible.
Yesterday I made a huge amount of progress on Dragons at Dawn, so much in fact that if I did my normal style update about everything I’ve changed, it would go on for a while. To keep things short and sweet I’ll just bullet point them with a short description afterwards.
- Improvements to the parallaxing backgrounds code, images now are moving a lot smoother. At some point in the later development I may write a proper class for this and submit it to MarteEngine and see what they think. Games always look cool with parallaxing backgrounds!
- Successfully implemented code that changes level when all the current enemies are destroyed. This now means that I can implement multiple levels whenever I want. After implementing this code I found that a lot of entities where still being rendered from previous levels, so once the game had loaded the fourth level, there was a quite a considerably large amount of entities that where apparently still there. I found that the reason for this was that I was not calling the Clear() method, however this lead on to another issue which I will talk about next.
- Implemented a Stats class, this class keeps a track of the players stats, everything from the X and Y Co-ordinates to the amount of health the player has. When the Clear() method was being called it was removing the player from the screen along with all the players information, this means that I had to render a new one, but I want to keep all the previous information about the player. The stats class allows me to pull this data at any time I want. Later in the day I made improvements to the stats class making it for efficient in the way it collects data.
- Implemented a basic HUD; at the moment it just displays the players health in a horrible magenta colour, I’ll need to design a better look for it and make a decision on whether I want it on the screen at all times.
- Implemented ProjectileFactory, Projectile, ProjectileAI and Fireball classes.
- Implemented the ability for the player to fire fireballs, player uses left mouse click to fire.
- Fireball collision now working as intended, fireball is removed on collision and damage is done to the enemy
That’s it for now, as you can tell that was a rather large update I managed to achieve yesterday. Hopefully I will make as much progress today and be on target to have a playable version by Thursday. I am away again on Friday as I am off to France for a holiday, having a playable version would be a really good milestone to leave on.
Now that I have the game fundamentals working the way I want to; the next step was to add in some other entities into the game for the player to interact with. Today I added in one new entity; the Dragon. At the moment it’s just a simple enemy that flies in the opposite direction to the player. While implementing the Dragon class I found a cool little method in Slick that I previously didn’t know was there; since the Dragons are flying in the opposite direction, they need to face the other way, instead of having two copies of every image, if you invoke the “getFlippedCopy” method on your image, lo and behold the image is flipped!
Once I had the Dragon Entity implemented and moving, I decided that I needed to implement Ai at this stage, by giving each entity its own Ai class, I can uniquely customise each enemy to have a specific behaviour, the code is then kept nice and tidy within each entity Ai class, however if there is a method or a specific behaviour that I want all or some of my entities to have then I have to duplicate the code. So to avoid this I have implemented a generic Ai class and made it abstract, then each of the individual Ai classes inherit from this. I can then put methods that I want more than one entity to use in this generic Ai class.
After this I was easily able to implement collision detection into the Ai’s, for now if a player collides with another Dragon that dragon is removed from the world and the play loses some health. This will get worked on more at a later stage of development, for now I just need to know that the game is working as intended, once I have all the game like that I can go back and make it awesome.
After making that last post I went and made a cup of tea and some toast, then gave the code one last look over before starting again. As Sod’s Law would have it, I fixed the issue that was causing me all the problems.
In the end the issue was quite a simple one to resolve and it stemmed from me not understanding how a part of MarteEngine works, but that is one of the reasons why I love programming. The sense of achievement you get from fixing something you didn’t think was fixable, of course the feeling you get when you can’t fix something far outweighs this and often happens a lot more, swings and roundabouts right?
Anyway, back to development!
Until about an hour ago this was going to be another “More Progress Has Been Made Post”, however I’ve stumbled across a small issue in the next stage of development which means I can’t implement the code in the way I thought I could. This means one of two scenarios must happen; either I start all over again, or I start the arduous task of refactoring all my code.
The only good that can come out of this situation is that I am going to be away from my laptop for 4 days, this means that I have time to rationally think about this and decide what is best. Perhaps in that time I’ll find a magical third option that allows me to continue with the way I have the code now, but that is about as likely as a kiwi learning to fly, and we’re talking the kiwi fruit here, not the bird.
While this setback is annoying, it hasn’t dented my ambition and it’s something I can learn from and grow as a programmer, I’m doing new things with the Java libraries that I’ve not done before and errors are going to be made. It’s better that I find this error out now at an early stage of development, rather than a few months down the line when the game is a lot bigger and starting again isn’t really an option.
Come this Friday I shall make a new post about what I’ve decided to do, however in all honestly it looks like starting again is the better option. I can re-use a lot of the code I’ve written now, I just need to change the core of the program.