by Mikko
I had a quick idea for an experiment. Started writing it on the train going home from work and finished it went I got home.
Maybe it will become more or maybe not.
(sorry for the frame rate drop from when I was recording, first time recording in HD)
_Posted in flash
by admin
As planned last week, the team turned our regular code review session into a 2 hr game development challenge. Basically we wanted to give team members the opportunity to flex some classes they don’t necessarily see on a regular basis. Deliberately we assigned developers with tasks they would have the least familiarity with. Another important goal of the exercise was focused on team communication. When working in tight deadlines within a team environment fluid communication between team members is paramount.
The timer had been set and the team broke into pairs. The paired teammates discussed their approach and generally speaking one team member per pair was at the keyboard while the other observed what was on screen.
Aaron and Sunil were charged with the sea mines. Nick and Mikko were working on the dock and general game framework. While Salpy and Michael worked on the sea itself.
What resulted after just a little over 2 hrs of development was a functional prototype that was tracing key game events. Really the game was less polished then everyone wanted to see it but in truth the objective had been met in a little over the allotted time. As much as i wanted to blow a whistle and pull the plug on the workstations a la Top Chef, a terrific vibe was present that felt too good to arrest.
The team is working on a tight deadline this week and probably into the next but there is a collective will to post the game once we’ve had a chance to give it that little TLC it needs.
Stay tuned!
_Posted in Category==Null
by admin
At Jam3, the development team meets every month for Code Review. The session usually serves as a venue for sharing coding practices, discoveries, and reviewing actual code from recent projects and talking about the jobs ahead. But at our next meeting in July we are going to do something different. We are going to build a game in 2hrs.
We are treating this more as an experiment and than a race because we primarily want individuals assigned to aspects of the game’s programming they have the least experience in.
A clock will start running after a quick 10 minute briefing at which the game concept will be broken down and assignments made to team members. Few graphics will be provided and the team will be encouraged to create effects and interpret the game design document.
Here is a crude diagram showing the game:
I will be writing a follow-up post in a week where i look forward to sharing the experience. Heck we might even stream it live over ustream!
_Posted in Category==Null
_Tagged 2hr, code review, development, flash, game, rapid, session, team
by Mikko
In this post I want to look in detail at LookMaps.
Click on the example below to see how look maps work:
Since some Voxel models can have 10,000+ voxels (or 3d pixels) it could be very intensive to for example tint every single voxel.
To put it into perspective imagine looping through 10,000+ colours and calculating their new colour every single frame, and then along with that also calculating new positions for 10,000+ particles. Traditionally this is how things would be done each particle contains it’s own colour.
Instead what I’ve done with the Voxel Engine is create a separate look map. A look map is essentially an array of colours and then each voxel (or 3d pixel) has an index that points to a colour in a look map.
Think of an image on the internet most likely every single pixel in the image is not going to be a completely different colour but instead colours are repeated. This is the basic idea behind the “look map” to have a colour pallette to create an image.
In the above example you may have noticed that when you were clicking on different colour swatches you would see the colours in the voxel model also change. We were essentially changing colour values in the look map without changing the index at which each voxel is pointing at.
Ok so every single Voxel Model has a LookMap. During the rendering process what actually happens is that when the renderer is rendering a model it will grab that models look map and tell it to render “something” at a specific 2d position.
So what that means is that the LookMap actually performs the physical rendering. This allows us to do some amazing things…
For instance in the above example you can see small squares not pixels being rendered. What’s actually happening is that this models look map is a “FillRectLookMap”. Essentially instead of rendering pixels (PixelLookMap) it’s rendering rectangles or squares.
Of course there is also a “BitmapLookMap”. Check out the example below where instead of drawing pixels or rectangles we are drawing bitmaps:
Again since we are using lookmaps we can quickly and easily change which bitmap is being rendered for which voxel. Another note is that because we only have 10 bitmaps to render and entire model we are using a lot less memory than each Voxel having it’s own BitmapData that would be rendered.
_Posted in R&D, Voxel Engine
by Mikko
At this point in the development cycle for the Voxel Engine I find it’s a good time to just play around with the engine. This way the engine gets debugged and I also get to see what works and what doesn’t work from a coding perspective.
Adrian and Pablo really wanted me to make a drawing app. So the recording above is what I’ve got so far. It’s not perfect but I think you can get some pretty nice results using it.
I’d also like to mention that my nose isn’t that crazy and I have quite a bit more facial hair.
_Posted in R&D, Voxel Engine
by Mikko
I thought it was time to talk about the Voxel Engine and how it all works.
Below is a diagram describing the different pieces of the voxel engine:
There are four major parts to the Voxel Engine:
_Posted in R&D, Voxel Engine
by Mikko
Make sure you press and hold down the mouse button:
We are displaying every fifth slice from this MRI image or so to keep the head proportional. (otherwise the head would be super wide):
_Posted in R&D, Voxel Engine
by Mikko
This experiment shows off a “particlized” voxel model:
Music by Massive Attack-Paradise Circus
_Posted in R&D, Voxel Engine
by Nick
Well, not really, but i figured with all the HTML5 and Canvas hype i might as well give it a go. So i decided to port the pseudo 3D application i wrote for www.stemcellcharter.org. Turns out canvas is pretty cool, and it runs pretty well to boot, well, at least on webkit browsers. It runs pretty well on Firefox too, but you can see it stutter every once in a while.
If you want to see the actual page, Click here to get a taste.
I will definitely be looking into the canvas a bit more, but like Mikko said, i don’t think this is the “Flash Killer” just yet. But hey, I’ve got no problem experimenting with it. Its a nice break from Flash anyways.
What to build next…
by Mikko
Last night I decided it was time to take a break from the Voxel Engine and work on the Voxel Engine. HEH…
I know that makes no sense but basically I started thinking with all this hype around HTML5 and Canvas I better try to build something in HTML5 and Canvas in order to know what it’s all about. With HTML5 and Canvas being touted as the “Flash Killer” I decided to try and see if it was possible to build the Voxel Engine using Javascript and the Canvas tag.
Here is a short video of the Javascript Canvas based Voxel Engine running in Safari:
You can see it in action by clicking below.
However we recommend that you use Safari or Google Chrome:
Click Here To See It in Action
This was an interesting experiment but from this I can say that right now HTML5 and Canvas is NOT yet the “Flash Killer” it’s being touted as. The performance on this experiment is quite a bit lower than what Flash can produce. I mean it doesn’t even run in Firefox, and this is the core of the problem with HTML and Javascript for years, browsers just aren’t built the same.
_Posted in Canvas, HTML5, R&D, Voxel Engine