next »

[mobilelast]

Hello, and welcome to the devlog of Avaruustaistelupeli (ATP).

Avaruustaistelupeli is an arcade-simulation-space-combat-party game for one to four local players. Players are able to assemble ships from various types of modules and battle against others in a vacuum arena. See itch.io or IndieDB for more detailed description and free download.





I’ve been developing the game more or less actively for a couple of years now. Last summer I also started writing a technical blog about its graphics: mainly focusing on the 3D-modelling and texturing process with Blender, Substance and Unity. Couple of chapters are still unpublished. If you're interested, the blog texts can be found from the sites mentioned above. https://mobilelast.itch.io/avaruustaistelupeli/devlog/270671/making-graphics-for-atp-1-prelude or https://www.indiedb.com/games/avaruustaistelupeli/news/making-graphics-for-atp-1-prelude are good places to start.

Since those blogs take a long time to write, I thought about sharing news more frequently in a shorter form also. My main goal is to keep track of my own progress and hopefully gather ideas from others. I’m aiming to write a post per week or two.

Thank you for reading. See you.

[mobilelast]

There’s seldom anything interesting to tell right after the release. During the seven month gap between releases, lots of technical debt was accumulated. So let’s get them out of the way.

Firstly I updated to the latest versions of Unity (LTS), Photon and SmoothSync (yes, the game has poorly tested online multiplayer support for the future). I removed lots of obsolete features and performed massive refactoring that I wasn’t brave enough to do before the release. Luckily, after a week of testing, nothing seems to have broken. Reorganizing and prioritizing the TODO-list was surprisingly time consuming; many small changes and fixes were delayed while I concentrated on graphics.

Thanks to testers, some new issues have risen:

• There weren't any instructions that player introductions can be skipped if every player presses esc or start. Now there is.
  
  
• I added a countdown timer to warn about the stalemate.
  
  
• Game now works in windowed mode. GUI scales surprisingly well also.
  
  
• Bonus objects’ functionalities are poorly visualized and unclear. I’ll address this when redesigning the battle GUI.
• There have been issues with controller recognition at least on Linux. The reason remains somewhat unclear, but I managed to find a workaround. I’m rewriting the input system, so new workarounds may be needed after the next release.

I also made numerous preparations for the future improvements:

• Control handling is now encapsulated better, but some parts turned out to be tricky. For instance, Unity’s old input manager wasn’t able to handle multiple UI users at once, so some ugly hacks were needed in the ship selection screen.
• While fixing usability issues, I prepared GUI prefabs for future re-styling. In theory, most of the reskinning can now be done by just replacing the graphics in prefabs. Changes should be automatically applied to all widgets. Should…
• Arena models are now defined in scriptable objects. This makes it easier to add audience and other details to make backgrounds more lively.

While I was prototyping the new controls, Unity 2020.3.24 was released. It updates the input system to version 1.2.0 which adds some useful features: full support to key up/down polling, binding serialization etc. More about those in the next posts.

[mobilelast]

Rewriting the player input handling has been on my TODO list for ages. So now that everything seems to be finally working, it was a good time to throw the whole system out and start over.

Luminosity has served well, but Unity’s new input system will probably be the way to go in the future. It was recently updated to version 1.2.0 which brings lots of improvements to many crucial features such as input polling (which I prefer over callbacks).

Although mouse and keyboard are (and will be) the preferred input devices, I intend to make the game fully usable with gamepads also. So far controllers have had GUI issues with navigation maps, focus losses, controller disconnections etc.

Transition has gone better than I expected: after a week of work, most of the input functionalities are already working. Naturally, lots of small fixes, polishing and testing is still needed.

New features include:

• Virtual mouse that can be used with a gamepad. Clumsy way of using menus, but now the player can neglect all the physical activities and keyboard reaching between the battles. Virtual mouse works in a shipyard also.
• Controller disconnect and reconnect are properly handled.
• Test flight and tutorial modes detect the input device as they are used; no longer need to select them manually with F8.
• No more indexing bugs. The player should always control the proper gamepad.
• Keyboard shortcuts and other buttons are streamlined: player introduction can be skipped with any button, ctrl+shift+z works as redo etc. Lots of help texts are still to be updated.
• Gamepads rumble on module damage. And don’t worry, it can be disabled.

Yet to do:

• Control rebinding needs a proper UI.
• Help texts should be dynamically updated to use the current controllers and bindings.
• GUI widget navigation is disabled for now in favor of virtual mouse cursor. I try to bring it back piece by piece.
• Xbox-controllers work well in Windows, but issues are to be expected with different controller/OS -combinations. For instance, PS controllers haven’t even been tested yet.

Unity’s VirtualMouseInput has some problems: sometimes the mouse stops working, the cursor doesn’t stay in place when the gamepad and mouse are switched etc. In order to have more control, I made my own solution. It’s probably not the perfect solution and may conflict with system mouse (it doesn’t use a virtual mouse device as recommended).

In case someone is struggling with the same subject, below is the component I managed to make. It should at least serve as a good starting point.

Code:

using UnityEngine;
using UnityEngine.InputSystem;
using UnityEngine.InputSystem.Controls;
using UnityEngine.InputSystem.LowLevel;

namespace mobilelast.space {

    // TODO acceleration

    public class GamepadAsMouse : MonoBehaviour {

        public InputActionMap uiActions;

        /// <summary>How many seconds it takes to move the cursor from bottom to top regardless the resolution.</summary>
        public float cursorSpeed = 2f;
        public float scrollSpeed = 100f;

        private float SpeedRelativeToScreenHeight(bool pSprint) {
            return (Screen.height / cursorSpeed) * (pSprint ? 3f : 1f); 
        }

        private void HandleClickEvents(ButtonControl pButton, string pActionName) {
            if (uiActions[pActionName].WasPressedThisFrame()) {
                using (StateEvent.From(Mouse.current, out var eventPtr)) {
                    pButton.WriteValueIntoEvent(1f, eventPtr);
                    InputSystem.QueueEvent(eventPtr);
                }
            }

            if (uiActions[pActionName].WasReleasedThisFrame()) {
                using (StateEvent.From(Mouse.current, out var eventPtr)) {
                    pButton.WriteValueIntoEvent(0f, eventPtr);
                    InputSystem.QueueEvent(eventPtr);
                }
            }
        }

        private void OnEnable() {
            uiActions.Enable();
        }

        private void OnDisable() {
            uiActions.Disable();
        }

        private void Update() {
            bool sprintOn = uiActions["Sprint"].IsPressed();

            var virtualMouseDelta = uiActions["Position"].ReadValue<Vector2>();
            if (virtualMouseDelta.magnitude > 0f) {
                var prevPos = Mouse.current.position.ReadValue();
                var pos = prevPos + virtualMouseDelta * SpeedRelativeToScreenHeight(sprintOn) * Time.unscaledDeltaTime;
                Mouse.current.WarpCursorPosition(pos);
                InputState.Change(Mouse.current.position, pos);
            }

            var virtualMouseScrollwheel = uiActions["Scroll"].ReadValue<Vector2>();
            if (virtualMouseScrollwheel.magnitude > 0f) {
                using (StateEvent.From(Mouse.current, out var eventPtr)) {
                    Mouse.current.scroll.WriteValueIntoEvent(virtualMouseScrollwheel * scrollSpeed, eventPtr);
                    InputSystem.QueueEvent(eventPtr);
                }
            }

            HandleClickEvents(Mouse.current.leftButton, "LeftButton");
            HandleClickEvents(Mouse.current.rightButton, "RightButton");
            HandleClickEvents(Mouse.current.middleButton, "MiddleButton");
        }
    }
}

And here are the bindings I’m using:

[pi-shack]

I love that you're posting code and insights.

[mobilelast]

Thanks. Nice to hear that I’m not alone.

Not much insight this time. Instead, I let the first spectator in.



The model is just a quick humanoid I made in Blender. Rigging and animations are from Mixamo.

Crowd stands are much larger than I assumed when modelling them; even the smallest arena seats thousands of spectators. So obviously, for a full crowd, many levels of details must be applied from animated spectators to baked ones to billboards. Additionally, top-down view is ill-suited for billboarding, which takes some creative methods to solve.

It is going to be an interesting challenge to make the crowd varied and lively while maintaining proper FPS. So at least there will be something to write about in the near future.

[mobilelast]

So far Avaruustaistelupeli has only used statically oriented cameras: top-down view on battles and some undefined rotation on menu background. As seamless 360-degree skyboxes are somewhat tricky to do, I have only used three of the six planes: front, left and right. This has been fine so far, but in order to make player introductions and menu backgrounds more lively, I want the camera to be able to wander freely, not to be restricted by missing background. This requires a proper space skybox.

I first considered doing the skybox completely in shader, but as there are more important things to do right now (more about them in the future posts), I decided to search for a ready solution. I found a couple of wonderful toys, which I’d like to share. Both are completely free, open source and easily integrated to Unity, Unreal or other engines:

https://tools.wwwtyro.net/space-3d/index.html
Easy to use for fast testing. It doesn’t have many options, but works nicely for quick testing and as an idea bank. It is easy to use, but note that when importing to Unity, left and right planes must be switched.

http://alexcpeterson.com/spacescape/ (or https://sourceforge.net/projects/spacescape/ if the link doesn't work)
This one is more complete and more complicated. It has good coloring options and it uses layers similar to Photoshop/Gimp allowing complex composites. User interface is quite cumbersome for experimenting, so some prior knowledge about noise and blending algorithms will certainly help.

Below is a snapshot of the current state. At some point I may use a hybrid approach: pre-create multiple skyboxes and blend/animate them in shader. But that's later.

[mobilelast]

I am helplessly slow in making graphics.

These have been frustrating two weeks with very little time to spend and even less results. I’ve been mainly updating the arena graphics: improved UV usage and resolution in all surfaces, fixed the missing faces in the background grid and re-modelled stands so the crowd can feel more comfortable. I quickly generated 30000 statically batched capsules for dummy spectators without a noticeable FPS penalty, so that's good news at least. In the process, I also continued to write the next chapter of “Making graphics for ATP” (see the first post for the links). Hopefully I have time to finish it within the following weeks.

As usual, things didn’t go without problems. Very soon I started noticing some weird glimmering artifacts around the new arena boards. Although I knew the glitches appeared because of geometry problems in the model, it took forever to finally find them. Some vertices were too far apart to be properly merged, and they caused duplicate faces. Merging with a greater distance helped.

A little.

Immediately after that, occasional white pixels started flickering at the bottom of the boards. The problem was in the emission texture: emissive pixels bled into neighbor polygons on large mipmap levels (smaller textures). I'm not sure if there's a way to completely solve a situation like this. I ended up just creating a separate object for board emissions.

After several days of fighting, I’m happy that the arena starts to take shape. Lots of polishing is yet to be done, but the main issues should be solved. Here are some images of the new arena. Once the models are finished, I'll have to improve the lighting. Dimmer appearance looks better already.

[Beastboy]

Thanks. Nice to hear that I’m not alone.

Not much insight this time. Instead, I let the first spectator in.



The model is just a quick humanoid I made in Blender. Rigging and animations are from Mixamo.

Crowd stands are much larger than I assumed when modelling them; even the smallest arena seats thousands of spectators. So obviously, for a full crowd, many levels of details must be applied from animated spectators to baked ones to billboards. Additionally, top-down view is ill-suited for billboarding, which takes some creative methods to solve.

It is going to be an interesting challenge to make the crowd varied and lively while maintaining proper FPS. So at least there will be something to write about in the near future.

Just had a huge "Ender's game" deja vu after i seen the animation.

[mobilelast]

According to the clips I've seen, I know what you mean. And I just realized the prototype capsules look like Hattifatteners.

[mobilelast]

So far the cockpits have been empty, but not anymore. Let me introduce my test pilot, Lehtinen. Still pretty rough, but will hopefully age like a good wine.


As the very first thing, Lehtinen started complaining about the poor visibility from the cockpit. Admittedly, I haven’t given any thought about pilots’ point of view.


But obviously this is not going to be a first-person game, so I'm not listening to any complaints. Let me introduce another new feature: the ejection seat.

[mobilelast]

Mondays…

I went through hundreds of lines of code in order to solve an extremely weird bug, where Photon sent callbacks to already closed scenes and destroyed game objects. After two hours of debugging, I finally found the cause. Do you?

Code:

public override void OnDisable() {
    base.OnEnable();
    mainMenuButton.onClick.RemoveAllListeners();
}

[mobilelast]

Full gamepad support and control rebinding is now just about ready. There are still some occasional issues when switching between GUI and battle controller schemes and resuming from pause-menu. These may have something to do with coroutines and they are hard to reproduce. Hopefully nothing too serious. Settings page’s layout, texts and icons will be finalized later with the UI refactoring.



Rebinding gets complicated pretty fast. Most of the controls are just buttons, but there are also composite controls (active module switching) as well as 2D-vectors (thrusting and aiming). Additionally mouse aiming should not be rebindable, gamepad sticks should only be switchable, thrust-commands should not be allowed for mouse, a warning for duplicate bindings must be added etc.

I ended up making quite robust solution which was, in hindsight, pretty dumb. After all, there are only about a dozen different controls, so it would have been faster to implement them separately. But it works now! Mostly. At least on my computer…

Naturally there are language-specific challenges that us non-English speakers have to deal with. If the settings-window is opened from the main menu, the input system’s GetBindingDisplayString-function returns button names in English as it should (see left in the image below). But if I open settings from the pause menu instead, the language is switched to Finnish (on the right).



Looks like Unity’s new input system mixes OS language and keyboard layout. For instance, I’m using English as a language, but Finnish as a layout. Localized texts make sense in non-latin characters but seem odd in keys like "Tab" ("Sarkain") or "Shift" ("Vaihto"), since hardly anyone uses those names even in Finland. Luckily InputControlPath.ToHumanReadableString-function returns proper localization, so the problem isn’t critical. I’m probably just missing something.

Full gamepad support brought plenty of new special cases to handle, many more being still unnoticed:

• In standalone-battles, AI ships can only be selected by mouse. Gamepad support required a completely new browsing option, which still takes some serious UX-design and usability testing.
• Leave-buttons in the ship selection and tournament results screens can only be pressed with a mouse. Gamepad exit is now added to both.
• Just to be sure, a force quit -option is added for unpredicted cases.

After a long time, we’re having a multiplayer session next weekend. It’ll be interesting to see if the new system works at all.

[mobilelast]

We had a positive and productive test workshop last weekend. Recent improvements proved to be useful, and a couple of new ones were also suggested. Also positive was one participant’s covid-test in the following day. I myself haven’t noticed any symptoms so far, but these are indeed bad times for local party-gaming.

Because of the workshop, I refrained from making any major changes last week. Instead, I concentrated on balancing, adjusting and fixing small things so the session would go smoothly. And I’m quite happy, as only one issue was detected; I’m not sure if it even qualifies as a bug, but I managed to fix it during the workshop anyway.

I recorded lots of video material that takes some time to edit. I’ll write a separate post later this week.

[mobilelast]

A few words about the ATP testing workshop on 12.2.2022. If you’re not interested in the technical details, you can skip to the fun part (game videos) at the end of the post.

There were three participants, and our primary focus was on controls. The rule was to rely solely on gamepads. Using a keyboard was only allowed for typing names (I broke the rule a couple of times, but only by accident).

We immediately realized that the mouse cursor can be controlled by all gamepads simultaneously. So this is how we wasted the first minutes:


Messing around almost hid the fact that one of the controllers moved the cursor by itself. We spent a good while trying to calibrate the controller in Windows, but without success. Finally I fixed the problem by adding a deadzone processor to the stick control.


Probably a more preferred way would be to use the input system’s settings asset and enable “Filter noise on .current”. I’ll try that later.


Once we got going, the findings were positive:

• Apart from the calibration issue, both virtual mouse and game controls worked like a charm. Unity has since released InputSystem 1.3.0 and I’m afraid that it will break my clever hacks and tweaks, though.
• Tempo of the game has improved. Battle is not a complete hassle anymore, but there is time to prepare, select weapons and communicate.
• Improvements to crosshair and ship coloring have helped. No-one complained about losing their ship.
• Playing as a team against the AI gets funnier every time. I think I have to add some kind of official co-op mode to 0.5.1.

Of course, there is still room for improvements:

• Controller dead zones should be adjustable from the game settings. There are remarkable differences between gamepads.
• At some point, the game should probably support different control schemes for each player. Now every player must use the same bindings.
• Blue lock-indicator is hard to distinguish from the crosshair. It has to be brighter.
• Serious design flaw was found from the built-in “Cruyff”-ship. Hitting the certain reactor causes a chain reaction that first destroys the neighboring energy ball launcher, then cockpit and finally the whole ship. This caused confusion, as the chain reaction is hard to notice.

I picked two videos from the recorded material. The first one is a co-op battle against the hardest AI opponent. Ships and opponent level can be freely selected in order to have even matches, and these were the best we could find.




Another one is a complete tournament that better demonstrates the game flow. I only sped up the ship selection phases by cutting out the talking and beer-sipping pauses.

[Ramos]

After seeing the gameplay video I can immediately confirm that your game design concept got huge potential in regards to the addiction factor and fun element. I also think you can easily target FTL fans as a target audience.

And nice thunder dome vibe 


Good luck mobilelast, keep the update flow coming

[mobilelast]

Thank you very much.

Now that I’ve got things rolling, I'll definitely keep updating. I still have several hundreds of messages to post in order to reach your blog

[mobilelast]

Little more graphics.

So far the player widgets at the top of the screen have been only placeholders. Ugly ones in a wrong way. Also, poorly visualized bonus effects have caused confusion among the players. So time to do something about it.


Firstly, I removed the bonus status from the player widgets and gave it a place at the top of the screen. In order to emphasize info-texts, I repositioned player widgets to the corners. They are the first GUI components I modeled in Blender. I started by splitting a pointy-topped hex (game's symbol) into four parts, and moved each part into the opposite corner of the screen.


I continued by subdividing each piece into four parts by the golden ratio, and making frames out of edges with a wireframe-modifier. Top part (yellow) will contain the player's name, so I removed the vertical frame and extended the space a bit in order to fit in long names. The largest part (green) is reserved for miscellaneous info such as energy overflow warning, ship’s value and player’s color. For the smallest part (blue) I found no use, so it’s only a decorative grid for now (achieved by stacking wireframe and subdivision surface modifiers to a subdivided quad).


I mapped all corner pieces into the same texture space in order to avoid repeating patterns. In Substance, I textured the frame and grid with a similar rusty metal material as in the modules.


I rendered widgets in Substance, took a screenshot and copied it to Gimp. I then removed the background and composed images for Unity GUI. Originally I intended to fill the whole info area with the player color, but small colored lines on the edges worked better. Also, instead of bright, glowing materials, I ended up using rather low saturated colors in order to avoid distractions. The end result is subtle and suits the overall style. And the bonus status text is now more noticeable.


Texts still look pretty bland, but I’ll replace them when I find a good font.

[cabalistik]

Hyvältä näyttää! It definitely feels that there is something original in this game concept (I don't really remember any other games quite like this one) and like Ramos said earlier, I also see a lot of potential if you keep working and improving on it. The graphics do appear a bit "placeholder-y" at the moment, but looks like that'll change in the future. Do you plan to release the game commercially at some point?

[mobilelast]

Kiitos.

I actually try not to make any major plans. I'm working in the IT industry full-time, so I'm fortunate enough not to take any pressure on the project. I just try to make good use of the limited time I have: enjoy and learn new things. If I someday grow tired of my work or get interested in marketing, things can naturally change.

The graphics may indeed look incoherent, and there’s still lots to be done. I have no visual skills whatsoever, and I wanted to build some kind of understanding of how to make them. Ideas, criticism and other comments are welcome

[Rolando_TheMajestic]

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