Hello Frakass,
I Finish your game and I hve seen bug.
In the forest scenario when I reload my copter in fuel and life I don t loose money.
And when I kill All 21 ennemies , I cant lift in the base camp , the game don t finish same as the desert scenario.
Finnaly in the .inf you have forgote to write the name of the game ...
The next in frech because my english is so bad
Techniquement j'ai regarder le code et j'ai (encore) quelque remarque.
Tous d'abord tu a bien séparer les methode de logique d'affichage (ce que tu n'avais pas fait dans le jeux de zombie et du coup j'avais pas pue faire un mode multi
)
Par contre Pour ce rapprocher d'e la philosophie POO (programation orienter objet) j'aime regrouper mes fonctionaliter par theme
Par exemple tu vas avoir
player.ino
dans lequel tu vas trouver 3 methodes (et les sprites lié)
initPlayer();
drawPlayer();
updatePlayer();
puis un world.ino dans lequel tu vas trouver ces 3 meme methode
initWorld();
drawWorld();
updateWorld();
Ainsi de suite pour les differents module ennemi, menu,......
On pourrais carrement faire avec des class (cf super crate buino) mais je pense que sur de si petit projet on y gagne pas forcement en lisibilité
ensuite dans ton .ino principal tu retrouvera le fameux :
- Code: Select all
switch case(GameState)
{
case MENU :
updateMenu();
drawMenu();
breack;
case GAME :
updatePlayer();
updateEnnemies();
updateWorld();
drawPlayer();
drawEnnemies();
drawWorld();
// et ainsi de suite
}
Bien évidement ceci n'est que mon avis pour faire du code propre, et, je prends souvent des raccourci, pour éviter des PB technique, ou juste par pure flemme
. (cf glaçi glaça ou tout est dans le meme .ino
)
Les avantage de cette organisation serons que quand tu veux modifier ton ia par exemple tu sais que tu vas la trouver dans le ennemies.ino dans la méthode update. Que quand tu touchera a ton IA tu ne touchera pas au reste du code qui fonctionne dejà bie.
Voila pour les conseille technique.
Sinon ton jeux est super je pense qu'il pourrais l'etre encore plus :
Le PB principal est la répétitivité.
Pour pallier a ça je pense que tu pourrais séparer ton jeux en plusieurs .hex
1 pour le menu qui servira de point d'entre.
1 par mission
Si on imagine un système copier du loader de la gamebuino tu pourrais avoir autant de mission que tu le désire.
Chaque mission étant dans un unique .hex tu pourrais faire des scénario différent.
-Protection d'un convoie
-destruction d'un objectif en temps limiter
-combat aerien
-.....
Si tu est OK je pourrais t'aider a refactorer le code et a prendre en charge le menu dans un premier temp.
j'ai déjà fait un embrion de systeme similaire dans le jeux des pirate (qui n'a jamais été fini)
Bon comme tu peux le constater je suis aussi bon en français qu'en anglais mais au moins mes phrases sont compréhensible
--------------------------------------------------------------------------
--------------------THx google trad
------------------------------------------------------------------------
Technically I look at the code and I (still) a remark.
All first you has separate display logic method (that you had not done in the zombie games and suddenly I did not make a multiplayer stinks
)
To bring against by e OOP philosophy (programing direct object) I like to group my fonctionaliter by theme
For example you'll have
player.ino
in which you'll find 3 methods (and related sprites)
initPlayer();
drawPlayer();
updatePlayer();
then a world.ino in which you'll find these same method 3
initWorld();
drawWorld();
updateWorld();
So on to the different enemy module menu ......
It could if wanted to do with class (see super crate buino) but I think that on such small project is not necessarily wins readability
Then in your main .ino you will find the famous:
- Code: Select all
switch case(GameState)
{
case MENU :
updateMenu();
drawMenu();
breack;
case GAME :
updatePlayer();
updateEnnemies();
updateWorld();
drawPlayer();
drawEnnemies();
drawWorld();
// et ainsi de suite
}
Obviously this is only my opinion to clean code, and I often take the shortcut, to avoid technical PB, or just sheer laziness;). (see Glaci froze where everything is in the same .ino: shock:)
The advantage of this organization will be that when you want to change your ia example you know you'll find it in the ennemies.ino in the update method. That when you receive your IA is you will not touch the rest of the code that already works bie.
So much for the technical advice.
If your game is great I think it might be the more:
The main PB is repeatability.
To overcome this I had thought that you may split your games more .hex
One for the menu that will serve point of.
1 per mission
If we imagine a system copy of the loader gamebuino you could have as many task as you wish.
Each mission is a unique .hex you could make different scenario.
-Protection Of a convoy
-Destruction a time limit objective
-combat aerial
-.....
If you are OK I could help you to refactor code and take over the menu initially Temp.
I already did a similar system of embrion in pirate games (which was never finished)