the Fiddler's picture

The Open Toolkit demo, stage 1: brainstorming

Project:The Open Toolkit demo

With 1.0 beta-1 out of the door, it is time to open the discussion on the OpenTK demo.

Why do we even need a demo?
In my opinion, a demo is useful for three main reasons:

  1. to attract attention and sell the features of the library
  2. to provide a concrete application as a reference for users and as a test case for the library itself
  3. to act as an experimental testbed, where new features must prove themselves before becoming part of the core library

There are other reasons for creating a demo application, but the bottom line is that this will be beneficial for both users and developers of OpenTK.

What will the demo contain?
This is ultimately up to the community to decide. A few rough ideas to get us started:

  • it should be possible to implement in a reasonable time frame
  • light on artwork, to avoid large downloads (can it fit in 10MB?)
  • (related to the above) procedural generation for graphics?
  • scalable to older hardware (to the extent possible)
  • it should be something interesting, i.e. something more than "yet-another-parallax-demo"

What could fit inside those constraints?

One idea: split-screen, 2-player deathmatch. Each player controls an aircraft and tries to shoot down his opponent. Can take advantage of simple physics and procedural terrain generation. Relatively simple to implement.

Other ideas?

Can I help with the demo?
Glad you asked! The first step is to decide what the demo will be (brainstorm!) The second step is to define with a very rough design document (which features it will include and which features it will not include). The final step is to implement this.

This topic is about the first step, so share your ideas!

Where can I get the source code?
Once the code becomes more mature, proper packages will be made available. Until then:

  1. Install an IDE (Visual Studio 2008 Express Edition, MonoDevelop 2.0 & 2.2 and SharpDevelop 3.0 are all fine. Higher versions will work, too.)
  2. Install git (Windows, Mac OS X, or "sudo apt-get install git-core" for Ubuntu).
  3. Run git clone git:// from a terminal, or from the git gui (on Windows, right click a folder and select "Git GUI here").
  4. Open Demo.sln and hack at will!
  5. git commit -a . to commit your changes to your local branch (or click the "commit" button in Visual Studio).

It will immediately become obvious that the code is currently pre-alpha quality. It contains an incomplete but usable graphics abstraction layer, as well as a working fractal terrain generator (if you know how to perform correct normal mapping on terrain, please drop a hint!)


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Inertia's picture


d) port a game from C to C#, e.g. Quake 3: Arena

sysrpl's picture


I'd say do not, do not, port a game, existing demo or reuse any other idea which has already been done.

Make opentk stand out by creating original demos, not recreating things that have already been done. I've seen quake ported to too many tool kits to care about what's next.

I recommend a few original demos (possibly with some injected humor) which emphasis creativity and technical achievement. Highlight the core strength of opentk: flexible, easy to use, and highly productive

Here is an example:

I've had an idea mulling around my head since viewing this video clip. And this might not be possible with opentk since it involves a taking a screen shot to a texture and registering a system hot key, but here goes ...

Write a humorous demo which over emphasizes (using effects galore) a common computer task. Create a demo which hides in the background, waiting for a special hot key to be pressed. Pressing the hot key causes your entire desktop to crumble into a black hole vortex. The entire screen forms a worm hole effect as your screen travels down a twisting and turning laser light filled hole until it reaches an all powerful "search" screen suspended in space. You type a search term and press enter or click the glowing god like "find anything" button. When the button is pressed the vortex reverses itself and warps you back your desktop. As the demo seamlessly ends a google window (from the default browser) is spawned with your search query and results.

flopoloco's picture


iliak: I think that Quake 3 is a beast to port... In the same idea, Quake 1 seems simpler and gets more points for the "nostalgia" factor.

nythrix's picture



I've had an idea mulling around my head since viewing this video clip.

You made my day. I got tears in my eyes. Oh boy...

AdrianPi's picture


Hi There, Me too I would like to contribute

flopoloco's picture


Many people willing to help, which is good. I am not used in collaborative projects, how can we collaborate?
Simply commit to SVN? Or should we make stuff and send them back to Fiddler?

kvark's picture


Guys, lets not bother Fiddler too much about the demo.
It would be perfect to have a separate project for the demo with it's own infrastructure (coordinator, programmers, designers).
Who is willing to rule and take responsibility?
But of course, the project is quite interesting (more than developing OpenTK I guess), so I understand why HE can't just give it away.

the Fiddler's picture


If this is not already obvious, I'm fully intending to take the back seat on this project. I will provide artwork, programming support, infrastructure and generally help in other any way I can, but - once things are up and running - I hope this can become a community project that we can all be proud of.

For this reason, I really appreciate your offers for help.

My proposal (how I think this can work):

  • Use a fully distributed version control system (DVCS), like git. In my experience, DVCS has a small learning curve in the beginning but it makes collaboration much easier in the long run, compared to something like SVN.
  • The code is currently hosted on Sourceforge, in the same place as OpenTK. We can either keep things this way (by granting access to this repository) - or we can fork the git repo and host it somewhere else. Either is fine by me.
  • With a DVCS, the workflow is typically like this: first, you clone the repository onto your computer. The result is a fully working repository, where you can hack and commit your work at will.
  • Once you are satisfied with your work, you can either publish your personal branch(s) and issue a "pull request" or you can create a patchset (by email or bug tracker).
  • Your patches will be reviewed by at least one other person and (once it is known they work correctly) a committer will take your branch and merge it into the master branch.
  • In this model, everyone is free to clone the code and hack on it equally (unlike, for example, SVN). Public review / committers help maintain quality.

Before we get to the coding part, I'd propose collecting the brainstorm ideas and finding some common ground on what we want the demo to be. Once we have that, we can think up specific features and create a specific list of tasks. Everyone interested can pick a task and start working towards it (with help from all other members). Once ready, tasks are merged into master and when enough tasks accumulate, we make a release.

Finally, I think it's best to start small. Set an achievable goal, work towards it, release. Iterate. Without this, interest is likely to wane after a few weeks and the project will slowly die.

So, who is willing to rule and take responsibility? :)

Inertia's picture


Is there any reason why there should be only 1 demo? Might aswell do multiple ones, depending on the number of participants.

Can only talk for myself, but I'd not be very motivated to work on a game, especially not a game that has anything to do with vehicles (yeah, I completed Crysis pretty much on foot). I might contribute some cloud-layers effect (would be an interesting challenge) but that'd be it. I'd be willing to come up with some effects for a demo, but tbh I liked the idea to remake the Voyager intro sequence so much, might even do this solo just for fun.

kvark's picture


There is no sense of planning N demos until we have at least one semi-working.
And I'm against a game. The simpler it will be - the better, because it increases a chance of it to be born.
Can't contribute much, because working on my own demos/games/engine.

In a perspective the projects build upon OpenTK will best serve as demos.
But it can't be forced, so making a simple 'official' demo is a good idea.