During my upcoming Christmas vacation, I was planning to either write a really basic and (hopefully) fast Lisp interpreter, or write a simple networked Bomberman clone.
The bomberman clone would be called EMP Activist, where the players are robots who drive around on treads, and who plant EMPs and activate them (hence the title).
The EMPs would disable the battery in any player in its path until the next round, so it couldn't drive around. The map would be littered with opaque force fields which dissolve instantly when an EMP activates in its range, revealing useful items.
One item would be a temporary battery, allowing a robot to sustain any amount of EMP blasts for 10-seconds without being disabled. Another would be hydraulic springs, allowing it to "bounce" across the map. Another would be extra treads, allowing it to go faster.
The whole idea was to make a game that I could play against my brother and my kids, over our LAN on our various computers. To make things way simple, instead of graphics files it would just use colored shapes at first. Gameplay would ideally be as smooth as butter on a baby's face.
In order to play over the network, I was researching server/client architectures. Here's the game plan I've come up with based on the most credible stuff I found:
The server should be in charge of the entire game. The server sends each client everything they need to know in order to draw the entire game view. To have a smooth framerate, it sends this data 30 times per second. It's okay if packets are lost, since the next packets will overwrite the display completely anyway. We'll use UDP for this.
In order to not have any fragmentation of datagrams, we'll send the entire game state in 508 octets or less (1 octet = 8 bits). For example: "there's a player at 0,3 pixels facing right", or "there's an EMP at 30,30 pixels". It doesn't need to send info about hidden items, for instance, since client's don't draw that. It could represent a player as "003" to save on bytes, as the coordinates followed by direction. Same with EMPs, items, blocks, etc. All coordinates will be pixel-based, since clients only care about drawing, not about game-logic details.
Besides drawing this data, the only other responsibility clients will have is to receive keyboard events, interpret them, and send the resulting game-actions to the server. For example, pressing the "w" key means "start-walk-up" and releasing it means "stop-walk-up".
I'm a bit nervous about the idea of sending a single message to start walking and a single message to stop, since the packet may be dropped, making things very confusing to the user. One option is to built TCP's reliability on top of UDP, and that sounds scary. Another option is to continuously send the "walk-up" action while the key is pressed, and stop sending it once it's released. This could also lead to user-confusion if packets are dropped, but probably not as severely.
I think this will be the easiest part, and it has the least unknowns, which is why I'm saving it for doing last. Each object on screen will be represented as a hash-map, containing its pixel-coordinates, animation-state if relevant (1 to N, then loops back to 1), and direction if relevant.
When an EMP "activates", it will disappear from the game state, and an "EMP-activation" (explosion) object will be created with base-coordinates relative to the old EMP. This too will have its own animation-state. While it exists, if anything exists in its path, collision detection will kick in, and something else will change depending on what collided with it.
Remaining Known Unknowns
Regarding animations and player-movements, what timer will they be based on? Will the FPS-timer (every 1/30 seconds) be responsible for changing these values? Or should there be another timer that does these things?
I don't fully understand UDP and datagrams yet. I know that 508 octets is the sweet spot for avoiding fragmentation, but do I have to force my messages to take up 508 bytes and include filler at the end?
Since I know I'm only going to be playing this over a LAN, I wonder if there are simplifications I can make to this design.
I wanted my brother and kids to be able to play this with me. Between us, we have my work computer (Mac Pro), my laptop (rMBP), the family computer (linux), and my brother's computer (Windows 8). So I needed to write this in something cross-platform.
Right now, it's written in Clojure. Mostly this is because a JVM app is pretty easy to get running on any OS. I wrote a simple GUI-based hello-world in Clojure in like 30 minutes the other night, and got it running on my brother's Windows 8 machine.
But originally I wanted to write this in C, and I still do. The problem is, I couldn't figure out how to create a platform-independent executable and run it on all 3 operating systems as easily as the JVM does. If anyone knows of a way to do this, please let me know, because I'd really like to try this in C (all except the UDP stuff which really scares me).
The source can be found here: https://github.com/sdegutis/EMP
My name is Steven Degutis, and I've been writing software professionally for a decade. During that time, I've written many apps and websites, quite a few technical articles, and kept up-to-date with the rapidly evolving software industry.
If you have software needs for web, mobile, or desktop, and are looking for a seasoned software professional, please reach out to me at email@example.com to set up a phone call.
- Self-employed – present
- Clean Coders – 5 years
- 8th Light – 2 years
- Big Nerd Ranch – 1 year
- Self-employed - 1 year
- Web: full-stack
- iOS (UIKit)
- macOS (Cocoa)
- REST APIs
- AWS / EC2 / ELB
- HTML5 / CSS
Over the past decade, I've written a total of 169 technical articles on various programming languages, frameworks, best practices, and my own projects, as I kept up-to-date and active in the software industry.
Subscribe via RSS / Atom.
- 2017 — "Clean code" isn't actually clean
- 2017 — Passion in your field is overrated
- 2017 — What I learned in 5 days of writing an experimental website
- 2014 — Age of the Polyglot
- 2013 — How to Program
- 2013 — Ignore the Naysayers
- 2013 — Writing Clearly
- 2012 — Reinvent the wheel
- 2010 — Good usability
- 2009 — Twitter is the wrong tool
- 2009 — We're all pretty bad at driving
- 2008 — Why I Code
|March||Notes on Haskell Extensions|
|February||Second thoughts on front-end tools|
|February||First thoughts on front-end tools|
|February||Some thoughts on GUIs|
|February||First thoughts on OCaml|
|February||First thoughts on Haskell|
Here are some of the projects I'm most proud of. They were created using a variety of technologies, running on several different platforms and OSes. They're all finished products, and many of them are open source.
I made Docks in 2009 for users who wanted to swap out icons in their Dock with a single click. Its unique functionality and design aesthetic attracted the attention of Apple, Engadget, MacWorld, and led to an acquisition of my start-up by Big Nerd Ranch.
This toy was made in a weekend to entertain my 1 year old daughter. It lets you create bubbles with your fingers, which then simulate physics by bumping into each other and falling.
When I couldn't find an app in the App Store that let me make very simple lists extremely quickly, I made one myself. I use it almost every day to organize and track my activities.
I created this app to increase my productivity by letting me move windows around in macOS using keyboard shortcuts. It grew into a community-driven highly extensible app, using Lua for its plugin system.
Implementing this elite social network gave me experience integrating both Apple Pay and credit card payments (via Stripe.com) seamlessly into web apps, for a frictionless and pain-free payment experience.
This isn't just any chatroom. In this web app, you can see what everyone is typing while they type it. I made this in order to scratch my itch for making real-time apps and games, and learned how to use WebSockets in the process.
This was written in 2009, before the time of Slack, when IRC was the main way for programmers to get short-term assistance from each other. Its purpose was to be a beautiful app with an emphasis on simplicity and usability over technical power.
This is an app I actually use every single day. It lets you move windows with global keyboard shortcuts. Since it uses Vim-like key bindings, it should feel pretty natural to any programmer. There's no configuration needed; it Just Works™.
As an evolution of Phoenix, Hydra was my first attempt at embedding a full Lua virtual machine into an Objective-C app, to make a lightweight and efficient window manager that focused on speed, low memory usage, low CPU usage, and overall being gentle on laptop batteries.
These may be tiny, but they're interesting technical feats.
|Lua4Swift||Swift framework for embedding Lua with a native Swift API.|
|choose||Command line fuzzy-matching tool for macOS that uses a GUI|
|music||Command line music daemon for macOS that only speaks JSON|
|hecto||Command line text editor with an embedded Lua plugin system|
|ZephSharp||Window manager for Windows using Clojure for scripting|
|management||Minimalist EC2 configuration & deployment tool in Ruby.|
|go.assert||Assertion helper package for writing tests in Go.|
|go.shattr||Go library for printing shell-attributed strings to stdout.|
|OCDSpec2||Objective-C based testing framework with Xcode integration.|