Samstag, 10. September 2011

Bottleship: New Update

Just rolled out the latest changes to the Bottleship web service, here's the list:

  • A preview at the right shows your picoid at pixel scale and updates as you paint.
  • Clicking the preview downloads your picoid as a PNG.
  • Due to popular request, brown has been replaced by orange.
  • Picoid remixes are now retrieved from the server instantly, without delays.
  • Picoid remixes are rendered at their original size.
  • Painting with transparent color actually shows a transparent brush.
  • "Picoid" and "Community" buttons in the header are now on the left. The "Picoid" button has been changed to "+Picoid" to hint that this is the way to add a new picoid.
  • Footer has a link to the bug tracker now, labeled "Problem?".
  • Internal: picoid implementation uses arrays instead of typed arrays, which should help with slightly older browsers.

Montag, 22. August 2011

Bottleship: Scripting Woes

What happened so far? Work on the client/server skeleton is finished. The client can now authenticate with the server, and there's a minimal chat client in place that allows all participants to communicate.

I tried both Lua and NodeJS for the server implementation, but finally settled with C++ and Boost.Asio, mostly because that eases sharing code between client and server application. I'm using Redis as a Database backend, and we'll see where that gets me.

The part I'm now working on is the actual creation part. I figured I'd start with a really simple primitive, a quad, on which to get a better understanding of how to implement the network synchronization, database storage & broadcasting infrastructure.

I wanted the tool with which the player is placing the quad in the world (nicknamed "The Billboarder") to be implemented in the magic script language already, to figure out how players could write their own tools.

I started off with an implementation in Lua, using Luabind, but kept having concept issues. I had yet to figure out how to terminate a CPU-hungry script or pass security contexts around. There was also no guarantee that each Lua context was perfectly sandboxed. I had to basically reimplement half of the base library myself to build a whitelist of functions that were allowed to use. To top it off, Lua has an unusual syntax, and I was wondering if maybe something more popular would feel more right.

I moved from Lua to Google's notably fast V8 JavaScript engine, which is written in C++, very well thought out in terms of security/access contexts, memory handling and parallelization. Unfortunately, while there are rather nice boost::python like C++ templates for binding Lua, there is no such thing for V8: V8-juice and V8Convert are just plain weird and cproxyv8 comes close, but is incomplete. I've spent the entire Sunday writing my own set of boost::python style bindings, and it's just no fun, because I want to get done with the actual task at hand, not despair on some shitty ass template metaprogramming.

So, as it seems, I'm going to have to write the bindings using V8 only, by hand, with a handful of helper functions. It sucks, but there is really no other way.

Montag, 15. August 2011

Bottleship: Awesomium, Client/Server Architecture

I scrapped the Native Client idea, mostly because there is no access to local resources, which makes caching large volumes of data impossible. It would have been fun to just roll out the client to the browser, but apparently it's not ready for prime time yet.

I wanted to embed Bottleship in Chrome, now I'm embedding Chrome in Bottleship - fate is not without a sense of irony, it seems. Doing everything on the OS level enabled me to integrate Awesomium. The windowless embeddable port of Chromium is a commercial solution, but usage is free for indie developers. Wolfire of Humble Indie Bundle fame is using it for his latest game, Overgrowth (Lugaru 2).

Playing around with Awesomium

I'm now doing all 2D UI's in Awesomium, which takes a huge burden off my shoulders, and allows me to write larger volumes of UI in shorter amounts of time.

A more serious use for Awesomium.

Moving on to client and server parts, I picked Node.js for the server prototype, with Redis as a fast DB backend, and possibly MongoDB or CouchDB for archiving content. As the client is written in C++, I'll be using Boost.Asio for networking. I'm not sure what kind of serialization method I'm going to use for packets, possibly either Protobuf or BSON. Initial communication will be TCP, with a reliable UDP protocol to be added later.

If you network coders have any ideas regarding the infrastructure, I'm open to suggestions.

Samstag, 13. August 2011

Bottleship goes Native Client & Game Specs

So I spent yesterday evening porting the Bottleship codebase to Native Client 0.5, which wasn't too hard, considering that the naclports project has already ported the most important libraries, such as SDL, Lua and Boost.

Native Client's 3D accelerator API is going to be GL ES 2, which doesn't provide a fixed pipeline, so I had to write basic shaders to get my pixels back on screen.

Unfortunately, a bug that prevents NaCl running on systems without enough consecutive unfragmented memory (1 GB) makes it hard to continue testing.

So I'm going to write a bit about the specs I had in mind instead.

Every player will need to get a personal account, which is password protected. Early players will be invited, later on viral invitations are possible, and at some point we'll require a small one-time fee to register an account, so we can keep the spammers and troublemakers at bay.

When the game starts, the player logs in with her username/password. If this is a recurring visit, the player will resume the game where she left off. If this is her first visit, she will start off at the Ego, a place which acts both as her administrative world and her in-game menu.

The player sees worlds from a first person view by default. The move controls require a combination of mouse and keyboard. The player is able to move freely within three dimensional space, as if diving in deep water. By default, WSAD maps to forward/backwards/left/right, Q and E are up/down, and the mouse controls the view direction.

From the Ego, the player can create, visit, rename and delete her TroomsTrooms represent separate worlds, which can be built and edited by the player. The name stems from the German word for dream, "Traum", which contains another German word, "Raum", which means "Room".

Every newly created Troom is both infinite and empty. The player is confronted with a blank world that asks to be populated with the players inventions. The player can now conjure things into her Troom, using the Imagenry and her Palette.

The Imagenry is the ark of ideas, located within the players Ego. It presents itself as a large room, in which the player can store one copy of every thing that she has created, invented or encountered. In the beginning, the Imagenry contains only a gray 1x1x1 cube, and a Vanifier.

The Palette is a surface located at the bottom of the players screen, which acts very much like a painting palette. Initially, the Palette is empty. The player can visit the Imagenry any time and add things onto her Palette by clicking the thing she would wish to add with the left mouse button.

In her Troom, she can then click anywhere with the left mouse button to use the thing currently selected on her Palette. Using the mouse-wheel, she can cycle the currently selected thing on her Palette.

When the gray cube is used, it will conjure a copy of itself at the position that the player is pointing at. If the player is pointing at a surface, the cube will stick to the surface. If the player is pointing at another cube, the cube will perfectly align with the other cubes surface.

The Vanifier looks like a laser gun and works like an eraser. When the player points at something and holds the left mouse button, the Vanifier will shoot a ray towards the object, and the object will begin to glow red. When the maximum intensity has been reached, the object will implode, explode or simply disappear. If the player keeps holding the button, the charge time will gradually reduce, and subsequent objects can be erased faster and faster.

Whoops, dinner is ready. More later.

Freitag, 12. August 2011

We Need To Go Derper: Bottleship 2.0

The hands keep coding, but they just can't keep up with the thinking machine, can they? Once again, fear, uncertainty and doubt crept upon me.

I realized that it would be almost impossible to aggregate all assets for this game in a satisfying amount of time, especially character design and animations, no matter if 2D or 3D - the amount of work I have to put into learning stuff and making art is simply too big, no matter how you turn it.

Which led me to an even earlier, 8 year old idea, which I had investigated into, even wrote some code. I abandoned the idea because it didn't feel right at the time. Apparently, times have changed, and we might talk about it as a viable alternative again.

The idea is simple: a game that contains nothing and allows everything. A "Second Life from scratch". A "Minecraft in space". a "4chan in 3D". Players start off in the void and model/code their world around them. Each player has his own 3D universe in which he's allowed to create anything. Players can visit each others universe and experience each others creations. Players can share a universe and create something together.

Created assets can be shared with, and modified by other players. Programmers can script games or mod the games of others, and reach for the assets of artists to give their game a face. Artists can replace assets in games programmers have written, and create new items, characters and landscapes free to be used by whoever comes along.

The result is a game that in itself is a "game, machinima and meme reactor", something that allows everyone (including me) to realize his entertainment ideas without having to drum up a team first.

The project keeps its name, "Bottleship". A few weeks back I registered "", and now I've got a good reason to use it.

Bottleship will run in your browser, and utilize Google's new Native Client technology and GLES 2 to render its content. The reason why I refrained from doing anything in the browser so far is the horrible state of Javascript/HTML/CSS, its unpredictable performance, peculiarities and implementation.  But now that I can do C/C++, SDL, OpenGL, Audio in a browser without having to install any plugins, I believe the time is right to get a project like this going.

Dienstag, 9. August 2011

Voxel Pause, Game Continue

Had trouble thinking today, riots and stock crash kinda made me worry how long I could still be creative before the heaven of Europe is going to fall on my head.

Spent yesterday evening reading Cyril Crassin et al.'s 2010 article on GigaVoxels and started seriously worrying about content production, framerates, memory and disk space consumption.

I'm starting to think that this is possibly a bit too much for the project, and the idea I'm having could also be realized as an isometric or zelda-style top-down game, with classic pixel graphics.

We'd be able to stem the work load in shorter amounts of time, and still could realize everything the game mechanics require. There can still be in-place level editing and scripting, and if the concept runs well with the public, I could go back to voxels or whatever is best in 3D, and do it again - just like GTA 2 compared to GTA 3 ;)

Since it's now less about technology and more about content, it couldn't hurt to tell a bit about the ideas of the game.

Essentially, the game is a multi-plot role-playing game set in a smaller city or large town. The town is a "clockwork city": it has inhabitants, but each character is persistent - they do not disappear behind street corners. Each has his/her own appearance, back story, job, habits, life goals and plan for the day.

I'm saying "Plan for the day", because there is just one day. It's a "Groundhogs Day", in that whenever you play, you play only this day. You are able to jump into almost anyone of these characters and play the day from their perspective. Then, when you switch character and start the day again, the people you played before will reflect the changes you made:

Let's say, you played a cop, and because you're feeling mischievous, you grab your gun and you shoot everyone you can find. The next (same) day, you play a milk man, and this time you plan to perform your duties as your job requires you to, but no, there's this cop coming around the corner and shooting you - and you know, you brought this onto yourself. You have to go back to the cop and fix the mess you created.

And this is pretty much the goal of the game: get everyone to be closer to their life goals at the end of this particular day.

That's about it.

Samstag, 6. August 2011

Rendering Sparse Voxel Octrees

In just a few years of time, Sparse Voxel Octrees (SVO's) will be a state of the art technique. Right now, we're at very early stages, with Minecraft providing us with in-game editable voxels at the scale of 1 meter edge length per block.

After I spent another few days on Minecraft servers, exploring the possibilities of the game and the various modifications that its fans have made, I saw that there is a strong wish for a more expressive resolution. On servers like The Voxel Box, artists keep pushing the envelope, using the ambiguity of block designs to repurpose each design for various meanings, e.g. fences are also wooden support structures or lamp posts, and signs are also used as arm rests for couches.

I would like to go further, and get my engine down to 1/16th of the resolution, allowing artists to edit the world at 1/16th of the scale, which is about ~6cm edge length.

Already, Minecraft has troubles managing its data mass, but I'm hoping it's merely inefficiently coded, I know, for instance, that the hierarchy it uses is not entirely octree balanced. Surely, with better distribution and a slim SVO data structure, those troubles might become more manageable.

I know that the data mass might eventually become too large, and needs to be saved to disk - but for simplicity, I'll start with keeping everything in memory.

After talking to a good friend, who is deep into raytracing and cutting edge CUDA/OpenCL computing, I tried a raymarching approach on the CPU first: The renderer casts an individual ray per pixel, which is collided against the octree recursively until a voxel has been found.

The approach isn't fast on a single core, but I might be luckier with the same process running on the GPU using OpenCL. My GeForce 8800 GTS 512 (G92) is perfectly capable of doing generic purpose calculations, so I can bypass all the OpenGL shader madness and port the code directly.

Another important job lies in producing content. Like Minecraft, I will most likely use a combination of generated landscapes and hand edited content. The landscapes will most likely be based on 3D perlin noise functions, controlling density, and later on, temperature and humidity, which can be translated into biomes.

For hand editing, I want a "Deluxe Paint" toolset for voxels, which means standard brushes of various sizes, copy/pasteable brushes, mirror/smoothing effects, palettes and so on.

Today I ported my codebase from my own small linear algebra library to GLM, a GLSL-style vector library for C++. The transition went smoothly.

The next step is now porting the raymarcher to OpenCL.