Friday 31 December 2010

Due Update

It's been a while since my last update. After a tiring 26 and a half hours of continuous work to make the deadline, I needed some time off from XNA. I got started again earlier this week though and I have a few teaser screenshots to show you guys.


The placeholder shells colliding with the environment.


The new shell models. (By Bo our 3D Artist)


Transparency/cube-map test for scope on Assault Rifle. (using Arbitrary model)


Dummies, a much easier way to align muzzle flashes and shell positions with the weapons.

The new (WIP) Gizmo. The current release on Codeplex is pretty outdated feature-wise. An updated release should be up soon (no ETA available yet)

Other upcoming tasks include, motion-blur on the shells, depth of field on the weapons and a proper muzzle flash among other cool stuff...

Sunday 21 November 2010

Updated SgMotion for Sunburn 2.0.6

SgMotion v1.2 for Sunburn 2.0.6 is now available on Codeplex!

Mostly changes to the Sample and removed some older unused classes that were causing trouble with the new XNA 4.0

The PlayerMarine.fbx class seems to loose his Animation clips in XNA 4.0 for an unknown reason. I have tested this issue with some of my own animated models, and they still work fine (using KW-Xport)

If you run into similar issues with your own models, I added a small *.xml file that demonstrates a quick way to split the model into custom animation clips (Note, default clip name in .fbx model is "Take 001")


Tuesday 2 November 2010

Project Sunburn: AI-Subsystem (First Dronetype & AI-Manager)

We completed our first playable prototype yesterday, and it includes AI! This was the first time I worked on game AI, previous games like Needle Juice and Over Night did not include any form of AI. Luckily our enemies are robotic, not human. It's a lot easier to create a believable drone that in-fact should act as if it's programmed compared to a humanoid character running around trying to act as a sentient being. So far the main drone class, the Spider-Drone, has been implemented and is strolling around in our game. Other drone types (including flying drones) will be added later in phase 2. (started yesterday) Below I wrote a very short summary of certain AI aspects that I included so far.

A lot of the info a drone requires is processed in a global manager class. This makes it easier to spread the workload across multiple frames, avoiding frame drops. One example is the Link Availability, testing the links against active drones in the level, blocking a certain link if a drone is not moving (shooting or idle), and therefore blocking that path. This avoids unnecessary navigation errors when drones try to reach the player.

Red lines indicate the path is blocked...

Another task that is handled by the AI-Manager is tagging waypoints as cover. As certain drone variations will hide behind cover to deploy their weaponry. These kind of non critical components are updated on low frequencies to safe CPU-cycles. In addition, only waypoints near the player can be tagged as potential cover.

The Yellow waypoints are tagged as "Cover"

All drones have some kind of weaponry to use against the player. Our first drone has a light machine gun, firing short bursts of bullets. Their weapons work very similar to the player weapons, so it was easy to setup. The turret tries to maintain a solid aim at the player (limited by its rotation speed) and fires bullet salvo's while trying while trying to get closer. In addition, the lens in front, can be destroyed by a single well-aimed shot. This basically counts as a headshot and immediately disables the drone.

These are some of the highlights currently implemented as part of the AI-Subsystem. In the upcoming phase I will spend more time optimizing the current manager, add air-drones, improve path-finding and improving overall behavior of the drones.

Wednesday 13 October 2010

Post-Process: Motion-Blur Effect

A simple Motion-Blur post-process based on the GPU Gems 3 article.

Editor Update: Clone-tool with ClonePreviewer

You can simply drag your clone to the desired location while using the scroll-wheel to determine the amount of clones you like. The process is finalized by pressing the Enter key.

The preview models share the same instance of the source model, rendered with an offset for each clone. The translation is snapped to the current grid size, alternatively you can use precision-mode (Shift) to fine-tune your clone-offset. Works with any type of placeable entities, however entities without a model (particles etc.) use simple boundingboxes/icons to show their destination. This may change in the future, where even particles may be fully rendered while previewing.

Tuesday 12 October 2010

Creating Line-based Animations with the SketchTool

A Proof of Concept to animate objects, particles and lights using the Sketch tool.

The position and normal (of the colliding triangle) and stored and converted to an animation file (shared with the already built-in Animation Editor). These can be plugged into any script to easily animate objects, lights or particles in the environment.

Sunday 10 October 2010

Effortless Waypoint & Path creation using 3D-Sketching

About 3 weeks ago, I demonstrated the Sketching in 3D Tool. Today I went a little further and expanded it to be able to create waypoints and paths for our upcoming levels without effort. Manually placing waypoints can be a tedious task, especially if your level is continuously changing in its early stages. With this new Tool we'll be able to create full AI paths in seconds, with easy tweaking after the initial waypoints are setup.


Currently there are two types of lines. WaypointLines and AvoidanceLines, the latter is used to state certain parts should simply be avoided by the AI or to break paths that are too close to geometry or ledges.

Monday 27 September 2010

Triangle-precision ray collision

Bullet collision was previously calculated using the triangle mesh capabilities of BEPU. This wasn't going to work efficiently with all the separate meshes that are going to be used in our levels. With the basics of triangle-picking already implemented in the editor tools it didn't take a lot of time to get a basic prototype up and running. In the image below you can see the new filtering algorithm.

each "group" (1 big sphere, 8 small ones) contain 41k polygons. (click image to read the text)

In a regular scene with a higher amount of objects with lower polygons per mesh that are spread across the scene, the optimization methods will become more efficient. This will be tested once the prototype level is complete.
The main focus of the new filtering system is excluding hidden models before they enter into the per-triangle collision check. This system is added on top of the bounding-sphere filter that was already present in the editor tool.


Overkill? 150 million triangles both rendered and tested against the bullet ray. This clearly wasn't going to run smoothly (roughly 0.1 fps)

Video:
(use 720p and fullscreen to read the filtering info in the topleft corner)

Saturday 18 September 2010

Engine Update: Sketching in 3D



Over the past 2 months I haven't posted a lot of news. With the new project up and running (kick-off was the 13th) I'll start doing more regular postings like I used to.

With the project details still being worked on, there is some time to develop tools that should make life easier later on in the development stage. So I decided to work on some odd ideas that I came up with while traveling. The first one is a pretty cool feature, its sketching in 3d. It uses the 3d meshes inside the level as a canvas to draw on. I think this is very useful for level designers and to help process play-testing feedback.


For this particular feature to work, triangle precision ray-testing was required. Luckily the XNA Creators Club had a sample project to get me started. The lines are made of vertices combined into a LineStrip. In addition the triangle normal is tested against the ray direction to prevent drawing on back-faced triangles.

While implementing triangle-precision picking I updated the Gizmo so it is now able to select models by triangle instead of the small boundingbox. Being used to 3D studio max' selection methods I decided to implement multi-layer selection. Because that name probably makes no sense, I'll try to explain it. If multiple objects are behind one another, clicking multiple times will select the object behind the previously selected object, clicking again will select the one behind it etc. That means you can select any object even if another is blocking your view.

Each click will pass through another "layer" and select the object occluded by the one in front.

Tuesday 7 September 2010

Level & Content management [Part 3]

I got a question about my level and object management recently and was asked if I could talk about it. So in this post I'll explain my old and current method of dealing with (level) serialization and how I combined it with my game editor.

A few months ago I created my levels using a hybrid implementation of a level editor and code to create and connect objects. A game would have several "Scene" classes to be filled with Entities and later set at the correct position in 3D space using the level editor. This worked pretty well, especially since our team had limited time to work on our projects (8 weeks) so I wasn't able to create a fully featured editor at the time. One advantage was the ease of setting up connections and events between objects in a level, because everything is available in the Scene class. An obvious disadvantage was the inability of adding objects on the fly (in runtime) it required some planning to work efficiently. With the game Needle Juice there was only a limited about of objects that required the use of the editor, so again, a fully featured editor wasn't necessary.

However, after completing Over Night I set aside some time to work on a more complex editor to aid in the upcoming project(s). This meant a new way of serializing the Scene to store any data. This new method will be explained below, with some code snippets. On a side-note I strongly recommend looking at existing editors (like UDK) Fool around with it, learn its basics and see what fits your needs and what doesn't. I occasionally opened up an existing Unreal Tournament 3 map and messed around with it to hunt for new features. If you're the only developer to use that tool you can mold it to your exact specifications and preferences very easily.

Before I go on, the following is in no way the only or the best way of doing it. It worked for me and should be easy to implement for yourself. It will hopefully give you a clear idea of you can combine your own requirements with the examples shown.

First off, any object that exists in my level is an ISceneEntity (interface) with a Position, Rotation, Scale etc. The interface holds data that is necessary for any object in the world. Any class that derives from this interface or any other subclass may have its own properties that need to be serialized as well. That means a flexible serializer is required. Luckily Shawn was so kind to explain everything you ever wanted to know about IntermediateSerializer. I recommend you read through his article.

To store all data in your level your engine needs to know what to serialize and what to ignore. I use a fairly simple Level class to keep track of any objects currently in the world (and part of the serialization list) You add your Entity to a List in your Level class. The IntermediateSerializer will go through the list and store all Entities in an Xml level file.

To actually store your level you need to call the IntermediateSerializer.Serialize() to write all of the level data to your disk.

The above method is part of the Level.cs class.

If you're following along, don't forget to add the Microsoft.Xna.Framework.Content reference to your project folder. By default its already part of your Content project, when referencing in code, you need to add it to your game project as well. The IntermediateSerializer class is part of the Microsoft.Xna.Framework.Content.Pipeline.Serialization.Intermediate namespace.

Your level is now stored on disk. Some class will require setting some Attributes in order to be stored properly. Use the [ContentSerializerIgnore] Attribute over any public property that you want excluded. Use the [ContentSerializer] Attribute to include private or protected variables.

Finally to load all of your previously stored data you need to call IntermediateSerializer.Deserialize(). For more info I recommend reading through some of Shawn's articles about it.

I was going to talk about a new feature (mentioned in my previous post) that allows preloading of assets, reducing overall idle-time. This post is already long enough so I'll keep it in mind for some other time.

I hope this helps anyone looking to create his own editor. Level serialization isn't a complex operation, the most important thing is properly structured component system. If you have any questions you can post your comments in the comment section below.

Sunday 29 August 2010

Engine Update: New Features & Tools!

It's been a while since my last post. That means I had a lot of time to add new features and spend more time on existing features as well. I'd like to include them in a video soon, for now I'll do a quick rundown of the most important new additions to the engine.

Preloading of Assets
Load Models, Textures, Video, SoundEffects in the background (Separate Thread) before the complete level is setup. The engine reads part of the level file and pulls out all the required assets for the upcoming level and load them before the game initiates a level transition.


Undo/Redo system
I Finally took the time to integrate this into the editor. For now it works primarily on SceneEntities (anything part of the level) and can undo translation/rotation/scale.



System messages
The system will "ping" important messages and warnings to the top-left corner of the screen, warning you of possible errors. (See above)

Game Properties Window
Allows you to set Engine properties as well as user-defined game properties, very useful when debugging.


3D Text Buttons
Selectable by mouse, useful for either ingame activators or 3D menus. Text is baked into a texture at runtime and stored on disk.


Improved Object placement
It's now possible to add objects using the Quick-menu (right-click popup) objects will be placed on the position the mouse is pointing in 3D.

Maya style navigation/orbit camera
Holding down "L"-key will orbit the currently selected object, scroll-wheel will zoom in/out.

VisualScript & AnimationEditor improvements
Added a lot of new Node-types and added the ability to directly add an animation to a new script.


Material editing inside VisualScript
All (Sunburn) material effects are stored and can be accessed using Script Nodes. Useful to dynamically set textures and other shader properties etc.

File browsing inside VisualScript
to easily attach files (Textures, Models, Levels etc.) to a Script Node.


I consider these the most significant changes/additions to the engine. Other things will show up in the next video.

Soon a new project will launch, lasting 4 months in total (instead of the previous 8 weeks we were given when building OverNight & Needle Juice) It's targeted towards XBLIG (Xbox Live Indie) and should be the first game to be fully developed (previous projects were prototypes, not full games) and released on that channel. I'm looking forward to get started, and will of course update on the progression of the game...

Wednesday 28 July 2010

Engine Update: Shaders & Editor Additions

It has been a while since my last update. The image below shows some of the things I've worked on these past few days...


So what's new? First off, the shaders might have caught your attention, the lava is flowing and the arrows are flashing which you can't see in the still image unfortunately, I'll make sure to include them in the next video. They were really just experiments to get some practice with shaders and was hoping to use it for a material editor I was working on (had to put it on hold for now) Still, I think they look pretty cool (especially when you see them in motion)

The next thing you can see on the image is the ContextMenu (pop-up menu that appears when you right-click) Its part of the Editor and is rendered inside of the XNA Game window. XNA is still running as it is used to, winforms is added to the XNA window not the other way around.
As you can see there are several useful options inside this pop-up window. You can quickly add new Entities, add selected entities to your current script and continue playing or restart the level using the changes you made in edit-mode.

Hopefully I'm able create another video soon, showcasing some other additions that were added over the past couple of weeks. In the meanwhile I'm working on a game prototype, this directly aids in build the engine as well...

Sunday 11 July 2010

Core Engine: Creating a simple level (Video)

I'm back with another video, this time I'll show you the creation of a (very) simple level. With The purpose of demonstrating some of the new additions, including the Animation Editor and the updated Visual Scripter. The video playback speed is set to x2 to reduce the overall length. Hopefully you'll enjoy watching and get a bit of insight in the engine's development capabilities.


The menu system shown in the video above is a WIP, originally all level objects were added at build-time. It's a big change in overall engine design to get these things working flawlessly with the new system. The core is aimed at rapid development and tweaking of the game/level while playing. It's been like that since day one and the new system should compliment that, increasing flexibility of the engine and speeding up the overall process of creating games.

Thursday 8 July 2010

Visual Scripting Editor (Video)

It's 6:45 in the morning and the scripting editor is finally ready for a short demonstration. Spend most of the time cleaning up the node-system and made it a LOT easier to add additional node types in the future. The scripts are now directly stored inside the level file and can be stored separately if desired (for re-use in other levels)

In the video you will see two simple scripts, one animating a box and the other toggling a point light on and off. You'll also see the new Level Manager window, more on that later.



(Watch in HD & Fullscreen!)

Monday 5 July 2010

Scripting for Artists (and programmers)

My last entry was over a week ago, but I've been very busy with C# nonetheless. The most interesting (to me at least...) is a visual scripter I've worked on for the past 4 days. It's supposed to work very similar to UE3/UDK's "Kismet". If you don't know what Kismet is, don't worry it is explained a little further in this entry. Although the visual scripter or artist-scripter (as it would be most useful to non-programmers) is not the only thing I've worked on (Animation Editor is another thing that is currently WIP), but I'll only talk about scripting for now.

The past couple of days I used MEL (scripting in maya) Unity Scripting and Dragon Age scripting. They all are terrible to get into. They are probably great if you spend a lot of time learning them, but I usually spend only a very limited about of time on any of those scripting languages. Now for "us" programmers it's not that hard to learn a scripting language if you take the time, but for artists and level designers whom only occasionally need to write a script it's very helpful to have a tool like Kismet. See below...

Example script made in Kismet.

Kismet is not designed to replace the regular scripting language in UE3...it's a tool to help create simple (and sometimes more complex) scripts for level specific behavior. The more complex and game wide scripting can only be done with the regular scripting language. Even though I'm a programmer and can probably live without this tool, I still decided to create something similar, as a challenge, a cool new feature and because it could prove to be very useful when working on our next game...

So far, the basic system is in place and working properly. I hadn't really worked with Winforms nor Event driven programming before, so this was a great way to get into that.

My own visual scripter implementation (visually still very unpolished)

Progress so far: A new script can be created at runtime, nodes can be dragged around, connections between nodes can be created and the whole script can be saved and reloaded to and from the hard drive. A few simple scripts have been created so far (ea. playing an elevator animation when the player enters a volume)

Similar to Kismet, you can load an animation file (previously created in the Animation Editor, more on that later) and play it when the assigned trigger is fired (Can be something like a level has completed loading or the player entered a trigger volume).

I should be able to demonstrate all this in a video shortly, first I'll continue working on essential usability features...
Be sure to keep an eye on my YouTube Channel if you'd like to get an early glimpse of the Scripter in action (I'll upload a video as soon as I feel it's ready to be recorded)

Monday 28 June 2010

Post-Processing Volumes

This time I'll keep the words to a minimum and let the images speak for themselves...(more info below)

Base Image

Increased black-point

Cold tint

Warm tint

If you've ever tried Post-Process Volumes inside of UDK/UE3 then you'll be familiar with the concept. I've tried to replicate a lot of its features. You can affect highlights, midtones and shadows (as seen in the images above) as well as bloomscale, blur, noise etc. They all react to the position of the player (inside or outside of the volume) and will transistion between the values when you enter/leave the associated volume. I'll upload a video of that later on...On a sidenote, I've made a lot of progress with the animation editor, more info on that will be available later on just like the video :)

Saturday 26 June 2010

Engine Update: (Finally?) Switching to Winforms

You might argue it's about time the engine got a proper interface, I agree :) I was trying to avoid using winforms (to keep compatibility with Xbox easy and maintainable to name a reason) and using the console for most if not ALL runtime actions (except for the Gizmo) I had my reasons for not using winforms, but after rethinking the overall design of the engine, its time to do things a little bit different...

One of the reasons that got me doubting the usability of the current interface is a new (and still WIP) feature for creating animations at runtime. The goal of the Animation Editor is not to create complex character animations, but rather allow the creation of quick and dynamic animations for rigid objects such as doors and elevators. At first I made it compatible with the Console like any feature prior to this one...It works, but is definitely not the best way to do animations. It's hard to know what keyframes are used, and what the timelines looks like...I made a very simple elevator animation (with acceleration and deceleration) and it does work...however it's not very flexible, at all.

That got me thinking and finally got me to try winforms...After an hour of experimenting, it finally worked. I'm pretty new to winforms, but it surprised me how easy most things can be achieved with very little effort. For starters I made a "Search Actors" window as well as a "Object Properties" window. Both are shown below. (Click on image for full-size)



The Search window can be activated using "Ctrl-F" like many other applications, clicking the "properties" button with an object selected will show its...properties.

I have a few other browsers/windows I'd like to get working on in the next couple of days (Tracker window, Content Browser, Animation Editor) I'm currently looking at UDK (Unreal Development Kit) for inspiration on browsers/windows. Their Content Browser is pretty great, and would really help with game development if Core Engine had something similar.
During development of "Over Night" we did lack a proper naming convention and both the asset naming and asset count quickly got out of hand. In the end it took a lot of time to find the proper texture file or locate a specific model.

I think I've talked enough about winforms for now :) I've got a few other features lined up, most of them are already working properly, but are still in early alpha stage...

Sunday 20 June 2010

Engine Update: Scripting, ReverbVolume & Tracking Window

The first one is the ReverbVolume as seen in other game engines like Unreal Engine 3. The volume is very useful when defining rooms,allowing you to alter sound properties when either inside or outside of the volume. The volume alternation is already working when inside or outside of the volume, ironically the only thing that is not yet in place is the Reverb effect itself. I'll explain ReverbVolumes a little more in-depth later on once I've completed finished it, hopefully including the actual Reverb effect instead of just the volume/pitch modifiers. In the video on the bottom you can see/hear it for yourself.

The white box is the reverb volume, the blue circles are ambient sounds emitters (or actually the radius of the emitter)

Another concept I've been experimenting with is a sort of Tracking Window (or output/clipboard window) It's an additional (and optional) window that you can use to print out useful information. You can choose to print it as a static string. As a sort of clipboard/memory aid to help with Vector positions or pretty much any piece of info you may need to remember in runtime. If it were nothing more than that, it would pretty much be an in-editor notepad...So I added something I like to call "live-tracking" (or real-time tracking, or just tracking...) You can use the tracking feature to keep track of any property an object may have (positions, rotations, scale, volume, pitch, visbility etc.) the window uses a series of Slots that can be filled with one traceable object each. Most of it is already working, I'll have to spend some more time on it to add every little detail. Eventually I'd like to have each slot assessable and allow user input to change any of the properties that is being tracked by the window. You can see a sneak preview of it in the video below.

The tracker window is tracking the positions of 3 objects in the scene.

The last thing I worked on today was a basic scripting/event system. In both "Needle Juice" & "Over Night" the event code got really messy over time, requiring a lot more time to find anything...which is a complete waste of time, especially when you're nearing the end of a project. In order to prevent this from happening again I need to have a solid and clean system to handle events and scripts. So far I redesigned the TriggerVolume class used for any positional triggers and added support for Enter/Leave Volume events. To test the new system I made a (simple) script that opens and closes a door when the player approaches.

All of the described features above are shown in the short video below. Make sure to turn on your sound, because the reverbvolume can only explain itself with sound ;)


The first sound you hear is that of a bar, the second is a bit more difficult to hear, it represents the streets just outside of that same bar. when you move through the door, the indoor sound will fade to a lower volume while the street ambient becomes more noticeable.

Saturday 12 June 2010

Over Night: In-game screenshots

A collection of in-game screenshots taken during development of our project "Over Night".












Over Night: Official Trailer Released!

The first official gameplay trailer of "Over Night" a game made in XNA.

The game was created within 8 weeks with a team of 4 students (and some additional outside help, see below for the full team setup)




The Team:

Mitch Manders (Design & Modeling)
Jorry Rosman (Concept Art & Textures)
Bas Babroek (Game Programming)
Tom Looman (Engine/Tech Programming)

Special Thanks to:

Paul van Gent (Audio)
Marvin Nooitgedacht (Video Editing)
Davy Jacobs (Animation)
Bo van Oord (Desert Eagle modeling, textures & animation)
Jeffrey van der Heul (Modeling)

Friday 11 June 2010

Over Night: Deadline reached!

We have finally reached the deadline of our project "Over Night". We had our final presentation (10min long trailer & making-of) yesterday with some time for others to actually step in and play the game themselves. We're very pleased with the results with only 8 weeks development. Below is a first (dev) video of the game, the trailer will be uploaded tonight...

Video: (Be sure you watch it in HD)

More development videos will be online once I get home.

Monday 31 May 2010

Engine Update: Major Editor/Gizmo Updates

I've spend some time adding new features to the editor and gizmo to increase overall usability and development speed. The lack of (gizmo)precision among other things started to bother me and was slowing down development of our prototype (only 10 days left!) I've compiled a short list of the most significant changes and additions and turned it into a small video.



Friday 28 May 2010

Dust Particles with Lights & Shadows [WIP]

About time for another video, isn't it? We thought it would be cool to have some kind of dust particles floating around near the windows in our game, so I started experimenting with dust + lit particle effects. Unfortunately the DPSF particles won't receive any of the Sunburn lighting calculations, so I made a basic particle system specifically for the dust trails. Currently they receive light and can cast shadows etc. The effect is a bit exaggerated to create a lightbeam effect.

Be sure to watch it in HD if you'd like to see any dust at all! :)

Thursday 27 May 2010

Video: Reflection & Refraction + FluidVolumes

I just finished a short sample video that demonstrates another combination of Sunburn + BEPU. The video contains both the Reflection/Refraction sample from Sunburn and the FluidVolume feature that's part of BEPUphysics.

(Sorry for the first glitched second of the video, it happend when Youtube converted the video)

On a side note, we've made some amazing progress with our upcoming game "Over Night" all footage/development videos will be released in about 2 weeks. We have been invited by Microsoft (NL) to pitch a demo once we have finished our prototype! We're very excited about that of course :)

Sunday 16 May 2010

BEPU with Sunburn integration Source Available!

The sample project is finished! :) The source download link is available below.

A quick rundown of todays progress. Multi-threading got added (very easy thanks to BEPU) Cleaned up the code to hopefully help you quickly understand one of the possible ways to fix and maintain a relationship between your physics & your visuals. Spacebar will spawn a lot of spheres into the scene and left/right button will shoot sphere(s) from your current location. Leave your Feedback, Questions or just your thoughts in the comments section below ;)

Image:


What's inside?

* One of the possible ways to combine your physics with your visuals.
* Commented lines explaining the code required to setup BEPU in your Sunburn project
* A basic scene (default start kit from Sunburn) with some additional dynamic objects
* Multi-threaded physics
* A ragdoll
* DebugDrawer to visualize boundingboxes
* Actor class that combines Entity & SceneObject

The "Blades" mesh isn't using his own dynamic collision yet. May be something for a future release ;)

Don't hesitate to report any bugs or other suggestions...

Source link HERE. Enjoy!

(Sunburn is required to run the sample) More info on BEPUphysics here.

Saturday 15 May 2010

Sunburn with BEPU physics: Day 1.

I've started working on a sample combining BEPU physics with the visuals of Sunburn. Almost everything is working so far, the code will need some minor cleanups before I'll release it. The purpose of this sample is demonstrating one of the possible techniques you can use to combine the physics with the visuals. The source is not yet available. I hope to have it ready & uploaded before the end of the weekend.

For now here are some images & a video :)



The video is using the default Sunburn sample LightRig.

Wednesday 5 May 2010

3D XNA Gizmo v0.2.0 Released!

A new update has arrived. You can download the latest release HERE. The most notable addition is rotation and scale functionality that's been added to the gizmo. Switching between the different modes is done using the keys 1,2,3 on your keyboard. Download the sample and get started!

Sunday 2 May 2010

Game Update: Storage Room Video!

Storage Room WIP video is done! You can see most of the (textured) storage room models we have so far (without the desk etc. the artist is currently working on it)

I will have more in-game footage tomorrow (TV, updated phone camera etc.)

For now here's the video:



Friday 30 April 2010

Game Update: Dual scene feature working!

Hi,

One of our most important mechanics is now finally working! It's the smartphone camera that can see a different world/dimension. By using the phone's built-in camera the player can uncover hidden objects and hints throughout the world. In addition, the camera can see ghostly appearances that are invisible to the naked eye. You can see why it's a big part of our game. So I'm glad that we got it working today!

The phone will see some things that the player normally can't. A player might wonder why a certain light isn't working, if he pulls out his camera he will soon find out that the wires have been cut, which is only visible on his phone's screen. This is just an example of the differences between the two worlds. With the current implementation the scenes can use different models and textures we can use this to keep the player engaged and wondering what has happened and how he can get out...(story will be explained later on)

For the time being I rendered the camera footage to a spritebatch (for debugging), but it's already working on a 3d mesh (as texture) You can clearly notice that the phone (topleft) can see something that the player can't normally see with his own eyes.

Somethings can only be seen with your own eyes...

All objects visible while in Editmode to place objects and debug a lot easier.