next »

[EyeballKid]

Zig is a frenetic retro-style arcade shooter.

Latest build(s):
Windows: zig_win32_2015-02-19.zip
Mac: Zig_2015-02-23.dmg
Linux: zig_64bit_2015-03-04.tar.gz (64bit, requires SDL2 and SDL2_mixer)



I've had this kicking about for a looong time - over 15 years.
I still love playing it myself, so I decided that it's finally time to dust it off and actually _release_ it properly.

It's been about 90% finished for most of it's lifetime - so I've only got the other 90% to do ;-)

This devlog is a little different in that it'll be less about development of the game itself, and more about the zillions of annoying little things that have to be done to a game to get it actually, finally out the door...

[Emperor Ing]

Looks interesting, but is all you do just move around and shoot enemies that fly in a straight line towards you? Also, what are your plans for the other 90% of your game?

[EyeballKid]

Looks interesting, but is all you do just move around and shoot enemies that fly in a straight line towards you?

Well, I never claimed it was the most deeply philosophical of games ;-)

There are currently about 25 types of bad dudes. There's one which swings around the outside of the arena, shooting inward. There are others which try to sneak around behind you before accelerating in for the kill. There's one which periodically divides the play area in two by shooting out a laser beam, a couple of boss-like ones.... all that kind of good stuff.



And some more... traditional enemies:



It's the mix of bad dude types which give each level it's feel and pacing. Some are simple blast-fests, filled with grunts. But if you throw in a few dudes which fragment when they explode, shooting out deadly shards, then the player has to be a lot more circumspect and adopt appropriately defensive tactics.

Also, what are your plans for the other 90% of your game?

The "Other 90%" refers really to all the infuriating little things to do with releasing a game - packaging, tracking down little platform-specific bugs, generating bloated animated gifs to post on devlogs... all that malarky.

That said, there are _so_ many things I'd like to modify. Loads of graphical improvements (it's pretty basic-looking), more sound effects, more levels (there are 50 right now).
I'll probably try and confine myself to just tweaking a few of the levels that don't 'feel' quite right to me, and there's one bad dude type which I want to redo in particular.

[EyeballKid]

[warning: dull tools-related post]

I've been trying to sort out my build system, so I can get some builds up here for people to try out. For now, I'm going for Linux, Windows and OSX.

The game tech is all pretty vanilla - it's written in C++ and uses a few extra libraries (sdl2, sdl2_mixer, libpng, zlib...). I've been using gcc the whole way through and I always had a Makefile which _mostly_ works on any platform. In theory I should just bite the bullet and work out XCode on the Mac and install Visual Studio on Windows... but I don't really want to. I like Free software. I like reusing the same tools. I like not wading through zillion of fiddly little project settings dialogs in proprietary IDEs.
All well and good, but getting all the platform-specific compiler and link flags was always a bit of an arse.

A year or two ago I even shifted everything over to CMake, to handle all the platform-specific config stuff. But somehow, it never really took - I could never bring myself to learn enough about CMake to really get comfortable with it, and so it was really just an extra layer of complexity lurking there, making me feel a bit stupid.

So recently I stripped out all the CMake stuff and went back to a bog-standard Makefile.

After a lot of jumping through hoops trying to get the Makefile to detect which OS to target, I ended up with a big brittle unreadable set condition checks. It was pretty ugly. So I ripped them all out, replaced them with a much smaller shell script. The Makefile delegates the platform-detection to the shell script.

zig-platform:

Code:

#!/bin/bash
# A cheesy little platform-detection script to simplify makefile

if [[ "$OSTYPE" == "linux-gnu" ]]; then
    echo linux
elif [[ "$OSTYPE" == "darwin"* ]]; then
    echo osx
elif [[ "$OSTYPE" == "cygwin" || "$OSTYPE" == "msys" ]]; then
    echo win32
else
    exit 1
fi

Now, in my Makefile, the big ugly lump of platform-detection stuff is magicked away, to be replaced with this slightly-less-big-ugly-lump of platform-specific config:

Code:

PLATFORM=$(shell ./zig-platform)

EXE = zig

ifeq ($(PLATFORM),linux)
  CXXFLAGS = -O2 $(shell pkg-config --cflags sdl2 SDL2_mixer libpng zlib gl)
  LIBS = $(shell pkg-config --libs sdl2 SDL2_mixer libpng zlib gl)
endif
ifeq ($(PLATFORM),osx)
  CXXFLAGS = -O2 $(shell pkg-config --cflags sdl2 SDL2_mixer libpng zlib gl)
  LIBS = $(shell pkg-config --libs sdl2 SDL2_mixer libpng zlib gl)
endif
ifeq ($(PLATFORM),win32)
  EXE = zig.exe
  CXXFLAGS = -O2 $(shell pkg-config --cflags sdl2 SDL2_mixer libpng zlib)
  LIBS = $(shell pkg-config --libs sdl2 SDL2_mixer libpng zlib)
  LIBS += -lopengl32
  CXX=g++
endif

...rest of makefile...

So now I've got about 25 lines of platform-specific build configuration which gets me up and running on Linux, Mac and Windows.

I'm happy for now.


Next step: getting packaging scripts set up to handle all the gory details of ensuring the right data files, icons and .so/dll/frameworks are included, pulling together a .dmg/zip/tarball/whatever and getting people to test it only to find certain machines have trouble running it on Tuesdays or whenever there is increased sunspot activity... yay!

[JobLeonard]

Do I get to move every?

[EyeballKid]

Do I get to move every?

I have no idea what you're talking about. I've never even heard of Zero Wing.
*cough*

[EyeballKid]

In my copious free time (ha!), I've been trying to get some builds together for people to try out.

Windows build now up - zig_win32_2015-02-13.zip
(OSX and Linux builds to follow, although amusingly enough the windows build runs just fine in Linux under Wine...)

Major caveat: on the windows build, the sound effects are broken. It only seems to play the first little fraction of each effect. They work fine on Linux and OSX, so it's windows debugging-time for me.
Yay.

I'd forgotten just how fiddly it was to package up a game.
I use a few third-party libraries (libpng, sdl2, sdl2_mixer). When you're coding, you install all the libraries you need on your machine and forget about them. But you can't expect users to have them installed, so you have to ship them along with the game.
I spent ages getting this windows build working - The game would run fine in-situ, but would crash horribly when I packaged up. I suspect I was picking a 64bit version of some DLL to include alongside my 32bit exe...

[EyeballKid]

I finally figured out and fixed the bug that was causing the borked sound on windows!

New build is up: zig_win32_2015-02-19.zip

[boring techy explanation]:

Turned out to be an undefined value being returned in one of my sound synthesis routines. During the sound generation phase, one sample value would be affected. Under Linux and Mac the value just showed up as some random number which just caused a tiny glitch which I'd put down to general noisiness. However, under windows, this single sample would pop out as an NaN (Not a Number - an invalid floating point value). Because I use a feedback loop as part of a low-pass filter, the NaN would corrupt _every_ sound sample from then on.

Of course, it turns out I'd forgotten to enable the compiler warnings which would've loudly highlighted the undefined return value issue as soon I'd typed it in... Doh.

[EyeballKid]

Out of interest, all the sounds in Zig are synthesised at runtime.

I wanted the audio to have a bleepy 8-bit asthetic, so this seemed to fit in with that. Besides, it was fun to implement.
When the game starts up, it runs a bunch of routines (collectively called the 'retromat' ;- ) to generate the sound waves.
It's _really_ loosely based on the sort of stuff you'd do on the old C64 SID chip. I've got:

• a base waveform (sine, pulse, triangle, white noise) whose frequency can be twiddled on the fly to get all those great 'wibbly' effects
• an ADSR envelope,
• a low-pass filter, whose cutoff frequency can be sweeped about on the fly

So all the sounds are defined by a playing around with a set of frequencies, waveform types, sweep ranges and whatnot.

The original idea is that the synthesis might be done in realtime and randomised slightly, so every sound might be slightly different and unique, or depend on various parameters in the game... but I suspect I'll never get around to optimising it enough to really be comfortable with the performance on lower-end machines. Maybe one day.

There are still loads things in the game I'd like to add sounds for, and a few fixes to be made to the existing sounds, so I suspect my near future is likely to contain a good round of sound fiddling...

[EyeballKid]

There's now a fully-playable Mac build available: Zig_2015-02-23.dmg

It's my first try at shipping a Mac bundle, so I'm really curious to hear if the download/install process goes smoothly or not...

It's the usual Mac drill: just open the .dmg run the app or copy it wherever you want to plonk it.

Give it a try!

[EyeballKid]

Just for the sake of collecting the whole set... there's a Linux build now up:

zig_64bit_2015-03-04.tar.gz

It's a 64bit executable, and requires SDL2 and SDL2_Mixer to already be installed. So a little rough in terms of packaging, but I'll work on improving that.

[koalefant]

Hey that is nice to see someone uploading a linux build. =)

It is pity this one didn't update for a while - I love the visual effects, I think they look very cool.

Notices couple little issues though: I am running the game in 4K and must say that textures look a bit low-res together with sharp geometry corners. I wonder what is the intended resolution. Also in the menu I can see some filtering issues on the edges of individual letters.

Also couple small ideas:
- Maybe adding a bit of inertia to the camera would give a better impression of the speed of the "vehicle".
- At the end of the level the game freezes for a moment. This feels a bit akward to me.
- If you're using C++/SDL2 you could easily make an WebGL build with emscripten and run it in browser - from what I observed people prefer online version to downloadable ones.

I hope you're still making games. 

[JobLeonard]

Hey that is nice to see someone uploading a linux build. =)

As a Linux user, I agree. Will have to download and try this later, at work now.

[EyeballKid]

Arise, necrothread!


Wow, time flies when you're busy doing other stuff!
But I'm still working on this, still edging slowly toward a proper release.

Since I last posted, I did, in fact compile a web version (thanks for the kick, @koalefant!), although it needs a little more care and attention, so it's on the back burner for now. It ran surprisingly well - totally playable, albeit with a little slowdown when there are a lot of frags onscreen.

In other news, I've been ruthlessly cutting down my TODO list to the bare minimum. And then ignoring it to do more fun stuff.
For example, I revamped the Divider, a two-way laser dude who cuts your play area in half:

Old-look Divider:



New-look Divider:


(looks way better in motion, and has some great charging-up sound effects too)

After that, I've decided to try and rein back my impulse to improve the graphics too much. It'll be waaay too easy to pile in with fancy shaders and effects and smooth glowy stuff... and the game will start looking like so many others out there.
I've decided that I want to try and keep it looking a little bit rough-edged... try and keep more of a retro aesthetic.
Not to say there won't be a few visual improvements, but they'll be for the sake of variety and "readability" rather than prettiness.
That said, there are a couple more bad dudes that I absolutely can't stand looking at, so I'll be giving them a quick makeover too.

[EyeballKid]

Something I've wanted to have in there for ages - the attract sequence now shows a gallery of the various bad dudes:



There's not enough room to show all 20 or so bad dudes without looking cluttered, so it'll pick a random selection each time.

With that and some more rainbow-flashing text applied around the place, the whole thing is starting to attain that retro arcade presentation I'm after!

[EyeballKid]

I did a pass through the various bad dudes, trimming out a couple I didn't like, tweaking some and completely rewriting others.

One of the new ones is the Puffer. I've had it in mind for a while - it expands as you shoot it, and really cuts down your space to maneuver. So you have to be careful when taking them on. It explodes only when you manage to 'pump' it up past bursting point, when it does it's best to take the player with it. Like so:



I'm pretty happy with how it came out. These bad dudes all take a while to tweak, but often you get lucky and hit a point where they just 'feel' right. It's great when that happens ; -)

[EyeballKid]

I've been doing builds for Steam.

Amusingly, the Windows and Linux builds are tiny (they'd fit on a floppy disk), while the OSX build is about 40MB!

The Windows build, I statically compile against the two libraries I need - SDL2 and SDL2_mixer. SDL2_mixer is a custom-compiled version with just the basic sample playback and no bulky codec support (ie ogg/mp3/flac/etc). So it's pretty small.

The Linux build is teeniest of all, as both the libraries it depends upon are supplied by the Linux Steam runtime. Yay!

The Mac build a gargantuan 40MB in comparison. It's an app bundle, and I include the standard-issue SDL2 and SDL2_mixer frameworks. The mixer one is particularly huge as it's got the full-blown support for all the codecs, which I don't need. I _could_ just build my own libs and statically compile against them... but the Apple guidelines strongly recommend not to do this. When in Rome and all that...

Years ago I set myself the silly arbitrary goal of the game being able to fit on a single floppy disk, and the Linux build gets me there. It amuses me that my entire game is smaller than most modern web pages :-)

[Pixelologist]

I was trying to open your game, after downloading the proper files, and it resulted in my PC thinking something was loading. Nothing happened after two minutes. It then crashed my anti-virus software and now I have to reset my PC. I am dissatisfied with your product.

[EyeballKid]

I was trying to open your game, after downloading the proper files, and it resulted in my PC thinking something was loading. Nothing happened after two minutes. It then crashed my anti-virus software and now I have to reset my PC. I am dissatisfied with your product.

Hmm. That's certainly unintended behaviour.
What antivirus and OS are you running?

[JobLeonard]

> Years ago I set myself the silly arbitrary goal of the game being able to fit on a single floppy disk, and the Linux build gets me there. It amuses me that my entire game is smaller than most modern web pages :-)

Give it a couple of years, you'll be able to compile to bytecode-WASM and ditch a ton of dependencies because the browser environment is guaranteed to have APIs that support multimedia aspects