Project in progress
-
@pie_flavor said in Project in progress:
@masonwheeler said in Project in progress:
They're on different ports on the same box.
... why? Why not
/api
and/static
roots?Because hand roll.
-
@pie_flavor Because the Blazor SPA requires a server that knows about URL rewriting to function properly, which my API server doesn't, and the API isn't done in ASP.NET, so I can't put it on the Kestrel server.
I'll probably end up updating the API server with rewriting before too long.
-
@masonwheeler said in Project in progress:
Because the Blazor SPA requires a server that knows about URL rewriting to function properly, which my API server doesn't, and the API isn't done in ASP.NET, so I can't put it on the Kestrel server.
When I've done that sort of thing, I've ended up putting it behind an nginx frontend that rewrote everything to appear as if it was on port 80 (and did the static file serving too, because that was convenient). Don't know if that'd work for your deployment, but it resolved all the CORS problems I was having with that complicated service (and which the vendor of the service was no help at all with… )
-
I put in a save system, but logs indicated it was failing sometimes. I figured out the problem and fixed it. (Hopefully.) Now you should be able to save with S or automatically by closing the game.
-
@masonwheeler said in Project in progress:
I put in a save system, but logs indicated it was failing sometimes.
I meant to ask about that. Zero feedback on S or Q when I managed to get registered the other day.
I can't say I'm keen on having the same key do different things depending on whether it's capitalised or not.
-
@Jaloopa Q isn't implemented yet. Did it show up in the help page?
*grumbles about malicious gremlins*
-
-
Running with the debugger (F5) isn't supported at this time.
-
@sockpuppet7 It's the CLR in the browser. Like Silverlight but still ʷ³ᶜ ᵃᵖᵖʳᵒᵛᵉᵈ. I can't think of an upper limit on how cool that sounds.
-
@pie_flavor said in Project in progress:
I can't think of an upper limit on how cool that sounds.
Zero.
-
@loopback0 Disagree.
-
@sockpuppet7 said in Project in progress:
@masonwheeler said in Project in progress:
Blazor
Is it as cool as it sounds?
Sort of, as long as you're fully aware that it's an alpha-level project with breaking changes in every release.
-
@Jaloopa said in Project in progress:
Running with the debugger (F5) isn't supported at this time.
Because what's actually running is in the browser, not inside Visual Studio, and bridging the two requires a non-trivial amount of work.
-
@masonwheeler Doesn't wasm32 have some sort of debugging symbol feature?
-
@masonwheeler Can't you use the browser's debugger? Using, for example, a .map file like both Vue.JS and TypeScript generates?
-
@blakeyrat for JS, yes. For WASM, no.
-
@pie_flavor said in Project in progress:
@masonwheeler Doesn't wasm32 have some sort of debugging symbol feature?
I have no idea, but my gut reaction is "no, or they'd be implementing that rather than trying to set up a debug bridge, which is what they're doing."
-
@masonwheeler Then why are you using it if it's obviously unfinished?
-
@blakeyrat Because even in its unfinished state it works well.
-
@masonwheeler said in Project in progress:
@blakeyrat Because even in its unfinished state it works well enough.
Prepare for vendor lock-in!
-
Almost a year later...
I've been doing some serious working on this for a while now, revamping quite a bit of the codebase. For example, it no longer looks like this:
It now looks more like:
I found a stable server that won't die or reboot at the drop of a hat, I greatly improved the battle engine code, added a bunch of new features, improved the server protocol so it no longer transmits the entire map with every frame... and formed a bona fide game publishing company to develop and sell this. I just submitted a build to Steam for review; it should be available to purchase in 2 weeks, under the name of Stormhunter Studios.
So... that's been my last year or so. How's everyone else been?
-
-
-
-
@Mason_Wheeler Welcome back! Why the username change? Also, my favorite project of yours is the other one - how is Boo doing?
-
@pie_flavor Argh, did it change my username?
Something is weird about logons here. My account is supposed to be linked to my Github account, but apparently I get a different username and icon when I sign in via Github (as I did here) than when I sign in directly.
how is Boo doing?
I built the DungonEpic server in it, so... pretty well.
-
@Mason_Wheeler any signs of a Rider / VS / VS Code plugin yet?
-
@pie_flavor Not yet. I haven't had the time to devote to solving a very specific technical problem:
- Visual Studio's language services run in-process, and use the compiler to generate data on the code being edited. (Syntax highlighting, Intellisense, etc.)
- The Boo compiler loads dependent assemblies into its process with
Assembly.Load
to analyze their metadata.- It would almost be possible to use a metadata reader instead, but this would completely break metaprogramming, which involves executing previously-compiled code from the dependent assemblies at compile time.
- Any .NET assembly loaded into a process never gets unloaded, with a very few very specific exceptions that don't apply here. (Trust me, I've looked.)
- In a typical Solution, it's quite common for one project to be a dependency of another project.
Take all these facts and put them together, and what happens? Project A gets loaded into VS's process as a dependency of project B. Then you go to rebuild Project A, but it fails at the final step (write out the compile result to disc) because
ProjectA.dll
is currently open and can't be closed. All the obvious solutions to this run into severe, non-obvious difficulties once you get a few steps in.
-
@Mason_Wheeler I assume there's a reason why application domains aren't a good fit.
-
@pie_flavor Yeah, that's one of those obvious solutions. There are a handful of non-obvious problems with it, the biggest being that with the architecture being what it is, there's no clean, obvious place to insert the AppDomain boundary.
-
@Mason_Wheeler is reading all the bytes from the DLL file and passing the array to the other overload of Assembly.Load another obvious solution? Since you describe it as though the obstacle is only the file lock.
-
@pie_flavor said in Project in progress:
Since you describe it as though the obstacle is only the file lock.
Not only; that's just the biggest, most obvious first problem.
If you get past that, such as by loading the bytes of each assembly, you still have assemblies that are held in memory forever (memory leaks). What's really needed is to be able to run this out of process (or in an AppDomain, see above) or to be able to get Collectible Assemblies to work with
Application.Load
. (Which is unlikely to ever happen as .NET Framework is essentially in maintenance-only mode now.)
-
@Mason_Wheeler probably a stupid question because of course you've tried that already, but maybe you could make the in-process part not do actual work and instead spawn a separate compiler process that actually does all the work and load assemblies and so on, but gets killed after it's done, and that would communicate with the in-process part through a socket or something?
-
@Gąska Yeah, that's exactly equivalent to the AppDomain idea, and comes with the same problem of there's no obvious, clear place to put the dividing line.
VS language support plugins are complicated!
-
@Mason_Wheeler said in Project in progress:
because ProjectA.dll is currently open
Another example where Windows locking a file because it's open is a dumb idea
-
@Mason_Wheeler said in Project in progress:
@Gąska Yeah, that's exactly equivalent to the AppDomain idea, and comes with the same problem of there's no obvious, clear place to put the dividing line.
Okay, there's no good place... But there must be some place, right? Like, start with very thin in-process part that only serializes inputs and outputs to JSON or whatever and pushes it through the socket, and the out-of-process part does all the work? And once it's done, try incrementally moving some out-of-process parts back in-process, until you're half-satisfied with it?
-
@Mason_Wheeler The difficulties make sense, but they make too much sense. As in, if there's a challenge here, there's a challenge everywhere. Which there isn't, because y'all made SharpDevelop work somehow. So where's the disconnect? How was this problem solved in SharpDevelop?
-
And the Steam page is now live.
Steam requires a page to be on "Coming Soon" status for 2 weeks before launch, so it'll most likely be ready on the 28th.
-
-
@TimeBandit said in Project in progress:
@Mason_Wheeler
No Linux supportUnity has support for Linux builds, but I have no Linux box to test it on so I have no idea if it would actually work.
-
There's an item in the Steamworks UI for requesting Steam keys for your game, to be distributed outside of Steam. They have a bunch of different categories for it, to help you (and Valve, apparently) track what you're doing. From the text that comes up as part of the request process, it appears that they've had trouble in the past with developers requesting excessively large numbers of Steam keys and then distributing them at prices that undercut the Steam service, and you're very strictly required to not do this.
I discovered all this when I requested a key batch under the "giveaway" category... and nothing at all in the options that followed had anything whatsoever to do with keys that you intended to give away. Everything implicitly assumed I was going to be selling them elsewhere.
-
Well that was quick. Just got an email stating that my key request had been approved. (Yes, apparently this is a thing that has to be reviewed by a human being and approved; I assume this is to prevent the aforementioned huge batch requesting?) If only the rest of their approval process could be so expeditious!
-
@Mason_Wheeler will you be giving away keys on here now then?
-
@Jaloopa I'll probably drop a few in the key thread. (Is that still around?)
-
@Mason_Wheeler Old threads never die; they just become difficult to find, until GODDAMNIT FBMAC!
-
@Mason_Wheeler Is ... this your card?
-
@Mason_Wheeler said in Project in progress:
And the Steam page is now live.
Steam requires a page to be on "Coming Soon" status for 2 weeks before launch, so it'll most likely be ready on the 28th.
Famous last words. I've been slogging through the Steam review process -- which is supposed to take "up to 5 days" according to their system -- ever since. Their testers will take 2-3 business days to find a single bug, fail the review based on this, and then you fix it, upload a new build, and they take 2-3 business days to find the next one. The most recent fail came approximately an hour after I fixed the bug they had encountered and uploaded the new build, because I was monitoring the server they were testing on and found that they had encountered a problem. Doesn't matter; back to the back of the line you go anyway!
Meanwhile, I'm paying for server resources for 2 weeks longer than expected and not making a dime because it's not available for sale yet.
Don't get me wrong. They're finding legitimate bugs which I wouldn't want to inflict on paying customers. It's just that the horrendous turnaround time is... well... horrendous! And expensive!
Still monitoring the server, and right now I think they're at the point where it should get approved by the end of this week... but I've thought that before. No idea when this will actually finally come out.
-
-
All right, this is just getting ridiculous. Just got another review failed notice... for two problems that aren't even real!
- "The game's page says it supports Steam Achievements, but the game does not appear to support Steam Achievements." It sure appears to support them from my perspective! They've been defined in the Steamworks backend, the game server has code to recognize achievement unlocking and report it to Steam, and the library page in the Steam client shows that the correct number of achievements exist. What else are they looking for?!?
- "Dungeon loading does not work. It only shows a black screen." Turns out this is caused by the server being idle and needing a few seconds to spin up, and their reviewer didn't wait long enough. That is caused by nobody playing on the server, because their review process is blocking it from being sold so the only people who can play the game are the reviewers, who don't touch it for several days so the server goes idle.
Just responded with a scathing email to that effect and a request that they quit screwing around and approve the game already, given that they are unable to find legitimate problems anymore.
-
Just emailed a friend of mine who works at Valve -- or used to last I knew at least; not sure if he's still there -- explaining the situation and asking if he knows anything that could be of help in extricating the game from the all-consuming black hole that is the Steam review process. Hopefully he'll be able to be of some help.