6 ms·

Wondering whether an LLM could be able to port a game like this instantly.

DonHopkins 2y ago
Good question, please don't downvote -- there's an interesting discussion to be had about that! The best approach is to use it like any other tool, and not expect it to do all the hard work for you, just relieve you of a lot of tedious work, and help you learn how to be a better programmer yourself, not replace you. There's no such thing as a free lunch, but some lunches are tastier and more nutritious and less expensive than others. I've been using ChatGPT to develop it, and it's helped a lot, and takes a great deal of iteration and guidance, but it's anything but instant. LLMs won't replace programmers, but programmers with LLMs will replace programmers without LLMs. Here's an example of how it was helpful in simply explaining the documentation and best practices of tools like Emscripten and Embind, getting the makefile to work, analyzing the code, categorizing methods and instance variables as private and public (to be wrapped by embind), generating the boilerplate Embind declarations, and writing the documentation through a back-and-forth discussion of goals and requirements, and acting like a glorified grep that actually understands the code syntax and accepts English queries instead of obscure command line arguments. The comments at the top (included below) were mostly written by ChatGPT in response to me writing the strategy, telling it in detail what I wanted to do, describing my goals, and how I wanted it to work, with lots of iterating and refining and hand editing: https://github.com/SimHacker/MicropolisCore/blob/main/MicropolisEngine/src/emscripten.cpp https://github.com/SimHacker/MicropolisCore/blob/main/Microp... The process was anything but automatic or instant -- in total it took about 33 years (and counting, I'm not done yet). I had to guide ChatGPT a lot, drawing from my previous experience porting the Mac version of SimCity to HyperLook on the NeWS window system in 1991, and other platforms later on. At the time I considered using a Mac compatibility library for X11, but that would have resulted in a terrible klunky user interface, could not have taken advantages of the Sun Workstation Unix programming and user interface environment (networking, big screen, better window management, pie menus and other nice user interface components, scalable color PostScript graphics and fonts, using native file formats for resources, audio mixing, lots of computing power to animate fast and zoom into the map, run the simulation super fast by skipping screen updates, profiling and optimizing the code, etc), tied the game to a proprietary library that is long obsolete, and would have only supported X11, not NeWS. For a game like SimCity, it was well worth throwing away the Mac UI, cleaning up the simulator to be independent of the UI, and writing a new high quality UI for HyperLook in NeWS (then later another for TCL/Tk in X11). Porting it to NeWS required separating the simulator from the user interface and defining a clean network API and shared memory raster animation library, rewriting the user interface in PostScript, and defining a messaging protocol between the simulator and UI. Then a few years later I ported that to TCL/Tk on X11, refactoring the simulator/UI messaging interface into TCL extensions. TCL/Tk made it possible to develop a networked multi-player version of SimCity. X11 SimCity Demo: https://www.youtube.com/watch?v=Jvi98wVUmQA https://www.youtube.com/watch?v=Jvi98wVUmQA Multi Player SimCityNet for X11 on Linux: https://www.youtube.com/watch?v=_fVl4dGwUrA https://www.youtube.com/watch?v=_fVl4dGwUrA TCL Doc: https://github.com/SimHacker/MicropolisCore/blob/main/notes/DocTCL.txt https://github.com/SimHacker/MicropolisCore/blob/main/notes/... Callbacks: https://github.com/SimHacker/MicropolisCore/blob/main/notes/CALLBACKS.txt https://github.com/SimHacker/MicropolisCore/blob/main/notes/... A couple of decades later, we made SimCity open source, released the TCL/Tk/X11 version for the OLPC and Linux, then I cleaned up and overhauled the simulator code into C++, and used SWIG to define the API and a callback mechanism, so I could plug it into Python. Micropolis Core: https://github.com/SimHacker/micropolis/tree/master/MicropolisCore https://github.com/SimHacker/micropolis/tree/master/Micropol... Refactoring the code as C++ really helped modularize and organize it, made it easy to use doxygen to generate documentation, and much easier to wrap and port to different platforms. Doxygen documentation (current): https://micropolisweb.com/doc/ https://micropolisweb.com/doc/ Development Plan (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/DevelopmentPlan.md https://github.com/SimHacker/MicropolisCore/blob/main/notes/... OLPC Plan (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/PLAN.txt https://github.com/SimHacker/MicropolisCore/blob/main/notes/... To Do (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/TODO.txt https://github.com/SimHacker/MicropolisCore/blob/main/notes/... User Interface Plan (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/UserInterfacePlan.txt https://github.com/SimHacker/MicropolisCore/blob/main/notes/... OLPC Notes (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/OLPC-notes.txt https://github.com/SimHacker/MicropolisCore/blob/main/notes/... I implemented a couple of Python user interfaces, including a desktop based PyGTK/Cairo/X11 interface, and a web based TurboGears/AMF/OpenLaszlo/Flash client/server interface. Micropolis Online (SimCity) Web Demo (old): https://www.youtube.com/watch?v=8snnqQSI0GE https://www.youtube.com/watch?v=8snnqQSI0GE Bil Simser used SWIG it integrate the simulator engine with C#. (SWIG's point is to integrate C++ code into many different scripting languages, not just Python.) C# Micropolis: https://github.com/SimHacker/micropolis/tree/master/MicropolisCore/src/csMicropolis https://github.com/SimHacker/micropolis/tree/master/Micropol... After all that work, and writing and executing on the design documents linked above, I had a pretty good idea how to prompt ChatGPT to write a design for the Emscripten/Embind API, and it was helpful for writing the boilerplate code, and validating the design, but not so much for coming up with the design in the first place. Beyond refactoring and wrapping the API, ChatGPT has also been extremely useful for learning the intricacies and best practices of TypeScript, SvelteKit, node, WebGL, canvas, CSS, HTML, etc, for developing the user interface. //////////////////////////////////////////////////////////////////////// // This file uses emscripten's embind to bind C++ classes, // C structures, functions, enums, and contents into JavaScript, // so you can even subclass C++ classes in JavaScript, // for implementing plugins and user interfaces. // // Wrapping the entire Micropolis class from the Micropolis (open-source // version of SimCity) code into Emscripten for JavaScript access is a // large and complex task, mainly due to the size and complexity of the // class. The class encompasses almost every aspect of the simulation, // including map generation, simulation logic, user interface // interactions, and more. // // Strategy for Wrapping // // 1. Core Simulation Logic: Focus on the core simulation aspects, such // as the methods to run the simulation, update game states, and handle // user inputs (like building tools and disaster simulations). This is // crucial for any gameplay functionality. // // 2. Memory and Performance Considerations: JavaScript and WebAssembly // run in a browser context, which can have memory limitations and // performance constraints. Carefully manage memory allocation, // especially when dealing with the game's map and various buffers. // // 3. Direct Memory Access: Provide JavaScript access to critical game // data structures like the map buffer for efficient reading and // writing. This can be done using Emscripten's heap access functions // (HEAP8, HEAP16, HEAP32, etc.). // // 4. User Interface and Rendering: This part might not be necessary to // wrap, as modern web technologies (HTML, CSS, WebGL) can be used for // UI. However, providing some hooks for game state (like score, budget, // etc.) to JavaScript might be helpful. // // 5. Callbacks and Interactivity: Ensure that key game events and // callbacks are exposed to JavaScript, allowing for interactive and // responsive gameplay. // // 6. Optimizations: Where possible, optimize C++ code for WebAssembly, // focusing on critical paths in the simulation loop. // // Decisions and Explanations // // - Excluded Elements: // // - Low-level rendering or platform-specific code, as this can be // handled more efficiently with web technologies. // // - Parts of the code that handle file I/O directly, as file access // in a web context is typically handled differently (e.g., using // browser APIs or server-side support). // // - Any networking or multiplayer code, as web-based // implementations would differ significantly from desktop-based // network code. // // - Included Elements: // // - Core game mechanics, such as map generation, zone simulation // (residential, commercial, industrial), disaster simulation, and // basic utilities. // // - Game state management, including budgeting, scoring, and city // evaluation. // // - Direct memory access to critical structures like the map // buffer, allowing efficient manipulation from JavaScript. // // - Essential callbacks and event handling mechanisms to ensure // interactivity. // // Conclusion // // Given the complexity and size of the Micropolis class, wrapping the // entire class directly is impractical. However, focusing on key areas // essential for gameplay and providing efficient interfaces for // critical data structures can create a functional and interactive city // simulation in a web context. Further optimizations and adjustments // would likely be needed based on testing and specific requirements of // the web implementation. // // Implementation Notes // // The enum_, class_, constructor, function, and property functions // from the emscripten namespace are used to specify how C++ // constructs should be exposed to JavaScript. You can use these to // control which parts of your code are accessible and how they should // be used from JavaScript. // // I've made some assumptions here: // // The types MapValue and MapTile are simple types (like integers or // floats). If they are complex types, they would need their own // bindings. // // I'm assuming that the copy constructor and copy assignment // operator for the Position class are correctly implemented. If // they aren't, then the Position object may not behave as expected // in JavaScript. // // Micropolis Binding Design // // The Micropolis interface organizes the Micropolis class header into // categories of functions that are relevant for interaction with the // JavaScript user interface, scripts, or plugins. The aim is to expose // functions that could help in monitoring and controlling game state // effectively. //
- deleted 2y ago
  [deleted]
- JKCalhoun 2y ago
  > LLMs won't replace programmers, but programmers with LLMs will replace programmers without LLMs. I like that. I would darken it a bit though: "LLMs won't replace programmers, but a programmer with an LLMs might replace two programmers without LLMs."
  - cubefox 2y ago
    A little bit darker: "LLMs won't replace programmers, but the LLM successors will."
    - DonHopkins 2y ago
      Agreed -- I purposefully avoided saying "AI" instead of "LLMs" because LLMs aren't all that's required for AI to replace programmers. And my guess is that it will be a long time until AI replaces programmers.
  - zamadatix 2y ago
    You could say the same thing about every improvement to programming workflows (version control systems, context aware editors, CI/CD, test frameworks, better languages/language improvements, package managers, Q&A repositories like StackOverflow, build systems, and so on). Whether you really consider increasing individual output dark/bad/ominous is up to you but if you apply that outlook historically you'll have had decades of negative outlook on the thought the job is going to become scarce while the number of high paying software jobs continued to increase despite efficiency improvements. In a more direct way: Making one programmer able to output what two programmers can do is almost always a gain for everyone involved. Making one programmer able to output what 10,000 programmers can do is a sign the field is being replaced. I don't think we'll get anywhere near concerns of the latter with LLMs.

Good question, please don't downvote -- there's an interesting discussion to be had about that! The best approach is to use it like any other tool, and not expect it to do all the hard work for you, just relieve you of a lot of tedious work, and help you learn how to be a better programmer yourself, not replace you. There's no such thing as a free lunch, but some lunches are tastier and more nutritious and less expensive than others. I've been using ChatGPT to develop it, and it's helped a lot, and takes a great deal of iteration and guidance, but it's anything but instant. LLMs won't replace programmers, but programmers with LLMs will replace programmers without LLMs. Here's an example of how it was helpful in simply explaining the documentation and best practices of tools like Emscripten and Embind, getting the makefile to work, analyzing the code, categorizing methods and instance variables as private and public (to be wrapped by embind), generating the boilerplate Embind declarations, and writing the documentation through a back-and-forth discussion of goals and requirements, and acting like a glorified grep that actually understands the code syntax and accepts English queries instead of obscure command line arguments. The comments at the top (included below) were mostly written by ChatGPT in response to me writing the strategy, telling it in detail what I wanted to do, describing my goals, and how I wanted it to work, with lots of iterating and refining and hand editing: https://github.com/SimHacker/MicropolisCore/blob/main/MicropolisEngine/src/emscripten.cpp https://github.com/SimHacker/MicropolisCore/blob/main/Microp... The process was anything but automatic or instant -- in total it took about 33 years (and counting, I'm not done yet). I had to guide ChatGPT a lot, drawing from my previous experience porting the Mac version of SimCity to HyperLook on the NeWS window system in 1991, and other platforms later on. At the time I considered using a Mac compatibility library for X11, but that would have resulted in a terrible klunky user interface, could not have taken advantages of the Sun Workstation Unix programming and user interface environment (networking, big screen, better window management, pie menus and other nice user interface components, scalable color PostScript graphics and fonts, using native file formats for resources, audio mixing, lots of computing power to animate fast and zoom into the map, run the simulation super fast by skipping screen updates, profiling and optimizing the code, etc), tied the game to a proprietary library that is long obsolete, and would have only supported X11, not NeWS. For a game like SimCity, it was well worth throwing away the Mac UI, cleaning up the simulator to be independent of the UI, and writing a new high quality UI for HyperLook in NeWS (then later another for TCL/Tk in X11). Porting it to NeWS required separating the simulator from the user interface and defining a clean network API and shared memory raster animation library, rewriting the user interface in PostScript, and defining a messaging protocol between the simulator and UI. Then a few years later I ported that to TCL/Tk on X11, refactoring the simulator/UI messaging interface into TCL extensions. TCL/Tk made it possible to develop a networked multi-player version of SimCity. X11 SimCity Demo: https://www.youtube.com/watch?v=Jvi98wVUmQA https://www.youtube.com/watch?v=Jvi98wVUmQA Multi Player SimCityNet for X11 on Linux: https://www.youtube.com/watch?v=_fVl4dGwUrA https://www.youtube.com/watch?v=_fVl4dGwUrA TCL Doc: https://github.com/SimHacker/MicropolisCore/blob/main/notes/DocTCL.txt https://github.com/SimHacker/MicropolisCore/blob/main/notes/... Callbacks: https://github.com/SimHacker/MicropolisCore/blob/main/notes/CALLBACKS.txt https://github.com/SimHacker/MicropolisCore/blob/main/notes/... A couple of decades later, we made SimCity open source, released the TCL/Tk/X11 version for the OLPC and Linux, then I cleaned up and overhauled the simulator code into C++, and used SWIG to define the API and a callback mechanism, so I could plug it into Python. Micropolis Core: https://github.com/SimHacker/micropolis/tree/master/MicropolisCore https://github.com/SimHacker/micropolis/tree/master/Micropol... Refactoring the code as C++ really helped modularize and organize it, made it easy to use doxygen to generate documentation, and much easier to wrap and port to different platforms. Doxygen documentation (current): https://micropolisweb.com/doc/ https://micropolisweb.com/doc/ Development Plan (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/DevelopmentPlan.md https://github.com/SimHacker/MicropolisCore/blob/main/notes/... OLPC Plan (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/PLAN.txt https://github.com/SimHacker/MicropolisCore/blob/main/notes/... To Do (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/TODO.txt https://github.com/SimHacker/MicropolisCore/blob/main/notes/... User Interface Plan (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/UserInterfacePlan.txt https://github.com/SimHacker/MicropolisCore/blob/main/notes/... OLPC Notes (old): https://github.com/SimHacker/MicropolisCore/blob/main/notes/OLPC-notes.txt https://github.com/SimHacker/MicropolisCore/blob/main/notes/... I implemented a couple of Python user interfaces, including a desktop based PyGTK/Cairo/X11 interface, and a web based TurboGears/AMF/OpenLaszlo/Flash client/server interface. Micropolis Online (SimCity) Web Demo (old): https://www.youtube.com/watch?v=8snnqQSI0GE https://www.youtube.com/watch?v=8snnqQSI0GE Bil Simser used SWIG it integrate the simulator engine with C#. (SWIG's point is to integrate C++ code into many different scripting languages, not just Python.) C# Micropolis: https://github.com/SimHacker/micropolis/tree/master/MicropolisCore/src/csMicropolis https://github.com/SimHacker/micropolis/tree/master/Micropol... After all that work, and writing and executing on the design documents linked above, I had a pretty good idea how to prompt ChatGPT to write a design for the Emscripten/Embind API, and it was helpful for writing the boilerplate code, and validating the design, but not so much for coming up with the design in the first place. Beyond refactoring and wrapping the API, ChatGPT has also been extremely useful for learning the intricacies and best practices of TypeScript, SvelteKit, node, WebGL, canvas, CSS, HTML, etc, for developing the user interface. //////////////////////////////////////////////////////////////////////// // This file uses emscripten's embind to bind C++ classes, // C structures, functions, enums, and contents into JavaScript, // so you can even subclass C++ classes in JavaScript, // for implementing plugins and user interfaces. // // Wrapping the entire Micropolis class from the Micropolis (open-source // version of SimCity) code into Emscripten for JavaScript access is a // large and complex task, mainly due to the size and complexity of the // class. The class encompasses almost every aspect of the simulation, // including map generation, simulation logic, user interface // interactions, and more. // // Strategy for Wrapping // // 1. Core Simulation Logic: Focus on the core simulation aspects, such // as the methods to run the simulation, update game states, and handle // user inputs (like building tools and disaster simulations). This is // crucial for any gameplay functionality. // // 2. Memory and Performance Considerations: JavaScript and WebAssembly // run in a browser context, which can have memory limitations and // performance constraints. Carefully manage memory allocation, // especially when dealing with the game's map and various buffers. // // 3. Direct Memory Access: Provide JavaScript access to critical game // data structures like the map buffer for efficient reading and // writing. This can be done using Emscripten's heap access functions // (HEAP8, HEAP16, HEAP32, etc.). // // 4. User Interface and Rendering: This part might not be necessary to // wrap, as modern web technologies (HTML, CSS, WebGL) can be used for // UI. However, providing some hooks for game state (like score, budget, // etc.) to JavaScript might be helpful. // // 5. Callbacks and Interactivity: Ensure that key game events and // callbacks are exposed to JavaScript, allowing for interactive and // responsive gameplay. // // 6. Optimizations: Where possible, optimize C++ code for WebAssembly, // focusing on critical paths in the simulation loop. // // Decisions and Explanations // // - Excluded Elements: // // - Low-level rendering or platform-specific code, as this can be // handled more efficiently with web technologies. // // - Parts of the code that handle file I/O directly, as file access // in a web context is typically handled differently (e.g., using // browser APIs or server-side support). // // - Any networking or multiplayer code, as web-based // implementations would differ significantly from desktop-based // network code. // // - Included Elements: // // - Core game mechanics, such as map generation, zone simulation // (residential, commercial, industrial), disaster simulation, and // basic utilities. // // - Game state management, including budgeting, scoring, and city // evaluation. // // - Direct memory access to critical structures like the map // buffer, allowing efficient manipulation from JavaScript. // // - Essential callbacks and event handling mechanisms to ensure // interactivity. // // Conclusion // // Given the complexity and size of the Micropolis class, wrapping the // entire class directly is impractical. However, focusing on key areas // essential for gameplay and providing efficient interfaces for // critical data structures can create a functional and interactive city // simulation in a web context. Further optimizations and adjustments // would likely be needed based on testing and specific requirements of // the web implementation. // // Implementation Notes // // The enum_, class_, constructor, function, and property functions // from the emscripten namespace are used to specify how C++ // constructs should be exposed to JavaScript. You can use these to // control which parts of your code are accessible and how they should // be used from JavaScript. // // I've made some assumptions here: // // The types MapValue and MapTile are simple types (like integers or // floats). If they are complex types, they would need their own // bindings. // // I'm assuming that the copy constructor and copy assignment // operator for the Position class are correctly implemented. If // they aren't, then the Position object may not behave as expected // in JavaScript. // // Micropolis Binding Design // // The Micropolis interface organizes the Micropolis class header into // categories of functions that are relevant for interaction with the // JavaScript user interface, scripts, or plugins. The aim is to expose // functions that could help in monitoring and controlling game state // effectively. //

deleted 2y ago
[deleted]
JKCalhoun 2y ago
> LLMs won't replace programmers, but programmers with LLMs will replace programmers without LLMs. I like that. I would darken it a bit though: "LLMs won't replace programmers, but a programmer with an LLMs might replace two programmers without LLMs."
- cubefox 2y ago
  A little bit darker: "LLMs won't replace programmers, but the LLM successors will."
  - DonHopkins 2y ago
    Agreed -- I purposefully avoided saying "AI" instead of "LLMs" because LLMs aren't all that's required for AI to replace programmers. And my guess is that it will be a long time until AI replaces programmers.
- zamadatix 2y ago
  You could say the same thing about every improvement to programming workflows (version control systems, context aware editors, CI/CD, test frameworks, better languages/language improvements, package managers, Q&A repositories like StackOverflow, build systems, and so on). Whether you really consider increasing individual output dark/bad/ominous is up to you but if you apply that outlook historically you'll have had decades of negative outlook on the thought the job is going to become scarce while the number of high paying software jobs continued to increase despite efficiency improvements. In a more direct way: Making one programmer able to output what two programmers can do is almost always a gain for everyone involved. Making one programmer able to output what 10,000 programmers can do is a sign the field is being replaced. I don't think we'll get anywhere near concerns of the latter with LLMs.