Posts Tagged with “ideas”

A New Light for the Graphical Adventure?

Rendering Synthetic Objects into Legacy Photographs from Kevin Karsch on Vimeo.

This mind-boggling technical demonstration from Kevin Karsch et al. from UIUC shows just how far algorithmic interpretation of imagery has come. The possible uses for it are many and varied, but the potential for games has really piqued my interest.

Read More »

Game Design Themes: Sacrifice

[verb] Give up (something important or valued) for the sake of other considerations

Giving up. It’s not really something you associate with the timed-reward structure of most games. Gamers have become accustomed to a steady accumulation of, well, pretty much everything, so who in their right mind would ask players to give something up?

Read More »

Design Doc: Scavenger Wars


Hybrid race / collecting / combat game set inside derelict spacecraft. 2D overhead space ships in zero gravity; small arenas with environmental hazards. Single player against AI, possible multiplayer. Read More »

Grow Your Home

A great idea from Mitchell Joachim. Not sure meat houses are ready for the public, but growing wooden houses from vegetation is a radical and brilliant solution to ecologically-friendly communities.

Five Things I’m Thinking Right Now

Alice did it, and from there I’ve found some more interesting people doing it. So to throw myself aboard a bandwagon (and break a long dry spell without posting), here are 5 things I’m thinking about right now:

Read More »

Dear Meg Hillier, The Digital Economy Bill is Unjust

Dear Meg Hillier,

As a constituent whose career and majority of personal communications are conducted across the internet, I’m very worried that the Government is planning to rush the Digital Economy Bill into law without a full Parliamentary debate.

The Bill contains measures that favour the protection of commercial interests at the expense of an individual citizen’s rights – specifically measures that allow copyright holders to issue requests to limit or even terminate the internet connections of private individuals based only on the belief of the copyright holder that the individual has infringed their copyright. In effect, this creates a situation outside the bounds of a fair and just society where a person can be punished by the withdrawal of a service that the UN is proposing be considered a basic human right.

Read More »

PyPlants – Now with added dimensions

PyPlants has come on in leaps and bounds over the past few days (well, evenings), and now from its new home as PyPlants on bitbucket sports a completely rewritten rendering backend which is more modular, should be really easy to plug into, and now supports POV-Ray out of the box.

What’s that you say? A 3-D ray-tracer? Yes indeed, as promised in the second part of this series of development diaries, I’ve now finished work on an update that turns this:

("A", "I+[A+O]-->>[--L]I[++L]-[AO]++AO")
("I", "FS[>>&&L][>>^^L]FS")
("S", "SFS")
("L", "['{+f-ff-f+|+f-ff-f}]")
("O", "[&&&C`>W>>>>W>>>>W>>>>W>>>>W]")
("C", "FF")
("W", "[`^F][{&&&&-f+f|-f+f}]")

Into this:


Rendering of an olive bush from pyplants povray renderer

Unfortunately it’s now 2am, so the write-up will have to wait for the weekend. Do feel free to grab the code and have a poke around. You’ll obviously need povray, pygame, and pycairo installed, but everything else should work with python’s included batteries.

Procedural Plants in Python – Part 2

In the previous part of this article we looked at the background to L-Systems, and how they could be used for describing self-similar biological systems. In this part we’ll look at a sample implementation of a very basic 2D L-System in Python, together with a basic PNG renderer using PyCairo.

This is an implementation of a deterministic, context-less L-System, which given the same initial conditions will always produce the same results. Whilst this won’t produce very naturalistic results for our plant system, it’s a useful first step to produce results like this:

Test render of a D0 L-System

Read More »

Procedural Plants in Python – Part 1

For a fledgling project idea, I’ve recently needed to work out how to draw plants procedurally, and of course Python is my language of choice for some rapid prototyping. Whilst some richly-featured professional applications exist for generating flora in a procedural fashion for high-end rendering, there are precious few systems available for the kind of bulk task that I require.

At first the task of generating plants might seem like a massive endeavour. The various permutations of stem widths, lengths, branch frequency, colour variation, leaf size, shape, frequency and mind-boggling. And that’s not even considering the problem space represented by flowers.

Fortunately, the problem of representing self-similar biological development is one that attracted Aristid Lindenmayer, who in 1968 introduced L-Systems:

… as a theoretical framework for studying the development of simple multicellular organisms, and subsequently applied to investigate higher plants and plant organs. After the incorporation of geometric features, plant models expressed using L-systems became detailed enough to allow the use of computer graphics for realistic visualization of plant structures and developmental processes.

(Lindenmayer’s book The Algorithmic Beauty of Plants is no longer in print, but is available for free in PDF.)

L-Systems are remarkably powerful, simple systems that express the development of a formal grammar through a parallel rewriting process. In effect, you start with a string that represents certain graphical operations, and a set of rules for rewriting the string. You iterate over the string a certain number of times, and are left with a final product.

For example in a 2D system, the symbol F represents drawing a straight line in a forward direction, the symbol + represents rotating left, and – represents rotating right. If you start with the string “F”, and a rule that says “(F → F+F−F−F+F)”, then you’d see the following iterations:

  1. F+F-F-F+F
  2. F+F-F-F+F+F+F-F-F+F-F+F-F-F+F-F+F-F-F+F+F+F-F-F+F
  3. F+F-F-F+F+F+F-F-F+F-F+F-F-F+F-F+F-F-F+F+F+F-F-F+F+ F+F-F-F+F+F+F-F-F+F-F+F-F-F+F-F+F-F-F+F+F+F-F-F+F- F+F-F-F+F+F+F-F-F+F-F+F-F-F+F-F+F-F-F+F+F+F-F-F+F- F+F-F-F+F+F+F-F-F+F-F+F-F-F+F-F+F-F-F+F+F+F-F-F+F+ F+F-F-F+F+F+F-F-F+F-F+F-F-F+F-F+F-F-F+F+F+F-F-F+F

If you then plot those rules using a unit vector length and an angle of 90 degrees, you end up with the following iterations:

  1. Single iteration of a Koch Square
  2. Second iteration of a Koch Square
  3. Third iteration of a Koch Square

There are several more symbols that can be applied to the graphical operations, including pushing the current position and orientation onto a stack and popping it off again, rotations in 3D, and operations to define closed polygons and moving through colour and size lookup tables.

The most basic type of L-System is the deterministic context-less system, D0L, where each operation is independent and will always produce the same output. The Koch Square above is one of the most simplistic examples, but with a couple of variations much more complex patterns arise:

  • Start: “X”
  • Rule 1: “(X → F-[[X]+X]+F[+FX]-X)”
  • Rule 2: “(F → FF)”
  • Angle: 25 degrees
  • Iterations: 5
  • Sample 1

In Part 2 we’ll look at a first approach to implementing L-Systems in Python, and a rudimentary renderer for 2D systems using PyCairo.

Ten Things I’ve Learned in a Start-Up

Ten things I’ve learned as a developer at WooMe:

  1. Be clear what your direction is. Identify your key proposition and focus on it. Don’t get distracted by unrelated features – somebody else is probably already doing those better than you.
  2. Be merciless with features that don’t cut it. No matter how much you like it, if your audience doesn’t like it, either change it or kill it fast. Wasting time on your personal pet project when there’s no clear demand for it is time you should be spending on features users want.
  3. Use what’s already there rather than inventing your own. Need a message queue? Video processing? Load balancer? Email distribution? Payment system? Use something that already exists rather than waste time you should be spending on feature development.
  4. Quick and dirty is better than late to market. At the rate this industry moves, capturing your audience’s attention first is more important than having a well-engineered solution. For the most part, users don’t care about your code quality, as long as it works.
  5. Don’t optimise until you need to. Sure, you may end up chasing your tail for a bit when you need to scale, but until you hit that point you’re wasting valuable time that should be spent on feature development.
  6. Scaling is most often a data problem. When you do need to optimise, scaling won’t be about the performance of your application. Scaling web applications horizontally is easy. Scaling databases vertically is expensive. Scaling databases horizontally is very, very hard. Don’t worry about what web application framework you use, worry about what database you put behind it.
  7. Abstraction is great, as long as you understand what you’re abstracting. This has been a constant pain with Django’s ORM. Yes, it’s a powerful and useful abstraction, but without a solid understanding of what the database is doing behind it, it’s easy to get into very deep trouble, very quickly.
  8. Log everything. Nothing is harder than trying to find problems on a live environment without detailed logging.
  9. Storage is cheap. It’s better to store everything than to throw away data. You never know when you might need something.
  10. Communication is critical. Not just outside your organisation, but within it. Tell people what you’re doing, frequently. Ask them what they’re doing just as often. Not only do ideas percolate through this process much more effectively, but when things go wrong, clear and frequent communication will stop them from getting worse.