badsectoracula

avant-hierdiscuss

Codeberg has some extra "anti-scraping" measures than just Anubis which, judging from the community issues[0] sometimes ends up with false positives that cause people to get garbage (example issue[1], potential page with the garbage i found from Google[2]).

Interestingly, someone mentioned that you may get the garbage when searching Codeberg using Google's `site:codeberg.org`

[0] https://codeberg.org/Codeberg/Community/issues

[1] https://codeberg.org/Codeberg/Community/issues/2603

[2] https://codeberg.org/Codeberg-e.V./requests/!~codeberger~!.g...

badsectoracula

avant-hierdiscuss

Same here, i've been on Codeberg since 2022 but if this passes, i'll most likely move my stuff elsewhere (my projects do not even have any AI code, i just dislike the idea of telling people what tools to use to make their own stuff).

I dislike GitHub and i'm using a shared host for my website which wouldn't let me install something like Forgejo (this is by choice as i don't want to bother with sysadmin stuff, my site is almost all static HTML with only a couple PHP scripts for some minor tasks). So i guess i'll be migrating to GitLab, even though i do not really like its UX. Or maybe i'll use some other Forgejo instance like CodeFloe. URLs aside, migrating between Forgejo instances should be easy.

badsectoracula

avant-hierdiscuss

Spinning up a docker image with GitLab is easy indeed, but the installation is huge and you can feel it doing weird stuff (and it keeps doing "stuff" all the time even if nobody does anything - before you even bother to create extra users or repositories or whatever). The whole setup seems to be designed to be opaque.

Forgejo is a single self-contained ~110MB binary (it contains all assets) you can drop anywhere and it'll just work - depending on your needs you most likely wont even need to bother with a DB server as it can use SQLite (my local install is doing that).

Also FWIW personally i find Forgejo's UX much better compared to GitLab.

badsectoracula

il y a 4 joursdiscuss

> I have no idea why they didn’t realize that earlier

14 layers of management :-P

badsectoracula

il y a 10 joursdiscuss

If your game wasn't approved or they didn't respond back there are better avenues than writing these pointless messages on HN.

badsectoracula

il y a 10 joursdiscuss

> ancient forefathers are ODE

I remember trying this back in 2004 or so when i was making my first real 3D game engine, but i ended up abandoning it because i was trying to use it on 64bit Linux and the source code had typecasts between pointers and (32bit) ints all over the place :-P.

That was fixed later and apparently the engine was used in a few commercial games during the 2000s and early 2010s.

badsectoracula

il y a 13 joursdiscuss

They just released four games yesterday and looking at the news reel it seems they release a bunch of games every day. They're also running a summer sale right now. I doubt they're anywhere close to being dead.

They are known to take their time when it comes to developer submissions (and that time can be quite long) but that was the case since pretty much forever, not something that happened with the new/original owner.

badsectoracula

il y a 15 joursdiscuss

The fact the site died after being posted here might be an indication why :-P.

badsectoracula

il y a 16 joursdiscuss

Doom 3 was SOTA in terms of realtime lighting and shadows, but that's basically it. In terms of visuals, Half-Life 2 with its baked lighting in directional lightmaps (essentially calculating three lightmaps for each surface for lighting coming from different directions, then using those with normal maps during rendering) with radiosity indirect lighting did a much better job with how good environments looked (and it scaled much better than Doom 3 which in lower settings looked worse than Quake 3). Doom 3's character rendering was also subpar compared to Half-Life 2 - let alone character animations mentioned elsewhere (Source/HL2's facial expressions were SOTA for several years after the game was released). Doom 3's physics were also not as complex as HL2's and the game didn't use them much (the expansion did better use of the physics engine and IMO the Grabber feels superior and more seamless in its use compared to the Gravity Gun but the expansion came later and while the Grabber is nice, the rest of the expansion suffered from focusing too much on gimmicks).

In general while Doom 3 has the better (and probably more forward thinking) rendering tech, HL2 also had some very good tech for its time and did a much better use of the tech they had available than Doom 3 did.

That said, personally i enjoy playing Doom 3 much more than HL2 but that is largely because Doom 3 plays more like a traditional shooter with very little scripting / storytelling to get in your way (and the little there is you can ignore it without losing anything) - you just shoot demons, find keycards/PDAs to open doors and that's it for the most part. I often just put it in low volume and play some podcast in the background :-P.

As for Far Cry, the game looked too plastic IMO, i remember playing the game and the characters' muscles had specular reflections :-P.

badsectoracula

il y a 17 joursdiscuss

Usually one would start with "is there a measurable performance bottleneck here?" :-P.

TBH i haven't played Elden Ring but from what i've seen there are so few "active" NPCs around that i highly doubt there'd be any performance issue coming from this.

badsectoracula

il y a 17 joursdiscuss

The article keeps on mentioning about the performance issues of the decision tree that somehow this approach avoids, but it doesn't seem to actually put any real detais about the why here. Especially considering that:

1. Many scripting languages you'd find in games are implemented by evaluating the syntax tree directly (IIRC WitcherScript in Witcher 2 and 3 is implemented like that)

2. A behavior tree can be "compiled" down to a bytecode VM similar to what some scripting languages use

Though if any of these two approaches makes any difference in performance i'm not sure and i'd expect it'd depend heavily on how exactly they're implemented (my kneejerk reaction would be to expect the VM approach to be faster because parsing a bytecode sequence might be more cache friendly than jumping through pointers, but i also suspect that since game AI scripts/behaviors wont do any real computation themselves and instead 99% of the code would be engine/native calls, any potential benefit would be diminished -- but as i haven't tried to implement the same stuff with a realistic setup using both approaches to compare, i cannot say one or the other for certain).

badsectoracula

il y a 17 joursdiscuss

This is game AI, games called this sort of thing "AI" for a long time. Behavior trees is (among others) one of the most common things someone with the role of game AI programmer will implement.

This has been the case since at least the 90s, it is not a new thing.

badsectoracula

il y a 20 joursdiscuss

The original Pascal didn't had a string type, that was introduced by various dialects.

FWIW all Pascal dialects since the 90s have a string type that allows more than 255 bytes. In Free Pascal strings are pointers to the first character with a header in a negative offset indicating the length, reference count and codepage (these fields are aligned depending on the CPU). For C compatibility the string is also null terminated so you can pass such a string to a C function and it'll work as expected. AFAIK Delphi also does the same.

badsectoracula

il y a 20 joursdiscuss

Free Pascal strings (and i assume Delphi as they are sometimes compatible) are pointers to the first character of a null terminated string with a header in a negative offset before the first character indicating the string's length, reference count and codebase.

AFAIK a "Pascal string" is basically another way to say "length-prefixed string" (as opposed to null terminated string) and Free Pascal (and Delphi) are like that (and they're Pascal dialects too, so their strings are literally Pascal strings :-P).

badsectoracula

il y a 20 joursdiscuss

FWIW pretty much all Pascals since the 90s use a similar approach.

In Free Pascal for instance, strings are pointers to the first character with a header in a "negative address" containing information about the length, reference count (strings are reference counted and use copy-on-write to avoid passing around copies all the time) and codepage (FP can convert strings between different encodings "transparently").

badsectoracula

il y a 20 joursdiscuss

For a long time i had a small Pentium III PC (released in 2000, though the hardware inside wasn't the best you could get at the time as it was meant to be compact instead of performant - it was in an almost pizzabox sized case) running Windows 98 for retro games and software (though mainly games). At some point i installed Visual Studio 6 to it too - and IME it launched instantly[0].

In general everything ran fast... except stuff that had to do a lot of disk access, obviously (i.e. installers and such). But i never though that the system didn't feel responsive.

Also many modern programs have splash screens too. E.g. have you tried to launch Gimp or Krita recently? Or Eclipse? "Heavy" applications never stopped having those.

Of course computers are much faster now, nobody is saying otherwise. What people are saying is that it often doesn't feel so. If my Pentium III can open Visual Studio 6 faster than my 3700X can open Calculator, then yes, things do feel more performant on the Pentium III running Windows 98 even if the modern machine is much faster.

[0] https://www.youtube.com/watch?v=h79Bt7h5ceo

badsectoracula

il y a 21 joursdiscuss

Impressive. I guess this isn't only the renderer made to use CSS but also a full recreation of the engine and logic right? My guess is because a bunch of things do not behave like the original game, e.g. some buttons need to be shot instead of touched to activate, some secret doors open by touching them instead of being shot, etc.

badsectoracula

il y a 23 joursdiscuss

Theoretically yes, but in practice you don't need the full repository, but even in mid-2010 (when i first encounter Perforce in a gamedev company - previously the companies i worked on used Subversion which was also able to handle some huge repositories -- one had all their games from the 90s to early 2010s in a single Svn repository, including code and data) a workspace with just the game's code and data in the engine's format (i.e. excluding everything a programmer wouldn't need, like the "source data" for assets such as max/maya/etc files) was around 250GB or so. IIRC the entire repository (all versions, not just latest) had crossed a petabyte in size :-P though that company put absolutely everything in Perforce.

badsectoracula

il y a 24 joursdiscuss

> I’ve also worked on games that have required a bunch of different standalone services just for core logic

Don't make your game be a spaghetti mess of dependencies.

Or.

When you decide on your dependencies, make sure they are compatible with the regulations. The chances of middleware developers not updating their middleware and/or licenses to comply with these regulations are practically zero: there will 100% be market need for compliant middleware and others to provide it, so the existing middleware developers will update theirs too.

> What if I rely on steam, or epic for P2P and they shutter the service?

That's the easiest of the bunch because Steam already has at least one opensource reimplementation of the API (probably multiple) so all you have to do is drop a DLL in your game's directory and you get Steam independence.

badsectoracula

il y a 26 joursdiscuss

> Yes, just use and IDE

The best the IDE can do is display a tooltip or something like that which is cumbersome when reading the code because you need to move over everything to figure out what the types are. And sometimes for whatever reason even that fails.

And this is only useful in the context of using an IDE: code can be found outside IDEs too, even if all you do is use an IDE for your development (not everyone does), the code can still be found in patch files, pull requests and code review platforms none of which have any IDE functionality to know what the types are.

> There’s no reason to repeat type definitions. If you can use auto, what that means is the type is already statically known

I'm not a compiler though.

comments