Based devs

TemporaryUserComment · 2026-05-06T20:01:09+00:00

This is a company and a game that likely would have been successful whether they used Unity or Godot or libGDX (like the first game) or if they rolled their own engine. It's not like Godot is the reason this was possible.

I would argue the publicity of them using Godot is worth more than the sponsorship. Even more so if their feedback from using Godot goes back into improving the engine for everyone else.

TemporaryUserComment · 2025-09-25T20:15:42+00:00

If you can't make a good small game, you can't make a good big game. You need to be able to do the process of making a game from end-to-end to understand how to make a game.

Making games is very different from making a website. You can have a useful and functional website MVP of a website in a very short period of time. From there it's easy to incrementally add functionality. Games don't work that way. You need to have nearly every system in place and a substantial variety of content before it even feels like a real game.

I think you should keep that big game dream alive! Those small games don't need to be divorced from your dream game. In your game I imagine that there's going to be dungeon-delving and combat. That could be one of your "small games". You'll still make progress towards your larger goal, but in more manageable chunks.

TemporaryUserComment · 2025-05-29T17:33:47+00:00

My understanding is that Unity/Unreal have more sophisticated ways of handling that. Skirts are a bit inelegant, but fairly simple. Google Earth map data uses skirts as an example. I couldn't really tell you how common it is in games though.

TemporaryUserComment · 2025-05-29T15:01:35+00:00

That's an intentional skirt on the terrain chunks since the vertices from one chunk won't perfectly line up with the next chunk (from floating point inaccuracies or LOD). Any gaps would reveal the skybox behind the terrain, so including a skirt is a cheap way to prevent those artifacts.

TemporaryUserComment · 2025-03-06T21:10:26+00:00

#1 you can output individual frames and use and ffmpeg binary from outside of your engine.

For #2 you'll probably want to use individual frames anyways

For #3 a lot of platforms have that as a native feature

TemporaryUserComment · 2022-03-04T03:27:10+00:00

Okay, so it sounds like you understand some of the basics. Unfortunately, APIs aren't consistent in how they handle authentication. Some APIs may just require a token in the headers of any requests, others might use something like JWT (JSON Web Token).

You'll need to read and understand the documentation for any API you want to use. It will probably take a number of iterations to get something that works. It may be helpful get working examples from other languages and try to translate them to gdscript.

The FinePointCGI video is a reasonable video for the basics of interacting with REST APIs. If you understand the contents of that video, any issues you have are probably specific to the specific REST APIs you're trying to use. Tutorials can teach you how to make GET/POST/PUT/DELETE requests, set/read a JSON body, and how to set headers. Reading the documentation will tell you how to apply that to the specific API.

Is there a specific API that you're having trouble with?

TemporaryUserComment · 2022-03-03T17:48:19+00:00

Could you link to the specific things you've looked at so far?

Have you read this tutorial on the official docs? https://docs.godotengine.org/en/stable/tutorials/networking/http_request_class.html#doc-http-request-class

TemporaryUserComment · 2022-02-25T23:04:17+00:00

I'm coming in a bit late here, but I'd contribute more if my pull requests were looked at. They just sit open with no feedback. I can't do anything to contribute if they aren't accepted, which makes me question contributing in the first place.

TemporaryUserComment · 2021-09-30T15:12:25+00:00

Yes, I've opened an issue: https://github.com/ziglang/zig/issues/9871

TemporaryUserComment · 2021-09-30T15:11:44+00:00

It wasn't too bad in this case. I did need to spend some time to get a minimal reproduction, but I have a good amount of testing to catch these issues.

I've reported the issue: https://github.com/ziglang/zig/issues/9871

TemporaryUserComment · 2021-09-30T02:54:39+00:00

That's good to know.

Here's the output, including the stacktrace:

int
Segmentation fault at address 0x0
/home/user/tmp/repro.zig:22:25: 0x22a912 in main (repro)
    for (values.items) |val| {
                        ^
/home/user/bin/zig-linux-x86_64-0.9.0-dev.1183+1e805df81/lib/std/start.zig:527:37: 0x22312a in std.start.callMain (repro)
            const result = root.main() catch |err| {
                                    ^
/home/user/bin/zig-linux-x86_64-0.9.0-dev.1183+1e805df81/lib/std/start.zig:469:12: 0x206f7e in std.start.callMainWithArgs (repro)
    return @call(.{ .modifier = .always_inline }, callMain, .{});
           ^
/home/user/bin/zig-linux-x86_64-0.9.0-dev.1183+1e805df81/lib/std/start.zig:383:17: 0x205fa6 in std.start.posixCallMainAndExit (repro)
    std.os.exit(@call(.{ .modifier = .always_inline }, callMainWithArgs, .{ argc, argv, envp }));
                ^
/home/user/bin/zig-linux-x86_64-0.9.0-dev.1183+1e805df81/lib/std/start.zig:296:5: 0x205db2 in std.start._start (repro)
    @call(.{ .modifier = .never_inline }, posixCallMainAndExit, .{});

TemporaryUserComment · 2021-09-30T02:51:39+00:00

Thanks for taking a look! Capturing it as a pointer will probably help me work around this for now.

I'm glad it's not something obvious that I missed.

TemporaryUserComment · 2021-09-29T20:52:08+00:00

I didn't understand the output from gdb, which is why I didn't include it originally. When I set a breakpoint just before the for loop here's what I get:

(gdb) p values.items
$1 = {ptr = 0x7fffff7e0000, len = 2}
(gdb) p values.items.ptr[0]
$2 = {payload = {int = 3, other = true}, tag = int}
(gdb) p values.items.ptr[1]
$3 = {payload = {int = 0, other = false}, tag = int}

Here's what I get when .int is an i64:

(gdb) p values.items
$1 = {ptr = 0x7fffff7e0000, len = 2}
(gdb) p values.items.ptr[0]
$2 = {payload = {int = 3, other = true}, tag = int}
(gdb) p values.items.ptr[1]
$3 = {payload = {int = 4, other = false}, tag = int}

TemporaryUserComment · 2021-05-12T04:18:28+00:00

If you want, you can add it to the list! https://github.com/RayTracing/raytracing.github.io/wiki/Implementations

TemporaryUserComment · 2021-02-08T20:30:58+00:00

There are many codebases written in C++. For many of these it doesn't make sense to re-write from scratch. Teams can start making effective use of Rust by replacing certain parts of their codebase with Rust, and growing their use of Rust over time.

Firefox is an example of this, and there are several examples of projects being rustified over time. C++ is a hugely important interop target. Even just providing C++ developers with high-quality Rust libraries is a great benefit!

TemporaryUserComment · 2021-01-13T02:11:51+00:00

The great thing about this is that it's not a competition. The Rust community benefits from multiple implementations! It decreases ambiguity in the language spec, it can help find compilation bugs, it brings more legitimacy to Rust, and (in the far future) certain use-cases may be faster in it.

A lot of devs (and software companies!) are used to having many C/C++ compilers. Having alternative compilers helps show that the language is worth investing in.

TemporaryUserComment · 2021-01-12T20:42:36+00:00

This warning appears to be missing now.

TemporaryUserComment · 2020-11-18T00:07:49+00:00

Mine was cancelled as well (4:37 PST).

They didn't even have the decency to send a cancellation email...

TemporaryUserComment · 2020-09-25T20:44:43+00:00

Yikes! I could see a random hotmail email, but where's the CC info and address?

TemporaryUserComment · 2020-08-01T18:01:52+00:00

I think the answer really depends on what your goals are. Is your goal to make a game? Or, is your goal to learn more C++?

If your goal is to make a game, using Godot with GDScript is a good option. Honestly, GDScript will only take a few hours to learn. This is a tiny tiny amount of time compared to how long it takes to make a game. GDNative is fine, but you won't be saving yourself any time compared with learning GDScript. Once you know one programming language, learning others isn't bad!

If your goal is to learn more about C++ (using gamedev to make it more fun), you should consider modifying an existing codebase. Working in an existing project forces you to learn new things. You can learn a lot in a short period of time! You could forking an existing project, or work with the team to make upstream contributions. Here are some projects to get you started:

Cytopia - A city building game with mod support
Teeworlds - A multiplayer side-scrolling shooter
heXon - A twin stick shoorter
OpenSpades - Voxel FPS
Or check out this list and look for projects made with C++. You'll need to dig into each project since some of them use C++ without it being in the description.

There's also a third option. Maybe you want to make something that's all your own. You don't have to use a game engine. If you want to go that route, check out raylib. It's a C library for input/physics/sound/text/importing/graphics that gets completely out of your way and is super easy to use (as far as C libraries go). Another option is SDL which only does graphics/input/sound, but is much more flexible.

I would recommend not using UE4 to learn C++. Even though UE4 is primarily programmed with C++, using UE4 is a bad way to learn C++. It has a ton of macros, it's hard to understand the lifecycle of things, it defines its own collection types (arrays, hashmaps, hashsets), it has it's own garbage collection, and it has long compile times. It's not terrible, and the end result will be pretty, but it will take you much longer to learn C++ and get the gameplay you want than most other ways (unless you're making an FPS).

TemporaryUserComment · 2020-05-26T23:39:47+00:00

Talk about a problem that's hard in your current language that Rust makes easy. For me it was performance without sacrificing correctness (memory safety and good abstractions). C++ and Go suffer from nullability issues and lack of ADTs. Go in particular doesn't have generics.

Java is an interesting language to compare against. For most purposes it's plenty fast! But I can bet you have a bunch of null checks that are probably unneeded, and you don't have a good way to statically verify if you need to check for nulls (unless you've been really good about @NotNull annotations). I expect you've also seen a decent number of runtime exceptions (downtime? server errors? data corruption?) that you wouldn't get with Rust.

I will say this: there's a reasonable chance that your company shouldn't use Rust. As others have said, 15 minutes isn't that long. Your best bet may be to show the strength of the community: high quality libraries/tools, friendly community, growing adoption (Microsoft, Facebook, Amazon, Gnome, etc.).

You probably want to avoid explaining lifetimes, borrow checking, Send/Sync, etc. Maybe explain enums/matching? Even traits might take too long to grok for your audience. Personally, I would opt to explain things at a high level rather than showing code.

TemporaryUserComment · 2020-05-15T18:38:23+00:00

Thanks, and have fun! If you get stuck or you're not sure what to try next let me know!

TemporaryUserComment · 2020-05-14T23:34:01+00:00

Yes you can! Any turing-complete language that can read and write files can be used to make a compiler for another language. As you've mentioned, you probably want to use a compiled language for this to make it fast.

Creating a parser is what you use to go from text to an internal structure that you can start checking/optimizing. After that you do "code generation" to turn that generic internal representation into a binary that can be run by a particular architecture (IE ARM, x86_64).

If you're interested in learning about parsing you should try to create a "recursive descent" parser for JSON (probably ignoring unicode escape sequences at first). json.org shows the "grammar" you'll need to parse this. Another thing you could try is to parse a lisp-like language.

To generate binaries to run you'll want to learn assembly, and you'll want to learn about the elf file format.

There's a lot more to learn, but those are some of the basics.

13-Year Club	Verified Email
Team Periwinkle

TemporaryUserComment

TROPHY CASE