itch.io

No cameras (yet), only IMU-based with neck simulation (although I doubt it is not enough since you are strapped inside the cockpit anyway). Planning a massive release soon (testing out the remaining bugs), so probably something will change (mostly focusing on custom map support and better visuals and gameplay atm)...

Sorry, guess I forgot to add the empty folder to the archive. Create "di_config" in the game's directory if it tells you it can't save the file. Also do forget not: "DI SAVE" saves the device profiles, stack-bound (e.g. the same joystick bound as device 0 and device 1 are two different profiles - so better initialize them with their most expected priority beforehand - say, connect pedals with "DI INIT 3" as you'll likely use them at the end of the stack, overwriting everything below), while "CONF.STORE" is needed to save the actual stack in your user prefs (so later you could combine various sticks without having to reconfigure them).

Project "Constraint" is not dead yet, although under a truly massive re-work. The goal of the overhaul was to add a level-switching capability to be able to enter some diverse environments, not only the tunnel one present at the initial demo release, preferably generated in a very simple way (the one I ended up with just needs two calls to load a model and spawn instances of it, while all the shading, collisions, texture loading, native format conversion etc is automated and happens behind the scenes, your models just get there without any additional work). The run-time level switching is not yet implemented, although the current build allows to play the two additional test maps as well as the old level. The controls were massively redone to process a set of up to 4 additional DirectInput devices connected at once for a neat control panel (along with classic keyboard+mouse and X-Box controller modes), and if looking for a stereo rendering mode you can use your PS VR headset (needs no additional software, even Steam VR is not used), or, if you learned this method, a conventional cross-eyed 3D is perfectly supported along with a special projector code to remove the artifacts of it (like image doubling, blurriness or broken perspective) on the larger screens.

Guess should be fine by now - the current build runs a stack of 4 devices (guess the biggest sane setup would be two sticks, pedals and... don't know, some switch pad, maybe? - can't think up anything else so 4 feels just right) added by "DI INIT #". The binding mechanism is mostly the same as before, all four are saved for the later starts using CONF.STORE. Yeah, yeah, overlap priority, dynamic disconnects and manual pause included :)

No idea :) Tho the controller stack feature is nearly done (in fact just need to re-implement the commands for the controller release etc, and test the thing for any surprises - guess tonight it will be), so will start doing the next map in a couple of days (yeah, yeah, promise to not get carried away by some other stuff like goggles support this time, although it is very tempting :) )

Well, seems like still a little bit of polishing for the DI support is needed (there's a little bug with the strafe binds not actually being bound, also roll left/right need the button assignment too in order to conform to the DualShock controllers' layout - and, as it is clear by now, a device stack is the perfect thing to have for it too - all are a pretty quick thing to code however) - and I will start adding some new environments (open mainly this time, I guess - would be interesting with the local infinite-space approach, got a few ideas and snippets already). I still want boss fights, yet guess they can wait a little bit more, as the environments and enemy types are more fun for the same effort.

Well, slowly getting it to run (hope to finish till this weekend) and got a few questions. At the moment I got the enumerator and the binder running, able to attach basically whatever is in the DI-standard joystick structure. The actual control, response curves etc are ready as well, and I'm mostly cleaning the stuff up. Unlike the XInput support from the current build, the DInput will not be multiplexed, but will be additive instead (as, opposed to how a gamepad can be used to control a real-life drone, and can be used as a complete control device here therefore, a flightstick may lack the ability to do several things unless in conjunction with a keyboard). And, FIY, yes - the selected device can be registered for future use, where it will start automatically (not really portable tho I guess, as stores the device's GUID) - the layouts are portable however, as are stored in separate tiny files named after each device.

Now, for the questions. So far I made it select a single device (for which it loads the control map as well, which you can edit in-game) and run like that, e.g. the keyboard is always available, mouse available whenever the axis pair meant for the yaw and pitch is not bound completely (for an obvious reason), and discrete, axial and POV controls, should they overlap, will be properly combined (yes, you will be able to bind a button as, say, strafe left, an axis for horizontal strafe and a POV switch to both strafe and ascend/descend all at the same time, and any combination of those will be correctly parsed). Should I leave it like that, or do I have to (won't really take that long I guess) make a control stack as well, allowing to assign and use a few DI devices at once (in this case you'd have to assign devices like #0...#something, where the layout of device #1 overrides the one of #0 in case of a direct overlap - say, if both are bound as "axis X", the one from #1 will be used, but binding one to strafe_x, and the other to strafe_left button is still combined - and so on)?

Also, about the deadzones. Should I rely on the DI ones, or have an own dead-zoning in software instead (atm I only tried the latter, just like with XI)?

I guess I should, although I need to get one first :) A little busy atm however, and first I badly want to do some tweaks to the particle system controller (almost finished in fact, will allow to fit things tighter by generating systems of a lower quality whenever the one requested does not fit into the buffer instead of skipping them altogether in this case - this is a neat touch for the lower-end GPUs where you would just limit the buffer without the need to set the effect quality that carefully).

Oh :) Although completely optional, the command system is a very immersive part of this one, mostly being like a configuration interface for your war machine. And yes, you can actually customize the heck out of it.

For Star Citizen, I actually never played it. Is the targeting feature there working like "you put the crosshair where you want to face, next the ship aligns with it (returning one to the center of the screen)"? I can try, by the way you can check the "MOUSEDELTA" on/off command which makes the mouse input become more FPS-style (still retaining some inertia because it would feel weird othrewize).

Thanks, tho I feel somewhat lost at the moment :) I initially planned on a somewhat straightforward Space Invaders clone with a few environments and bosses (and pre-defined waves), yet after adding the random waves it felt... more fresh? Guess they should stay as they fit that "evil AI" plot, also clearing some of them gets pretty tricky at times (took me quite a few restarts to deal with some of them: as you have noticed, they reset if failed to clear damage-less) - yet the whole concept becomes less clear this way.

With a fresh build thoroughly tested, and proved to be enjoyable (to me at least) I guess it is safe to call it "a build", not a demo anymore (especially as of how slowly the new features affect the actual gameplay).

The overall idea was to combine a classic flight-action scrolling arcade (although more of it's more modern "bullet-hell" type) with a convincing spacecraft simulator, along with the first-person view, configurable craft's subsystems, working onboard computer and so on. The physics are somewhat non-canonical, as the physical model is pretty accurate (especially when it comes to weapon behavior), yet allows for special moves like evasive dashes. Based on a custom engine, the game is really non-demanding of drive space, and boasts fast loading times, making one a nice choice for a quick dinner-break game. All the details are, of course, on the project's page:

https://lithium-ballistics.itch.io/project-constraint

A couple of videos I shot, depicting a run through the whole set of pre-defined, and a few randomly-generated enemy encounters, note how taking damage results in a wave being restarted:

Thanks, glad that glorious waste of time didn't turn out to be that much of a waste after all! Yeah, the gameplay is pretty much short at the moment, was too busy with the other stuff like improving the physics, maximizing the performance and, later, the PSVR support. Now, with those solved and finished the next step will be adding a new enemy type and a few new waves, later some more environment options will likely be added. However even now it still may be pretty fun and relaxing if added a "-hardcore" switch to the calling shortcut (or by the same-named option in Config), making to the last wave becomes pretty challenging this way. Another fun thing is to type "L OFF" in the in-game console (after all the lights start up), or "AUDIO ON" (for the latter I'll soon post the tweaking program as well, one syncs with your currently playing audio for some cute lighting effects).

No problem, also GD seems a little laggy today :)