Ludum Dare 42 - Page 2

Ludum Dare 42

Moderator: Content Developer

dansan
Server Owner & Developer
Posts: 1203
Joined: 29 May 2010, 23:40

Re: Ludum Dare 42

Post by dansan »

Cool game :)
Amazing what you did in such a short time!
Love the drilling, ice-stealing ships.
Becomes really involving after a time with the paratroopers and more ships arriving :)
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14673
Joined: 17 Nov 2005, 02:43

Re: Ludum Dare 42

Post by Forboding Angel »

Journeywar is so off the wall and strange looking that people forget that he is an excellent artist.

His desert related features (that I used for akilon wastelands and volcanic basin) for spring features for example were amazing.

Btw minor detail that others might have missed. If you look at the ships closely and how the drills and ice are positioned. It's feasible that because of the screw motion, the grooves could conceivably deliver the drilled ice to the bin on the ship.

I thought that that was a pretty awesome bit of attention to detail.
hokomoko
Spring Developer
Posts: 593
Joined: 02 Jun 2014, 00:46

Re: Ludum Dare 42

Post by hokomoko »

gajop wrote: 14 Aug 2018, 07:17 so you're not actually even seeing the intended art to its fullest.
post it here maybe?
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Ludum Dare 42

Post by PicassoCT »

Was really fun.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Ludum Dare 42

Post by gajop »

hokomoko wrote: 14 Aug 2018, 11:40
gajop wrote: 14 Aug 2018, 07:17 so you're not actually even seeing the intended art to its fullest.
post it here maybe?
I haven't seen it either. It crashes for me on Linux and I can't open s3o to see it anyway.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Ludum Dare 42

Post by PicassoCT »

hokomoko wrote: 14 Aug 2018, 11:40
gajop wrote: 14 Aug 2018, 07:17 so you're not actually even seeing the intended art to its fullest.
post it here maybe?
Its mostly about selfilu and that bump map aproximation you can do with the reflection and selfilu map

Image
Attachments
screen00218.jpg
(595.86 KiB) Not downloaded yet
screen00213.jpg
(421.85 KiB) Not downloaded yet
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Ludum Dare 42

Post by gajop »

The results are out. I also organized all our previous entries in a table.

Generally I'm not surprised with our scores. They aren't great, but not completely awful either.
To summarize, we didn't have enough time to polish gameplay (hence the very low fun scores), while Picasso's ships looked nice so we did OK with GFX :)

This means it's also time for our Post-Mortem - these are just my views, I encourage other members to share theirs. I wrote most of this as I was working, so as not to forget it after a few weeks.

I also tend to focus on what went wrong, to organize my further development. The unordered list of complaints is as follows:
- Setting up new unit defs with Spring. There are too many assumed behaviors that usually aren't helpful. I'd prefer to have a cleaner interface.
- Changing unitdefs requires restarts which sucks and wastes time. Same thing for adding new models/textures or new script files. Trying the /reloadgame command just reveals poor naming ("Warning: We can only reload the game when it has been started from a savegame")
- Unit collision and weapon firing (colvols, scripts, unitdef categories, weapon speed, etc.) is very annoying to debug. There is very little information that can be used to figure out what's wrong. It's usually just "things aren't working" and then going through hours of trying different values until it finally clicks. We need better debug tools.

- Novice users are very likely to do `git pull` instead of `git pull --rebase`. Apparently a client-side setting `git config --global branch.autosetuprebase always` would work, but we need to figure out how to ensure they've done that setup.

- Had to patch the springcontent.sdz so it would give me a more useful error.
What I got:

Code: Select all

Engine error handling issue: gadgets.lua 215:     Spring.Log(LOG_SECTION, LOG.ERROR, 'Failed to load: ' .. basename .. '  (' .. err .. ')'):
            [f=-000001] Error: [LuaRules::RunCallInTraceback] error=2 (LUA_ERRRUN) callin=Initialize trace=[Internal Lua error: Call failure] error = 2, luagadgets/gadgets.lua, [string "luagadgets/gadgets.lua"]:215: attempt
            to concatenate local 'err' (a function value)
            stack traceback:
                [C]: in function 'Include'
                [string "LuaRules/main.lua"]:7: in main chunk
What I wanted:

Code: Select all

        [f=-000001] Error: Failed to load: unit_centeroffset.lua  (<function>)
- SpringBoard:
  • Mutator-based file conflicts. Mutator file conflicts do more harm than good. Poor default behavior. This wasted some time while I was trying to setup SpringBoard with our game in the first day.
  • Some difficulty using SpringBoard State and Command structure while developing new game features. Editor class is much easier to use. Libraries are better than frameworks and less likely to run into contraints.

- Spring crashes if I try to make it use QTPFS instead of the legacy PFS:
pathFinderSystem = 1, -- (GameData/ModRules.lua)

Code: Select all

    *** buffer overflow detected ***: /home/gajop/.spring/engine/104.0.1-616-g52f5f2b maintenance/spring terminated
    [f=-000001] [CrashHandler] Error: Aborted (SIGABRT) in spring 104.0.1-616-g52f5f2b maintenance
    [f=-000001] [CrashHandler] Error: Halted Stacktrace for Spring 104.0.1-616-g52f5f2b maintenance using libunwind:
    [f=-000001] [CrashHandler] Error:   <00>                                                                       .../spring() [0x9d13b7]  log_util_prepareSection
    [f=-000001] [CrashHandler] Error: [00]                                                                                        0x9d13b7  ??:?
    [f=-000001] [CrashHandler] Error:   <01>                                                                       .../spring() [0x9d177a]  log_util_prepareSection
    [f=-000001] [CrashHandler] Error: [01]                                                                                        0x9d177a  ??:?
    [f=-000001] [CrashHandler] Error:   <02>                              /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890) [0x7f2ec9638890]  __restore_rt
    [f=-000001] [CrashHandler] Error: [02]                                                                                         0x12890  ??:?
    [f=-000001] [CrashHandler] Error:   <03> /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51 (discriminator 3)  __GI_raise
    [f=-000001] [CrashHandler] Error: [03]                                                                                         0x3ee97  /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51 (discriminator 3)
    [f=-000001] [CrashHandler] Error:   <04>                                              /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81  __GI_abort
    [f=-000001] [CrashHandler] Error: [04]                                                                                         0x40801  /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81
    [f=-000001] [CrashHandler] Error:   <05>                        /build/glibc-OTsEL5/glibc-2.27/libio/../sysdeps/posix/libc_fatal.c:181  __libc_message
    [f=-000001] [CrashHandler] Error: [05]                                                                                         0x89897  /build/glibc-OTsEL5/glibc-2.27/libio/../sysdeps/posix/libc_fatal.c:181
    [f=-000001] [CrashHandler] Error:   <06>                      /build/glibc-OTsEL5/glibc-2.27/debug/fortify_fail.c:33 (discriminator 8)  __GI___fortify_fail_abort
    [f=-000001] [CrashHandler] Error: [06]                                                                                        0x134cff  /build/glibc-OTsEL5/glibc-2.27/debug/fortify_fail.c:33 (discriminator 8)
    [f=-000001] [CrashHandler] Error:   <07>                                   /lib/x86_64-linux-gnu/libc.so.6(+0x134d21) [0x7f2ec80dad21]  __fortify_fail
    [f=-000001] [CrashHandler] Error: [07]                                                                                        0x134d21  ??:?
    [f=-000001] [CrashHandler] Error:   <08>            /build/glibc-OTsEL5/glibc-2.27/debug/../sysdeps/unix/sysv/linux/readonly-area.c:31  __readonly_area
    [f=-000001] [CrashHandler] Error: [08]                                                                                        0x132a10  /build/glibc-OTsEL5/glibc-2.27/debug/../sysdeps/unix/sysv/linux/readonly-area.c:31
    [f=-000001] [CrashHandler] Error:   <09>                                        /build/glibc-OTsEL5/glibc-2.27/debug/vsprintf_chk.c:31  __sprintf_chk
    [f=-000001] [CrashHandler] Error: [09]                                                                                        0x131f29  /build/glibc-OTsEL5/glibc-2.27/debug/vsprintf_chk.c:31
    [f=-000001] [CrashHandler] Error:   <10>                                             /build/glibc-OTsEL5/glibc-2.27/libio/genops.c:417  __GI__IO_default_xsputn
    [f=-000001] [CrashHandler] Error: [10]                                                                                         0x8e494  /build/glibc-OTsEL5/glibc-2.27/libio/genops.c:417
    [f=-000001] [CrashHandler] Error:   <11>                                   /build/glibc-OTsEL5/glibc-2.27/stdio-common/vfprintf.c:1643  _IO_vfprintf_internal
    [f=-000001] [CrashHandler] Error: [11]                                                                                         0x5cfeb  /build/glibc-OTsEL5/glibc-2.27/stdio-common/vfprintf.c:1643
    [f=-000001] [CrashHandler] Error:   <12>                                        /build/glibc-OTsEL5/glibc-2.27/debug/vsprintf_chk.c:84  ___vsprintf_chk
    [f=-000001] [CrashHandler] Error: [12]                                                                                        0x131fcb  /build/glibc-OTsEL5/glibc-2.27/debug/vsprintf_chk.c:84
    [f=-000001] [CrashHandler] Error:   <13>                                         /build/glibc-OTsEL5/glibc-2.27/debug/sprintf_chk.c:35  ___sprintf_chk
    [f=-000001] [CrashHandler] Error: [13]                                                                                        0x131efa  /build/glibc-OTsEL5/glibc-2.27/debug/sprintf_chk.c:35
    [f=-000001] [CrashHandler] Error:   <14>                                                                       .../spring() [0xe11aa0]  std::basic_streambuf<wchar_t, std::char_traits<wchar_t> >::epptr() const
    [f=-000001] [CrashHandler] Error: [14]                                                                                        0xe11aa0  ??:?
    [f=-000001] [CrashHandler] Error:   <15>                                                                       .../spring() [0xe13ce2]  std::basic_streambuf<wchar_t, std::char_traits<wchar_t> >::epptr() const
    [f=-000001] [CrashHandler] Error: [15]                                                                                        0xe13ce2  ??:?
    [f=-000001] [CrashHandler] Error:   <16>                                                                       .../spring() [0xfb66b0]  std::this_thread::__sleep_for(std::chrono::duration<long, std::ratio<1l, 1l> >, std::chrono::duration<long, std::ratio<1l, 1000000000l> >)
    [f=-000001] [CrashHandler] Error:   <16>                                                                                      0xfb66b0  ??:?
    [f=-000001] [CrashHandler] Error:   <17>                                      /build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463  start_thread
    [f=-000001] [CrashHandler] Error:   <17>                                                                                        0x76db  /build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463
    [f=-000001] [CrashHandler] Error:   <18>              /build/glibc-OTsEL5/glibc-2.27/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:97  clone
    [f=-000001] [CrashHandler] Error:   <18>                                                                                      0x12188f  /build/glibc-OTsEL5/glibc-2.27/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:97
- libcurl4/libcurl3 nonsense. If I want to run a Spring maintenance version I have to forget about obs-studio, R and most importantly cmake. Switch to full static libs and a package manager so we can actually manage our packages.

PS: The next event is already scheduled for Friday November 30th to Monday December 3rd, but for your local date and time see the countdown clock in the top right of the homepage.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Ludum Dare 42

Post by PicassoCT »

Would like to participate in the next one.
My question there- could we do innovation, not on the gameplay (just a miniature-standard rts) and more on the control side for a LD-Game?
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Ludum Dare 42

Post by gajop »

PicassoCT wrote: 09 Sep 2018, 11:00 Would like to participate in the next one.
Great
PicassoCT wrote: 09 Sep 2018, 11:00 My question there- could we do innovation, not on the gameplay (just a miniature-standard rts) and more on the control side for a LD-Game?
I don't understand this. You want to focus on innovation rather than gameplay? I also don't get the "control side" part.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Ludum Dare 42

Post by PicassoCT »

I would like to take a pre-existing User Interface (Evo-RTS or Zero-K or Cursed) and innovate on that during the jam.
As in allow for a more efficient form of controll, allowing for a easier automation of giving certain commands.
I think this part of gameplay design is actually quite neglected by our community.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: Ludum Dare 42

Post by gajop »

PicassoCT wrote: 09 Sep 2018, 11:23 I would like to take a pre-existing User Interface (Evo-RTS or Zero-K or Cursed) and innovate on that during the jam.
As in allow for a more efficient form of controll, allowing for a easier automation of giving certain commands.
I think this part of gameplay design is actually quite neglected by our community.
If you can think useful general purpose UI (RTS or otherwise), feel free to make PRs here: https://github.com/SpringCabal/SkeletonGame . Code needs to be readable and shouldn't be huge (taking entire ZK's UI would probably be too much, and give us little flexibility).

PS: There's no guarantee that we'd be making an RTS, and constraining ourselves to it only reduces innovation.
Post Reply

Return to “Ludum Dare”