next »

[marcgfx]

I find it quite hard to understand what is going on in the matches. Ships look very floaty and hard to control, so it really just looks like a battle of attrition to the untrained (my) eye. I think it would be good to make it visually more obvious what the different parts of a ship are + maybe add a color-outline to identify the different players. Or maybe color the components in a player color?

Currently its gray modules vs gray modules and every part looks the same. So in the end its just outline of a flat ship vs another weird flat ship.

It might help to make some modules larger, like hexagonal tetris blocks. This could help make ships visually more distinct too. if modules were not all the same height, ships would not be as flat as they are now. The current ship style would work better in 2D, in 3D they look very weird to me.

It looks impressive from a technical side,

[mobilelast]

Thank you very much for the constructive and thorough feedback!

I find it quite hard to understand what is going on in the matches. Ships look very floaty and hard to control, so it really just looks like a battle of attrition to the untrained (my) eye.

It kind of is. Especially in tournaments, it is sometimes wise to sacrifice one's own ship in order to take down as many opponent modules as possible. But it depends. Flying in a vacuum takes some practice, but it isn’t such a hassle as it used to be (until you start losing thrusters). Nowadays the most experienced players seem to win constantly, which is a good indicator of improvement. There’s also arcade-mode that adds drag and makes flying easier, but also takes away lots of the humorous elements. Version by version, the more careful tactics seem to be more successful ones. I could use better editing in videos to bring up more interesting stuff, though.

I think it would be good to make it visually more obvious what the different parts of a ship are + maybe add a color-outline to identify the different players. Or maybe color the components in a player color?

Currently its gray modules vs gray modules and every part looks the same. So in the end its just outline of a flat ship vs another weird flat ship.

Each module is indeed colored with the player's color. Players had difficulties telling their ship in the previous versions, so I added a setting to increase the color intensity, and now they are well visible at least on my monitors. I try to be subtle with emissions, but perhaps I should ramp the colors up for the videos. Here's how they look at full emission:

It might help to make some modules larger, like hexagonal tetris blocks. This could help make ships visually more distinct too. if modules were not all the same height, ships would not be as flat as they are now. The current ship style would work better in 2D, in 3D they look very weird to me.

Tetris-suggestion is an interesting one, but it would require major changes to the game logic, so it probably won’t be done. In practice, there’s no time to aim at any particular module, so telling types from another isn’t that important anyway. The only module that should be distinguished is the brightly lit cockpit (once you lose that, you lose the ship). Same thing with the graphics, although with my skills, 2D probably wouldn’t look any better (now everything’s at least consistently ugly).

But these were very valuable first impressions. I’ll keep them in mind for this and the future projects.

[marcgfx]

The coloring is good enough, I agree. Main problem for me is that it all looks like cirlces. Maybe add different shapes, e.g. triangles/squares/stars/crosses, or have the outline colored in some, the center in others. Some modules could just be black, others gray/white. I can see that there are different modules, but nothing looks distinct. I think I know where the pilot capsule might be, but even that is really hard to tell!

Is there no strategic importance to where you place the modules or what you target? Trying to get into the best position to take on an enemy sounds like basic strategy to me, but I guess with the floaty controls that might be difficult? Maybe teleport behind enemies (at a cost) to get into an advantageous position ... maybe you could have weapons that change the environment, e.g. floating shields/bombs that can be pushed by both opponents.

I used to play a game called roboforge, where you could build your own robots. The most fun I had was thinking of novel/crazy ideas and building really weird stuff.

I'm not sure how the tetris-block idea would be in conflict with your current mechanics. You could simply join 3 modules together and if one is destroyed the whole block no longer works.

But it sounds like you have some playtesters, most likely you will be getting much better feedback from them. I just think it looks like a game I could like, but watching the matches makes me think differently.

[mobilelast]

You’re actually the first one to mention about the modules. Especially during the local multiplayer battles (the main feature) ships get very small, so I don’t think making modules distinguishable would affect the gameplay. It’s enough to tell the owner of the ship, and roughly the number of modules still left.

The thing I agree with (and which might be the main cause of your critique) is that the game suffers from a lack of cunning ways to win. There are occasional surprises, but often it’s just shooting until the opponent runs out of modules. More interesting arena layouts could help. For instance, generating meteors with Perlin etc. instead of placing them randomly would make ribbon-like patterns for kinds of roads and protective walls. Battles only take a minute or so, so this is definitely not a strategy game. But that could bring the tactical level almost on par with Pacman.

There’s one feature that is missing from the videos: the shipyard where custom ships can be built. This is one of the things I’m planning to concentrate more on in the near future, and one I should probably make a video about.



You can create and modify ships from quite a few module types: mines, tractor/pressor beams, shields, brakes (to help flying) etc. A warp engine is also implemented, but it needs some refining (with meteors and detached modules flying around, there’s often no room to teleport the big ships). Partly due to this, I’ve made the graphics consistent by recycling module parts. This makes it easier to add more modules in the future. Might look pretty dull, though.

Bigger modules would require changes to the shipyard, module connection calculations (handling detached modules) and probably many other places. So that’s out of scope at least for now. I’m finalizing the next release version, so I won’t be implementing new features very soon.

But thanks. Although I disagree on some areas, it’s interesting to hear new ideas completely out of the box.

[mobilelast]

Crosshairs are pretty much the most important source of information in ATP. They have changed a lot during the development, as can be seen from the history video I posted earlier. They must meet two, often conflicting requirements: be clearly visible, but not get in the way. Earlier version (seen below) didn’t quite succeed with the latter one.


I had already reduced the crosshair opacity. To take things further, I got rid of the useless outer circle, which (I think) had some kind of purpose that I’ve since forgotten. Additionally, closed aiming triangles and rectangles were simplified, and two lines to indicate simultaneous shooting is enough instead of previously used three.


The circular energy bar opacity now increases with the energy consumption. In order to keep players aware of the usage, the circle starts blinking when the consumption exceeds 66%.


Adding the bloom effect was easy, as crosshairs are world-space UI-components. Nowadays additive GUI shaders can be made by creating a “Sprite Unlit Shader Graph” asset, and setting blending mode to “Additive”; I should probably replace my custom additive GUI-shader with this. It seems that the overlay camera’s bloom is also applied to the base camera, so game view and crosshairs must share the same post-processing effects. I may be missing something, but I didn’t find any way to change this via layers or anything.


This is how the new crosshair looks in use.


Beside this, I renamed and re-balanced some modules. As it often happens in simulations, every fixed feature seems to break two others. So (once again) it took longer than I expected.

[mobilelast]

About those unpredicted simulation issues I mentioned earlier…

Many unexpected things can (and will) happen in physics simulations, many of them because of the mathematical inaccuracies. So far ATP has mostly used discrete collision detection, which is performant, but sometimes unable to handle small objects with great velocities. In the animation below, for instance, a pressor beam gives the missile a double push, causing it to speed through a module.



Limiting the velocity probably helps somewhat, but similar may happen also on CPU hiccups. For a more complete solution, three collision calculation modes are introduced:

• Fast. Always uses the discrete model. This is similar to the one used so far.
• Accurate. Always uses continuous calculations. The most accurate one, but may increase the CPU load on action-packed situations.
• Analytic. Default setting that tracks the projectile velocity and adjusts the mode accordingly. If everything works, this should have the benefits of the other two.

Settings page is quite badly organized. I should probably re-group all the performance-related stuff, both graphical and physical. But as I have the version 0.5.2 pretty much wrapped up (and tested also on Linux), that’s a job for 0.5.3.