I achieved a big step in my game yesterday! I am now able to change the current map in the game. Before doing the real code, i have modified the MapContext object with all the initialization process inside one method. The RuntimeContext object can call this method during map switch. It is now possible also to reload a MapContext, updating only what is necessary when the map is used as the current one. The RuntimeContext object is able to load multiple MapContexts and switch between them when the player move to another room.
The current result is pretty rough but it is working !
So now, when killing a monster, they have a probability to drop one item (coin, ammo). The randomness is quite simple in this first implementation but i will polish this later because for example, i need to be sure that if some ammo are dropped, that the player has the right weapon for this type of ammo.
As i said later, i prefer to implement now the basis and polish everything later.
Next step? Changing map with a door or a stair! But i know this will require lot more work that the last things i have shown.
I am progressing a lot these days in my Cthulhu game.
After implementing items drop, i added the code to manage ammo for shotgun, displaying it in the weapon bar, peeking ammo on the floor, decreasing ammo when shooting monsters, and running out of ammo with the shotgun. The font used to display it (the same as gold) is not perfect but this will do the job for the moment. Too many times i have focused on details but i think that i need to make progress on high level mechanisms and not trying to make everything perfect. This will be polished later.
My next goal is to implement dropping items from dead monsters.
So now i am able to drop items on the floor, i have implemented to pick them.
Next step: pick ammo on the floor, manage ammo when shooting etc
So it took me lot of time to implement ranged attacks in the game. Mostly because it was difficult for me to work on the game. I have refactored a lot of things: the attack system was too much “close attacks” oriented and i just want only one attack system in the game.
I have also modified the rendering because there is a sprite for the bullet to handle with other sprites like hero or monsters.
The collision system i used for wall works great for bullet hits so this part was easy.
Indeed the most difficult things was to debug the code because it is not really possible to use unit tests to check each logic parts. I have implemented a feature to slow down the game speed in order to debug it like a step by step process in the real game.
The next step i have already started is item drop like coin and ammo.
to be continued !
Pre-Launch Panic attacks
This article is from a unity developer explaining how the stress invades him just before releasing his game. He is giving some useful tips on how to handle with bad feedbacks. The title is not accurate because some tips are more general and concern the whole developing process but he has definitely some good points. The article mentions the software Spine which I already heard about months ago because it was made with LibGDX. I am pretty sure that Spine is really useful but for the moment I am dealing my animations without it as I want to keep my game with a “pixel” look and feel.
Mark brown youtube channel
I just discovered this guy when i was reading a test about the new Zelda ([FR]). His channel is pure gold for an indie game dev. The guy is analyzing top hit video games (zelda series, doom, mario …) on a particular domain: gameplay, music, difficulty etc. Currently, there are 48 videos available grouped in a list he calls “Game maker’s toolkit“. These videos gave me a lot of new ideas and make me realize the importance of certains aspects in my games.
There is also a set of videos called Boss keys on how Zelda dungeons were build over all episodes.
How to code and release the damn game
I really like Orange pixel. First, the guy has developed a lot of good games since 2004 like Meganoid or Heroes of Loot for android. He shares all his progress on his blog and some articles concerned directly his life as an indie game developer. This article explains how he is choosing which game to work on, how much time he think it will take him to release it and why depending on the money of this game can motivate someone. For him, it is the key difference between an hobby and pro dev and can explain some choice done during development.
Scala 2.12 is released since several weeks now, and Scala 2.12.1 yesterday. It has a lot of features including using java 8 lambda for Scala lambda. But sadly Android is stuck to java 7 even if Android support some Java 8 features.
I was asking myself if I have to moe my game on this version but as i am targeting Android for my main platform, it seems a little dangerous. So i said to myself that someone else have already ask this question somewhere and i am right.
A part compilation enhancements, performance gain and java interoperability, there is nothing new regarding language with Scala 2.12. And as a redditer mentioned, Scala 2.11 is still in the loop and a 2.11.9 is scheduled.
So why trying to move to this version? Good question. What I suppose to be a smart move is indeed not necessary and indeed time consuming.
I never got the chance to play with Unity but I am seeing more and more games developed entirely with it. I thought that Unity requires developers to pay a license but it seems that the free personal version gives enough stuff to do the job. I found it when I have looked to the game Dungeon of Zaar. I was very surprised to see that the game was developed with this type of license. The game looks neat and is available on several platforms.
So I have decided to give it a try and see how fast/easy it is to develop with Unity. This could give me some idea for future development.
So finally i have tackled this nasty bug in my game which makes all my animations really weird when using a tool like a shotgun… it was very difficult to find it because there was a mix of action cleaning stuff with states check routines and, at the end, my code was really difficult to understand.
So to track it, I have refactored a lot of code in order to make me understand what happened. The final code is still complicated and I am not satisfied with it but at least I can now continue to implement ranged attacks.
The cool thing is that to track the bug, I am now able to decrease/increase the speed of the game with a keyboard shortcut. I am sure this would help me a lot for future bug tracking.
All this thing make me realise that it is very difficult to debug a game because of the real-time process:
- you can’t really use breakpoint because they will stop the process on every frame.
- you could use a conditional breakpoint to reach a bad state. You will be able to see the context but you will not be able to track all the history.
- forget to log every step, you will have zillions lines of logging where it will be difficult to find any relevant information.
- some would tell me to unit tests but as I explained above, it so dependent on the context that it is difficult to reproduce it.
I don’t know how real game studio are working but I am sure some technics (that I don’t know) exist.
Well… 6 months without touching any line of code in my game or the framework… Sometimes it happens. But i am back now ! And i hope that i will have something to show soon!