It is! And what the production designers put on screens is part of what communicates with the audience. Maybe the audience needs to get specific information from the UI in order to understand something in the story. Maybe the audience needs to understand that the talent is having a certain kind of interaction that gives them a particular kind of information, or allows them to control something. In all those cases, the UI is part of how the creative team tells the viewer what's going on in the world of the film!
Yeah the functionality is definitely important from story telling perspective, my point there is the style of the UI is also part of the world building, e.g. the screens from Star Wars should look different from the screens from Blade Runner cuz they're different worlds and different culture, people should have different means to access information from devices. Making everything typical sci-fi style hologram looking UI works but it's a place that can add some nice touch (or can use non screen interfaces if it makes sense in the world)
You end up needing more complex optics to focus the image comfortably onto your retina at a distance that feels comfortable. An OLED display on a glasses lens with no other optics would just look like a bright blur between you and the rest of the world.
I agree that 6.5ft^2 is probably too small for a good RDW experience based on the gain numbers I'm familiar with. The tracked volumes of the experiments I was a part of were all on the scale of ~15-20 ft square. (I'm not a researcher, really, but I was a developer at a lab that did some RDW research -- for instance, https://dl.acm.org/doi/abs/10.1145/2931002.2931018). There are some tricks that the literature suggests could help (forcing the user to turn >360 degrees in place, exploiting change blindness to get people to accept non-euclidean spaces, etc) but I believe it's not controversial to assert that the user is going to realize they're not walking straight if someone tries to get them to walk a circle with radius ~3ft with traditional RDW cues!
I'm the lead dev on Walking Dream: No doubt the player will "notice" they are being redirected in a small space, the question is if it's bad enough to induce nausea. Our goal is to be able to tell the player "you can just walk wherever you want in the game, but you'll notice some weird rotational shifting, however you won't get nausea". It's a lower bar that can still lead to fun gameplay.
You might want to look at Wolfpack, mentioned elsewhere in this thread. It requires multiplayer, 2-5 players control a German u-boat against Allied convoys in the Atlantic). It's an interesting combination of sim-lite (engines, battery and buoyancy are modeled relatively simplistically) and deep nerd simulation (fire control/torpedo solution) aspects.
I'm not sure how TIE Fighter's mechanics would translate to modern sensibilities, and I say this as someone who loved the LucasArts games (at least part of the reason I'm a graphics programmer today!) and currently has, well, a not-insubstantial investment in flight simulation hardware for modern titles like DCS/Falcon BMS/various IL-2 things.
House of the Dying Sun (https://store.steampowered.com/app/283160/House_of_the_Dying...) might be the closest thing going I'm aware of on the current market, as an arcade space fighter game in VR. Doesn't have the same theming, but it's at least space fighters doing space fighter things in space!
For me, the question of how you'd do a modern TIE Fighter remake becomes "how do you make assumptions about how space combat works in your game-universe that line up with the Star Wars films, and also lead to fun gameplay?" Since the space combat from Star Wars (at least ANH) was basically "Dambusters, in space!" you can draw lots of inspiration from World War 2-era aviation and combat. However, given an environment where gravity doesn't play and everything has ridiculous thrust-to-mass ratios, you lose some of the interesting bits re: altitude/energy trades and everything just turns into a "Pull as hard as you can" circle fight in the within-visual-range (WVR) / basic fighter maneuvers (BFM) space, which is where most of the iconic Star Wars dogfights-in-space happen. Beyond Visual Range (BVR) combat isn't really a thing in Star Wars, because Rule of Cool indicates that dogfights are cooler than slinging missiles at each other based on sensors. In the films, the writers/VFX people created the scenes they wanted by creative fiat -- in a game you need the mechanics to drive to the experience you want, and that's a challenge given Star Wars' apparent assumptions about how space combat works.
Of course there's all sorts of interesting assumptions you could make instead, but then you're just making a space arcade-sim game, not a Star Wars game.
Nope, I've clearly never thought about this. At all. Clearly.
Thanks for bringing some of those non-existant thoughts to the surface!
I used to imagine how to improve game play in the X-wing series, but not really outside the existing mechanics (just tweaking max speed, weapons load, or shielding). I have such fond memories. I started out in web programming largely to the web community around the game.
The Mighty Eighth reminds me of a take on Star Wars space combat game play that I wished was explored more, like the gunner role in a Y-wing, or what it's like to be the crew a Corellian Corvette taking on other similarly sized ships.
Having different energy retention and ‘flight envelope’ would at least let you make distinguishable ships to fly around. Couple that with the ship power management, stuff like shielding and so on could end up plenty complicated. X-Wing vs. TIE Fighter and Allegiance are two games that did movie space combat really well. I’d love a more detailed model in a version of either of those games.
Allegiance! Now there's a name I haven't read in a long time. tried to get into that community around the time the first Free Allegiance release happened, but I didn't end up with the right combination of personality and time to get really involved, and even though I think the gameplay might be more my jam today, I think the community has largely dried up, and I don't have nearly the time I used to for gaming. (A few years later, I got DEEP into ArmA and DCS, which led my career into academic research connected to defense training and simulation.)
Incidentally, this is another reason to be excited about the second coming of Microprose -- I'm unclear on the exact relationship, but I believe I read that some of the same leadership responsible for TitanIM is associated with the new Microprose.
TitanIM is a defense simulation engine, using Outerra, which is a world-scale 3d+terrain engine. Tech demos of Outerra are around, and there's at least a few TitanIM videos floating around. I've been out of the sim/training niche for a couple of years, but I believe Titan is still being marketed as a competitor to Virtual Battle Space (VBS) which is the ArmA engine, but expanded and specialized for training, and sold into government with the associated contract support, etc.
I have no idea if this overlap in leadership means Microprose might have access to/be using the same tech stack as Titan for the new Microprose games, but if they are, it could be pretty darn cool.
It seems like space sim combat ... almost is too weird, or twitchy or something or other to actually enjoy. At least I've found the more sim like it gets when it comes to sort of dog fighting combat the more it just gets immediately disorienting / feels to the user very random.
You try finding a PAPR in stock for sale to anyone who isn't a purchaser for a medical provider or first responder agency right now..
True story: I almost bought a 3M PAPR last fall because I wanted it for a "The Expanse" prop replica space suit I've been thinking about building. Decided that a few hundred bucks was too much to spend for the look of something alone, though. That would've been the best gratuitous purchase I ever made, in hindsight. Of course I probably still wouldn't be able to get filters for the thing, and properly caring for and disinfecting non-disposable hardware like that is nontrivial...
As a long-time Apple user who switched to Windows/Linux after Apple decided to ditch discrete GPUs and open standards for graphics, 100% this. Razer Blades are the spiritual successors to the pre-unibody Macbooks.
That said, I've had terrible luck with Razer batteries, and their only warranty replacement option involves a multi-week turnaround. It's a good thing I'm pretty handy and replacements can be had on the usual sources.
Same question -- I've been using Kicad on personal and light-duty professional projects for about 5 years (yeah, Altium is the real deal, but when you're making a small run of prototypes for a university lab, sometimes you use the tools you have). It definitely has some rough edges, but it's also got a very established ecosystem, so I feel like Horizon will have to be a massive improvement to compete.
I use horizon for more than a year now and have quite a few pcbs from it in production. What made me pick up horizon was mostly Autodesk's aquisiton of Eagle and kicads messy library concept.
Horizon misses nothing (for me) now and has a beautifully efficent UX compared to Eagle and KiCAD. Their library concept is also well thought through, so I don't have the feeling I am wasting my time when I am contributing parts.
The downsides are:
- you still have to create many parts yourself (but parts, packages, etc are json and generating them can help a lot)
- horizon supports only newer OpenGL versions, so if your machine is old it might not run
Other than that I'd take it over all the others every day (and I do).
I've been using Kicad for the same workloads as you, and Altium + Cadence for heavier ones over the years, and I must say they hit the nail on the head here with their comments about KiCad:
https://horizon-eda.readthedocs.io/en/latest/why-another-eda...
I'll have to find a simple project to test this out on though, because as you say, It needs to be a huge improvement on KiCad to warrant a switch.
Thank you for linking to this. That's a pretty compelling story he's telling, I'll have to give it a go if I can find a low-pressure project to experiment on it with!
Some rough edges? Kicad has a lot of rough edges, and some of the biggest have to do with footprint libraries & sharing, which is the key piece of momentum in this space. Meanwhile, that's something horizon does very, very well. I could see horizon overtaking kicad.
The code's a bit of a mess -- James is clearly not a software engineer first. This is totally understandable, given that he does so many other things!
When I first saw the code, I thought about doing a refactoring pass and making a pull request. It would be painful to test correctness without the hardware, and I don't want to make things worse, so I haven't.
It's probably also worth mentioning the project is a work in progress, and from the videos, it looks like OpenDog is likely to undergo at least one more major change before "completion".
For future reference, I saw "OpenDog" and thought we were discussing James Bruton's (XRobots) OpenDog/Mini-Dog, which is where the firmware I linked above comes from.
NanoDog is something different, apparently! Sorry for any confusion I might've caused there.
Hell, I'm getting flashbacks to my own code in EE lab. Except this stuff looks way less messy, not nearly enough random assembly declarations to bludgeon a register or pin into submission.
