Let's pick some old classic game, reverse engineer the data formats and game rules and write an open source engine for it from scratch. Some games from 1990s are simple enough that we could have a playable prototype by the end of the week.
Write which games you'd like to hack on in the comments. Don't forget to check e.g. on Open Source Game Clones, Github and SourceForge whether the game is ported already.
Hack Week 24 - Master of Orion II: Battle at Antares & Chaos Overlords
Work on Master of Orion II continues but we can hack more than one game. Chaos Overlords is a dystopian, lighthearted, cyberpunk turn-based strategy game originally released in 1996 for Windows 95 and Mac OS. The player takes on the role of a Chaos Overlord, attempting to control a city. Gameplay involves hiring mercenary gangs and deploying them on an 8-by-8 grid of city sectors to generate income, occupy sectors and take over the city.
How to ~~install & play~~ observe the decompilation progress:
- Clone the Git repository
- A playable reimplementation does not exist yet, but when it does, it will be linked in the repository mentioned above.
Further work needed:
- Analyze the remaining unknown data structures, most of which are related to the AI.
- Decompile the AI completely. The strong AI is part of the appeal of the game. It cannot be left out.
- Reimplement the game.
Hack Week 20, 21, 22 & 23 - Master of Orion II: Battle at Antares
Master of Orion II is one of the greatest turn-based 4X games of the 1990s. Explore the galaxy, colonize planets, research new technologies, fight space monsters and alien empires and in the end, become the ruler of the galaxy one way or another.
How to install & play:
- Clone the Git repository
- Run
./bootstrap; ./configure; make && make install - Copy all *.LBX files from the original Master of Orion II to the installation data directory (
/usr/local/share/openorion2by default) - Run
openorion2
Further work needed:
- Analyze the rest of the original savegame format and a few remaining data files.
- Implement most of the game. The open source engine currently supports only loading saved games from the original version and viewing the galaxy map, fleet management and list of known planets.
Hack Week 19 - Signus: The Artifact Wars
Signus is a Czech turn-based strategy game similar to Panzer General or Battle Isle series. Originally published in 1998 and open-sourced by the original developers in 2003.
How to install & play:
- Clone the Git repository
- Run
./bootstrap; ./configure; make && make installin bothsignusandsignus-datadirectories. - Run
signus
Further work needed:
- Create openSUSE package
- Implement full support for original game data (the open source version uses slightly different data file contents but original game data can be converted using a script).
Looking for hackers with the skills:
This project is part of:
Hack Week 19 Hack Week 20 Hack Week 21 Hack Week 22 Hack Week 23 Hack Week 24
Activity
Comments
-
almost 5 years ago by jkohoutek | Reply
It would be hard to find a game with expired copyright. But I have some recommendations: Hungry Horace Colony
-
almost 5 years ago by MDoucha | Reply
Copyright status of the original game doesn't matter. We just can't bundle the original game data with the open source engine and if we need to disassemble the original EXE files, we'll need to do a "clean room" implementation of that part of the code. (One person analyzes the disassembled code and writes a spec, another person implements the spec without looking at the disassembled code.)
The games I had in mind were something like Jagged Alliance, Battle Isle 3, Polda, etc.
-
-
-
almost 4 years ago by MDoucha | Reply
My top pick this year: Petroglyph has released the original sources of Command & Conquer and Red Alert as mod SDK under GPLv3. Let's write an SDL front-end for it and make the classic C&C games fully playable again. (Yes, I know OpenRA exists but I'm not installing the Mono bloatware to play it. The original game used to run smoothly on Pentium 90 with 16MB of RAM dammit!)
-
almost 4 years ago by MDoucha | Reply
My second pick: Jagged Alliance 1. No sources are available AFAIK, we'll have to reverse engineer it from scratch. We might find some reused AI and game mechanics code in Jagged Alliance 2 sources though.
-
almost 4 years ago by MDoucha | Reply
My third pick: Master of Orion 2. Two of our colleagues have tried to remake the engine in Python a while ago but I'd prefer to start from scratch in C++.
-
-
-
almost 4 years ago by mlnoga | Reply
Nice one. I would love to see Battle of Britain - Their Finest Hour resurrected from 286 days, especially the campaign mode. Or the Wing Commander series. But these graphically oriented games are probably not doable.
Strategy games might be more within reach. I made a start on the logic of Capitalism in Golang several years ago. Basis was observed game behavior. I might still have the code lying around somewhere. Paired with a web UI, it might make a nice multiplayer (e.g. the Rancher stack with vue.js).
-
almost 4 years ago by MDoucha | Reply
Thanks for the tip, I'll definitely keep Capitalism in mind for the next year. There already is a fan remake of one of the Wing Commander games: Privateer: Wing Commander Universe. Though I don't know whether it's playable and how closely it resembles the original Privateer.
-
-
almost 4 years ago by mlnoga | Reply
Also check out these gaming-themed ideas: Game for SUSECon, Workadventu.re.
-
almost 3 years ago by MDoucha | Reply
My top pick this year is obviously to continue working on Master of Orion II. We've started from scratch during the last Hack Week so most of the work was about internal code infrastructure and reverse engineering with very little to show at the end. But that work is now mostly done and we can start making some big visible progress this year.
- Easy tasks: implement planet list screen, colony list screen, fleet list screen
- Medium tasks: implement colony screen, officer pool screen, diplomacy screen, audio subsystem
- Hard tasks: reverse engineer ship design, research or the rest of savegame format, implement help/info screen, find palettes for space combat sprites
-
almost 3 years ago by MDoucha | Reply
My second pick this year is to select one existing open source game project from Open Source Game Clones database and contribute to it. Something semi-playable would probably be the best choice but the only real restrictions are the project licence, programming language and access to the original game files. Note that in this case we have to pick a project at least a week before the Hack Week starts so that we can look around the codebase beforehand. I don't want to spend the whole Hack Week just looking for actual issues to fix or missing features to implement.
I also have a third pick but I'll need to resolve some potential licence issues with the original developers before I say more. Stay tuned.
-
-
about 2 years ago by MDoucha | Reply
My top pick for Hack Week 22 is once again to continue working on Master of Orion II. We've implemented planet list and fleet list screens during the last Hack Week and both are almost feature complete except for actions that change the gamestate (which is intentional for now).
- Easy tasks: implement colony list screen, officer pool screen, diplomacy screen or fleet window (on galaxy screen)
- Medium tasks: implement colony screen, audio subsystem, ship detail window, reverse engineer ship design or research
- Hard tasks: reverse engineer the rest of savegame format, implement help/info screen or star system window (on galaxy screen), find palettes for space combat sprites
-
about 2 years ago by MDoucha | Reply
My second pick is to contribute fixes and improvements to OpenGothic. You can pick some task from the project issue tracker or play the game over the holidays until you find some bugs/missing features you'd like to fix. My personal focus would be on improving Gothic 1 support but feel free to work on Gothic 2 as well.
-
about 2 years ago by MDoucha | Reply
My third pick is to select some game from the Open Source Game Clones database. Something semi-playable would probably be the best choice but the only real restrictions are the project licence, programming language and access to the original game files.
-
over 1 year ago by MDoucha | Reply
Just like the last time, my top pick for Hack Week 23 is to continue working on Master of Orion II. We've implemented office list screen and part of the colony list screen during Hack Week 22.
- Easy tasks: Finish colony list screen, implement diplomacy screen, research selection window, fleet window (on galaxy screen) and star system window (ditto)
- Medium tasks: implement colony screen, audio subsystem, ship detail window, colony production screen, reverse engineer ship design or planet orbit position calculations
- Hard tasks: reverse engineer the rest of savegame format, implement help/info screen, find palettes for space combat sprites
-
over 1 year ago by MDoucha | Reply
My second pick is to improve the Linux port of Gates of Skeldal. IIRC the game engine needs to be ported to LibSDL 2.0, savegame format needs some fixes and there are a few graphical glitches.
-
over 1 year ago by MDoucha | Reply
My third pick once again is to select some third-party project from the Open Source Game Clones database.
-
5 months ago by MDoucha | Reply
My top pick for Hack Week 24 is once again Master of Orion II. Last time, I've implemented the research selection window. The colony list screen partly implemented during Hack Week 22 remains unfinished. But there are still many more tasks to work on:
- Easy tasks: Finish colony list screen, implement diplomacy screen, fleet window (on galaxy screen) and star system window (ditto), game settings window or galaxy screen windows (opened by clicking the sidebar)
- Medium tasks: implement colony screen, audio subsystem, ship detail window, colony production screen, reverse engineer ship design, planet orbit position calculations or galaxy screen zoom buttons
- Hard tasks: reverse engineer the rest of savegame format, implement help/info screen, find palettes for space combat sprites
-
5 months ago by MDoucha | Reply
My second pick is to add improvements to Signus (from Hack Week 19). Implement support for subtitles in cutscenes, implement single-click "move and shoot", allow unloading transported units to a specific tile, start working on custom scenario editor (which will require redesigning the map file format and implementing more general AI algorithms).
-
5 months ago by MDoucha | Reply
My third pick is to contribute to some third-party project from the Open Source Game Clones database.
-
about 1 month ago by wfrisch | Reply
I will work a bit on Chaos Overlords (1996), a turn-based strategy game with a clunky mouse-driven interface but with interesting mechanics underneath and a story that doesn't take itself too seriously.
https://github.com/wfr/re-chaos
Status quo (RE):
- Resource file format (images, sound): done
- Core logic and structs: mostly analyzed, easy
- Networking: medium difficulty, will probably defer until the end
- AI: hard. Lots of strategies with a lot of code duplication.
Challenges (RE):
- Almost all code is completely intermixed, i.e. sound, GUI, networking. Hard to untangle.
- Some game rules are neither documented nor obvious to the player. There is no way around diligent decompilation and debugging.
Status quo (new implementation):
- PoC Qt Widgets interface is working. Qt is the right choice for a faithful recreation, IMHO, because it matches the look & feel of the original which is very mouse-driven, with drag & drop etc. It wouldn't make much sense to implement this in a custom game engine.
- Refactoring is direly needed
Goals for this week:
- Migrate the existing decompilation project to Ghidra
- Get to know Ghidra
- Set up remote debugging for Ghidra (Linux) → gdbserver (Windows)
- Ideally make some progress with yet unknown data structures
Similar Projects
RISC-V emulator in GLSL capable of running Linux by favogt
Description
There are already numerous ways to run Linux and some programs through emulation in a web browser (e.g. x86 and riscv64 on https://bellard.org/jslinux/), but none use WebGL/WebGPU to run the emulation on the GPU.
I already made a PoC of an AArch64 (64-bit Arm) emulator in OpenCL which is unfortunately hindered by a multitude of OpenCL compiler bugs on all platforms (Intel with beignet or the new compute runtime and AMD with Mesa Clover and rusticl). With more widespread and thus less broken GLSL vs. OpenCL and the less complex implementation requirements for RV32 (especially 32bit integers instead of 64bit), that should not be a major problem anymore.
Goals
Write an RISC-V system emulator in GLSL that is capable of booting Linux and run some userspace programs interactively. Ideally it is small enough to work on online test platforms like Shaderoo with a custom texture that contains bootstrap code, kernel and initrd.
Minimum:
riscv32 without FPU (RV32 IMA) and MMU (µClinux), running Linux in M-mode and userspace in U-mode.
Stretch goals:
FPU support, S-Mode support with MMU, SMP. Custom web frontend with more possibilities for I/O (disk image, network?).
Resources
RISC-V ISA Specifications
Shaderoo
OpenGL 4.5 Quick Reference Card
Result as of Hackweek 2024
WebGL turned out to be insufficient, it only supports OpenGL ES 3.0 but imageLoad/imageStore needs ES 3.1. So we switched directions and had to write a native C++ host for the shaders.
As of Hackweek Friday, the kernel attempts to boot and outputs messages, but panics due to missing memory regions.
Since then, some bugs were fixed and enough hardware emulation implemented, so that now Linux boots with framebuffer support and it's possible to log in and run programs!
The repo with a demo video is available at https://github.com/Vogtinator/risky-v
YQPkg - Bringing the Single Package Selection Back to Life by shundhammer
tl;dr
Rip out the high-level YQPackageSelector widget from YaST and make it a standalone Qt program without any YaST dependencies.
See section "Result" at the bottom for the current status after the hack week.
Current Status
See the development status issue at the GitHub repo.
tl;dr: It's usable now with all the key features.
It does real package installation / removal / update with reasonable user feedback.
The Past and the Present
We used to have and still have a powerful software selection with the YaST sw_single module (and the YaST patterns counterpart): You can select software down to the package level, you can easily select one of many available package versions, you can select entire patterns - or just view them and pick individual packages from patterns.
You can search packages based on name, description, "requires" or "provides" level, and many more things.
The Future
YaST is on its way out, to be replaced by the new Agama installer and Cockpit for system administration. Those tools can do many things, but fine-grained package selection is not among them. And there are also no other Open Source tools available for that purpose that even come close to the YaST package selection.
Many aspects of YaST have become obsolete over the years; many subsystems now come with a good default configuration, or they can configure themselves automatically. Just think about sound or X11 configuration; when did you last need to touch them?
For others, the desktops bring their own tools (e.g. printers), or there are FOSS configuration tools (NetworkManager, BlueMan). Most YaST modules are no longer needed, and for many others there is a replacement in tools like Cockpit.
But no longer having a powerful fine-grained package selection like in YaST sw_single will hurt. Big time. At least until there is an adequate replacement, many users will want to keep it.
The Idea
YaST sw_single always revolved around a powerful high-level widget on the abstract UI level. Libyui has low-level widgets like YPushButton, YCheckBox, YInputField, more advanced ones like YTable, YTree; and some few very high-level ones like YPackageSelector and YPatternSelector that do the whole package selection thing alone, working just on the libzypp level and changing the status of packages or patterns there.
For the YaST Qt UI, the YQPackageSelector / YQPatternSelector widgets work purely on the Qt and libzypp level; no other YaST infrastructure involved, in particular no Ruby (or formerly YCP) interpreter, no libyui-level widgets, no bindings between Qt / C++ and Ruby / YaST-core, nothing. So it's not too hard to rip all that part out of YaST and create a standalone program from it.
For the NCurses UI, the NCPackageSelector / NCPatternSelector create a lot of libyui widgets (inheriting YWidget / NCWidget) and use a lot of libyui calls to glue them together; and all that of course still needs a lot of YaST / libyui / libyui-ncurses infrastructure. So NCurses is out of scope here.
Preparatory Work: Initializing the Package Subsystem
To see if this is feasible at all, the existing UI examples needed some fixing to check what is needed on that level. That was the make-or-break decision: Would it be realistically possible to set the needed environment in libzypp up (without being stranded in the middle of that task alone at the end of the hack week)?
Yes, it is: That part is already working:
https://github.com/yast/yast-ycp-ui-bindings/pull/71
New KDE Plasma notification app/applet by apappas
Description
My memory is terrible so I depend a lot on notifications to carry me through the workday. As a plasma user I am ok with the current applet, but I don't love it. It is too small for the centrality it has in my day. Also I dislike how you can not go back to notifications you have dismissed
Goals
Develop a plasma app that * must gather notifications without disrupting the existing notification app * must offer the ablity to refer to dismissed/archived/seen notification up to some defined point in the past * must allow deletion of notifications
SUSE AI Meets the Game Board by moio
Use tabletopgames.ai’s open source TAG and PyTAG frameworks to apply Statistical Forward Planning and Deep Reinforcement Learning to two board games of our own design. On an all-green, all-open source, all-AWS stack!
Results: Infrastructure Achievements
We successfully built and automated a containerized stack to support our AI experiments. This included:
- a Fully-Automated, One-Command, GPU-accelerated Kubernetes setup: we created an OpenTofu based script, tofu-tag, to deploy SUSE's RKE2 Kubernetes running on CUDA-enabled nodes in AWS, powered by openSUSE with GPU drivers and gpu-operator
- Containerization of the TAG and PyTAG frameworks: TAG (Tabletop AI Games) and PyTAG were patched for seamless deployment in containerized environments. We automated the container image creation process with GitHub Actions. Our forks (PRs upstream upcoming):
./deploy.sh and voilà - Kubernetes running PyTAG (k9s, above) with GPU acceleration (nvtop, below)
Results: Game Design Insights
Our project focused on modeling and analyzing two card games of our own design within the TAG framework:
- Game Modeling: We implemented models for Dario's "Bamboo" and Silvio's "Totoro" and "R3" games, enabling AI agents to play thousands of games ...in minutes!
- AI-driven optimization: By analyzing statistical data on moves, strategies, and outcomes, we iteratively tweaked the game mechanics and rules to achieve better balance and player engagement.
- Advanced analytics: Leveraging AI agents with Monte Carlo Tree Search (MCTS) and random action selection, we compared performance metrics to identify optimal strategies and uncover opportunities for game refinement .
- more about Bamboo on Dario's site
- more about R3 on Silvio's site (italian, translation coming)
- more about Totoro on Silvio's site
A family picture of our card games in progress. From the top: Bamboo, Totoro, R3
Results: Learning, Collaboration, and Innovation
Beyond technical accomplishments, the project showcased innovative approaches to coding, learning, and teamwork:
- "Trio programming" with AI assistance: Our "trio programming" approach—two developers and GitHub Copilot—was a standout success, especially in handling slightly-repetitive but not-quite-exactly-copypaste tasks. Java as a language tends to be verbose and we found it to be fitting particularly well.
- AI tools for reporting and documentation: We extensively used AI chatbots to streamline writing and reporting. (Including writing this report! ...but this note was added manually during edit!)
- GPU compute expertise: Overcoming challenges with CUDA drivers and cloud infrastructure deepened our understanding of GPU-accelerated workloads in the open-source ecosystem.
- Game design as a learning platform: By blending AI techniques with creative game design, we learned not only about AI strategies but also about making games fun, engaging, and balanced.
Last but not least we had a lot of fun! ...and this was definitely not a chatbot generated line!
The Context: AI + Board Games