{"author_link":"\/users\/twothumb","author_name":"twothumb","author_uid":"twothumb","comments":[],"epoch":1664482416,"event":"LD51","format":"md","ldjam_node_id":301522,"likes":6,"metadata":{"p_key":"166755","p_author":"twothumb","p_authorkey":"1301359","p_urlkey":"393321","p_title":"Ludum Dare Hard Mode","p_cat":"LDJam ","p_event":"LD51","p_time":"1664482416","p_likes":"6","p_comments":"0","p_status":"WAYBACK","us_key":"1301359","us_name":"twothumb","us_username":"twothumb","event_start":"1664496000","event_key":"114","event_name":"Ludum Dare 51"},"node":{"_collation":{"body_sanitizer":"TextUtils::SanitizeHTML via existing importer","event":"LD51","removed_author":false},"_superparent":296586,"_trust":0,"author":301359,"body":"I'm looking into creating a native game engine from scratch in C and open-sourcing any tools developed along the way.\n\n## Development Strategy\nDevelopment will occur in two repositories: code (open-source), team (closed-source).\n- code repository: C modules that might be open sourced\n- team repository: everything else needed to plan & publish an actual game\n- code: main branch: released \\ open-sourced modules\n- code: dev branch: unreleased \\ experimental modules\n- code: staging branch : modules picked from dev to merge to main to release\n\nSince the team repository is closed source it will be okay to store todo lists, drafts, and screenshots in the main branch so that they are not lost in a discarded topic or feature branch.\n\n## Embedding Files in Comments\n\nC modules will have additional files embedded in comments.\n\nIn the following example there is a `test.c` unit-test program and `test.sh` runner  embedded in the `mylib.h` header library:\n\n```\n\/\/ mylib.h - useful functions for video games\n#pragma once\n#include <stdint.h>\ntypedef uint8_t U8;\ntypedef uint16_t U16;\n#define U8_MAX UINT8_MAX\n#define U16_MAX UINT16_MAX\n#define def static inline\n\n\/\/:test.sh cc -Wall -Wextra -Wpedantic -O3 test.c -o test; .\/test\n\/*:test.c\n#include \"mylib.h\"\n#include <assert.h>\n#include <stdio.h>\nint main(){\n*\/\n\n\/\/ sadd : saturated addition\ndef U8  sadd_u8(U8 a, U8 b){ U8 c=a+b; return c < a ? U8_MAX : c; }\n\/\/:test.c assert(sadd_u8(128,128) == 255);\ndef U16 sadd_u16(U16 a, U16 b){ U16 c=a+b; return c < a ? U16_MAX : c; }\n\/\/:test.c assert(sadd_u16(32768,32768) == 65535);\n\n\/*:test.c\n  printf(\"okay.\\n\");\n  return 0;\n}\n*\/\n```\n\nNote: LDJam.com makes comments hard to read (very low contrast), but they are easy to see in my editor.\n\nA tool then copies the original file + embedded files to new directory and runs an optional command:\n\n```\ncodetool mylib.h \/tmp\/mylib\/ ls\n  mylib.h test.c test.sh\ncodetool mylib.h \/tmp\/mylib\/ bash test.sh\n  okay.\n```\n\nThis way related files for experiments can be stored, drafted, and discarded together without littering the repository.\n\n\n## Future\n\nI'm also prototyping a dependency resolver so `codetool` can copy imported modules to the output folder as well. The resolver parses dependencies from embedded comments without needing a separate folder or metadata file per unit. My hypothesis is that embedding files in comments will be useful for attaching unit tests, examples, manuals, build scripts, and shaders to single-file modules since C has no default package manager. Instead of embedding a `test.c` program in a `mylib.h` library, it might also be possible to embed a mock `mygame.h` library in a `game-engine.c` program. Not sure how this will play out yet.","comments":1,"comments-timestamp":"2022-09-29T20:27:12Z","created":"2022-09-29T20:07:28Z","files":[],"files-timestamp":0,"id":301522,"love":6,"love-timestamp":"2022-09-29T21:19:25Z","meta":[],"modified":"2022-09-29T21:19:25Z","name":"Ludum Dare Hard Mode","node-timestamp":"2022-09-29T20:13:36Z","parent":301360,"parents":[1,5,9,296586,301360],"path":"\/events\/ludum-dare\/51\/$301360\/ludum-dare-hard-mode","published":"2022-09-29T20:13:36Z","scope":"public","slug":"ludum-dare-hard-mode","subsubtype":"","subtype":"","type":"post","version":926847},"node_metadata":{"n_key":"301522","n_urlkey":"393321","n_parent":"301360","n_path":"\/events\/ludum-dare\/51\/$301360\/ludum-dare-hard-mode","n_slug":"ludum-dare-hard-mode","n_type":"post","n_subtype":"","n_subsubtype":"","n_author":"301359","n_created":"1664482048","n_modified":"1664486365","n_version":"926847","n_status":"WAYBACK"},"source_url":"https:\/\/ldjam.com\/events\/ludum-dare\/51\/$301360\/ludum-dare-hard-mode","text":"I'm looking into creating a native game engine from scratch in C and open-sourcing any tools developed along the way.\n\n## Development Strategy\nDevelopment will occur in two repositories: code (open-source), team (closed-source).\n- code repository: C modules that might be open sourced\n- team repository: everything else needed to plan & publish an actual game\n- code: main branch: released \\ open-sourced modules\n- code: dev branch: unreleased \\ experimental modules\n- code: staging branch : modules picked from dev to merge to main to release\n\nSince the team repository is closed source it will be okay to store todo lists, drafts, and screenshots in the main branch so that they are not lost in a discarded topic or feature branch.\n\n## Embedding Files in Comments\n\nC modules will have additional files embedded in comments.\n\nIn the following example there is a `test.c` unit-test program and `test.sh` runner  embedded in the `mylib.h` header library:\n\n```\n\/\/ mylib.h - useful functions for video games\n#pragma once\n#include <stdint.h>\ntypedef uint8_t U8;\ntypedef uint16_t U16;\n#define U8_MAX UINT8_MAX\n#define U16_MAX UINT16_MAX\n#define def static inline\n\n\/\/:test.sh cc -Wall -Wextra -Wpedantic -O3 test.c -o test; .\/test\n\/*:test.c\n#include \"mylib.h\"\n#include <assert.h>\n#include <stdio.h>\nint main(){\n*\/\n\n\/\/ sadd : saturated addition\ndef U8  sadd_u8(U8 a, U8 b){ U8 c=a+b; return c < a ? U8_MAX : c; }\n\/\/:test.c assert(sadd_u8(128,128) == 255);\ndef U16 sadd_u16(U16 a, U16 b){ U16 c=a+b; return c < a ? U16_MAX : c; }\n\/\/:test.c assert(sadd_u16(32768,32768) == 65535);\n\n\/*:test.c\n  printf(\"okay.\\n\");\n  return 0;\n}\n*\/\n```\n\nNote: LDJam.com makes comments hard to read (very low contrast), but they are easy to see in my editor.\n\nA tool then copies the original file + embedded files to new directory and runs an optional command:\n\n```\ncodetool mylib.h \/tmp\/mylib\/ ls\n  mylib.h test.c test.sh\ncodetool mylib.h \/tmp\/mylib\/ bash test.sh\n  okay.\n```\n\nThis way related files for experiments can be stored, drafted, and discarded together without littering the repository.\n\n\n## Future\n\nI'm also prototyping a dependency resolver so `codetool` can copy imported modules to the output folder as well. The resolver parses dependencies from embedded comments without needing a separate folder or metadata file per unit. My hypothesis is that embedding files in comments will be useful for attaching unit tests, examples, manuals, build scripts, and shaders to single-file modules since C has no default package manager. Instead of embedding a `test.c` program in a `mylib.h` library, it might also be possible to embed a mock `mygame.h` library in a `game-engine.c` program. Not sure how this will play out yet.","title":"Ludum Dare Hard Mode","wayback_source":[]}