AS.T.Ro is a science-fiction themed squad-tactics roguelike.  The basic genesis of it was that I wanted a project that I could use to teach myself Java, and feeling inspired by the 7-day-roguelike challenge (though lacking the time to actually compete that week) I decided to write a roguelike in 48 hours – which is to say 48 total hours coding time spread out over a couple of months whenever I could find the time.  Just to jump on as many game development bandwagons as possible I decided to mix it up a little by giving you control of a small squad of characters rather than just the one.  Also, it’s in space!

For the full story of how I got on, you can check out my devlog on TIGSource: here. But, long story short: I succeeded!

Features:

  • Control a team of 4, each with their own strengths and weaknesses
  • Battle 9 different enemy types
  • Use 14 different items
  • Explore strange new worlds, seek out new life and new civilisations and shoot them with lasers

Screenshots:

Play it online here:

http://www.vitruality.com/ASTRo/Version1.0/launch.html

If you like it, let me know.  Even though this version is ‘complete’ there are still plenty of ideas that I didn’t have time to implement, so if there is sufficient interest I wll probably continue to expand it ad infinitum, in the grand roguelike tradition.

 

 

I have redesigned the look of the site a bit, because:

  • The old ‘Vitruvian Man’ header was only ever meant to be temporary
  • The black-blue colour scheme was a bit dark and hard to read
  • I like Lego.

Scientists have calculated that the new look is 1 x 10^9 times better than the old one.  You can tell scientists did it because everybody else would have just said ‘a billion’.

Might be a few more things that I’ll tweak here and there, but its basically done I think.

Now that Super Hover Blast is out of the way I can concentrate more on my next game project.  I’ve actually been working on it for a couple of months already while simultaneously putting the finishing touches to the last one.

The approach this time around is going to be a little different.  I mainly wrote Super Hover Blast as a way of teaching myself the intricacies of C++.  In the design of it my chief concern was with the technical side and the sort of thing that I (as an individual with little previous 3d programming and no C++ experience) could reasonably accomplish.  Of course I wanted to make it fun as well (and I hope that I succeeded – it seems to be doing OK) but in general I set out to make ‘a game’ rather than ‘the best game ever’ or even something that spoke particularly to my own personal preferences.

This time around, I actually hemi-demi-semi know what I’m doing.  Sort of.  A bit.  That means I can afford to be a little bit more ambitious.  I can make the sort of game I want to make, rather than the game I think I can make.  More on that at a later date.

One other thing I didn’t do with Super Hover Blast was to actually tell anybody I was making it until I was 99% finished.  I didn’t particularly want to be just another amateur game creator spending ages telling everybody how great their masterwork is going to be and then forgetting to actually make it.  The downside to that was of course that if nobody knows about it, nobody is going to play it.  So, this time around, I’ve decided to keep a little devlog of my progress.  I’m planning on releasing things a bit more incrementally this time around (hell, it worked for Minecraft) and as it’s going to be a more complicated and technically experimental game some documentation is probably in order.  Also, I have a website now and these things don’t just fill themselves up with trivial bullshit, you know.

Just to prove I am actually working on something, hereafter follows a screenshot of naked bald men standing in a blocky desert.  Oh yeah, I know my audience.

Making it actually look un-arse comes later.

This week, we look at using Genetic Algorithms to solve geometric problems via Grasshopper’s built-in genetic algorithm engine, Galapagos.  Genetic algorithms attempt to mimic the way lifeforms evolve over time, on the basis that if it’s good enough for creating all life as we know it, it’s probably a fairly good tool for helping us develop design solutions.

There are two main things to consider when we are setting up a grasshopper model to use Galapagos.  The first are the input parameters that we are going to use as genomes.  Each genome is a value that controls certain aspects of the design – the height of a wall, for instance, the width of a window, the number of columns etc.  Galapagos will modify these values for us and attempt to find the ‘best’ solution.  At present, galapagos can only do this through modifying sliders, which places a slight limitation on the way we set up the grasshopper definition because it means that everything we want it to be possible to change has to be controlled via a slider.  We can still include other parameters (linked geometry, strings etc.) but galapagos will not be able to modify them for us.  At each generation, grasshopper will fiddle (technical term) with these values and come up with a variety of different combinations.  The best sets of values will pass on to the next generation (either directly or through ‘breeding’ with another value set) – the rest will be eliminated.  The idea is that the population at each generation will become more and more suitable to the task at hand and hence you will be given ever improving solutions to whatever problem you are trying to solve.

The second, possibly more difficult part, is coming up with a way of assessing your model and turning that assessment into a single numerical value that you can use to express the ‘fitness’ of a given design, i.e. giving it a score based on how ‘good’ it is.  This gets especially tricky if you need to consider more than one criteria that are not all of the same importance, since then you need to weight each criteria’s contribution to the final score.  This is mathematically quite easy (you just need to multiply it by a certain factor) but determining what these weightings should be in order to give the best results can take a bit of trial and error.  For some more on this I recommend this blog entry by the mighty David Rutten himself.

Indeed, if you’re thinking of using Galapagos you should probably leaf through the rest of David’s blog – he did write the thing, after all.

For my part, here are two annotated examples that use it:

The first (the idea for which I think I probably stole of of David anyway) uses galapagos to arrange a catenary so that it passes through (or at least, close to) a point, while (as a secondary consideration) minimising the length of the catenary.

Not breathtakingly useful, I know, but it should help to demonstrate the basics.  Get it here: Example6a.ghx (Right click, save target as)

The next one does something a little bit cleverer.  Given a certain set of points, we use metaballs (a form of implicit surface, although in grasshopper they only creates curves, which represent a 2D ‘slice’ through a metaball) to cover as many points as it can while also keeping the total covered area as small as possible.  In this abstract form again this is probably not particularly useful but hopefully it is easy to see how it might be modified for use in masterplanning, for example.

Get it here: Example6b.ghx (Right click, save blahdy blah)

As an optimisation tool, genetic algorithms leave something to be desired.  They need a large pool of test cases at each cycle and are highly random in the way that they work, meaning that they can take many many times longer than a more ‘straightforward’ optimisation routine would and may in the end not actually find the most optimum possible solution anyway.  For this reason, they tend to fall onto the ‘often discussed, rarely used’ pile.  However, they are also a lot more ‘creative’ – possibly throwing up solutions that you might never have considered otherwise.  Given that we are all evolved creatures ourselves, it could be argued that all ‘designs’ are really the product of a genetic algorithm that has been running for several billion years.

This week, we create our own universe.  Specifically, we create a universe with two physical laws:

F = ma, or Newton’s second law of motion

F = G(m1*m2)/r^2, or Newton’s law of universal gravitation

Using those laws, we’re going to simulate a ‘solar system’ of different bodies and plot the paths they make moving under gravitation.  To do this we’re going to use an iterative algorithm; calculating the forces that the planets exert on each other, moving them a little bit, re-calculating the forces based on their new positions, moving them again and so on.

First up, we’re going to create a class to represent the ‘planets’ in our solar system.  We’re going to do this separately using Visual Studio, then compile it as a DLL, a library of code that does nothing on its own but that can be used freely by other bits of code.  There are a couple of advantages to doing it this way – we can re-use this bit of code easily if we need to and we can minimise our time spent using grasshopper’s horrible built-in script editor.

To create the dll, open up Visual Studio/Visual Basic Express and create a new ‘class library’ project.  DLLs are used a lot – RhinoCommon itself is stored in a DLL, and since we want to use some of the RhinoCommon types (points, vectors etc.) our first task is to reference that dll to let Visual Studio know where it is and that we want to use it.  To do this, go to Project->Properties->References and add one to RhinoCommon.dll (should be somewhere in your grasshopper install directory).  Then add this code:


'Before we can use anything from RhinoCommon, we need to reference the .dll
'You can do this in Project->Properties->References

'This imports the Rhino.Geometry namespace so we don't have to type it out every time we use something from there
Imports Rhino.Geometry

'This is the class we will use to represent each 'planet'
'This could be adapted to any kind of agent, however
Public Class Planet

'Each planet has three 'physical' properties
Public position As Point3d
Public velocity As Vector3d
Public mass As Double

'So we can plot the trail of the planet we store all of it's previous points
Public path As List(Of Point3d)

'Constructor:
Public Sub New(ByVal initialPosition As Point3d, ByVal initialVelocity As Vector3d, _
ByVal initialMass As Double)

position = initialPosition
velocity = initialVelocity
mass = initialMass

path = New List(Of Point3d)
path.Add(New Point3d(position.X, position.Y, position.Z))

End Sub

''' <summary>
''' This sub gets called iteratively to update the position of the planet
''' </summary>
''' <remarks></remarks>
Public Sub Move()
position += velocity
path.Add(New Point3d(position.X, position.Y, position.Z))
End Sub

''' <summary>
''' This converts a force into a change in velocity
''' </summary>
''' <param name="force"></param>
''' <remarks></remarks>
Public Sub ApplyForce(ByVal force As Vector3d)
velocity += force / mass
End Sub

End Class

Then hit ‘Build’ to create our actual .dll. VS will put it in the folder for your project under Bin/Release.

Now for our grasshopper part.  Create a script component, right click on it, go to ‘Referenced assemblies’ and use the pop-up form to add a reference to our newly-created .dll.  This will allow us to use our ‘Planet’ class within the scripting component.

Set up the component’s inputs to take a list of points, P, a list of vectors, V, a list of doubles, M, and an integer, T.  These represent, respectively, our planet’s starting positions, initial velocities, masses and the length of time we want to simulate.  Then add this code:

Private Sub RunScript(ByVal P As List(Of Point3d), ByVal V As List(Of Vector3d), ByVal M As List(Of Double), ByVal T As Integer, ByRef Path As Object)

Dim planets As New List(Of Planet)

'First of all, we create our 'planets'.
'Here we recreate the behaviour Of the 'longest list' data matching option
For i As Integer = 0 To P.Count - 1
Dim position As Point3d = P(i)
'If values exist for the other parameters here then we use them
'otherwise, we use the last value in the list
Dim velocity As vector3d = V(math.Min(i, V.Count - 1))
Dim mass As Double = M(math.Min(i, M.Count - 1))
Dim planet As New Planet(position, velocity, mass)
planets.Add(planet)
Next

'All our simulation is going to take place in this loop
'Each step through this loop represents a discrete amount of time
'To simplify things, we've assumed this is equal to 1 time unit
For time As Integer = 0 To T

'First, we check every planet against every other planet and work out the forces each
'pair is exerting on each other
For j As Integer = 0 To planets.Count - 2

Dim planetA As Planet = planets(j)

'By checking each planet only against the planets later in the list, we ensure that each
'pair is only going to be checked once
For k As Integer = j + 1 To planets.Count - 1

Dim planetB As Planet = planets(k)
Dim F As Double
'Here we calculate the force using the formula:
'Force = (mass1 * mass2)/distance^2
'i.e. Newton's law of universal gravitation
F = (planetA.mass * planetB.mass) / planetA.position.DistanceTo(planetB.position) ^ 2
Dim direction As Vector3d = planetB.position - planetA.position
direction.Unitize
direction *= F

planetA.ApplyForce(direction)
planetB.ApplyForce(-direction)
Next

Next

'Now that we have worked out how each planet will be moving, we update their positions
For Each planet As Planet In Planets
planet.Move()
Next

Next

'NOTE: This part *should* work, but doesn't always due to a bug in RhinoCommon:
'=========================================================================================
'Dim outList As New List(Of Curve)
'For Each planet As Planet In Planets
'  Dim crv As Curve = Curve.CreateInterpolatedCurve(planet.path, 3)
'  outList.Add(crv)
'Next

'Path = outList
'=========================================================================================

'Since the above won't work reliably, we instead create a data tree, with the points that
'describe each planet's path stored in a separate branch.  This means we can feed them into
'an 'interpolate curve' component and get a separate curve for each planet.
Dim Tree As New DataTree(Of Point3d)

For z As Integer = 0 To planets.Count - 1
'For each planet we create a new path:
Dim TreePath As New GH_Path(z)
For Each pt As point3d In planets(z).path
'We then add each point to the tree, stipulating the path to use to store them
Tree.Add(pt, TreePath)
Next

Next

'And finally, we output our tree:
Path = Tree

End Sub 

Now plug the output path points into an ‘interpolate curve’ component, stick in some initial variables and you should have some interesting results, or at least interesting messes.  Note that the algorithm is quite sensitive to scale – if you don’t see anything it may just be that your planets are too far apart to have any effect on each other.

You can download the complete example here: http://www.vitruality.com/Teaching/PhysicsExample.zip

I used a script like this when we were in the initial stages of designing the Orbit as a way of defining the centreline of the lattice.  In the end however, this approach proved a bit to difficult to control.  If you play around with it a bit you will notice that it is extremely sensitive to initial conditions.  Move one of the starting positions even slightly and it will totally change the result you get.  Since for the Orbit we needed to have finer control over the form in order to get something that was structurally feasible (we were going for visually unstable, but not actually unstable), in the end we abandoned that idea and went for something a bit more manual.

But, while this script might not be particularly useful for this reason, this basic structure could be modified for any sort of physical simulation or agent-based generation (dynamic relaxation, boids, pheremone-based stuff, etc.).  The only things that you’d need to change would be the controlling equations (in this case, the gravitation formula)…

Well, it’s finished.  Ladies and Gentlemen, may I proudly present…


(version 1.1, .zip, 49.3Mb)

Super Hover Blast, as mentioned in the earlier preview, is a free 3D action/puzzle game that I’ve been working on for a while now (about 18 months on-and-off, I think) and which I have finally decided to release into the wild.  It began as a project to create a physics engine from scratch and to teach myself C++ and morphed into something a bit more…

Tasked with single-handedly bringing down the regime of the evil kitten-hating General Al Imakhbeel, your mission is to clear out a series of heavily-defended military bases.  However, to make things interesting the only weaponry at your disposal is a hovercraft armed with a powerful – but basically harmless – air cannon.  The enemy, on the other hand, has missiles, machine guns, land mines, spinning blades, pointy spikes and a whole load of other tools of destruction.  If you’re going to survive you’ll need to figure out some way of turning their own weapons against them…

The game then is kind of a shoot-em-up but without any actual weapons.  Your air cannon does zero damage but can be used to clear your path of obstacles, push enemies into hazards, deflect missiles…  Completing each level requires a certain amount of point-n-shoot skill, sure, but it also needs clever positioning, lateral thinking and forward planning in order to defeat all the enemies in each stage using only the weapons and traps they’re trying to use against you.

The best description I’ve managed to come up with for how this works in practice is “a bit like billiards, only in real-time and with all the balls trying to murder you”.  If that sounds vaguely appealing to you then here’s that download button again:


(version 1.1, .zip, 49.3Mb)

Then simply unzip the file somewhere on your computer.  To change your display options run setup.exe.  If you enjoy it, please tell your friends!

Credit where it’s due: The game uses the 3d graphics engine ‘Irrlicht’ by Nikolaus Gebhardt and his crew; the music is by Kevin Macleod; everything else is by me, but with help, playtesting and advice from: Kim Loo, Dustin Gunn, Robert Garford-Tull, Daniel Brown, Daniel Sheppard and everybody who posted something in this thread.

Update 28/02/2011: Version 1.1: Added support for AZERTY keyboards and added some missing .dlls for the setup utility that somehow avoided inclusion the first time. Sneaky .dlls!

Four examples this time around, showing how to take all that sexy VB.NET stuff we covered last time and stick it in grasshopper.  First up, a super-simple example of how you can write your own version of the standard line component.

Using the code:

Private Sub RunScript(ByVal P1 As Point3d, ByVal P2 As Point3d, ByRef A As Object)
'This subroutine is the one that will be run whenever the component is updated.
'Note that the names and data types we set up outside the code are here as subroutine arguments
'The last one is our output - it is 'ByRef' so that changes we make here are not merely local</p>
Dim L As Line 'This declares that we are going to be using a line called 'L'
L = New Line(P1, P2) 'This creates a line using one of the built in constructors that takes two points
A = L 'This sets the line we have created as our output object A.

End Sub

You can download the example here: http://www.vitruality.com/Teaching/Example3.ghx (Right click, save as…)

That example will follow the same basic rules on data-matching as most other components; namely if you input a list or a tree it will be run once matching the first item in both lists, again with the second and so on.  If you want, however, you can take control of how that works by bringing in lists of objects as inputs instead.  This can be set up by right clicking on an input and selecting ‘List Access’:

This script will take two lists of points and draw a zig-zag between them.

Private Sub RunScript(ByVal P1 As List(Of Point3d), ByVal P2 As List(Of Point3d), ByRef A As Object)</p>
Dim i As Integer
'We calculate the maximum index we're going to go to.
'This is the minimum of the highest indices of the two lists
Dim maxi As Integer = math.Min(P1.Count, P2.Count) - 1
Dim OutList As New List(Of Line) 'This is to store our output lines

'Here we loop through both lists
For i = 0 To maxi
'We take the ith point from P1 and the ith point from P2 and draw a line between them
Dim fromPt As Point3d = P1(i)
Dim toPt As Point3d = P2(i)
Dim L As New Line(fromPt, toPt)
'We add our line to the output list
OutList.Add(L)
'If there is another point still to go in P2...
If i &lt; P2.Count - 1 Then
'...we do the same to the ith point from P1 and the (i+1)th point from P2
Dim ToPt2 As Point3d = P2(i + 1)
Dim L2 As New Line(fromPt, toPt2)
OutList.Add(L2)
End If
Next

A = OutList 'This will set the output of the component

End Sub

Aaaaand you can download it here: http://www.vitruality.com/Teaching/Example3a.ghx (Right click, save as…)

Now things get a little more interesting.  All of the above could be done in grasshopper just using the built-in components, but there are a few things that are impossible in grasshopper normally but that we can do via code.  One of these things is recursion, which you might recall is the tool we use for creating fractals.

So, the next example uses this principle to create a fractal branching structure.  Here’s some I made earlier:

Which were made with this script:

Private Sub RunScript(ByVal startLine As Line, ByVal Factor As Double, ByVal Angle As Double, ByVal Axis As Vector3d, ByVal Iterations As Integer, ByRef branches As Object)
Dim OutList As New List(Of Line)</p>
'Start the branching
Branch(startLine, factor, angle, axis, iterations, outlist)

branches = OutList

End Sub

'&lt;Custom additional code&gt;

'Branch() is a separate subroutine so that we can call it recursively from within itself
Private Sub Branch(ByVal startLine As line, ByVal factor As Double, ByVal angle As Double, _
ByVal axis As vector3d, ByVal iterations As Integer, ByRef outList As List(Of Line))
'We pass in everything we need to calculate the new lines.  Note that outList is ByRef so we can change
'the original rather than just create a copy

If iterations &gt; 0 Then
'Vectors have 'operators' defined, meaning that we can use them in mathematical equations like numbers
'Operators are things like + - * / etc.
'This is vector subtraction, i.e. |A| - |B| = (A.x - B.x, A.y - B.y, A.z - B.z)
Dim VectorA As Vector3d = startLine.To - startLine.From
VectorA *= factor 'This scales our vector by a factor

'We want two branches, so we create a copy of vector A:
Dim VectorB As New Vector3d(VectorA.X, VectorA.Y, VectorA.Z)

'Then we rotate them in opposite directions:
'Vector3d has a built-in 'Rotate' sub we can use for this.
VectorA.Rotate(angle, Axis)
VectorB.Rotate(-angle, Axis)

Dim LineA As Line
Dim LineB As Line

'The endpoint of our new lines will be the end of our starting line plus our vectors
Dim EndPointA As Point3d = startLine.To + VectorA
Dim EndPointB As Point3d = startLine.To + VectorB

'We now draw lines from the end of our old line to the points we just found
LineA = New Line(startLine.To, EndPointA)
LineB = New Line(startLine.To, EndPointB)

'We add the lines to our output lists
outlist.Add(LineA)
outlist.Add(LineB)

'Now we use recursion (calling a function from within itself) to branch further
'Note that we subtract one from the iterations.  This lets us 'count down' branchings and stop.
Branch(LineA, factor, angle, axis, iterations - 1, outList)
Branch(LineB, factor, angle, axis, iterations - 1, outList)
End If

End Sub

Get the definition here: http://www.vitruality.com/Teaching/Example4.ghx (Right click, save as)

And finally, here’s a tweaked version of the Branch() subroutine that does the same thing in 3d:

Private Sub Branch(ByVal startLine As line, ByVal factor As Double, ByVal angle As Double, _
ByVal axis As vector3d, ByVal iterations As Integer, ByRef outList As List(Of Line))</p>
If iterations &gt; 0 Then
Dim VectorA As Vector3d = startLine.To - startLine.From
VectorA *= factor

Dim VectorB As New Vector3d(VectorA.X, VectorA.Y, VectorA.Z)

'======================================================================================
'This is the only bit that's changed: we now rotate twice, once about our given axis and
'again using the line itself as an axis (we copy vector A again to use as this axis)
Dim NewAxis As New Vector3d(VectorA.X, VectorA.Y, VectorA.Z)

VectorA.Rotate(angle, Axis)
VectorA.Rotate(math.PI / 2, NewAxis)
VectorB.Rotate(-angle, Axis)
VectorB.Rotate(math.PI / 2, NewAxis)
'The key thing is that by rotating it the second time, we are changing the plane that
'the branches are in.  We thus need to rotate the first rotation axis as well
Axis.Rotate(math.PI / 2, NewAxis)
'=====================================================================================

Dim LineA As Line
Dim LineB As Line

Dim EndPointA As Point3d = startLine.To + VectorA
Dim EndPointB As Point3d = startLine.To + VectorB

LineA = New Line(startLine.To, EndPointA)
LineB = New Line(startLine.To, EndPointB)

outlist.Add(LineA)
outlist.Add(LineB)

Branch(LineA, factor, angle, axis, iterations - 1, outList)
Branch(LineB, factor, angle, axis, iterations - 1, outList)
End If

End Sub

Which you can download here: http://www.vitruality.com/Teaching/Example4a.ghx (Right cl- oh, you know the drill by now)

For reference, here are some lecture slides that go through some of the fundamental theory behind object-oriented programming as it relates to VB.NET.  It’s primarily aimed at people moving to VB.NET from RhinoScript, but is possibly still a useful reference for anybody else interested in starting out with Visual Basic as well.

Download it here:

VisualBasic.pdf

The main example this week doesn’t use grasshopper at all, instead it is a simple standalone application written in Visual Basic to calculate the areas of different shapes.  Not the most useful tool in the entire universe, but hopefully it does demonstrate how concepts such as classes, inheritance and polymorphism can be implemented in VB.NET.

This example was created using Visual Basic Express 2008; to recreate the form create a new windows form project and set up a form with Text Boxes called ‘WidthBox’, ‘HeightBox’ and ‘OutputBox’, a ComboBox called ‘TypeCombo’ and a Button called ‘CalculateButton’.  (Since this is a grasshopper course not a Visual Studio one I won’t go over again how to set this up: google is your friend here.)  Add code like this:


Public Class Form1

'This subroutine will get run whenever the 'CalculateButton' is clicked by the user
Private Sub CalculateButton_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles CalculateButton.Click

Dim W As Double
W = CDbl(WidthBox.Text) 'Extract the data from the 'WidthBox' textbox and convert it (if possible) to a Double (Double-precision Floating Point Number)
Dim H As Double
H = CDbl(HeightBox.Text) 'And the same for height...

'Here we declare that we are going to use a Shape.
'Note that this will not actually *create* a Shape
Dim Shp As Shape

If TypeCombo.SelectedItem IsNot Nothing Then 'This if statement merely checks that something has been selected by the user

If TypeCombo.SelectedItem = "Rectangle" Then
'This line actually creates a rectangle and stores it in 'Shp'.
Shp = New Rectangle(W, H)
'Even though Shape and Rectangle are different types, because Rectangle derives from Shape we can still store it as such
'(i.e. a Rectangle is also a Shape)
Else
'Ditto for triangle:
Shp = New Triangle(W, H)
End If

'At this point in the code we don't necessarily know what *sort* of shape we have here, because 'Shp' is just generically defined as a 'Shape'
'However, we don't actually *need* to know.  When we call Area() the right function will be called depending on the class we have actually stored.
OutputBox.Text = Shp.Area()

End If

End Sub

End Class

'Shape is a base class, which means that it only exists to hold the code shared between our Rectangle and Triangle classes
Class Shape

'These are properties which will be common to all Shapes:
Public Width As Double
Public Height As Double

'Shape has no constructor (a 'New' subroutine) - this means you cannot actually create an instance of this class.

'By declaring this function 'overridable' it means that we expect classes which inherit from this to have their own Area() function to replace this.
'By defining this here in the base class, it means that we can access the function Area() from objects which are simply dimensioned as a 'Shape'
Public Overridable Function Area() As Double
Return 0
End Function
End Class

'Rectangle is one of our sub-classes of shape, that represents a rectangle(!)
Class Rectangle
Inherits Shape 'This line sets the rectangle as inheriting from 'Shape'
'Because Rectangle inherits from Shape, it will automatically have all the properties and methods that Shape has.

'This is a constructor - any class that you want to be able to create an instance of will need one of these of some form, even if it's empty!
Public Sub New(ByVal WidthValue As Double, ByVal HeightValue As Double)
Width = WidthValue
Height = HeightValue
End Sub

'This replaces the Area() function in Shape with more specific code for Rectangles
Public Overrides Function Area() As Double
Dim A As Double = Width * Height
Return A
End Function

End Class

'Triangle is our other sub-class of shape, works pretty much the same as Rectangle:
Class Triangle
Inherits Shape

Public Sub New(ByVal WidthValue As Double, ByVal HeightValue As Double)
Width = WidthValue
Height = HeightValue
End Sub

Public Overrides Function Area() As Double
Dim A As Double = Width * Height / 2
Return A
End Function

End Class

You can download the complete source code here:

ExampleAreaCalculator.zip

This example creates a ‘pixellated’ (to be more exact, voxellated) approximation of any solid or surface by eroding a 3D grid of cubes until only those within a certain distance from your target object remain.

You can download the annotated definition from here:  http://www.vitruality.com/Teaching/Example2.ghx (right click, save as)

This example demonstrates how to create a conditional definition (equivalent to an ‘if’ statement in code) inside grasshopper.  A function component is used to evaluate whether a condition is met, and the boolean result from that is used to sort objects into ‘pass’ and ‘fail’ groups.

This is also a useful definition in and of itself, since it can be used to approximate any shape and (although I’ve used a cube grid here to keep things simple) could be easily adapted to use any kind of packing system.

I didn’t actually know about this until I accidentally stumbled accross it in iplayer, but Cecil Balmond (my boss when I was in Arup’s AGU (Advanced Geometry Unit), until he went off to do his own thing) did a radio series for the BBC a little while ago about the evolution and use of mathematics in design.  As it turns out, they’re pretty good, and well worth a listen if you’re at all interested in anything ever.

You can listen to all three episodes here.

Episode 3 is where he gets into the sort of things that we actually do for a living, but episode 2 in particular is well worth listening to for the part where Cecil interviews the previously mentioned (and sadly recently deceased) Benoit Mandelbrot.  I geeked out a bit over that part and it sounds like Cecil did too.

© 2012 VITRUALITY Suffusion theme by Sayontan Sinha