May came and went quicker than a Deinonychus can catch a squirrel! A lot of things are happening with Dinolords that we are super excited to talk about, and a couple of the things in progress are what we are going to have a look at today. [img]{STEAM_CLAN_IMAGE}/44682436/51e30125860498e996e471345fb7245f778d4672.gif[/img] [h2]Connection in progress[/h2] One of the big things we have been talking a lot about internally is multiplayer - we read all the comments and we definitely agree. Playing an awesome game is fun, but sharing that experience with friends is even better! Some of you picked up on it in the trailer where there suddenly was a lord with a different coloured cape and we have been working hard to make the underlying systems work for networked play. All those technical things are coming along nicely and our latest playtests have been hectic, fun and chaotic, trying our best to find bugs and make sure it’s all working as intended. But all the underlying code is only as good as the gameplay, and that part is still in flux. We are looking at co-operative PvE play and PvP for online play and are currently experimenting with how coop play will work; there is a big difference between playing multiple people in one castle or each player having their own, both in the fantasy of playing together, but also in the mechanics - how does sharing resources make sense and how does coordination work in both base building and in combat etc. We discovered the necessity for clearly showing all players what is under construction to avoid multiple players placing down construction sites for the same type of building. This of course was not really a problem in solo play, as it was easy to keep track of what buildings you place. Similarly, it was difficult to know what units are currently being controlled by another player, to avoid a tug of war with conflicting commands to the units. Those are small humps to iron out though, and overall multiplayer is shaping up to be a bunch of fun! [h2]Taking control[/h2] Dinolords is a hybrid genre game taking cues from RTS and ARPG. Both of these genres traditionally rely heavily on mouse input. This has been a long standing challenge we knew we had to find a good solution for, and we have tried various solutions but things are taking shape in a way where we feel like the level of friction between the player and the controls have gone down and the fun and intuitiveness have gone up! But before we talk about the current state, let's have a look at the challenges and what the previous solutions have been trying to do. In RTS games, you typically do a lot of building management, production and construction with the mouse - clicking on buildings, placing construction sites, ordering units for production and so on. You also do a lot of unit control with the mouse - selecting units both via clicking and box dragging, issuing unit commands like move and attack with right click. So there is a [b]lot[/b] of clicking going on in a strategy game! In ARPGs there is also a lot of clicking: you often move with right click, attack with left click, interact by clicking, drag inventory and equipment around, pick up items with left click and so on. By now the issue is becoming clear: we want to do all of the things but we are limited by only one hand and one mouse with two primary buttons. So imagine a scenario where you stand next to a tree, an enemy, a friendly unit and on the ground is a resource pickup. What would happen if you click in the vicinity of all of those? Do you attack the enemy? Do you chop the tree? Do you select the friendly unit? Do you pick up the resource? Do you move? [img]{STEAM_CLAN_IMAGE}/44682436/fcd35b4f03862dd55282edaf41491305faf10a81.png[/img] [h3]The ‘[i]smart[/i]’ solution[/h3] At first we tried to solve this by trying to predict and weigh the importance of actions, effectively making a hierarchy of interactions and what priority they all had so that when you clicked it would do the most important task of the available options. This worked okay in many cases, but felt super restrictive in situations where the player intentions did not align with the hierarchy. Say if you actually wanted to select the friendly unit and not attack the enemy, or you wanted to pick up the thing on the ground and not chop a tree or vice versa. Next up we experimented with putting certain interactions behind modifiers, for example holding a modifier down to box select or to otherwise “circumvent” the auto priority input system. This went some way to solving the issue, but it left us feeling like we were fighting the input system more than we were fighting the enemies while playing. From the beginning people have mentioned a mode switch, toggling between building and commanding units and fighting. Figuratively and literally a sort of “unsheathe/sheathe” your weapons. This always felt a little like a copout from making an actual hybrid of the genre by piling down a wedge between them, making you switch between playing an RTS and an ARPG, and was something we wanted to avoid but we kept it in the back of our minds as a last resort solution. [h3]Present day[/h3] After some more experimentation it is starting to appear that we have found a solution that has less friction than the hierarchy, and does not further fragment the genres. It is also strangely familiar to interact with, and makes fighting and commanding units at the same time feel a lot more intuitive but still with a curve that enables skills to develop for more optimal play. We already had the lord movement on WASD, abilities on number-row, but by moving some of the combat and interaction buttons over to the keyboard we freed up the mouse to be more traditionally RTS, while keeping the ARPG feeling juicy and engaging. Being able to pick up resources, interact with trees or ore and deliver them to a stockpile from the press of a keyboard button, and attack in a similar fashion, makes doing these tasks while commanding units to attack a big dino a frictionless experience and we can’t wait to show you what we came up with in more detail. [h3]Unit Commands[/h3] Commanding units is now free to work how one would expect: select or box select, unit groups, double click a unit to select similar unit types, shift click or box to add to selection, deselect all by clicking the ground, deselect individual by right clicking their portrait in the selection group etc. Leaning on tradition is helpful in lowering the learning curve to play, but we have also been exploring an additional way to interact with units in a slightly simplified way. This is a little sneak peak with lots of temporary visual gizmos so these are by no means a representation of the final implementation, but we are pretty excited to show a little. [img]{STEAM_CLAN_IMAGE}/44682436/6a9b755145c95c6daa695f5ececf1c142775b079.gif[/img] ‘[i]Paint[/i]’ selection of units allows the player to quickly paint over units and select all within the circle, while box select still works, this allows you to pick units in different shapes or diagonally in one swift motion. [img]{STEAM_CLAN_IMAGE}/44682436/b9c3a55d3249f4d37a8c7e3a16db5a157568a121.gif[/img] Seeing your units group hug a big dangerous dinosaur and suddenly get crushed is a fun sight to behold, but also detrimental to succeeding on the battlefield. If you select and issue a move command, the units opposite the direction of the move will have to run all the way around the dangerous unit. The new ‘[i]scatter[/i]’ command makes your units run away from where the command is issued! No more being squished under the feet of a Brachiosaurus! [h2]You, me, them, everybody, everybody![/h2] We are still absolutely humbled by how many future Dinolords have wishlisted our game and words can not express how grateful we are. [b]Thank you[/b], to each and every one of you, who are coming along for this journey with us. And thank you for checking out this edition of Dinolords Monthly! Catch you in the next one.