Return to “Dev Logs”

Post

Re: [Adam] Thursday, February 15, 2018

#46
FormalMoss wrote:
Sun Feb 18, 2018 2:33 am
...
I'll pick this apart in detail at some point, but I'm fairly solidly done with batch. It's been an unnecessary time sink every time I touch it for years. I say that knowing my way around it fairly well.

Just for a bit of perspective, consider the fact that it takes this much effort to do something that should be trivial, drags in systems that shouldn't be involved (file IO), and still isn't a robust solution (hard coded wait and hope that the other processes have finished running). There are so many red flags it might as well be a Chinese parade. It's simply not the best tool for the job.

Cornflakes_91 wrote:
Sun Feb 18, 2018 4:06 pm
<snip>

configurable dead zone, zero point, sensitivity and inversion options individually for any and all axes

thats how inputs are handled properly
(the only improvement would be adaptable input-output mapping curves)

the interface also provides direct graphical feedback as to how the output behaves with the current input state.
i can see how the sliders change the behaviour of the mapping function.

<snip>

runtime autodetect of removed/added input devices
Configurable dead zone and inversion are already in the high level API (the low level API is meant to be unprocessed, raw input).

Device connect/disconnect handling is already in the low level API.

Sensitivity will be handled by gameplay, not the input system. The input system always returns values from [-1, 1].

Zero point, custom curves, and graphical representation seem maybe unnecessary but I haven't done my HOTAS research yet. If any of them end up being necessary I'll make sure they're supported. Note however that you can currently set an exponent on input to tweak the curve a bit and that the UI will, of course, be easily moddable.

DoctorGester wrote:
Sun Feb 18, 2018 6:53 pm
Reading on your ramblings about shell scripts and exceptions, how excited you are about Jai on a scale from 1 to 10?
Probably an 8. I think it's a massive step in the right direction.

My ideal language would contain (at least):
  1. Keeps the simplicity and low level power of C
  2. Adds 'high level language' features in a way that doesn't annihilate performance
  3. Has robust meta-programming features
  4. Has a not-insane standard library
  5. Interops with C
  6. Doesn't require header files or forward declarations
  7. The 'build system' is written in the language itself and part of your code
  8. The compiler handles 'package management'
  9. The compiler is <100 MB and trivial to install
  10. defer
  11. Doesn't have/encourage exceptions
  12. Makes using other people's code easy (this is the motivation behind several of the other points)
  13. Statically typed
  14. Supports mixins
  15. Isn't garbage collected
Jai manages to hit just about everything there (not sure about 8, 9, and 10).

My biggest reservation is adoption. Even if I love it, will I be able to use it in a professional capacity?

FormalMoss wrote:
Mon Feb 19, 2018 6:12 am
What is Jai? I did a Google and it came back with Indian stuff?!
It's a programming language being developed by Jonathan Blow, the developer behind Braid and The Witness. He's an excellent programmer with ideals very close to my own. The language is intended to take the speed and power of C and bring it into the modern era, adding high level features without sacrificing speed and control. It also makes a point to remove 'friction' or unnecessary thought/work from actually writing code. He streams development on Twitch and archives the streams on Youtube. Development has been going on for about 2 years I think and the plan is to start releasing the compiler to larger and larger groups this year.

Cornflakes_91 wrote:
Sun Feb 18, 2018 7:08 pm
as its not available to the public theres not much to be excited about but promises :ghost:
I've been following development pretty closely. Jon streams development of the compiler as well as semi-regular demos where he shows off the capabilities of the language. That makes it a bit more than just promises to me.
Post

Re: [Adam] Thursday, February 15, 2018

#48
0111narwhalz wrote:
Mon Feb 19, 2018 1:11 pm
JaiPrimer wrote: good programmers tend to produce relatively few errors
I feel attacked :ghost:
I think thats a superstition. The same as "good programmers can type really fast" or "good programmers use a low level editor like vi "...

Look at that guy:
https://www.youtube.com/watch?v=ydyztGZnbNs
He types slow, uses an IDE and makes all kinds of small errors. Still he can be considered a good programmer.

A way more important thing here: he iterates a lot on the code, making (and testing) small incremental changes.
Post

Re: [Adam] Thursday, February 15, 2018

#49
Cornflakes_91 wrote:
Sun Feb 18, 2018 4:06 pm
and a shoutout to Frontier Pilot Simulator because it seems to be input handling week
Spoiler:      SHOW
Image
configurable dead zone, zero point, sensitivity and inversion options individually for any and all axes

thats how inputs are handled properly
(the only improvement would be adaptable input-output mapping curves)
This is highly relevant to my current interests. I was going to create a thread, but maybe this is the right place to say:

I hate console controllers for PC games.

HATE.

We're talking Hulk-like rage hate here.

This is occasioned by finally getting to spend a few hours with two new Kickstarted games: Kingdom Come: Deliverance and InnerSpace. I wound up having to take a break from both of them because I found them both extraordinarily difficult to control... and it sure looks to me like both of them were developed by people who used a controller as the primary input device.

KCD is remarkably clumsy with WASD+mouselook. Just walking around isn't too bad. But as soon as you have to interact with anything smaller than a person, it's like you're playing a "claw machine" minigame: good luck actually frobbing the thing. And I had to stop playing after a drunk guy destroyed me with nothing but his fists -- the interface for fighting slaps a weird immobile crosshair on the opponent; there's some kind of intricate "damage" UI widget that's too small to follow while having your ass handed to you; half the time I pressed the right or left mouse button, nothing happened; and the character I'm playing cannot be maneuvered fast enough out of his own way, much less that of the guy punching and kicking me at will.

This doesn't appear to be a skill-based ability degradation, like wonky weapon aiming at the very start of Deus Ex. Nor do I believe it's just me being "bad at games." It's just horrifically clunky and unresponsive input control, and it is very difficult not to think the movement and UI were not optimized for WASD+mouselook. It's worth noting that KCD was Kickstarted as a PC exclusive game, but halfway through development it was announced that it would become multiplatform. If the devs weren't already using controllers instead of proper PC input devices, they were from then on. I can't believe anyone who tested KCD with mouse & keyboard would have thought it was ready to deliver to the PC gamers who backed it.

As for InnerSpace, I remain a fan of the concept. And the interaction I've seen so far with the Archeologist is fun and informative. A lot of work has clearly gone into these parts of the overall experience.

But perhaps the single most important component of them all for a flying game -- the flying -- is unbelievably frustrating. As just one example, there is no mouselook. There is no mouse cursor, not even for selecting things in the options menu. The mouse is used only (by default) to press the left or right mouse button. Moving the mouse does nothing. Actually turning, and yawing, is accomplished by mashing keyboard keys.

I don't understand this decision... unless it's a one-to-one mapping from a controller interface.

So despite playing with a highly-capable mouse & keyboard -- still the standard input system for PC gaming -- I spent the first couple of areas in InnerSpace missing tiny rocks (in the tutorial) and smashing repeatedly into huge objects in the actual game, because the flight interface was incredibly more complicated than it needs to be for a gentle game of airborne exploration though a calm pastel landscape.

And I'll say it again in case anyone feels a need to get all chest-thumpy: no, I don't think it's entirely because I "suck at games"; I've played my share of flight sims from Microsoft Flight Simulator to Wing Commander to A-10 Tank Killer to Strike Commander to Freelancer to the Limit Theory Prototype, and I've never had this much difficulty making the craft go where I want it to. It's not fun; it's the single worst part of this game to be not-fun; and it darned sure looks like the clumsiness comes in part from prioritizing a stinking console controller during development and testing.

I will add one more note: I don't own a console, so I have close to zero experience using a controller. When I was at the previous PAX South demo for LT, and Josh offered me a controller to try the demo, I had to decline. It wouldn't have been fun for anyone as I fumbled around for ten minutes trying to figure out how to use a controller before even doing anything in the game itself.

So just speaking for myself, making LT feel good using a console controller does literally nothing whatsoever useful for me. I don't mind spending some time making it feel good for those who do prefer to play PC games with a controller. But it's worthless to me personally. (I also consider supporting controllers for PC games an abomination for -- by comparison with the large number of distinct inputs available from a keyboard+mouse -- either restricting the number of supported game action verbs, or implementing actions as modal combinations that are then unnecessarily copied one-for-one to keyboard+mouse. I despise what designing and implementing a game for a controller as the primary input device does to cripple the input possibilities for a PC game. But I understand this is a debatable opinion.)

Based on the smoothness and intuitiveness of the Limit Theory Prototype, I choose to believe that Limit Theory Actual will be equally responsive, where the perception is that -- within reason, given the inertia of big ships -- you have only to think it and your ship will do it. I also hope the gameplay verbs for this PC game will not be artificially limited because of controller input limitations ("I don't know what we'd map that to on my controller -- guess we can't implement it.")

Mostly, I hope somebody is or will be using keyboard+mouse, and not a console controller, as the primary development and testing interface for Limit Theory, so that it "feels right" for the PC gamers using the mouse+keyboard convention all the way from the very start.

I appreciate that others will have a different opinion on this. (I don't mind at all the recent thread on action mapping for a controller.) But if you feel like disagreeing, I hope you'll bear in mind that I'm not trying to tell you how to enjoy your gaming... and my preferences for fun are equally valid.
Post

Re: [Adam] Thursday, February 15, 2018

#50
Flatfingers wrote:
Mon Feb 19, 2018 3:11 pm
This is highly relevant to my current interests. I was going to create a thread, but maybe this is the right place to say:

I hate console controllers for PC games.

HATE.

We're talking Hulk-like rage hate here.

This is occasioned by finally getting to spend a few hours with two new Kickstarted games: Kingdom Come: Deliverance and InnerSpace. I wound up having to take a break from both of them because I found them both extraordinarily difficult to control... and it sure looks to me like both of them were developed by people who used a controller as the primary input device.

KCD is remarkably clumsy with WASD+mouselook. Just walking around isn't too bad. But as soon as you have to interact with anything smaller than a person, it's like you're playing a "claw machine" minigame: good luck actually frobbing the thing. And I had to stop playing after a drunk guy destroyed me with nothing but his fists -- the interface for fighting slaps a weird immobile crosshair on the opponent; there's some kind of intricate "damage" UI widget that's too small to follow while having your ass handed to you; half the time I pressed the right or left mouse button, nothing happened; and the character I'm playing cannot be maneuvered fast enough out of his own way, much less that of the guy punching and kicking me at will.

This doesn't appear to be a skill-based ability degradation, like wonky weapon aiming at the very start of Deus Ex. Nor do I believe it's just me being "bad at games." It's just horrifically clunky and unresponsive input control, and it is very difficult not to think the movement and UI were not optimized for WASD+mouselook. It's worth noting that KCD was Kickstarted as a PC exclusive game, but halfway through development it was announced that it would become multiplatform. If the devs weren't already using controllers instead of proper PC input devices, they were from then on. I can't believe anyone who tested KCD with mouse & keyboard would have thought it was ready to deliver to the PC gamers who backed it.

As for InnerSpace, I remain a fan of the concept. And the interaction I've seen so far with the Archeologist is fun and informative. A lot of work has clearly gone into these parts of the overall experience.

But perhaps the single most important component of them all for a flying game -- the flying -- is unbelievably frustrating. As just one example, there is no mouselook. There is no mouse cursor, not even for selecting things in the options menu. The mouse is used only (by default) to press the left or right mouse button. Moving the mouse does nothing. Actually turning, and yawing, is accomplished by mashing keyboard keys.

I don't understand this decision... unless it's a one-to-one mapping from a controller interface.

So despite playing with a highly-capable mouse & keyboard -- still the standard input system for PC gaming -- I spent the first couple of areas in InnerSpace missing tiny rocks (in the tutorial) and smashing repeatedly into huge objects in the actual game, because the flight interface was incredibly more complicated than it needs to be for a gentle game of airborne exploration though a calm pastel landscape.

And I'll say it again in case anyone feels a need to get all chest-thumpy: no, I don't think it's entirely because I "suck at games"; I've played my share of flight sims from Microsoft Flight Simulator to Wing Commander to A-10 Tank Killer to Strike Commander to Freelancer to the Limit Theory Prototype, and I've never had this much difficulty making the craft go where I want it to. It's not fun; it's the single worst part of this game to be not-fun; and it darned sure looks like the clumsiness comes in part from prioritizing a stinking console controller during development and testing.

I will add one more note: I don't own a console, so I have close to zero experience using a controller. When I was at the previous PAX South demo for LT, and Josh offered me a controller to try the demo, I had to decline. It wouldn't have been fun for anyone as I fumbled around for ten minutes trying to figure out how to use a controller before even doing anything in the game itself.

So just speaking for myself, making LT feel good using a console controller does literally nothing whatsoever useful for me. I don't mind spending some time making it feel good for those who do prefer to play PC games with a controller. But it's worthless to me personally. (I also consider supporting controllers for PC games an abomination for -- by comparison with the large number of distinct inputs available from a keyboard+mouse -- either restricting the number of supported game action verbs, or implementing actions as modal combinations that are then unnecessarily copied one-for-one to keyboard+mouse. I despise what designing and implementing a game for a controller as the primary input device does to cripple the input possibilities for a PC game. But I understand this is a debatable opinion.)

Based on the smoothness and intuitiveness of the Limit Theory Prototype, I choose to believe that Limit Theory Actual will be equally responsive, where the perception is that -- within reason, given the inertia of big ships -- you have only to think it and your ship will do it. I also hope the gameplay verbs for this PC game will not be artificially limited because of controller input limitations ("I don't know what we'd map that to on my controller -- guess we can't implement it.")

Mostly, I hope somebody is or will be using keyboard+mouse, and not a console controller, as the primary development and testing interface for Limit Theory, so that it "feels right" for the PC gamers using the mouse+keyboard convention all the way from the very start.

I appreciate that others will have a different opinion on this. (I don't mind at all the recent thread on action mapping for a controller.) But if you feel like disagreeing, I hope you'll bear in mind that I'm not trying to tell you how to enjoy your gaming... and my preferences for fun are equally valid.
You are aware that 80% of what you just said is merely developer choice/focus related?

Hopefully we can agree that having a controller for what is currently a space shooter is not the worst idea in the world (from a "pickup and try" pov)?

Unless you would like to debate how a full flight sim cockpit is the only way that the flight/combat part of LT can be played? :)
Post

Re: [Adam] Thursday, February 15, 2018

#51
AdamByrd wrote:
Thu Feb 15, 2018 7:15 pm
FormalMoss wrote:
Thu Feb 15, 2018 5:25 pm
Would you consider Powershell, Python or something else?
Something about Powershell rubs me the wrong way. Admittedly, I haven't used it heavily, but I at this point I don't want to rely on another OS specific feature anyway. Python is an option. Lua too, maybe. I also need an excuse to learn some Rust and Go (not sure if either are particularly good choices for tools, but it'd be fun to find out). As tired of it as I am, C# is solid for tools too.
PowerShell is cross-platform now ;)
Python is probably the better option if you're already familiar with it.
Post

Re: [Adam] Thursday, February 15, 2018

#53
BFett wrote:
Mon Feb 19, 2018 4:52 pm
Flatfingers wrote:
Mon Feb 19, 2018 3:11 pm
big rant
I'll be testing Limit Theory with Mouse and keyboard, and I actually expect most of the game to be played like that. I wouldn't mind using my controller for dog-fighting though.
Personally, I will be playing LT by touching neither controller or keyboard, except for the mouse, in 3rd person view, as I drool at the 3d vistas, and get carried away with the music.
Roll on 50" plasma tv :squirrel:
YAY PYTHON \o/

In Josh We Trust
-=326.3827=-
Post

Re: [Adam] Thursday, February 15, 2018

#57
Because several games just control better when you have one or two analog joysticks available. :roll:
That's the strength of having a pc - not the mouse and keyboard, but that you can plug into it whatever you want to use. Mouse and keyboard, controller, joystick, HOTAS, racing wheel, etc.
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image
Post

Re: [Adam] Thursday, February 15, 2018

#58
CSE wrote:
Tue Feb 20, 2018 2:55 am
Flatfingers wrote:
Mon Feb 19, 2018 3:11 pm
big rant
Mostly seconded :).

Who needs an alien controller (I personally never used and blane myself with when testing a game at a friend’s console) when every single computer today has mouse and keyboard available?
Thirrrdddeeedddd.... I played Freelancer, the control system for that was spiffy. If it ain't broke...... :twisted:
Image
Post

Re: [Adam] Thursday, February 15, 2018

#60
The ability to play with more input devices is only a positive thing imho, I'd love to see what could be done in LT with VR hand controllers
Image
Challenging your assumptions is good for your health, good for your business, and good for your future. Stay skeptical but never undervalue the importance of a new and unfamiliar perspective.
Imagination Fertilizer
Beauty may not save the world, but it's the only thing that can

Online Now

Users browsing this forum: No registered users and 16 guests

cron