So this weekend work continues on the Blaster Project. Dan has made some new art for explosions and blocks. We’ve cleaned up a lot of the prefabs and written a lot of new code. I replaced my previous cube matrix with an infinite hash map instead. You can add and remove blocks now via weapons as well. I have 4 different types of blocks at the moment: Full blocks, Half blocks, Ramps, and Half ramps. There is a glowing block too, but I haven’t put it in as a launcher yet. If you are near enough to an adjacent block, you can just pretend its minecraft and place the block based on where you are aiming. If the there is no block, or the block you want is too far out, you can launch the block and “lock” it into place by right clicking while its in the air, which is the same way that the pulse rifle activates its explosion. Rotation information works based off normals when you are in range or when there is a collision, based on velocity when it gets locked down in air, and based on the direction of your camera when you are putting it on top of a block below you. If the block / pulse rifle hits another entity while its fired, it will lock or explode instantly.
I refactored most of the code to be significantly cleaner as I start to understand more and more of how unity works. I still have lots to clean up before its finished. Soon to come will be AI for the enemies, and most likely the final boss will be the ship from Contour I will have to build a level with blocks that can’t be broken so that there is always a path to the boss that you have to work towards. I’ll need to place some obstacle blocks as well. If time permits I’ll see about adding multi-player so that you can have your friends join in.
And of course with this many changes, a video is in order. Sorry about the frame skipping. Seems my pc recorder couldn’t keep up during the excessive particle debris, it looked fine in game of course.
We will be taking a quick break from our own engine to try out Unity3d! In an effort to learn how the unity engine works, I’ll be making a very simple game with a working title of Blaster. Unity work goes well, we might consider switching over to that since it provides so much out of the box. And our previous code is already in C#, so a lot of systems will be reusable.
At first, I tried to create a self generating world, but the algorithms were taking too much time given the scope of this game. So instead I switched over to a minecraft style of level creation. The world is now composed for 2×2 voxel cubes. You fly and create the world by placing blocks, which are then saved out to a file. Currently I have Blocks and Ramps from Dan tied to numpad 1 and 2. Delete removes the block, and R rotates it. I still need to add minecraft’s raycast extruder for placement since the current placement is kind of cumbersome by comparason. Each block you place saves the level out.
The basic weapon is now added as well. The weapon is a blaster which you fire, and then later detonate. Upon detonation the blaster projectile explodes and creates a force sphere. The game will have various force types, and power ups. There will be simple AI orbs that fly through the world and try to knock you off to your DOOM. The goal is to climb your way up past all the enemies and obstacles and take out the boss at the top.
Simple right?! Ya I thought so too. Here’s some pictures of how its coming along:
For the past two weeks I’ve been working on getting skybox support working. This has required quite a bit of work, but its finally starting to work. I had to create a Textured Cube, and write a CubeMapped shader. Details of how this concept works can be found over at: http://rbwhitaker.wikidot.com/skyboxes-1. I found some awesome sky box textures and tweaked them out so they work correctly in engine.
Now that its working I’ve been trying to create a texture picker so that we can change which textures are applied to objects. That has been one of the trickier parts as textures can be 2d, 3d, cubic, and sequenced. That part is still in progress, I hope to have it done soon. After that I’ll add a script that enables me to link the skybox object to the camera so that it always follows the player. Also I think i’ll take this time to add support for layers and locking via layer, because once you have a skybox you won’t want it constantly being selected when you click off into space. (You want it to deselect everything else).
Once that’s all finished, I’ll probably be re-visiting the UI system, triggers, and then finally starting work on the actual game! First up will likely be a procedural level generator to create the galaxy / universe. Which will be populated with sub levels that are designed directly.
Today I focused on fixing up the color picker. I ended up going with http://www.codeproject.com/Articles/406126/WPF-ColorPicker-and-BrushEditor. I did have to make some modifications to get it working the way I wanted it to. But its looking pretty good. Of course while working with colors, I had to improve the CustomData type to be more flexible with Vector4 vs Vector3 vs Color. Also allowing people to change the type was the perfect way to crash a shader, so now I added a TypeLock on any CustomData that references against a Shader property. Next I’ll have to link into the regular non-shader properties among like 300 other things I still have to do!
As with most games, it helps to be able to set up complex levels using various scripts. Most editors have something like this. So this week I’ve been working on getting the Scripting layer added. I decided to go with game code as the scripting engine. Which seems a little strange, but I feel that it gives a pretty flexible approach. So in my game I would define a series of script actions that I want my objects to perform. In the video below, I use a generic Wiggle script. The script is applied to a given object by dragging and dropping it on the object. Currently the scripts don’t save, and they can’t be removed once added, but its a first pass… its supposed to be pretty ugly.
The editor searches all the loaded DLLs and finds any and all classes that extend the IScript interface. That means all you have to do to create a script, is create a class in your game. The engine will find it, and make add it to the project. Eventually scripts will need to be triggered by an event. Various events could include, being clicked, updating a frame, colliding with something, being shot, etc. Again events will be dynamic and you will be able to create events just by creating classes that extend IEvent. I still have a lot of polishing to do on this system, and I’m sure I’ll refactor it a few times still.
This week I’ve been working on cleaning up the library panel. I’ve changed it so that It can compare what is in the library vs what is on disk. It will allow you to add to the library any files that are on disk. This way its a lot easier to see what assets are available. Its not very exciting, but its coming along.
What is exciting is having some awesome ship models! Dan converted my old Harvester model. It was a Taizon Ship that could spawn little Taizon Sleuth ships. Originally, he was the first boss of the original game. We’ll see how we work out his placement in the new version.
Today I worked a little bit on the stability of the multi-threaded setup. There were a few race conditions between the event system and the renderer which were causing crashes, those have been ironed out now. I also improved our ability to find and detect textures as well as support adding for Image File Lists. I also took this time to import some of the old art assets from the original Contour game. As I added them, I realized some of the FBX import code was broken. Its all working nicely now =) Here is a picture of some of the old art scattered into the world. We definitely need to fix up these models and of course export them using the new exporter pipeline.
This week, I worked on fixing up the GUI experience. Now, the World Nodes and linked with the visual nodes in both directions. So you can select an object and it will highlight the node, and or you can select a node and it will highlight in the world.
Also I took the time to re-thread the code so that the Inspectre’s graphics run on their own thread, and the WPF gui runs on the main GUI thread. This actually increases the performance of the editor by quite a bit. However, now that its multi-threaded, I’ve already had multiple crashes and side effects that I had to fix. WPF doesn’t like things messing with its values from other threads, and DirectX doesn’t like having its context destroyed and reset by the WPF thread =) Go figure. But all is good now, its running well, its running fast, and progress continues! Hopefully I can show some new art next time, as we get closer to being able to actually use the editor for game content!
This week, I worked hard on fixing our multi-scene support. At first, I had planned to have a separate window for every scene, its own tab, and with its own instance of Mono Game running. But it turns out MonoGame is not anywhere near ready for such a feat, so instead, I took advantage of our Screen/State system. Basically every level has its own Editor Screen. When you switch levels, we load up a new editor, unless we already have one for it, in which case, we just restore it back to the main screen.
As you can see in the video, the process of changing screens was always been implemented with a nice cross fade, though we had previously disabled it when we ported to MonoGame. So I spent a little time fixing the cross fade and you can see it gives a really professional feel to the scene switching experience.
Lastly, you can see that our Manipulators are finally working! Complete with Snap to grid… Well.. they aren’t the right visuals, the rotation manipulator is supposed to use round rings, but our triangle collision detection system hasn’t been ported over yet, so I had to use a bounding box selection friendly model for all three, so it definitely gets confusing. This will be addressed soon though!
Of course with each update I only talk about the really noticeable changes, there are always lots of little changes that I do behind the scenes, and just write it off as magic =)
This week Dan and I worked on the look and feel of the editor. Dan created some nice new assets for editing and placing objects while I hooked in the code to make it act as you would expect. Overall we are trying to mimic the feel of 3dsmax while adding our own little ease of use to it. While I was working on making the code play nice, and fixing all the things that were still yet missing, Dan took to playing around with WPF and managed to change the skin of our app to something a little more professional looking.
Still working to get multiple scenes capable of loading, but it will require some re-writing of the organization system. Should have it ready by next week! Hopefully with a video as well.