

Boxxle in Swift – Game Boy Port - KennyCason
https://github.com/kennycason/swift_boxxle

======
SeoxyS
By the way, this is originally a japanese game called Sokoban. Boxxle was a
clone of Sokoban.

[https://en.wikipedia.org/wiki/Sokoban](https://en.wikipedia.org/wiki/Sokoban)

I wrote a space-themed iOS derivative of Sokoban many years ago, which I sadly
never put up on the app store. I wanted to build more levels, free-to-play
mechanics, and got sidetracked and never finished the project. This is what an
early build looked like, before I built in a better input mechanism:

[https://vimeo.com/3918704](https://vimeo.com/3918704)

I ended up finding it cumbersome for each move to require a tap, so I built a
mechanism whereby you could draw your movements on screen and queue them up.

[http://cl.ly/image/0c222O3I020Q](http://cl.ly/image/0c222O3I020Q) (a whole
bunch of stuff is broken in this dev screenshot).

~~~
unwind
Nice!

I wrote a rather simplistic clone (no sound!) just to learn some Z80 assembly
and GameBoy hardware low-level programming, back in 1997
([http://www.student.nada.kth.se/~d94-ebr/rel_sw/gb/sokoban/do...](http://www.student.nada.kth.se/~d94-ebr/rel_sw/gb/sokoban/docs/)).

It's the first (and only!) program I've written for the GameBoy, so don't
expect too much.

~~~
KennyCason
Awesome! Is there a link to the source? I couldn't seem to find it, but I'm
actually a huge fan of Z80 ASM as it was one of the first assembly languages
that I tinkered with. I'd love to revisit sometime as a fun side project.

------
MattPearce
Just to be pedantic - this isn't a port as the original source wasn't used,
this is a remake.

~~~
ginko
Another nitpick: It wasn't Nintendo who created Boxxle. The game was developed
by Thinking Rabbit and published by FCI.

[http://en.wikipedia.org/wiki/Boxxle](http://en.wikipedia.org/wiki/Boxxle)

------
lyinsteve
Great job!

A few suggestions:

1) You may have better results with your pixel art if you change the
filteringMode of your SKTextures to SKTextureFilteringMode.NearestNeighbor
instead of .Linear.

2) You might want to store SKTextures in your imageDict instead of full
SKSpriteNodes. It seems you aren't reusing those nodes, just the textures.

3) Maybe use a plist file to store the level data instead of hard-coded array
constants? It's a little more flexible once you abstract the data outside of
your source code.

~~~
KennyCason
Thanks a lot, It was certainly a battle of figuring out Swift while making
continual forward progress. Thanks for the suggestions. I didn't even know
about the filtering mode! I also agree on only storing the SKTextures. In
regards to the level data. I hated storing hard coded arrays but couldn't
figure anything else out in time :) I would 1000x prefer to use a plist file
to store the data. That way I could also more easily parse the common level
formats. For example:
[http://www.ne.jp/asahi/ai/yoshio/sokoban/handmade/soko001.tx...](http://www.ne.jp/asahi/ai/yoshio/sokoban/handmade/soko001.txt)

Thanks for taking time to read through the code!

