[Released] Copter Strike

[Sorunome]

Glad I could be so helpful XDD

[alastorn]

ohhh great man!!

[frakasss]

Done!

B button allow player to switch between 'rotation' and 'lateral' movement of helicopter.
Helicopter automatically land on heliport area when life and/or fuel are not 100%.

Next steps in 2 weeks: I'm going to be lost in mountain in the meanwhile!

[erico]

if we are able to kill em all, I´m fine!
Great work!

[clement]

Some news?

[frakasss]

Sure!
I'm moving forward!

I just complete the map, placing enemies. Everything is working, but I'm going to break it again
I'll try to add the map to this thread later today

[frakasss]

And I think it's done!
I'll create a new post in the 'Game' section!

[clement]

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)

[frakasss]

Hi Clement!
First, thanks for giving your time to 'beta-test' my game!

I had a quick look, and fixed bugs in lvl2:
- player is now 'losing' money for fuel/copter fix.
- when all hostile building are destroyed, copter can go back to base-camp, and finish the game.
- inf. file is up-to-date now (I also added a 'credit' slide... after all, I'm quite proud of my game )

About all your comment about POO oriented development and so, I'm always open to technical advises! Thanks!
I agree about your point 'the game is quite repetitive' and I'm very interested by your idea of having several .hex files (1 per mission) and a common menu.

Indeed, I'm ok if you want to refactor / improve / add features!
I'll be quite busy in the next couple of weeks, so probably not really active, but this idea of having several .hex files communicating together is quite awesome and motivating!

Pas de soucis pour le niveau d'anglais! Je ne suis moi-même pas très sur du mien!

[clement]

I ve create a pull request with generic menu and Two mission.

Now we can create unlimited(20 but I can increase this limit) missions for the game !

Missions are classed by 01....HEX, 02.....HEX, and we can create a scenario

I Create subfolder for dont loose your original game, you can merge in total trust .

I use a clone of the gamebuino loader for generate game menu, thx to Sorunome/Rodot for theire works.

It's not perfect but it's functionnal .

++