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++.
-
-
-
over 3 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).
-
over 3 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.
-
-
over 3 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.
-
-
almost 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
-
almost 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.
-
almost 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.
-
4 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
-
4 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).
-
4 months ago by MDoucha | Reply
My third pick is to contribute to some third-party project from the Open Source Game Clones database.
-
7 days 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
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.
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
Go there for a screenshot
That's already halfway there.
The complete Ruby code of this example is here. The real thing will be pure C++ without any YaST dependencies.
The Plan
- DONE: Clone libyui where libyui (high-level), libyui-qt, libyui-qt-pkg live
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
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
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!
AI + Board Games
Board games have long been fertile ground for AI innovation, pushing the boundaries of capabilities such as strategy, adaptability, and real-time decision-making - from Deep Blue's chess mastery to AlphaZero’s domination of Go. Games aren’t just fun: they’re complex, dynamic problems that often mirror real-world challenges, making them interesting from an engineering perspective.
As avid board gamers, aspiring board game designers, and engineers with careers in open source infrastructure, we’re excited to dive into the latest AI techniques first-hand.
Our goal is to develop an all-open-source, all-green AWS-based stack powered by some serious hardware to drive our board game experiments forward!
Project Goals
Set Up the Stack:
- Install and configure the TAG and PyTAG frameworks on SUSE Linux Enterprise Base Container Images.
- Integrate with the SUSE AI stack for GPU-accelerated training on AWS.
- Validate a sample GPU-accelerated PyTAG workload on SUSE AI.
- Ensure the setup is entirely repeatable with Terraform and configuration scripts, documenting results along the way.
Design and Implement AI Agents:
- Develop AI agents for the two board games, incorporating Statistical Forward Planning and Deep Reinforcement Learning techniques.
- Fine-tune model parameters to optimize game-playing performance.
- Document the advantages and limitations of each technique.
Test, Analyze, and Refine:
- Conduct AI vs. AI and AI vs. human matches to evaluate agent strategies and performance.
- Record insights, document learning outcomes, and refine models based on real-world gameplay.
Technical Stack
- Frameworks: TAG and PyTAG for AI agent development
- Platform: SUSE AI
- Tools: AWS for high-performance GPU acceleration
Why This Project Matters
This project not only deepens our understanding of AI techniques by doing but also showcases the power and flexibility of SUSE’s open-source infrastructure for supporting high-level AI projects. By building on an all-open-source stack, we aim to create a pathway for other developers and AI enthusiasts to explore, experiment, and deploy their own innovative projects within the open-source space.
Our Motivation
We believe hands-on experimentation is the best teacher.
Combining our engineering backgrounds with our passion for board games, we’ll explore AI in a way that’s both challenging and creatively rewarding. Our ultimate goal? To hack an AI agent that’s as strategic and adaptable as a real human opponent (if not better!) — and to leverage it to design even better games... for humans to play!