next »

[Mikademus]

I originally intended this to be the first TIGCompo I'd enter but time and circumstances didn't allow me. Nonetheless, I have followed previous ones, and this one in particular at a daily (frequently multi-daily!) bases, then especially some selected favourite entries. In all I'm overwhelmed by the quality of the submissions!

Also, perhaps in being a theme that invited 3D games, this compo seems to have had more than the usual amount of drop-offs and technical issues. Therefore I thought that a post-mortem thread might be interesting where short analyses of what went right and what went wrong with the games (as well as any other interesting notes or comments) would be an interesting read!

[edit]

Would you also mention which game you worked on?

[nihilocrat]

Hard Aether Postmortem

Summary-

Lots of shortcomings in several sectors, but I am happy that I've managed to make a game that is, more or less, complete, and has all the trappings of a complete game. At least I don't feel it was a failure, but even if that were the case, at least I would have started something and finished it.

Good:
*Visual style was nice
*First proper game with a main menu
*Learned /again/, design-wise, to keep it simple. Became much more productive when I simplified the cockpit interface.

Bad:
*Missile tracking is broken!
*Cockpit interface is more spartan than it really should be
*Game isn't really fun, at least for me
*Enemy craft models are wasted because you never see them


Technical-

The biggest lesson here was: keep it simple, stupid.

The orignal plan to have a fully 3D interactive cockpit, with the view rotateable and even little doodads that are fully 3D and toggle and move around. This would have been completely feasible if the function of the cockpit were much simpler, and not a tool for piloting a realistic combat spacecraft. However, it was a humongous hindrance and source of wasted effort early on.

Mid-way through the compo, I was able to re-implement the cockpit as a static 3D object with static 2D overlay on top over the space of a weekend, and changed my attitude completely around from a sinking feeling that I wouldn't get it done in time.

However, on top of that, I didn't get a series of cockpit interfaces done that I really would have preferred to get done. Not having them makes flying harder in a way that's more frustrating than fun. I'm disappointed that I didn't get around to making a radar display of any sort. They are fairly easy to implement and are very helpful for orientation, it's just I didn't have the energy to create it in the final days of the compo.

Math-wise, I should stay well out of 3D until I can figure out the correct math for doing a score of "fundamental" operations. Of course, by fundamental I don't mean stuff like matrix rotations or vector math. I mean things which 3D engines never implement, because they are just rendering engines. Slerping, position prediction, and a host of other things I couldn't manage to get working properly.

The missile tracking algorithm, being a core feature of the game, didn't really show its ability to completely dismantle the game until the last moments. The missile tracking algorithm worked out when I had all of the targets in visual range; everything was about 50km or closer, and wasn't moving very quickly. When I toned up the acceleration forces and distances, it started to fall apart. I don't actually properly predict the path of ships, I predict using values that are "good enough" at close ranges and low speeds. The true method is hidden somewhere in piles of source code and the minds of professsional game programmers. It's very frustrating and shows the core of my diffuclty with math; I know there is a correct answer out there, so if I can't find it, it must be because I'm too stupid to figure it out, leading to even more frustration.



Design-

This is probably the one game I've worked on where the final product was pretty amazingly different from the original idea. The basic ideas are there; real physics, missiles, lasers, huge distances. However, all the details are different; the cockpit interface is more spartan than I'd really want, and the gameplay is a wave-based gauntlet scenario instead of some sort of more realistic mission-based game.

The more I worked on it, the more I realized the idea wasn't really going to lead to a game that was simeltaneously fun and could be completed in a month. Honestly, this was not my primary goal; the idea was more experimental than an attempt at executing a cool idea.

When the gameplay finally came along, it seemed I was making a missile interception game. It was sort of fun to have to keep up with all the targets as they came in range and started firing volleys, but I noticed that the range and recharge rate of the laser versus the number of missiles incoming was a bigger factor than the player's ability to keep up with the missiles. When you had about four incoming at once, all launched from approximately the same distance, you were screwed. It's not really a bad thing, though, as part of the strategy should be to keep your distance and only engage a few at once.


Visual-

I'm bummed that you never actually see the models of the ships! I'll have to fix that in future versions by showing models of your targets on the targetting screen.

Otherwise, I'm pretty happy with the visual result. I'd like to play more with particle systems and try using ribbony particles instead of blocky ones for my next set of contrails.

[Glyph]

To shorten it to a statement- I needed 5x more playtesters. I spent forever finding new bugs and slowly fixing them, when one quick runthrough would have sufficed.

[genericuser]

A brief summary of stuff that went right and wrong in Super Cockpit Football Fighters:

The Good Things!

1. It was fun. The gameplay worked pretty well, and it was (at least for me) a game you could easily play for a few minutes(or hours, YMMV  )

2. It was simple. The fact that you could explain the controls in about 10-15 seconds helped a lot.

3. The music. Tomica made the soundtrack for the game, and I think that the game really benefits from having sound. For instance, when I saw the playtest of the game on YouTube, the Benny Hill theme was playing; I almost immediately noticed that the game was funnier that way...so I pretty much learned that music and sound really helps make a game.

4. I managed to make a good entry for the competition. 
(Basically, most stuff just went right.)

The Bad Things...

1. The physics were buggy. Although the physics bugs weren't something I could've fixed without messing about with Bullet and such, the bugs still irk me quite a bit.

2. I wasted my time adding features that weren't actually necessary and didn't really work. After realizing that I didn't actually need to have MP3 playback and packed executables, things went a lot smoother.

3. I could've spent more time working on it. 


So in the end...it worked out pretty well, I guess. 

[Fuzz]

1. It was fun. The gameplay worked pretty well, and it was (at least for me) a game you could easily play for a few minutes.

Hours, not minutes...

[genericuser]

1. It was fun. The gameplay worked pretty well, and it was (at least for me) a game you could easily play for a few minutes.

Hours, not minutes...

Thank you 

It'd be interesting to see a postmortem of your games 

[David Pittman]

Cockpit Crash 1984

What went right:
I made the game.
It worked.
I improved it based on feedback.

What went wrong:
Well, it's just Battlezone.


Seriously, though, the biggest thing that helped me was already having a bunch of existing code (a 3D math library, an FMOD wrapper, an input library, a library to draw clean lines on a console window, etc.). I didn't want to spend a long time on this compo like I did on the CPB, so I just took a very simple concept and coded like hell for a day. I used global variables with gleeful abandon. I wrote the whole thing in one big main.cpp. It was totally not object-oriented. I copied and pasted instead of generalizing. And it was fast, at least at first. The downside of that approach is that it became increasingly rigid, and things that should have been relatively simple, like adding sound effects at the last minute, took much longer than I expected. In retrospect, the one thing I really wish I had done is to include one good gameplay innovation. The tech was solid and I breezed through the implementation, but the game just isn't worth more than a passing glance because it does nothing new.

I'd like to revisit "vextor graphics" in the future, maybe for another compo, and I'll focus a bit more on design next time.

[Super-Dot]

Damsel Game (which didn't end up being made)

What went right:
I had a complete game design!
I had a mostlycomplete software design!

What went wrong:
Content creation ended up being a problem. The game uses two outputs: window-shaking and audio. As it turns out, the math for the window-shaking ended up being tedious and error-prone to implement. And I don't really have a place IRL where I can record audio without bothering people.
I was working on other projects which interested me more.
Schoooool

[György Straub]

Tragedius

Happy with, no questions asked:
- my second (attempt at writing a) full-fledged (something presentable: menus, states, settings) game in C++. it's full-fledged, it's a game, I'm a happy.
- deploying my framework for something it wasn't even really made for (and correcting bugs and implementing new functionality for it), alias making 2D look and act and (sorta) feel like 3D
- the way how the ship's behavior and collision detection worked out
- the level editor
- music (I've been missing musicmaking, and Tragedius was a good excuse to get back to it)
- the particle traces behind bullets that was something I only added in the last minute

Unhappy with, no questions asked:
- feature cuts (bosses and story mode)
- documentation and not having pulled the player's attention how important it is to shoot those flashing enemies (okay, it's partly thanks to cutting the story mode for the CCE).
- okay, also the difficulty, a bit.

Will improve:
- modular design, with special regards to game events (of which there wasn't a lot) - the source has got very messy towards the end, classes are reaching over and past each other. partly as a result of this I've spent a considerable amount of time waiting for recompilations
- the way memory is allocated/deallocated for stuff that's changing as fast as shots and explosions (I reckon some more cycles could be squeezed out of this baby)
- variety of enemies and weapons (still don't know how would it be sensible to do the weapons - there was a secondary weapon, a bomb planned and may still make its way to the final, non-CCE version if there'll be one)
- animated sprites anyone? (however the illusion of the gatekeeper and the interceptor leaning left and right as moving sideways worked surprisingly well)
- sound effects
- not leaving bugs in (the Gatekeeper enemy should not get behind the walls, it should stay in the plane of the walls - it's fixed in the yet unreleased v0.93a)
- post-mortem writing skillz(zzah)

to be continued?

[mirosurabu]

Emoticubes (not finished)

What went right
> I came up with cool but short-term game idea
> I composed music and designed relatively intuitive interface

What went wrong
> I fell in love with it
> I overlooked the time it takes me to write one single script
> I forgot how boring and frustrating can be to design drama management systems
> Initial 3-hour prototype was boring as hell
> It wasn't looking promising
> It sucks big time
> It's the worst game idea I have ever come up with (not really)

[J. Kyle Pittman]

Keep On Truckin' (canceled)

What went right:

• I got the tech for an infinitely scrolling road with hills and crappy faked lighting working in about a day.
• What's there is playable.  You can drive (and drive and drive); there's some simple physics for going up and down hills, and the car veers to the right.
• Technically I had a cockpit.

What went wrong:

• Didn't have any really interesting gameplay ideas besides recreating Desert Bus in 3D.
• Competition coincided with a big milestone at work and I didn't have as much free time as usual.
• Gave up caffeine last month and the late night coding sessions that came with it.

Actually almost came back to this one a couple of days after canceling it, when some of my friends suggested putting zombies on the road and QTEs when you ran them over.  Would've been hilarious in a sort of "LOL WUT" way, but it just didn't happen.

[Dugan]

Aqua Kitty - demo(barely)

THE GOOD:
  >Worked out a bit of code so the land tiles worked out what sort of edge piece they should be, so I didn't have to manually place corners/straights etc. It wasn't rocket science, but was a useful time saver.
  >Getting the big snake creature working was interesting and fun. Same for the subs, working out the AI for how they turn towards the player and so on.
  >Looked at as a basic prototype I think it worked out ok, as I can see what does and doesn't work compared to how I intended.

THE BAD:
  >Game not actually fun to play. There are small elements that are fun, but on the whole its muddled (as I have repeated below).
  >Ended up with a nice extra list of ideas but no time to implement them.
  >Forgetting how the code works a week after writing it! And then wasting time picking back through it (even with comments) - is really not fun. If the code lines could be coloured for the different sections that would help (am using gamemaker).
  >Started late (again), which really doesn't do the project any favours.
  >The idea of the game wasn't nailed down firmly enough. It up leaning partway to being arcadey, part to being sim-like (with the hampered turning for example which relates to speed), and as a result feels like a bit of a muddle.
  >Crappy audio, done in the last minutes and it shows.
  >Got sucked into the details too much rather than getting the overall game working (such as the route finding for the snake thing).
  >Collision needs a rethink - as there's some odd snagging issues which may be in part due the the sprite rotating. Further complications come from enemy subs bouncing you between themselves and the wall - whole thing just needs to be addressed from a fresh perspective.
  >It kinda cheats on the whole cockpit concept, as the view is more of a cat playing an arcade machine than an actual cockpit.

...still - on the bright side its always fun to enter these things 

[Pishtaco]

Venus Patrol

Good:

Satisfying an ambition - I had been thinking for a while about doing a small flight-sim project, with the goals of just having a realistic-feeling plane, mouse control and a simple AI which could at least fly a plane and navigate. I am pleased that I achieved at least this much.

Libraries - Using the Pyode physics library was a big timesaver. I didn't use much of the joint or collision stuff, but it took care of all the differential equations for me and meant that I didn't have to look at a single quaternion.

Lighting - I'm happy with the cheap environmental lighting I used for the plane, with one light the colour of the sky and one the colour of the ground, both changing with height. These do a good job of making the plane look like it belongs in the world, and I am glad that I resisted the temptation to spend time getting into shaders and GLSL to "do it properly".

Sound - Most of it is some pink noise I made in audacity, modulated based on the total drag on the plane (for the wind noises) or by doppler shift. These were pretty easy to do and work well, although it would have been good to spend more time making the engine sounds more rounded and less grating.


Bad:

Time - This was my first proper 3d project, and I must have spent about 90% of the time worrying about technology and framerate. In the end most of these things didn't matter, but it gave me very little time to spend on gameplay stuff.

Gameplay - Even if I had spent the time better, it's not clear that I could have made a complete game that would satisfy me in a few weeks. I didn't want to make an arcadey game where you shoot down dozens of enemies and rack up points, but rather something with a larger, more serious feeling; but I had no practical, realizable idea of what this could be.
 

[Bood_war]

Textpit

Right
-Got done.
-Somewhat fun.
-TI-84+ SE

Wrong
-Accidentaly erased

Damn RAM erasing function...

[muku]

I Approve Of This Thread. Post-mortems are cool. So, sorry for going a bit overboard.


Vessel-IV (thread)


Initial idea

The fundamental concept was to take the whole cockpit theme to its logical conclusion and have the cockpit be the sole interface between the player and the game world; no windows or other direct views into the world. Instead, I planned to have the cockpit be an actual three-dimensional place, with lots of gadgets and intriguing instruments, much like nihilocrat described above for Hard Aether.

Hardcore submarine simulations do this "cockpit-only" thing a lot (as the periscope typically doesn't play much of a role), and I actually enjoy those to a degree, so that was initially a strong influence. I even dug out my old copy of 688(I) Hunter/Killer to replay a couple of missions for inspiration.

The first idea as to the vessel to be controlled was one of those underground drills (as seen in the Turtles, remember? ). I even had a vague notion of a background story to go with it, however as time went on (and I had already implemented a good portion of the engine) I had this other idea which is now in the game, and which I feel works even better.

Including narrative in the game was also something I definitely wanted to do; increpare's games were a strong influence in this regard. I was quite impressed with how the narrative in games like Signifier or Opera Omnia transformed the experience from what were basically puzzle games into something more sophisticated.


Technical

I spent a good while implementing the underlying 2-D vector engine for representing the level geometry. Thankfully I already had my generic matrix/vector code from earlier projects, so most of it was quite enjoyable. Good clean fun with vector maths. I used a simple grid/spatial hashing strategy for collision detection with the map, which worked fine.

Not until relatively late in development did it hit me that the SVG format would be perfect for representing my maps, so I implemented a simple SVG map loader and was then able to draw my levels in Inkscape. It was great to be able to design the maps in a program which actually has a good UI for a change (as opposed to homebrew map editors which generally suck in the UI department). The SVG loading code also was relatively painless to implement; the format is quite simple if you only care about basic features. Definitely one of the best decisions in this project.

The 3-D cockpit itself is just rendered in a rather naive way; basically I just throw triangles at the GPU and let it sort the rest out (although I do render the actual cockpit interfaces in a second pass). There's no real 3-D engine underlying the game, but it works okay because the game is not demanding visually.


The good

I'm quite happy with how the general ambience of the game came together. One thing that I think helps immensely here is the sound; I didn't have any grand plans for that initially, so I'm all the more surprised how well it worked out. Most of the sounds were made in Audacity or using free softsynths.

The other thing I feel works very well for immersion are the camera shaking effects. This is where having an actual 3-D cockpit really pays off as you can simply translate your camera by some Perlin noise function and have a rather convincing illusion of the vessel moving.


The bad

Interaction with the game is limited; basically all you do is move around (although I think the control scheme is, if certainly not unique, at least something you don't see every day). I wanted to have many more instruments for the player to interact with and thus richer gameplay but, alas, time didn't suffice. At one point about a week or so before the original deadline, I even considered scrapping the whole thing because what I had just didn't seem fun. I still think it's not much of a "fun" game, but if it works as a one-time experience for the player to sit through, I'm just fine with that. This is also the reason I decided to keep the game short (that as well as lazyness on the level design front).

I guess a competent artist could make the cockpit much nicer to look at with not too much effort; art just never was my strong suit. But that's okay, I never intended visuals to be the game's selling point.

I'm not quite convinced that the narrative works as well as I hoped it would. I wanted to keep it ambiguous and have the player figure out step by step what the hell's going on, with the final conclusions partially open to interpretation, but I'm not sure I pulled it off.

[pgil]

Blastmosphere (unfinished)
The idea: Bring fast arcade-style gameplay to a flight sim.
The Good: I was pretty happy with the graphical style. I learned quite a bit about 3d graphics. I also learned a bit about sound, using a software synth to produce sound effects on the fly.
The Bad: Gameplay. Collision detection was the biggest problem, since game maker doesn't have built in functions to handle 3d collisions, and I don't yet have the knowledge to do it myself. This is the first 3d game I've ever attempted, and I have a lot to learn.

They're Going to Blow Up the Train
The Idea: Finish a game before the deadline 
The Good: Learned a lot about rapid prototyping. Came up with a concept, gave myself realistic goals, and got it working within a day's time. The result is far from perfect... but it's a complete game. And (imo) it's fun.
The Bad: Released it with a ton of bugs. Score didn't reset after starting a new game. There are some cheap deaths that I would have liked to prevent. There's a rare bug that may prevent you from exiting the game (hope I fixed this one!!).

Commander Jetpack (music)
The Idea: A ZX Spectrum style of music that fits the game.
The Good: A nice variety of styles, yet I think they work together. Experimented with odd time signatures, with pretty good results.
The Bad: Most of the tunes are way too short for such large levels. I should have spent more time on them.

[Jonas Kyratzes]

Phenomenon 32 (withdrawn)

The Good:

• I really like the abstract style of the graphics.
• I pushed myself to create a game of a completely different type from everything that I've ever done, and it worked. I managed to write some damn complicated code, for my standards.
• I managed to come up with a story that has some philosophical depth without hitting the player over the head with it or totalling railroading everything.
• The interface is really awesome, which is the thing that makes me the saddest about withdrawing the game. I wanted to make something that has a lot of detail, like a real cockpit, and that really worked out. The player has lots of options, and they all do something.
• I am very happy with the voice acting; it gives the game an additional level of reality (and scariness, hopefully).

The Bad

• I overestimated the amount of free time I would have.
• I overestimated the amount of time it takes to create these graphics. It's a very short amount of time, but if you multiply a very short amount of time with a big gameworld...
• I got stuck on some nasty bugs in the combat system that I still do not fully understand. (I went another way with the code and that worked fine, but I'm not sure what was wrong with the first version.) That cost me more time than it ought to have.

The Ugly

• I got a lot of work dumped on me at the end of the month.
• I spent quite a bit of time being ill, too.
• Because of the above, and because of the tendency of our cat to annoy me in the morning, I was way too tired, and worked at 50% of the speed I could have otherwise.

The Rest

• I'm something of a perfectionist. I just couldn't release the game the way it was. This is probably the wrong mindset for these competitions. But it's like showing someone the first draft of a story - I don't do that.
• On the other hand, the competition pushed me to actually put my ideas together and make a game. I'd been experimenting with doing something strategy-RPG-ish for a while, but it never cohered. Now there's an actual game.

[agj]

Viewpoints was a good experience. I set my mind, originally, to make a very quick game, in the week or so I had left of time to make it. When the competition was announced I wanted to make some sort of racing game, and I'm a big fan of Out Run, so I took inspiration from that to frame my game. Everything about it was designed to get it done as quickly as possible: the choice of platform, the mechanics, the visuals, the very concept. One thing I didn't expect would take quite as long as it did was the script, which ended up being around eighty unique lines, which seems to be a lot for such a small game. It was definitely what took the longest to complete. The visuals were done very quickly by just tracing sketches and photographs. Had I a tablet, it would've been a much faster process, too. Oh, and I had some trouble getting the engine to sound right, and I never did quite manage that, but it's good enough.

I would've been able to make it to the original deadline, but when it was extended I took my time to polish all the little details, so I'm glad I was able to do that.

The game didn't garner much popular interest, but I'm still happy about it, because it accomplished all my objectives, small as they were, and it turned out pretty much how I had imagined it in the beginning.

[andy wolff]

RELIGARE

run around as Vir, trying to restore the balance between good and evil
you can jump in and out of a mech, and kill stuff. we have/had sweet plans for it

good:
 michael's sprites are really cool and smooth. he did them in moho, an extinct vector animating program
 i like the visual atmosphere of the game
 the level editor is pretty effective, and you can do a lot of stuff in it
 i learned a lot about 3d game dev with this project, and i might make a third-person game of some sort eventually
 the music lined up for the game is intense

bad:
 neither of us had very much time, so the end demo didn't really meet our expectations at all
 you can't really tell what's going on when you're in the mech. at all.

[astrofra]

This game was the opportunity to develop a range of visual tricks. As a consequence, the gameplay was almost unexisting.
Here's a detail of some of the techniques used to achieve the overall visual look in "the Flying Island".

Game thread is here.


The 3D assets used for the game.

The Sea :



I made it with a set of concentric vertical waves. Each even circles are animated to the left, the odd ones are rotated to the right, then vice versa.
The UV coordinates were animated, to produce a scrolling effect of the texture, synchronised with the object animation.

Pros : easy to setup, no need for a morph or any kind of mesh deformation. Visually quite compelling.

Cons : once setup, it was almost impossible for the boat to move over the sea without making the trick obvious.

The island :
As the boat doesn't really change its position, I had to implement an internal system to make it actually move.
Depending on its speed and heading, the boat will come closer to the island, or not.
The distance between the boat and the island it real, so is the compass representation, unless we come very close.

The visual representation of the island works like this :

Code:

screen_island_pos = (real_island_pos - real_boat_pos).Normalize() * Mtr(1500)

So that, whatever happens, the island will always remain at the same distance.
To give the illusion of distance, the island mesh is scaled, more and more, as the player will come closer to it.

The good : fun to implement
The bad : players won't understand why they can't actually reach the island !

The moon :
The glowing moon is a 3d sphere, with a 2D ring in its half, to mimick the glow effect. In order for this ring no to be noticed, the moon is always facing the camera, as for a billboard sprite.

The main light used on this scene has the same coordinated as the moon, so that everything looks like it was actually lit by the moon.

The Water Impacts :



Only a ring modeled in polygons, that was scaled on its Y axis to create an animation.

Pros : easy to setup, no morph, no texture
Cons : quite cheap once animated, looks like a bad Adobe Flash animation.

The boat animation :
In order for the boat to appear sailing on the sea, it was rotated on its X axis, back and forth, using a simple Cosine function.
But I wanted it to physically interact with the rest of the environment (skulls, cannon feedback, etc). So I enabled the physics on the whole boat object.

Directly modification of the boat rotation didn't make any good to the physic system, especially regarding the collision detection.

To fix this problem, a dummy object was rotated, and the boat was connected to this dummy thanks to 3 physical joints (Position Constraints, aka Springs). Hence, the rotation was physically transmited to the boat thru the springs, easing greatly the collision system.

Same thing for the boat heading / turning.



In order to catch collisions properly, I placed collision cubes inside the boat. The result is not 100% accurate, but it works quite well.



Pros : The physics creates some additional appeal to the boat.
Cons : A bit complex to setup. Took me time to find the correct combination, though tt doesn't serve the gameplay directly.

The boat visual :
The boat stands for the main part of the cockpit. It was modeled entirely, but eventually I got rid of the sails & poles, for they would have obscured the camera & the main view.

At first I planned to texture it, but with the lack of time, I simply relied on an Ambient Occlusion baking. Auto UV unwrap and render texture did almost all the work for me.



Pros : quite fast to get a cool & proper result.
Cons : less personal than a hand painted texture.

The canon & boulders :
As for the ship, they are all handled in physics. Before being shot, they will remain on the bridge, for they are trapped into an invisible collision box. Their trajectory is full physic as well, the initial force of ejection being proportionnal to the time the player pressed the fire button.

The good : Easy to implement, as the physics handled everything for me, collision included.
The bad : the straight trajectory is not really fun. As Toastie mentionned in the thread, a curved path would have been more interesting to play with.

The enemies :
The enemies are spawn behind the player, whatever its position.
To do this with a minimal maths skills, I used 3 dummmies objects, parented to the boat object. These dummies defined the area in which I wanted the enemies to be spawn, with a few vector & rand() operations.

Code:

k1 = Rand(0.0, 1.0)
k2 = Rand(0.0, 1.0)

v0 = ItemGetWorldPosition(spawn_area_a)
v1 = ItemGetWorldPosition(spawn_area_b) - ItemGetWorldPosition(spawn_area_a)
v2 = ItemGetWorldPosition(spawn_area_c) - ItemGetWorldPosition(spawn_area_b)

enemy_pos = v0 + v1.Scale(k1) + v2.Scale(k2)

The good : the enemies look like a real armada, surrounding the player.
The bad : No AI at all, they can't even shoot at the player, thus reducing a lot the challenge. More variety in the type of enemies would have been cool too. I had in mind to make some giant crabs or squids ... or even the Kraken in the end.

Conclusion :

The good :

* The game looks quite good and is close enough to what I had in mind in the beginning.
* I implemented a lot of stuff as well, that I won't have to rewrite for the next game (menus, controller, audio manager, gui ...).
* it was fun to make it.

The bad :

* The challenge in this game is reduced to the max.
* no AI for the enemies
* the game objectif is quite unclear (reach the island, for what ?)
* no end level boss
* you can't even die