Game release: The Echidna Menace

Over the years I've dabbled making lots of small games, but I've always been afraid to release. This game isn't perfect, but it actually has some fun to it.

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

Download:

echidna_menace_v1.0.tar.gz (11MB)
echidna_menace_v1.0.zip (12MB)

Readme:

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.