Any plans for a bigger game?

[vtereshkov]

@marekmaskarinec What are your future plans about tophat? You know, a game engine is just a tool that needs adequate applications. The space shooter is a good demo for engine capabilities, but its gameplay is too simplistic and, so to say, one-dimensional (I remember we discussed it earlier in the context of a hypothetical Raider 2.0).

I recently attended a small unofficial gamedev event (a "drink-up", as it is sometimes called) and talked about Umka and tophat there. My first impression was that everyone wanted to see real games and 3D art rather than to delve into game engine internals. Unfortunately, I had almost nothing to show, except my raytracer and your space shooter.

Sometimes I even think of writing a bigger game in Umka/tophat myself, but I have never had actual experience with games. I don't even know where you find the free assets for your demos.

[marekmaskarinec]

I want to write a bigger game in tophat one day, but I still want to focus on tophat. There aren't many features I have in mind, but there are definitely bugs there for me to fix. If I ever get to it, I will either make something based on raider, or something about automatic rail transportation (something like rail systems in factorio, but whole game about them).

but I have never had actual experience with games

If you want to get started out, I can recommend joining some game jams. There are usually lot of people willing to help you. As for asstets, I usually create them myself. I sometimes find some music on opengameart.org.

I will keep this open so it pushes me to do it one day.

[skejeton]

I'm currently making a project in tophat, I do not guarantee I'll release it ever. However I'm working on it for a few months in free time, I'll probably make it into an intermediate 30 minute long game and then after having a taste, will probably spend a good year or two making free 7-ish hour long game. It's gonna take a lot of time though, I don't usually dedicate more than an hour or two

[vtereshkov]

@skejeton That's exciting! I will be looking forward to your beta, demo, preview or something.

@marekmaskarinec By the way, I'm actively using your railgame proto as a testbed for Umka. For example, it has helped me reveal and fix https://github.com/vtereshkov/umka-lang/issues/130, so I tend to think that garbage collection is a bottomless pit of bugs :-) However, it will be great to see a complete game someday.

[skejeton]

@vtereshkov thanks. If want to view the source code to debug umka. HMU. Although I have checking tools and usually report problems as I find them.

[vtereshkov]

@skejeton Please report any 'Dangling pointer' or 'Memory leak' warnings. In general, they are more dangerous than it may seem.

[skejeton]

Oh I've seen a bunch of these already, I dismissed all of them... I'll definitely will report them from now on

[vtereshkov]

@skejeton Thanks. If it's difficult for you to reproduce the warnings in a smaller code sample, then I can try to debug Umka with your whole project.

What you can freely dismiss is the 'Memory leak' warnings after a reported runtime error. They are absolutely harmless.

[vtereshkov]

@skejeton How is your project going? I think your feedback is important to understand how far we are from the 1.0 release of Umka.

[skejeton]

@vtereshkov Yes, so it's still going and there's some feedback I'd like to leave.

• Why can I return a module-private struct from an exported function and use it? This shouldn't be legal as I don't really have access to the struct symbol.
• Error messages about returns are reported on the next line.
• Overall I think error reporting should be rehearsed, I'm quite sure there's a few minor issues I've forgot to write down.
• Inserting into dynamic arrays isn't that fast, the array is copied on every insert. This isn't a big deal for small arrays, but for dynamic arrays with many elements, it's noticeable that every new insert is significantly slower than the one before. I'd much rather prefer a dynamic array like std::vector, as I honestly haven't yet found a use for copied dynamic arrays.
• The map type should preferably be a built in and type checked like in Go. I'm not much of a map user, but it's all over the place in UI code, World Chunk code, etc. It's honestly pretty useful, but not really in the current form.
• There should be a way to specify where to source modules from. So if you source from, say, src/ then from wherever else you can just load the modules from src as if they were localy.
• The point above brings me to another point, the module path errors are incorrect. If you have a built in module named mod.um, and it contains an error, then if you import that module from other directory, it will say that the error is in module src/mod.um, but mod.um isn't in src. Related issue: #54 . Also errors for modules imported with relative paths, say ../../src/d_ui.um, imported from test/ui/ will report an error in test/ui/../../src/d_ui.um, which is just effectively src/d_ui.um. So in my opinion the module paths for errors should be reported absolute, from the folder it's ran in.

My last point is...

The performance is not particularly great.

Take something like this

fn main() {
    x := 0.0
    for i := 0.0; i <= 10000000.0; i += 1 {
        x += i
        x /= 2.0
    }
    printf("%f\n", x);
}

versus this

x = 0
for i=0,10000000 do
    x = x + i
    x = x / 2
end

print(x)

First is umka, second is lua. On my computer at least, umka is about 3x slower. Which is a shame because it has potential to be much faster than lua. I usually don't pay attention to the speed of scripting languages, since it's almost always not the issue, however since I'm writing almost the entire game in umka, the speed matters, and it shows: Most of the "self" execution time is spent in vmRun. The above isn't a perfect benchmark, so here's few more (these benchmarks mostly tackle umka's "raw" speed, e.g. crunching speed):

fn fib(x: int): int {
    if x < 2 {
        return x
    }
    return fib(x-1) + fib(x-2)
}

fn main() {
    printf("%d", fib(40))
}

20 seconds vs

x = 0
for i=0,10000000 do
    x = x + i
    x = x / 2
end

print(x)

10 seconds (lua about 2x faster)

---

type (
    StringMod = interface {
        f(s: str): str
    }

    TypeA = struct {}
    TypeB = struct {}
)

fn (t: ^TypeA) f(s: str): str {
    return s + "a"
}

fn (t: ^TypeB) f(s: str): str {
    return "b"
}

fn apply(iface: StringMod, n: int): str {
    s := ""
    for i := 0; i <= n; i++ {
        s = iface.f(s)
    }
    return s
}

fn main() {
    a := TypeA{}
    b := TypeB{}
    apply(a, 100000)
    apply(b, 100000)
}

(interface version) 600ms

fn apply(f: fn (s: str): str, n: int): str {
    s := ""
    for i := 0; i <= n; i++ {
        s = f(s)
    }
    return s
}

fn main() {
    apply(fn (s: str): str { return s + "a"; }, 100000)
    apply(fn (s: str): str { return "b" }, 100000)
}

(function pointer version) 900ms

function apply(interface, n)
    s = ''
    for i=0,n do 
        s = interface.f(s)
    end
    return s
end

a = { f = function(s) return s .. 'a' end }
b = { f = function(s) return 'b' end }

apply(a, 100000)
apply(b, 100000)

("interface" version) 400ms.

function apply(f, n)
    s = ''
    for i=0,n do 
        s = f(s)
    end
    return s
end

apply(function(s) return s .. 'a' end, 100000)
apply(function(s) return 'b' end, 100000)

(function pointer version) 566ms

There's more I can show. But I just think there's room for improvement when it comes to performance. I've tried to re-implement umka with focus of VM performance, but the project is nowhere near as complete as umka. While it's faster than Lua in general, I don't think it's fair to compare it with umka yet. (https://github.com/skejeton/elka), It's pretty much abandoned//

Either way, good luck. And if something, just ask me. I'll be glad to respond and/or help.

[vtereshkov]

@skejeton Thank you for the great report! The truth comes out, earlier or later :-) I'll split the report into several Umka issues for better tracking.

[vtereshkov]

@skejeton Could you show us anything related to your game project (maybe a pre-alpha)? I don't even know the genre of your game, though I conclude from some of your comments that it should be something like Minecraft. Dealing with a quite big real-life project would be profitable for the development of both tophat and Umka.

[skejeton]

@vtereshkov Hi! No it's certainly not Minecraft. It's a platforming game, I decided to keep it simple as I don't have much time. However I decided to also make it a learning material as an example project for tophat. So it aside from the actual game itself, it contains a level editor, ability to script by modifying the source code (which I kind of already made a framework of). Here's some stuff: (Here I got slopes working, this is mostly in the beginning) https://cdn.discordapp.com/attachments/845631328656293928/963818503205433384/Peek_2022-04-13_18-09.mp4 (I think you are in the tophat server so you should be able to open this: It's a series of videos/screenshots) https://discord.com/channels/846663478873030666/846663478873030672/992736277415874641 https://www.youtube.com/watch?v=BqY2AF4zHKc

Also since you are in tophat discord, you can hit me up about the status of the game at any time.

I'll DM you and Marek a test version which will contain the game demo when I'm done.. As to when, probably at the end of July.

[vtereshkov]

@skejeton That's cool! Do you use any third party libraries for your UI?

[skejeton]

@vtereshkov aside from tophat, no, but I think I'll try to use the UMI modules for it when i'll need it