next »

[mobilelast]

It is very satisfying to see how the yellow projectiles hit the ships.

Thanks.

It's been quite a challenge to make a good feedback mechanism for weapons. Battles can get quite chaotic and in order to improve clarity, I left out the music and used only subtle explosions instead of flashy and decorative ones. Currently things work quite well on some cases (cannons and missiles), but not so well on some others (energy ball, mines).

[mobilelast]

Two weeks have passed since the latest update, so here’s a quick situation review.

I’ve been doing lots of miscellaneous things such as module details -screen for shipyard, couple of new pre-built ships as well as frustrating Git-repository fixes. We organized a testing workshop last Friday, so in the previous week I fixed the last controller deficiencies (mostly) and added a completely new cooperative game mode.

Controller improvements include:

• All players and controller settings are now stored between games. This was a quite trivial addition, but there were of course some special cases with disconnected gamepads, different game modes etc.
• Since the virtual mouse may cause weird functionality with some gamepads, I added a setting where it can be disabled.
• Lots of instructions were added in order to make the GUI more usable. Gamepad controls are now represented as (placeholder) icons, which makes them clearer.

I will tell you more about the testing session and co-op mode in the next post. I have several hours of videos to watch through and edit, but I’ll try to write the post during this week.

[mobilelast]

I sometimes tend to forget that from its essence, Avaruustaistelupeli is a local multiplayer party game. As a reminder, we started having testing workshops more regularly. They help find issues that are hard to detect when playing/developing alone, and when properly organized, can also be one of the funniest moments of the development process.

But they are also surprisingly hard to prepare: list of design goals should be clear, all previous issues should be fixed and everything should be bug-free and stabilized. As drinking and coding don’t mix, I usually avoid modifying the game during the workshop. This means that preparations may easily take a day or two.

In the 11.3.2020 workshop there were four participants, a table full of pizza and a fridge filled with beer (workshops can get quite expensive). And of course, something new to play with.

The first version of cooperation mode is now added. Up to three human players can battle together against one AI ship. Currently the AI is far too selfish to cooperate with anyone, but I might add team-vs-team -game at some point. Below is a video of the very first cooperative game, and a collection of some other matches we played.





We also held the first four-player tournament where every player had a gamepad. Input system recognized all four controllers (two XBox-controllers and two Logitechs) without any problems. No calibration issues either. Nobody had difficulties to tell one’s own ship, crosshair or even lock icon anymore, so all the recent changes seem to be improvements.





I made three new ships to replace the old pre-built ones. Each of them has only three special modules, so they should be easier to handle. For the cooperative game, there’s also a stationary ship with immense firepower and strategic points that detach large parts when destroyed.

Naturally, some room for improvement was also found.

• Energy consumption and reactor overheating are still quite hard concepts for new players to grasp. I have no real solutions to this. Suggestions are welcome.
• Players often blew energy balls on their own ship without realizing what happened. Also, launching missiles too rapidly may cause them to collide with each other and cause damage to the launching ship. I try to figure out some kind of better visualization for these mishaps.
• AI struggles turning off the secondary modules (especially shields and beams). It also has something against bonus objects as it tends to shoot them before collecting.
• The tutorial relies too much on states, and the player can easily get stuck without a chance to finish it. Fixing this will take some planning.
• Some smaller issues: energy overflow warning should be turned off when the ship gets destroyed, bonus objects shouldn’t have negative effects on teammates, AI opponent should be clearly distinguished from humans in coop etc.

There are already more features added to 0.5.1 than I intended. The following weeks I'll probably concentrate on polishing and releasing the next version.

[mobilelast]

During the last week, I’ve been fixing the small bugs that were detected in the workshop. And as usual, found lots more in the process.

Unclear game events should now be clearer. For instance, a message is shown when a player's energy supply gets destroyed by overuse, and several tooltips and help texts are added to clarify usability issues. Mishaps with weapons (when the user gets destroyed by his/her own weapons) are still a problem, however. Because of the simulation nature of the game, everything affects everything. Therefore it is hard to reason the ultimate cause of an event programmatically.

I’ll be also redoing the tutorial to better highlight the general game concepts. A new menu page for common instructions will be added: seven short chapters about modules, energy, physics and other game mechanics, each containing a few sentences of text and some clarifying images. Tutorial flight mode will be integrated to this page for practicing.

[aperson4321]

Looks really cool!

Got a great mood to it! Has a very cool scifi 1990 video game feel to it

[Ramos]

Nice progress on your project mobilelast

I am curious, what kind of download rate/traffic did you have on itch? And why didn't you use the traffic from itch io and Gamejolt on a funnel for the Steam coming soon page? I mean won't all that traffic be wasted until you make a Steam page or do you plan on making it Itch.io exclusive?

[mobilelast]

Besides numerous small fixes and the typical pre-release cleaning, the last two weeks have been pretty text-driven. Nothing special to show, but at least something to tell.

In addition to common usability improvements, I drafted texts for the new “instructions”-page. Seven chapters, each concentrating on one concept: the game, ships, modules, energy, moving, shooting and secondary modules. A few sentences from each; images are still needed. I’ll have a test person visiting next weekend to tell if the instructions make any sense.

I’ve also been writing detailed descriptions about each module type. Texts don’t only describe modules’ purposes, but should also deepen the lore behind the game world. My goal is to give every graphical detail a purpose, and each module a history. The story doesn’t have a direct impact on gameplay, but it has already been a source of many balancing and modeling ideas. And it is a breath of fresh air compared with the technical stuff.

I browsed through the version history for 0.5.1 release notes, and it is always rewarding to see how much progress there has been. I may collect a list of them for this blog, so you don’t think I’ve been lazy.

[mobilelast]

Looks really cool!

Got a great mood to it! Has a very cool scifi 1990 video game feel to it

Thanks. I think the game might have issues deciding the decade it fits in.

Nice progress on your project mobilelast

I am curious, what kind of download rate/traffic did you have on itch? And why didn't you use the traffic from itch io and Gamejolt on a funnel for the Steam coming soon page? I mean won't all that traffic be wasted until you make a Steam page or do you plan on making it Itch.io exclusive?

Thank you, and don’t worry. There’s practically zero traffic to waste

To be honest, I haven’t really decided what to do with the game. I’m already working full time in the IT industry (not game-related), so I’m lucky enough not to have any financial pressures. Unfortunately my time is quite limited also.

For now, I’m planning to keep Avaruustaistelupeli strictly a hobby, concentrate on one thing at a time, avoid stress and learn new things by doing as much as possible myself. I’m not much of a community manager, and promoting the game takes a lot of time. But hopefully in the near future I'll have more time for such things.

[mobilelast]

We had a small test session last weekend, where our main goal was to validate the new tutorial-screens. Here’s a couple of pictures of what the current drafts look like.





But so it happened, that instead of reading, we ended up playing several co-op matches. And curiously enough, we encountered a couple of newish AI-glitches; I knew they existed, but I’ve never seen them occurring so frequently.

AI kept shooting detached modules, bonus objects and stalemate buoys although it shouldn't. While doing so, it forgot to battle, and usually lost the fight. I found out that in some special cases AI interpreted detached modules as incoming projectiles. It shouldn’t anymore. As a bonus, it seems that the fix improved AI’s energy ball handling, as it no longer gets distracted by false obstacles.

Occasionally AI’s shields were left on forever, which drained the ship's energy and caused it to blow up. Log files confirmed that some modules stayed on even though they weren't supposed to be used anymore. I still haven't found the ultimate cause, but I managed to tackle the problem by explicitly handling the problem.



Log entries also reported situations where missiles had traveled outside the arena boundaries. Such cases are handled already, but I’d really like to find the reason for them. There was a needless collider in a missile model, at least…

These were more patches than proper fixes. I will be refactoring the AI code for version 0.5.2., so expect many similar cases in the future.

[mobilelast]

It is about a year since I started replacing the initial placeholder models with real graphics. As I had no prior experience on graphical design, I decided to write some kind of blog series - half tutorial, half diary - about my successes and mistakes. Last year I published six parts of it, each with a different theme. The seventh took me a long time, but now I FINALLY got it done. This time I concentrated on modeling and texturing hard-surface models, and animating them interactively in Unity.

You can read the text from itch.io or IndieDB. As it is a continuation to the previous chapters, starting from the first part might help. Below are links to every chapter in both sites. Feedback is welcome.

itch.io: 1, 2, 3, 4, 5, 6, 7

IndieDB: 1, 2, 3, 4, 5, 6, 7

[mobilelast]

Busy and somewhat productive two weeks.

I added some variance to the modules and improved their balancing: different durabilities, energy consumption, damage to neighbors etc. I’m actually pretty happy how varied they are now; common sliders, percentages and numeric values aren’t enough anymore, but descriptive texts are needed instead. More unique names, background stories and other lore will be added to the future versions also. Below are a few examples of the module details view. (And yes, I will change the blue background at some point.)







The game has had a problem with many sudden destructions and other events that have left the player wondering what happened. After the changes, the game doesn’t punish the player so mercilessly, and it should be easier to follow.

• Reactors still damage their neighbors remarkably when exploding, but don’t necessarily destroy them anymore. This mostly prevents chain reactions where one blown up module may instantly destroy the whole ship.
• Energy balls now paralyze modules instead of destroying them. So no more surprise game overs from innocent experimenting.
• Some clarifying info messages are added to the battle. For instance, players are given information when the ship is damaged because of the energy overflow. This, however, may result in a LOT of text, so I have to be careful with it.

As a bonus: while balancing, I accidentally found a bug I’ve been trying to reproduce for a long time. When the currently used function was destroyed and the player immediately browsed to the previous function, code started throwing indexing exceptions which caused occasional FPS drops. That should be fixed now.

I also made lots of small fixes and tweaks for the upcoming 0.5.2 release (hopefully released in a couple of weeks), and built versions for Mac and Linux for further testing. I’m expecting the controls to cause problems on some devices and if so, I will try to fix them for the next release.

[TimeSlip]

Looks good - will there be a campaign where you can build up resources / parts?

[mobilelast]

Looks good - will there be a campaign where you can build up resources / parts?

Thanks.

I'm focusing on making ATP a fast, simple local multiplayer party game. Campaign/career mode would make a whole new game, so there won't be one.

All modules are available at all times, only arena sizes and energy utilization rate (big ships consume more energy) restrict the ship building. Ships can also be used freely in battles. At one point I considered a possibility to repair ships between the battles, but that broke the game flow and was hard to use in multiplayer mode.

[mobilelast]

Pre-battle ship selection has several special cases depending on the game mode. Human players always select their own ships, but AI selection varies. In the tournaments, AI pilots select ships for themselves. In standalone and co-op game modes, however, AI ships are selected by human players. This has caused confusion.

I created a new ship selection screen to (hopefully) address the problem. Screen space is now better utilized, and although the graphics are still placeholders, this should be a good base for future decorations. Most of all, instructions on when to select AI ships and how to do it with a gamepad should be clearer. Below are images of different ship selection modes.

The first one shows a standalone battle with two humans and two AI pilots. Humans have already done their selections, and the yellow player is currently selecting the ship for the green AI pilot.


In tournaments, AI players select their ships after humans have selected their own.


In cooperative mode, AI’s ship (red) is once again selected by humans. Green human player is currently selecting a ship for the AI. There are only three participants, so the last selection slot is empty.


There’s still a lot to improve, but as this is obviously a very important screen and it is easy to introduce critical bugs at this stage, I’ll leave the rest to the later versions.

[mobilelast]

Finally! I got the Avaruustaistelupeli 0.5.1 released! As always, it took longer than I expected.

Free downloads are available for Windows, Linux and OSX in itch.io and IndieDB, whichever you prefer. Feel free to try it out. I’d be more than thankful for any feedback.

I’ve had difficulties concentrating during the last few weeks, so I’m happy to reach this milestone and start the next cycle. There’s lots of interesting stuff to study for the future features: light baking, global illumination, audio handling, UX designing etc. In other words, lots of blunders and mishaps to learn from.

But for now, it looks like a beautiful summer weekend, so I’m going to celebrate this with a or two.

[mobilelast]

A fresh start for the 0.5.2 cycle; a good spot to reorganize TODO-lists and get everything up to date.

Unity update from 2020.3.24f1 to 2021.3.4f1 caused tons of changes to be committed. A few exceptions also, but nothing seems to be broken. Most of the changes were because of the new URP version (basically all materials).

The only problem I came across was that the virtual mouse’s press/release/drag doesn’t function anymore. Otherwise everything seems to be working on the new input system (1.3.0), which was quite a surprise. Maybe I’ll give Unity's built-in virtual mouse a new try in order to get rid of my own implementation.

There’s plenty of new stuff in Unity to examine and configure, so I will be spending some time just studying and experimenting. The static parts of the game need better (baked) lighting, at least. And of course, there's now support for URP decals for even more unnecessary cosmetics!

[mobilelast]

This heat wave is melting my brains, but I’ve managed to do something. There’s now lots less technical debt than a week ago, but also something new.

Me and a few others have hoped to see some deeper statistics after the tournament, so I implemented a general stats collector for later refinement. I quickly modified the tournament ending screen to summarize the collected info.



Recording played time and traveled distance was an easy start. Fired shots and received hits were also trivial to count, but then things got more complicated. For instance, when calculating hit accuracy, it is hard to determine whether the cannon projectile has successfully hit something or not. Hitting another ship is a non-brainer, but does stopping incoming missiles or mines count? Does hit to enemy shield count? Does cleaning meteors or detached modules out of the way count? Lots of things to think about there.

There’s still plenty of room for the other statistics. Perhaps something about the usage of special functions, more about the used ships and their condition per round etc. If anyone has suggestions, I’d like to hear about them.

I also came across some controller-based weirdnesses that are too brain-consuming in this weather. I’ll get back to them later.

[mobilelast]

Last two weeks I’ve been mostly fixing bugs and making improvements to AI; a slow job and particularly difficult to debug and test. As I’ve probably mentioned before, my final goal is to implement a set of clearly distinct AI opponents with individual skills and combat styles.

As a starting point, I usually try to implement as perfect AI as possible. In this case it requires a complex observation system, hit detection and prediction of accelerating projectiles. In other words, lots of trigonometry and somewhat higher math. Not one of my strengths. Downgrading the AI is easier: just apply random inaccuracy to shooting and other activities. Previously the inaccuracy was just a random offset to the aim position, amount of randomness depending on target distance and AI skill. This worked with projectiles, but it made beams (cutter, tractor and pressor) jumping around recklessly. Therefore even poor AI has so far aimed beams perfectly.

In order to fix this and achieve smoothness, I switched the common random to perlin-noise. The following Unity code generates a gradual movement inside a circle as shown in the image below it. Statistically the distribution isn’t quite even, but close enough.

Code:

public static Vector2 PerlinInsideCircle(Vector2 pCenter, float pRadius, float pTime) {
    float x = Mathf.PerlinNoise(pTime, 0f) * 2f - 1f;
    float y = Mathf.PerlinNoise(0f, pTime) * 2f - 1f;
    var offset = Vector2.ClampMagnitude(new Vector2(x, y), 1f) * pRadius;
    return pCenter + offset;
}

Adding this to the perfect aim makes the crosshair movement smooth, and it can be used with any AI level. Below are examples of an accurate AI (yellow) and a very inaccurate one (red).


In order to make the AI opponents more diverse, I’ve parameterized pretty much every aspect of the behavior. These give me tons of possibilities to determine the skills and style of the opponent, but I am yet to pick the most significant ones and balance them properly.


I also improved the component that observes the battlefield. For instance, the AI now uses the close and ranged combat power of its enemies to decide its actions. No longer should AIs do stupidities such as close combat with missiles against laser cutters and cannons. But as I mentioned earlier, it is a slow job and particularly difficult to debug and test. So they probably will.

[oldblood]

Glad to see you're spending time trying and perfect the AI. I've struggled with other multi-player-only indie games I've supported in the past as they're (of course) contingent on other players to even play or enjoy the game. Great stuff!

[mobilelast]

Glad to see you're spending time trying and perfect the AI. I've struggled with other multi-player-only indie games I've supported in the past as they're (of course) contingent on other players to even play or enjoy the game. Great stuff!

Thank you.

Originally I made the AI mainly for development purposes, but I started prioritizing it more after introducing the co-op mode. I have a tester that keeps finding AI exploits all the time, so the overall code is getting quite filled with tweaks and fixes. It seems like an infinite task that will never be perfect.