next »

[Yxven]

I'm getting frustrated with Haskell's debugging.

The default behavior on an uncaught exception is to dump the program with the exception but no line number. If you want to know the line number, you have to rerun your program with the easily remembered -xc flag (xc stands for stacX traCe).

I tried installing EclipseFP in hope of a graphical debugger. Immediately upon installing eclipseFP, it tries to download all of the cabal packages on your computer in parallel, keeping them all in memory including space leaks. I didn't know this of course. My computer locked up for 30 minutes before I could get eclipse to respond, but it eventually downloaded everything. Although, it couldn't get the dependencies to work together, and it couldn't figure out how to run my basic cabal project. Apparently, EclipseFP is abandon-ware. I wish someone had told me that 3 hours earlier.

I also tried the Leksah haskell IDE. It also crashed during installation albeit in a much kinder way. I also never got this to run my code. Although, I admittedly didn't try very hard.

I resorted to print statements. If I discover a bug, I liberally sprinkle print statements around where I think it is. I then compile and run it. If I'm unlucky, this may take repeated attempts until I have the data needed to understand it. Then, I add a test to reproduce the bug. I recompile, and it fails because I forgot to export the private function to test it. I export and recompile. I make changes until the bug gets fixed.

Have I mentioned that each time I recompile I'm really recompiling twice? Apparently, you have to compile twice if you also want a build that can print the line number on exceptions. My code base is probably less than 2000 lines, but I'm already at 20-30 second compile times.

I think I'm done using Haskell for game dev. I like the language, but the tooling and ecosystem leave much desired. My physics engine is borderline working. I've ironed out the bugs at least for circles, but it's about 10x slower than it needs to be. I think I could fix it if I wanted to, but I'm not certain I want to.

[dancing_dead]

shame about that, but I'm not surprised that something like haskell doesn't have the tools for gamedev.

I know it's not nearly the same (level of insanity), but have you considered something like F#? Visual Studio Community Edition now being completely free and absolutely functional should provide a debugging experience that's lightyears ahead of this hell. you'd lose out on some purity and functional geek cred, but with F#, I think, you have a much better chance of producing something that actually works.

[Yxven]

I've had modest success optimizing this.

This is what it was originally:

Code:

	total time  =       21.80 secs   (21799 ticks @ 1000 us, 1 processor)
	total alloc = 26,889,695,632 bytes  (excludes profiling overheads)

COST CENTRE                            MODULE             %time %alloc

resolveCollisions.collisions           Components.Physics  45.0   78.3
gatherCollisions                       Components.Physics  14.1    0.0
resolveCollisions.combinedCollisions   Components.Physics   8.4    0.0
resolveCollisions.combinedCollisions.\ Components.Physics   7.5    0.0
bucketize.generate'                    Components.Physics   7.4    7.3
bucketize.generate'.next               Components.Physics   4.4    6.4
bucketize.generate'.(...)              Components.Physics   3.9    3.3
bucketize                              Components.Physics   2.0    0.4
rnf                                    Components.Physics   1.4    1.1
physicsUpdate.physics'                 Components.Physics   1.4    1.1
bucketize.generate'.remaining          Components.Physics   1.3    0.0

This is what it is now:

Code:

	total time  =        5.95 secs   (5954 ticks @ 1000 us, 1 processor)
	total alloc = 5,970,057,680 bytes  (excludes profiling overheads)

COST CENTRE                         MODULE             %time %alloc

bucketize.generate'                 Components.Physics  25.3   33.1
bucketize.generate'.next            Components.Physics  15.5   28.9
bucketize.generate'.(...)           Components.Physics  13.4   15.5
physicsUpdate.physics'              Components.Physics   8.6    4.8
rnf                                 Components.Physics   8.2    4.8
physicsUpdate.spaceWithCollisions   Components.Physics   7.4    1.6
bucketize                           Components.Physics   6.4    1.6
bucketize.generate'.remaining       Components.Physics   4.1    0.0
applyPaletteWithTransparency.pixels Codec.Picture.Png    0.4    1.2

I've reduced the accumulative memory usage from 26 gigabytes to 6 (it's about 50mb in memory at any one time). It was around 500% too slow, but now it's closer to 20% too slow. I've already tried optimizing the bucketize function, but I haven't been able to improve it much.

Code:

--This function transforms a vector of (bucketIndex, Entity) into a jagged
--Vector (Vector Entity) where the index of the enclosing vector corresponds to
--the bucketIndex
bucketize :: Int -> 
    Vector (Int, Entity) -> 
    Space
bucketize gridSize xs = unfoldrN gridSize generate' (0, sorted)
    where
    sorted = runST $ do 
        thawed <- thaw xs
        Intro.sortBy (\(a,_) (b,_) -> compare a b) thawed
        freeze thawed
    generate' (a, b) = Just (next, (a + 1, remaining))
        where
        (matching, remaining) = span ((==) a . fst) b
        next = map snd matching

shame about that, but I'm not surprised that something like haskell doesn't have the tools for gamedev.

I know it's not nearly the same (level of insanity), but have you considered something like F#? Visual Studio Community Edition now being completely free and absolutely functional should provide a debugging experience that's lightyears ahead of this hell. you'd lose out on some purity and functional geek cred, but with F#, I think, you have a much better chance of producing something that actually works.

If I jump ship, it would definitely be to something much more mainstream. Monogame qualifies, but I can't say F# was on my radar. It does have inferred typing going for it which is nice. I'm not inspired by #monogame having 20 people in it vs the 100 in love2d's irc. Is it nice? Are you making something with it?

[Boreal]

The other solution would be to go back to a typical game development language (like C++) and apply all the stuff you learned about functional programming so that you can be one of the few who don't go insane trying to make stuff like threading and data-oriented design work.

[Yxven]

With reddit's help, I reimplemented bucketize as

Code:

bucketize :: Int -> 
    Vector (Int, Entity) -> 
    Space
bucketize gridSize xs = map fromList lists
    where
    lists = create $ do 
        space' <- MVector.replicate gridSize []
        let prepend (i, entity) = do
                bucket <- MVector.read space' i
                MVector.write space' i (entity : bucket)
        Vector.mapM_ prepend xs
        return space'

It should be fast enough now for 60 fps now:

Code:

	total time  =        3.10 secs   (3102 ticks @ 1000 us, 1 processor)
	total alloc = 3,830,758,504 bytes  (excludes profiling overheads)

but I can only do 30. I'm guessing Gloss is adding overhead that's not included in my profile.

The other solution would be to go back to a typical game development language (like C++) and apply all the stuff you learned about functional programming so that you can be one of the few who don't go insane trying to make stuff like threading and data-oriented design work.

I'm not sure I know how to do that, but I do know that sigfaults make me want to seppuku.

I don't know. I looked at a lot of 2d frameworks today.

• SFML has nice documentation, but C++.
• Love2d has nice docs, but Lua seems odd.
• Haxeflixel is web deployable and has type inference, but the docs are weak and community is small.
• I already know Unity, but I'd need a pro license to integrate with the C++ code I want. Plus, I wouldn't be able to release the source of my game very easily.
• Monogame has weak docs.
• Libgdx looks very nice overall. How long until first class functions decruft the java ecosystem?

[dancing_dead]

I wasn't aware you need a high level library like Monogame for this project. When I said F#, I meant it together with something like OpenTK (which, afaik, can be used with F# just fine - it's crossplatform, too). googling even reveals a simple example

Also, even though monogame has weak docs, xna, whose API is almost identical, still has a massive amount of documentation and examples on the internet. All in C#, tho.

I, for one, would love to see a purely functionally done game. Making games in your everyday OOP friendly language is not nearly as exciting.


If you do go ahead with something casual, I can vouch for LibGdx, it's very nice, I'm using it for a 2d mobile game, performance is great and the library has many little clever things going for it, GC-friendly collection types, built-in texture packer and atlassing, an actually usable ui library etc. xna/monogame is great as well, but xna is dead, and monogame still has ways to go, although I hear they've been finally getting the content pipeline issues ironed out.

[Yxven]

I decided I was going to try to push my physics engine over the 60 fps hump by parallelizing it today, so I set up Linux and failed to install the parallel profiling tool (Threadscope). I figured this would be a sure thing since what makes it fail on windows is the Gnome Tool Kit, but apparently, GTK makes it fail on linux too.

Unfortunately, my patience for a crippled ecosystem is gone. I like Haskell, and all else being equal, I think it would probably be the most productive choice. However, all else is not equal. I want to make a game not a game engine and certainly not an ecosystem. Haskell needs a better build system, profiling tools that just work, a pure GUI, and a pure sound library that will install. Until all that happens, I'm done trying to make games with it, but I probably would use it if I wanted to program a website, command line tool, or Euler problems.

I, for one, would love to see a purely functionally done game. Making games in your everyday OOP friendly language is not nearly as exciting.

I'm tempted to use clojure for libgdx, but I'm not in the mood for more work with little benefit. Looking at play-clj's docs, I can already see that it's missing bindings to the AI engine and ECS. I'd bet I could glue 90% of my game's code together in libgdx in a month using java. It would take that long to learn lisp and emacs plus whatever time it'd add due to being the red headed step child. Ask me again when I haven't just spent 4 months wasting my time.

[maxl]

Very entertaining devlog! I admire your bravery 

Libgdx looks very nice overall. How long until first class functions decruft the java ecosystem?

Take a look at Kotlin! I am currently using it in conjunction with LibGDX. It's Java without the bad parts + functional programming without the insane parts.

[Yxven]

Maybe 6 hours later, my libgdx game is farther along than I was in Haskell. I have an animated dude who can teleport around my tiled map. Shout out to these guys http://www.gamefromscratch.com/page/LibGDX-Tutorial-series.aspx for writing an in-depth tutorial. If I were relearning unity, I would have spent my 6 hours watching videos.

Holy shit have I missed nice editor integration. If I fuck up my code, vim goes, "Dude, don't embarrass us by trying to compile this. It's not gonna work. By the way, nice logic error on line 67." It's like having an annoying brother that is smarter than you but still wants you to succeed.

On the other hand, it's kinda weird going back to a stateful language. There are functions that compile and can be executed that don't seem to do anything. Everything in Haskell obviously does something. Every pure function returns a value, so it's completely obvious what happened. For example, "new OrthographicCamera(x, y)" the x and y don't do anything in my program. It's supposed to adjust my viewport but because I'm using a TiledMapRenderer it doesn't do anything (and that fact isn't documented anywhere). The same goes for "camera.setToOrtho(false, viewPortWidth, viewPortHeight)." Viewport Width and height do nothing. I replaced setToOrtho with it's less confusing twin "camera.setToOrtho(false)" for my sake, but what do you think "camera.setToOrtho(false)" does? I'll give you a hint. It doesn't turn off the orthographic perspective of the camera.

You don't see functions named that poorly in Haskell because Haskell rewards making functions as single purposed as possible. I'm not knocking the libgdx developers. They're obviously a very capable bunch, but this is what java does to your code (and in the spirit of java all my code is in one class right now).

Take a look at Kotlin! I am currently using it in conjunction with LibGDX. It's Java without the bad parts + functional programming without the insane parts.

Heh, I like the insane parts. =) They make you feel like a worm who will one day evolve into a worm with wings. I've never used one of these JVM languages. Can I call normal java functions from them or do I have to write/use bindings? Clojure looked like it needed bindings. Can I easily mix and match languages in the same project?

I'll think about Kotlin, but I'm gonna stick with Java for a while. The last version of java I played with was version 5, so I want to see its new tricks.

[Yxven]

An Corp

It's time to resurrect this. I lost interest because the friend I wanted to do this with flaked out. I don't know what it is with business partners, but they always flake out without saying anything.

In any case, I re-injured my forearms by playing too many video games, so programming with voice-recognition is one of the few things I can do to be productive right now. Hence, I'm back.

I blew the dust off my old code, and the first thing I decided to do was change the perspective from top down to a side view platformer perspective. I prefer top-down perspective, but as an independent developer, I don't feel like you can logically justify doing 4 to 8 times more art for a preference that doesn't necessarily enhance gameplay. The trade-off is that the theme is going to have to be rather weird. Because I want SHMUP gameplay in my RPG, everyone is going to have to fly or float really well, so the theme is going to be underwater, on a different low gravity planet, Casper the friendly ghost, Angels verse demons, or something else along those lines.

I also set up the ability to paint static collectible objects in the tiled map editor, and have changed the placeholder art to Kennyland.

[Yxven]

Beh, I can't motivate myself to work on this. I feel like it would take about two years to ship what I envisioned, and I'm not interested in that sort of commitment right now.