• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
    625
  • comments
    1446
  • views
    1006530

Why YOU should embed a web server in your game engine

Sign in to follow this  
Followers 0
ApochPiQ

6982 views

I'm going to give you a sales pitch. It might sound outlandish at first, but bear with me - I think, by the end, you'll agree that this is a Good Thing(TM).

You should embed a tiny web server in your game engine.


It doesn't need to ship with the game, of course; this is a development tool. If you're into letting people mod your work, though, consider leaving the server active.

Don't roll your own. That takes too much work and is a security liability. There are plenty of tiny HTTP servers available in the open source world, in virtually any relevant language you can name; pick one and go with it.

What does this server do, you ask? Simple. It provides a window into the game world that can rival even the best IDE debugger's offerings. It gives designers and content creators a way to iterate on their work almost instantly instead of spending hours in the build/test/tweak/rebuild cycle. And it offers a mechanism for directly manipulating your game state for easy experimentation and exploration.

Sound fantastical? Too good to be true? Read on!


Debugging Unhinged
Ever wanted to dump a list of every NPC in your game and view its current state? Done. Stuck on a bug that only repros after several hours of play on someone else's machine, who doesn't have a debugger installed? No problem! Just dump the relevant data through your web server and you can diagnose it right at their desk. Frustrated by the difficulty of reading complex data structures in your debugger's interface? Worry no more; you can output the data you want and view it in any way that makes sense to you. No messing with visualizers or other IDE extensions.


The Ultimate Iteration Tool
This was actually my original motivation for building one of these suckers. Suppose you're working on tuning a game feature, and you need to edit a few numbers repeatedly. Make a tweak, test the changes, tweak some more, rinse, repeat. If you have to run through a build cycle every time this tweaking happens, you're in for a lot of pain.

Worse, you will lose context every time you wait on a build. Even if all you need to do is restart the engine or reload a level, your brain will stop processing the task at hand and get distracted a tiny bit (or a lot). If you could edit those numbers and instantly see the game change in response, you can keep that feedback loop tight and fast.

The best part? Iterating instantly means you'll not only have time to try a lot of ideas, but you'll find that over time it changes the kinds of ideas you have in the first place.

This is powerful.


OK, OK, sign me up. How do I do it?
Pick some lightweight HTTP server code. Plunk it into your engine and set it up to listen on some innocuous port (I like 8088). You're going to need to implement three things: the landing page, the "features", and the web-facing UI.

First, the landing page. This should just be a list of things you can go do in the game. As you add features, it should grow. (Hint: generate this page dynamically. Trust me, it's cooler that way.) This is the first thing a user sees when hitting your web page, and should help guide them into what they want to see or do.

Secondly, the features. This is the bulk of the work. In my system, I have a simple central API where I can register a "web console feature." This is basically just a set of callbacks. When someone opens the web page for the game, they click a link for a feature, and the appropriate callback is invoked.

Each feature is just a well-defined unit of functionality, such as "list all NPCs" or "drill into detail on a specific NPC" or "show me the stats of all the weapons in the game" or whatever. From the code side, the implementation is easy enough, but once you start wiring this up, chances are you'll get addicted to it and find yourself wiring up more and more code to the system.

Now for the UI bit, and the secret sauce. Don't generate HTML in your web server. Instead, generate XML documents. This allows you to keep the code that emits the web page constant, as long as the data it puts out remains in the same form. When you want to actually use this XML, then you write a simple XSLT layer that turns it into something pretty.

This last bit of separation is crucial. It means you can update your view of the game data without rebuilding any engine code. It also means that you can have a web dev or someone else comfortable with XSLT and HTML build the UI for you. You can even do fancy JavaScript, CSS, and whatever else your browser supports. Just remember to keep the original data in simple XML, so that the UI layer can be upgraded at any time, without touching the engine itself. This is especially vital on larger teams where you don't want to constantly make updates to the "NPC code file" every time you change the color scheme of the UI.


Bonus Mode
Here's a handful of ideas to run with, that make this system really shine:

  • Give each game object a unique ID. Offer a URL that lets you enter an ID and see details about the corresponding game object.
  • Attach state information as well as static information. Don't just say this NPC has 50 hit points, show his max as well. Hell, show his entire character sheet or whatever.
  • Don't forget this doesn't have to be read-only. Letting people edit the game via the web console is insanely powerful and a great time-saver.
  • Mock up a rough draft and hand it to a Web UX designer to build a really shiny product out of it.
  • Try to make URLs stable and easy to share between developers.

    Do all this stuff, and I promise your team will love you. YOU might even love you, I don't know. Either way... enjoy your new fame and glory!

17
Sign in to follow this  
Followers 0


22 Comments


Have to sign this.

 

My game implemented a webserver and it was one of the most useful things I have added to my engine in the recent decade.

 

Additionally , using HTML5 canvas + Javascript + Ajax helps a lot to rapidly implementing really useful tools just by using your common webbrowser.

1

Share this comment


Link to comment

Good day,

 

This sounds great for Indy developers, but documentation and other accountability issues weigh heavier the larger the development company becomes.  Management software by itself demands tracking people's contribution for a wide variety of reasons.

 

Like I say, great for the small and nimble developer but when investors and large organization must be tracked and paid, maybe not so good?  This could be a detour from the highway to true game development scalability.

 

Any thoughts?

-1

Share this comment


Link to comment

I'm doing a lot of HTML5 games, so I get all this 'for free'... adding it to a native-code game is an interesting idea.

 

I guess I'd implement most of it in javascript, like this:

- HTTP server serves index.html and console.js directly from disk, with no processing

- console.js does AJAX requests to get data as needed

- server looks up object by GUID and calls its .toJSON()

0

Share this comment


Link to comment

This sounds very interesting. I really like to read your blogs. This one is not only interesting but also seems very useful.

0

Share this comment


Link to comment

I was actually going to ask something along the same lines. I don't think XML should be dismissed out-of-hand, I actually tend to like it in its place, but XSLT and such isn't knowledge that most non-web-devs have.

 

I wonder if JSON would be easier for many things. It might also make it easier to interface other tools with it, aside from a web-browser interface (although, I think the browser is great for knocking up quick UI). Maybe even an SQL-like query language would be cool -- like Linq in .net-land.

 

Any thoughts on XML v. JSON, or which other web technologies you think might be useful for implementation?

1

Share this comment


Link to comment

This is exactly what I'm going to be needing in the very near future.  I just didn't realize it until reading this article, thanks so much!

 

I'm working on a city builder and I'm deep in the bowels of getting the simulation code fleshed out.  What that naturally means is that there is a lot of data that affects the game, but is not intended to be directly viewable in-game.  I've been dreading the process of writing throw-away UI components within the game, and I've found direct debugging to be very impractical for assessing simulation behavior.  Writing out massive log files and manually examining them, or even writing visualizers for the data, is also quite a pain.

 

But having an HTTP-accessible API sounds awesome.  I've already done some successful experiments moving my finance information out of spreadsheets and into a more web-friendly form, so I think I'm psychologically prepped for doing a similar thing to my games.

0

Share this comment


Link to comment
I'm not really religious about the XML/XSLT thing. The point of that is more that you should stream data from your engine's web service, not usable content. Separating the UI implementation from the raw data that comes from the game is powerful because it lets you vary them independently.

I personally really like the XML/XSLT combo, because I have access to a lot of library code that makes generating great-looking and feeling pages really easy. If JSON is a more suitable approach for your given project, go for it.

I've had zero need to write more than trivial JavaScript in my web console implementations, so JSON isn't really a win to me. Implementing a trivial set of code in the server is more valuable to me than having a rich, RESTful API; so I literally have three URIs in my server: the root landing page, /edit, and /submit.

As with anything, don't just drink koolaid and try to fly; use what makes sense for your project and apply your own reasoning to determining what that might be.
2

Share this comment


Link to comment

This is a great post - if you have any implementation details (i.e. which web server you are using) and any friction points that you ran into, I would appreciate hearing about them.

 

In general, the web interface sounds more or less like a normal game console extended to support the common browser interaction model.  Especially if you are only wiring up specific commands to the interface, it is very much like a traditional console.  The benefit (and I think this is one of your key points from above) is that you get to separate the visualization of the data from your engine, which is nice.

 

Regarding the REST interface, I think there are quite a few off the shelf REST libraries available too, so there shouldn't be any issue with adding it.  The URL scheme is actually no more complex than the list of links that your landing page contains, so I don't see any issue there.  If I recall correctly, BitSquid is actually running all of their tools over a JSON enabled API...

0

Share this comment


Link to comment

Andy, http-parser sounds useful.. thanks.

 

For persistent connections I think you want WebSocket. It's a recent extension to the http protocol, meant to supersede old hacks like 'COMET' and 'long polling'. (Here's a little test code: http://tnovelli.net/junk/ws2/ ... note that the server isn't running so it won't work..)

0

Share this comment


Link to comment

Any recommendations on simple embeddable http server libraries for C++? We do this regularly for debug tools at work, but that is in Java, which is a tad more capable out of the box. And I'm hesitant to take a dependency on Boost just for ASIO (my game is not networked beyond debug tools)...

0

Share this comment


Link to comment

Any recommendations on simple embeddable http server libraries for C++? We do this regularly for debug tools at work, but that is in Java, which is a tad more capable out of the box. And I'm hesitant to take a dependency on Boost just for ASIO (my game is not networked beyond debug tools)...

An alternative to Boost that I was considering is lighttpd, written in C, using the BSD license.

 

I had also briefly looked at Libmicrohttpd (LGPL) and Mongoose (GPL), but licenses dissuaded me.  Your relation to various licenses might differ.

0

Share this comment


Link to comment

 

Any recommendations on simple embeddable http server libraries for C++? We do this regularly for debug tools at work, but that is in Java, which is a tad more capable out of the box. And I'm hesitant to take a dependency on Boost just for ASIO (my game is not networked beyond debug tools)...

An alternative to Boost that I was considering is lighttpd, written in C, using the BSD license.

 

I had also briefly looked at Libmicrohttpd (LGPL) and Mongoose (GPL), but licenses dissuaded me.  Your relation to various licenses might differ.

 

 

I am on the same boat, the problem is lighttpd is not suitable for embedding, or the developers don't care about that, so you're on your own (reference).  Different kind of embedding... should have known.

 

libmicrohttpd and thttpd would be my options, myself leaning towards thttpd because of the BSD license variant, though libmicro is LGPL 2.1, so no problems with propietary code as long as it is a shared library.

 

The problem with both of those is that there is no Windows port, if you use cygwin, you get GPLed, so you'd pretty much would have to create the build scripts to build them with MSVC or MinGW, not that it would be impossible or too complex, but definitely extra work you were not expecting to have.

0

Share this comment


Link to comment

I'm really looking for something that I can drop into my own build system - I don't like dealing with heavyweight dependencies. Makes me miss python, where things like itty exist...

0

Share this comment


Link to comment

What is the benefit of using HTTP over UDP or TCP and a dumb/simple receiving application?


Why bother with that? Why not just build the UI for your debugging etc. directly into the game then?

The point of using known, commodity protocols and formats is you do less work. Your approach requires a shitload more work, and maintenance cost on top of that.

Would you rather write, debug, maintain, and constantly add features to your dumb-and-formerly-simple app, or just use an existing browser that already has all the stuff you could ever want for UI and presentation layers?
1

Share this comment


Link to comment

What is the benefit of using HTTP over UDP or TCP and a dumb/simple receiving application?

jQuery.

Need to be able to configure a list of post-process filters via drag-n-drop? That's a full afternoon with most desktop UI frameworks, and a couple of minutes with jQuery.
1

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now