Game release: The Echidna Menace
I've made all sorts of little games over the years, but not put them up for people to see. I decided to buck this trend and not only get something out, but something that should just work ™ on both Windows and Linux.
"Release often or release never"
The 1.0 release contains:
- a Windows .exe
- Linux (glibc) x86 and x86_64 builds
- Source code
I put this game together with a bit of zesty humour for an HSC assessment back in 2012. As it turned out all of the marks were for the documentation, not the game itself, so I made a mistake in trying to make something fun. Perhaps not. Good luck! There's 10 levels and only 3.2 bugs. --- How to run the game --- Windows users: just double click on the run_windows.bat file. Most Linux users: you will need to install "SDL" and "SDL image" first. Your package manager will undoubtedly have these. Version 1, not 2. Then just double-click (or otherwise run) the run_linux.sh file. --- Unusual things about this game --- Maze-like AI without using A* A* is a common way of making monsters find you in games. It's complex for beginners to understand, it can bring your computer to its knees, and it's clinically accurate. In 2012 I had no hope of implementing it. And I'm glad I didn't. The AI in this game does not feel like every other game and has some actually interesting behaviours. Fully self-contained Windows toolchain Back in 2012 I made this game under Linux on a USB stick I would bring into school. I especially loved the contrast this made between me and my class- mates: I could boot my computer up into my OS and get working within a couple of minutes whilst it would take them a good 10 to login to Windows and get started. But hey, at least we didn't have Novell Netware anymore... Over the past couple of months (2017) I have been investigating porting the game over to Windows. "It'll be easy, because I'm using SDL!" I thought. Oh dear. Compilers and toolchains (the things you need to turn your game from C code into something that actually runs) are abundant and easy in the Linux world. In Windows they're a straight out PITA. Here are the big players: 1) Microsoft Visual Studio. Massive fully-integrated IDE. Has its own project structure management and compilation stuff. Admittedly I've never tried it, but the stories I hear keep me holding my breath in the shadows. 2) gcc. I tried to use mingw64-gcc. Oh dear installing this took a long time. And hundreds of megabytes and tens of thousands of files (I'm not kidding you). And half the time the install process wouldn't work because some dependency couldn't be downloaded. Ugh! The biggest thing I hated about these options was their entry barrier. They're massive. They're difficult to install. If I used them, then there was no hope that any Windows user would ever tweak a source file to see what would happen, because they'd have to spend the next few hours setting up a toolchain. So I looked at the smaller players: 3) openwatcom. A compiler with an interesting heritage and modern support for compiling games to dos. Less than 100MB in size, if I recall. 4) tinycc, the tiny C compiler. Something that I've used before when doing work for people, without a laptop, stuck in the Windows world but really in need of being able to write some code. Less than 5MB in size. Tinycc, again, blew my mind. It's so tiny you start to question why things like GCC take so much space up and whether or not it's really worth it. It by no means optimises its output anywhere as much as something like gcc does, but who cares, this isn't a shader-filled 3D game that has to render a steady 60FPS or higher. I've included tinyCC in the version of the game that you have here. To compile this game on Windows you just have to double-click the batch file called "compile_windows.bat". That's it. No installing massive toolchains. No setting them up. No dealing with dozens of out of date guides on the web. Just double-click a 6-line batch file. So please, screw up the source and have a play! Especially if you're not a programmer. All of the files ending in .c or .level in the game folder can be edited with notepad. You might be interested in how things work after struggling with some of the later levels, you might not. I learned how to program thanks to a fellow called James Bunting. He released a free game called Meteor 2 that included all the editors that he used to make the game content. A map editor, and object editor, a weapon editor and the likes. Whilst he has never released the source code to the game, each level could have a script. These script files were plaintext C. When the level was loaded they would be compiled on the fly. I made many exciting maps, with trains that ran people over, secret passages that would open, and stories that made no sense. Key to this was the fact that the developer gave the users the same tools that he used to make most of the game. Without that it would have just been another freeware game. But the community was amazing. Small, but amazing. And some of the total conversion mods released were staggering. Go and download "The Ravagers of Time" for Meteor 2 today. Actually, I need to con a friend into playing the co-op on that... http://www.jbplay.com/games/meteor2/ http://meteormods.com/File_Info.asp?FileId=1064 If any of these links ever die, tell me, I have backups of the game that I can rehost or send you. Anyway, I think _every_ free game should come with the tools used to make it. I have no hope of ever emulating what I felt and learned through Meteor 2. But I can try. And I can hope that others do too. There's another great advantage to shipping with a compiler. Your game is much less likely to become one of the forgotten parts of the great turn of millenium internet dark ages. How many pieces of software do you yearn for, but do not work any more? How can you make sure that your program is easy to get working again in another 20 years? No header files Back in 2012 I had never written a C program larger than a single file, so getting my head around "all that crazy #ifdef stuff" was not working. Alas I really wanted to split the source code up a little into different files, just to make it easier for me to find things. So I cheated. I #included other .c files into the main.c file. And it worked, brilliantly. I have the simplicity of the C language to thank for this. --- Compiling --- Windows users: You're in luck! This game comes with a compiler and a (compiled) copy of SDL. You don't have to go chasing copies of Visual Studio, mingw or any libraries. In the "source_code/" folder is a "build_windows.bat". Double-clicking this will call a copy of the Tiny C Compiler (included) and the result will be spat out as "echidna_menace.exe" (replacing what was already there). Feel free to have a play around with the source! It's not usual for Windows games to be this easy to tweak. Linux users: You will need: - A plain C compiler (eg gcc) - SDL and SDL-image devel packages (SDL1 not SDL2) Run the 'build_linux.sh' script to compile the game: cd game/ ./build_linux.sh An "echidna_menace.linux_XXX" binary will be spat out, where XXX is your architecture name. --- Bugs --- Glitchy background picture on Windows I'm not entirely sure, but I have a few ideas of what might be causing this: (1) SDL not being initialised properly due to my TCC/SDL main() hack. (2) Wrong combo of SDL and SDL-image versions. (3) Some fun TCC main <--> GCC .dll interaction. AI collision detection Hint: You'll need to learn this bug to finish the game. You might discover it accidentally. Good luck :D Escaping the map boundaries A fun way to explore memory. Take it as a challenge to find a shortcut via the outside of a map. --- Files and internals --- This is the fun bit! *.level Plaintext level files. Open one up and have a look. The second line of the file has a pair of numbers representing the coordinates of where the player spawns. Any sets of numbers at the bottom of the file represent the coords and chosen face of the echidnas. *.dll SDL libraries (and libraries they depend on). These provide an easy way for me to draw pictures on the screen and handle keyboard input. historical_content/ Original assignment documentation files. Merely a curiosity. Saved in Abiword file format (Libreoffice can open this now). sdl/ Original archives I took the SDL *.dll and header files out of. The full authorship and licensing info can be found in these .tar.gz files. sdl/include/ Just the header files for SDL and SDL-image. tcc/ A compiled copy of the TinyC compiler, fetched from GIT. Commit: b8fe8fc2105455eb5004be89fa8575aa928a18f3 (Mon Aug 21 19:38:11 2017) Compiled using a previous version of TCC. --- Licensing --- The Echidna Menace is distributed and depends on various other projects. SDL, SDL-image and the other .dlls distributed with SDL-image each have their own authorship and licensing. All of this can be found in the .tar.gz files found in the sdl/ folder. SDL: GNU LGPL 2.1 SDL-image: zlib license zlib: zlib license libpng: libpng license TinyCC is also under its own license with its own authors. See the tinycc/ folder for more info. TinyCC: GNU LGPL 2.1 The Echidna Menace game itself is by me. Detailed license information is available in gpl.txt. If you need a less restrictive license then please just contact me. If you're not wearing a suit then I will probably say yes. Echidna Menace: GNU GPL v3 Copyright William Hales 2017
Ramblings about releasing software
"If you put enough text on the page then everyone will be afraid of the game"
Releases and builds
I had a whole bunch I wanted to write down here about how I think software should be packaged, but I've been working all day on trying to get this game ready. This is the third time I've tried to write this section. So bugger it, I'll get to the point:
Release your games and programs with generic linux binaries
Please don't tell me your program runs on Linux and then only provide binaries in the form of links to distro repositories. Please don't tell me your game runs on Linux and then only provide the source.
Please provide a .tar.gz with the thing compiled in it. And if the project has any unusual dependencies (ie things that you will not find in every distro's package repository) then include fully working and compiled versions of those too. When I have to spend an age fixing problems, tracking down deps and hacking things together, I tend to give up. I delete the folder I extracted your software to and use something else instead.
All developers start as users. They at least have to get your program running before they work on it. If you scare away users then you are only offending yourself.
Users of the top Linux distros (Ubuntu, Debian, Arch, etc) make up the majority of Linux users. Why should you care about people on the smaller distros?
Most users are on Windows, not Linux. So why should you care about Linux users?
There's a variety of answers, but in my mind the people who go to the effort of doing something unusual with their computing are more likely to be interesting community members. They're more likely to engage, even if it's just to say Hi.
There's another big motivation I have behind all of this:
Your games and programs should be portable across space and time.
We're living in the dark ages of the turn of the second millennium. Much of our software and online art is being lost and forgotten forever. Do you want people to have a fighting chance at getting your software working in another decade from now? Or two? I regularly play games that are from the 90's, now more than 20 years old. But I struggle to get many programs from less than ten years ago to compile.
There are lots of guides on the web on how to inspect your executables and see what libraries they depend on, and many people arguing the benefits of static vs dynamic builds. But packaging and portability is a lot more than just some compiler flags. It's about your project's design and build system. It's about whether or not you care enough to see what it's like trying to get your project working on someone else's computer.
There's nothing worse than the feeling you get when you think that the only place in the world the software works is on a certain subset of computers. Whether it be "only Ubuntu from 2012" or "only the developer's laptops". You question if something really is open-source if it takes a large effort to get the source functional.
So, if you have any problems getting this game working, whatsoever, please complain to me in the comments below :) Especially if you don't think I'll care.
A big thankyou to the tinycc project
The tinycc devs on their mailing list have been amazing. They not only helped me out when I was doing something wrong, but added a warning to the compiler to stop other people doing the same thing.
Obligatory irony: tinycc needs a release. The latest release is years old and full of bugs. The latest version from GIT is mindblowingly amazing in comparison. I'd recommend you steal the copy I include with this game and use it instead of the dated 9.26 release.