Our development process so far… Part 3

When building a local-multiplayer game, customizable controls are a must. The game simply cannot exist without them.

 

Its like stepping on Legos

 

 

My first experience with custom controls was after the first couple months of the project. We only had hard-coded controls and it was really frustrating changing them during playtesting as we do have 4 different planes to test. So it was time to implement one. Less did I know that this item on the backlog took almost a year to finish! Well it’s not active development time, and we have had custom controls in the game with gamepad support the bigger part of the project. The first demo event we went, custom controls were implemented.. and that was in.. February? March (2017) probably.. But they didn’t work as I wanted them to and of course the worst thing was that I didn’t code it. Trying to code it about a year ago I really didn’t have the know how of the game engine and how things worked so this led me look for alternate options.

Improvise, Adapt, Overcome

As a side hobby, I just picked up Pico-8 fantasy console. If you are a dev reading this and don’t know what Pico-8 is, I strongly recommend to check it out! In short it’s really open platform for making really small “quick” projects/games. The best part is the open community where every game shared is open-source by design. So every game on the platform is a chance for learning something new. I mention this because our early custom controls code was thanks to GMS extension called input-dog. Adapting it to our code was an early savior for my BIG problem. After working with it and sometimes against it, I’ve learned a lot from it but as mentioned before it really didn’t work out the way I wanted it to work. Trying to modify the code to bend to my will was always a pain, as you never can get too familiar with someone elses work. So about a month ago I started again on the custom controls problem.

The problem I had with input-dog extension was that it left the inputs to be read as dynamic list and reserved lots of memory for this. Memory usage was no problem at all but this still bothered me to no end. It also made duplicates of its master objects on room_end event and so the memory usage doubled everytime room change happened. This may also be my faulty coding but the debugging process takes so long that I just rather be without it all together. Second thing was that it designated the input master objects for player1 player2…etc and I wanted to designate controls per player. So player1 has control1 – player2 / control 3 – player 3 / control 2… Look at the image under to get the idea. I dont know if this is the best way to choose control type for the player but it’s the style we use now. And as the code I have written is much more flexible, so if I want to change it at later point it does not need heavy modding to the code.

Much more compact skirmish page. Controls can be changed onClick.

 

There are no victories without defeat

As I’m writing this my next job is to finalize the gamepad code to show the input values in the settings screen, after that our new custom controls code is fully working again. It’s missing some thing that input-dog had like connecting gamepad mid-game and getting it to work with default inputs. We wont be supporting direct input controllers for now as x-input is the default one to work with windows and every gamepad can be virtually simulated to support x-input. If not supporting becomes an issue, then I’ll just add it later. Direct input definitely brings challenges with it as pad makers in the worst case have made inputs to be whatever was first suggestion in the editors automatic fill list. -_-

Currently, our selected menu font doesn’t support letters like å,ö,ä and some brackets etc… so Iiro will have his hands full to edit the font the get that support to show specialized letters. In the next game we’ll definitely pick a font that has all letters already built-in :P …Iiro did say in a side note “how hard it is to draw fonts” so maybe I need so show him that even a coder can do it! :D

Also there is this slight problem of lazyness that our menu wont work with keyboard nor gamepad inputs.. YET.. I know I know… “Any supported input device must be supported on the menu” … AND it suck to use the mouse when playing on TV screen and not be able to use pads.. It’s on the backlog I PROMISE! We also need some nice way to visualize the selected object when using other than mouse input.. Currently with the buttons we have the “selected wings”  but in the objects like the controls select above or the ribbons in the menu book or map select we have no good system for visualizations. So any ideas are welcome!

Words of ‘wisdom’

If you have any questions about customizable keys or about this post or gamemaker related or anything at all, hit us on twitter or comment here! :) I’ll try answering to the best of my knowledge!

Part 4 will probably be last part of the catch up series and is probably concentrated to the future of Triplane: Furball so stay tuned! Next week “Graphics design with Iiro” or something related :P

 

TSAKATSAKATSAKA!!

 

-Antti

 

Leave a Reply

Your email address will not be published.