Alpha InputCandy 0.9.8 releases its first "tech talk" video to discuss gamepad and controller realities

lost

Member
As the project gets closer and closer to 1.0.0 the lead developer, Capn' Poopiepants, wanted to share his findings and recent developments. You can find InputCandy major releases on YoyoGames Marketplace, or the bleeding edge on Github ---> https://github.com/LAGameStudio/InputCandy

Version 1.0.0 will be the first "complete" and "bug free" release. 0.9.8 is very close to but not quite there yet. Expect version 1.0.0 in the next few weeks, and with that version will come some new videos, tutorials and updated documentation.

InputCandy makes it easier to use input in GameMaker and does all of the "settings" and "selection" for you, so you can easily import these features into other projects. It was first written by LostAstronaut.com for use with their games.


Tech Talk:
GameMaker 2: InputCandy Library 0.9.8 Preview - First Look

InputCandy is for PC games and games for "Linux-based" consoles like the Atari VCS. It also specifically supports Atari VCS Modern and Classic controllers now available at GameStop. Premium, but very nice controllers.

InputCandy helps you provide players with a way to customize their input.

Using InputCandy

You can use InputCandy in pieces or as a whole.

It currently does not handle multitouch, screen reorientation, platform specific scenarios beyond gamepads.

InputCandy makes it easier to use input in GameMaker and does all of the "settings" and "selection" for you, so you can easily import these features into other projects. It was first written by LostAstronaut.com for use with their games.

It's important to note that this is for detecting momentary actions, not for detecting textual input ("typing"). It treats mice, keyboard and gamepad input as "button states"

InputCandy has two modes:
  • NES-style simple mode, which works on a variety of devices and requires no set up but has a limited number of inputs, and works with certain assumptions
To access Simple mode, see the script InputCandySimple included in the package. It's one function, so you don't have to import all the other stuff.
  • Advanced, verbose player-configured mode which allows for a lot of freedom but requires setup by the player
A Notes file contains Advanced mode information. You want to use this is if you want a wider support for the gamepad, and the ability to allow players to set their own control schemes.

What is InputCandy Advanced Good For?

InputCandy "Advanced" is split into several components:
  • InputCandy, the main ball of wax that handles the major features of designer-provided Actions, player-provided Settings, trackable Players (did they start yet? which controller are they using?), Devices (gamepads, keyboard, mouse), Signals (from devices) and a few other useful things.
  • ICUI, the InputCandy User Interface, a style-able complete UI solution for selecting, configuring and simulating game control apparatus
  • SDLDB, a library for reading, parsing and providing access to SDL GameController DB files (a recent one is included, or you may update it)
InputCandy comes with:
  • A simple version (with simple diagnostics) for quick use
  • A diagnostics screen that inspects game inputs
  • A single room with multiple panels that shows off ICUI
  • A test game
  • A "Gamepad Keyboard" similar to the old nintendo games for highscore entry
InputCandy is good for:
  • Multiplayer hot-seat games that use controllers
  • Console games
  • PC games with USB SDL-compatible PC game controllers and mouse/keyboard games
  • Simplifying your work with control schemas
  • Allowing players to rebind controls
  • Allowing players to take advantage of the SDL Game Controller DB
If you are going to use SDLDB, and you are testing with devices that don't map or have no DB entry, developers on the GameMaker Discord emphatically encourages you to submit a Pull Request to the SDL Gamecontroller Database at https://github.com/gabomdq/SDL_GameControllerDB

Note that use of the SDLDB is turned off by default as it may have undesired consequences and is not really necessary if the player is going to be permitted to remap input by use of device testing/capture or input selection.
 
Last edited by a moderator:

lost

Member
Updated the Github to 0.9.9 Release today. Would have updated Marketplace but it snagged on my upload...
 

kburkhart84

Firehammer Games
Hmmm, I have more competition with my input system. Competition is good. We have plenty of overlapping but you have a few things in yours that mine doesn't do. Maybe someone should make a table of features for comparison between the 3 - 4 input handling systems out there.
 

lost

Member
Maybe they should compare the price... InputCandy: Free. FireHammer: $5.

InputCandy is nearing version 1.0.0 -- this version should be a fully vetted version with as few bugs as possible. Versions after 1.0.0 will be maintenance releases or include non-core feature upgrades (like timed vibration effects, and advance stick/axis gesturing, and whatever else)

The JujuAdams "Input" Library has a different aim -- it purports to bring together disparate platforms like mobile, PC, tablets, TV. InputCandy is for your PC and Atari VCS games. Games that need players to configure them.
 

kburkhart84

Firehammer Games
Maybe they should compare the price... InputCandy: Free. FireHammer: $5.
100% I agree, price would of course have to be on the table of comparisons :) I also realize that this is gonna be the biggest reason why people don't purchase mine as compared to the free alternatives even before yours came out. But I personally think it is worth the price. Some others do, plenty of others don't :p

InputCandy is nearing version 1.0.0 -- this version should be a fully vetted version with as few bugs as possible. Versions after 1.0.0 will be maintenance releases or include non-core feature upgrades (like timed vibration effects, and advance stick/axis gesturing, and whatever else)
These are some of the features that I don't have yet in mine either. I'm interested in adding vibration, but I'm not sure if I care to add the gesturing thing. I'm also missing the usage of the SDL DB thing, though that is actually on my list for after I finish my audio system. Mine also has a thing where you can "fake" inputs, like having an AI drive the actions and then have the objects that use those actions not need different code to account for the AI. And I'm considering adding direct support for mobile, mostly virtual joysticks and the like, which would also tie in to the same actions that gamepads and keyboard keys do.

The JujuAdams "Input" Library has a different aim -- it purports to bring together disparate platforms like mobile, PC, tablets, TV. InputCandy is for your PC and Atari VCS games. Games that need players to configure them.
I think mine is more similar to yours than to Juju's ideas. Mine has the whole configurable input things as well and that is one of the bigger focus points I had(I HATED games that didn't let you configure controls with a passion). One thing mine does differently is that I don't assign gamepads/devices to players. Instead, I let them literally do whatever they want. That random player that wants to use keyboard keys combined with a gamepad's axis can do that as they please. My other pet peeve with input systems are limitations that shouldn't really be there.
 

lost

Member
These are some of the features that I don't have yet in mine either. I'm interested in adding vibration, but I'm not sure if I care to add the gesturing thing. I'm also missing the usage of the SDL DB thing, though that is actually on my list for after I finish my audio system. Mine also has a thing where you can "fake" inputs, like having an AI drive the actions and then have the objects that use those actions not need different code to account for the AI. And I'm considering adding direct support for mobile, mostly virtual joysticks and the like, which would also tie in to the same actions that gamepads and keyboard keys do.
I actually see no reason why you couldn't use SDLDB separately from the rest of InputCandy if you need it for your own games. I'm not too excited to see you sell it, though, since that wouldn't be fair without telling people you got it for free and linking the github. However, it is MIT licensed so you could technically sell it.

The truth is that the SDLDB part is not very useful. It can be tough to really use it effectively, and it has no real value if you are going to provide custom configuration anyway. I had a discussion with someone on the GameMaker Discord at length about this and that convinced me that, while it was good to provide the loading and deciphering functionality of InputCandy's SDLDB module, it made no sense to offer it and would only serve as a trap for players to misconfigure their controllers. If they really know what they are doing, they can locate the inputcandy ic.controller.settings.json file and insert their SDL remapping string there.

I think mine is more similar to yours than to Juju's ideas. Mine has the whole configurable input things as well and that is one of the bigger focus points I had(I HATED games that didn't let you configure controls with a passion). One thing mine does differently is that I don't assign gamepads/devices to players. Instead, I let them literally do whatever they want. That random player that wants to use keyboard keys combined with a gamepad's axis can do that as they please. My other pet peeve with input systems are limitations that shouldn't really be there.
I actually may own a copy of yours, or was going to buy it but decided to make my own -- not sure -- and then decided i should share my work and then.. InputCandy was born. I'm making a 4-player spritestack shmup sequel to Apolune 2 (thus it is called Apolune 3) and I wanted better controller support than in Apolune 2.
 

kburkhart84

Firehammer Games
I actually see no reason why you couldn't use SDLDB separately from the rest of InputCandy if you need it for your own games. I'm not too excited to see you sell it, though, since that wouldn't be fair without telling people you got it for free and linking the github. However, it is MIT licensed so you could technically sell it.
The only part that I'm worried about using is the GUID to Brand/Model part. I have a buddy who did some initial work on converting it to GML which is saving me a lot of time(I paid for the work but not near what I think its worth, their choice though). I'm simply tired of telling the users that it is "gamepad #1" and instead would like to have an actual name for it. But the value in my system has nothing to do with that, its more an added thing. You have a point though that I should mention where the initial work on the DB itself came from, we agree on that for sure.

The truth is that the SDLDB part is not very useful. It can be tough to really use it effectively, and it has no real value if you are going to provide custom configuration anyway. I had a discussion with someone on the GameMaker Discord at length about this and that convinced me that, while it was good to provide the loading and deciphering functionality of InputCandy's SDLDB module, it made no sense to offer it and would only serve as a trap for players to misconfigure their controllers. If they really know what they are doing, they can locate the inputcandy ic.controller.settings.json file and insert their SDL remapping string there.
Yup, as I mentioned, I'm just using it to map GUIDs to legible names. The description that GM's function for that is typically not very good. The thing with mapping is that sometimes even the GUIDs are the same for multiple similar but differently branded controllers, and frankly, I can't count on it. So I will still be using my own generic descriptions for axes and buttons instead of trying to use the mapping. It's the best way to ensure compatibility with anything that GMS's gamepad functions can pick up.

I actually may own a copy of yours, or was going to buy it but decided to make my own -- not sure -- and then decided i should share my work and then.. InputCandy was born. I'm making a 4-player spritestack shmup sequel to Apolune 2 (thus it is called Apolune 3) and I wanted better controller support than in Apolune 2.
Nothing wrong with making your own. The way I see things is that you always pay for what you need and want. You either pay with cash, you pay with alternatives(like swapping services or something), or you pay with the time to make your own. Nothing much is free and generally what is free isn't worth it by the time you check things out. Also, can you link me your game? I might buy it if it looks good. If you don't want to advertise it in this post you can PM me.
 

lost

Member
Also, can you link me your game? I might buy it if it looks good. If you don't want to advertise it in this post you can PM me.
Apolune 1 and 2 are on Steam linked via http://lostastronaut.com

Apolune 3 (will use InputCandy) is only in the very early stages of development, but here are some Gifs:

http://lostastronaut.com/apolune3/Apolune3-Lighting.gif
http://lostastronaut.com/apolune3/Apolune3-LightingSlime-reduced.gif
http://lostastronaut.com/apolune3/Apolune3-LittleGuy_xD.gif
 
Top