Shadows and light

As mentioned before light will play a major role in tight spaces inside derelicts, asteroid mines or space stations, so to expand the exploring experience light has to be good enough so it can help players to discover areas as they move. So below you can see an example how light will play a major role while exploring some areas in the game.

There is no light in closed environments in space...

In closed environment like old abandon derelicts, asteroid mines or tunnels light should be pretty much non existant, it should be dark, the darkest of all, so I just decided that is time to add some of this into the game, while exploring those places you will have to rely on lights or sensors and this is just my first try to see how light will work inside a derelict.

Still there is a lot of work to do to make sure that all the illumination goes as planned, at this moment is very basic since I just wrote the code in 2 hours including the basic pixel shader. Now a more complicated ray casting method may be implemented since I don't want the player to see other corridors that are behind the next wall, and also I need to still enable the collision detection inside tunnels, but looks interesting enough to continue this approach. I am still thinking if sensors should show more on screen, in this case all walls around you depending on your sensors upgrade level and power distribution, I will show up the idea in another screenshot later during the week.

Size and exploration

I've been doing a little bit of testing today just to feel how big or small a level inside a derelict feels. Just to give an idea how big can it feel at this moment, this is a random maze made by the derelict creator.

Every character in the screen above is a block in the map for now, the red square above is what you will be able too see if you put a ship inside the map.

Still graphics are just dummy textures for the test, but it feels quite big just by looking at my lonely ship there. And this is a small map, maps may be up to 20 times bigger easily but that can become quite complicated for the player to not get lost.

Procedural content creation in space

Yesterday I had a new idea, well is not new, but it is something I wanted to add to the space ship game, to be able to explore more than just empty space or asteroid fields, something like derelicts, space stations or asteroid mines and many other locations. So, after thinking for a few minutes I started my research and after 1 hour I was able to make somethink like a maze, which looked like something like this:

But, just adding a maze won't be fun, you need to have rooms, caves and something more interesting, so I scrapped the idea of having just a maze, and started again from scratch, I read some articles about room generations in rogue games, so based on some of those ideas found on the web I started to write my own generator and randomly create rooms and connect them. After a long night of coding I reached my bed but before that I had something like this:

It automatically generates an entrance as seen on top, and some interesting things inside the labyrinth like portals or exits to other levels, it still needs some more work but it has a very viable design for the game, one of the main challenges I had was that rooms can't be too small and the tunnels also can't be just one unit wide, since I don't know how big or small the space ship will be it would be better to give enough room to maneuver and also encounter enemies and other things. Since I have each room as objects I can easily decide what to add to each one without having to worry about tunnels and how everything is glued together. The image above is just a representation of what is filled or not on the map, but internally everything is divided as rooms and tunnels connecting to each other, so there will be always a connection to the start or end and everything will be accessible otherwise there may be rooms which can't be accessed like the exit and that will not be good at all. Also some obstacles are added in some tunnels so the player will have to discover secret tunnels for a little bit of variability in game.

So what's next? adding enemies and other things inside the maze as well as loot and rewards for doing it. There will be more complicated layouts but for a night of coding this was very good, hopefully I will be able to show up the final result in game with graphis in a couple of days.

In space nothing stops you unless you hit something...

I was having some thinking about space today, I was looking at the smoke trail that missiles left in game, and somehow I felt that there was drag and smoke started to move behind, that would look fine if you are on earth when air resistance and gravity will drag your weapons bullets and even smoke trail, but in space it shouldn't. Actually I've spent a few hours thinking what is off on screen, bullets and energy weapons seem fine but missiles and torpedos did not, after so much thinking it was the smoke trail! sounds simple and didn't look so important but I like to take care even of the small details, when a missile was fired to the right side of your ship the smoke trail started to move down as my ship accelerated up, but missile keep moving at the same rate as my ship, up!, but smoke moved down!, if fired on earth it will be fine, but not in space, so I have to redo the smoke trail algorithm to take into account the missile accelearation, and keep attention when the missile change direction.

Red arrows show the direction of things moving below. On earth it may make sense but not in space.

More thinking to come later and most of the bugs I was planning to fix today are done, except the UI flow which is my next step, a little bit complicated to use even for me, after simplifying it I hope to post some new screens and gameplay videos.

2.5D or 2D? normal maps quest for a better game

As usual, for any new game I do, I try to make something new on the tech side and learn new skills and usually increase the development time and make things ugly in the long term and delay the end result. But is a challenge I like to take just to make something different, something refreshing and something that I haven't done before, I did it with the Mystic River animation framework which works very well but it does not fit this project... yet , I have several plans for it but that will be for the next version. So what is the 2.5D challenge then? Well I've spent the last couple of days thinking how to improve the look of the game, and one of the key features is graphics, eye candy. So instead of trying to make super nice sprites with fixed shading I think I can make them even better by adding shading effects to add depth, that will make it look better without having a major impact on the development "time"...   well I was wrong but not by much.

2.5D brings some new challenges, but finally I was able to resolve them today, the simple use of normal maps to address the shading in 2D have been explored before in other games, like Legend of dungeon and also many others, but all of the implementations I found are for platformer type, or platformer camera style, with all sprites standing vertically aligned without rotations. Why do I mention without rotations? well if you use normal maps with lights, and use sprites in a batch the normal map information is baked in the normal map texture, and the light calculation is performed per batch usually, so the problem with this approach is that once you start rotating the sprites, the light information will also rotate to the same direction giving you wrong illumination. To illustrate the problem, the image below shows a bunch of asteroids and all are supposed to recieve the same light from a star located top right, but after rendering with rotations all the shades were off.

 

 

The green arrows show the actual shade of an asteroid which is pointing the to the wrong angle given the light source in red.

After trying for 2 days to align the shades, I found a not so nice solution. The thing I was trying to do in the pixel shader is not possible between the scope of spritebatch in XNA, the reason for this is because how everything gets batched, I had to think how the spritebatch batch works to understand why the light rotation is not working at the pixel shader to compensate for the rotation of the sprite.

The actual code that is not visible to the normal XNA user behind spritebatch is quite interesting, as per documentation there is a limitation 2048 sprites that spritebatch can batch at a single time, if more sprites are drawn more batches do happen, why? because it has a dynamic vertex shader with a fixed number of quads which is 2048, with a total of 2048x4 vertices. So how does the batch works then? it actually creates 1 quad per sprite and put each sprite into the dynamic vertex buffer, the transformations are performed in the spritebatch batch process in the CPU and then the end result is passed to the shader (yes up to 2048 sprites in one batch goes to vertex+pixel shader), which is what I was receiving in my shader, so I am getting a total of 2048 sprites in one go all of them already transformed, so I can't transform back the light source for each sprite because simply a maximum of 2048 sprites is already clumped together in one big mesh! so there is no way to move the light back for each sprite at this stage, it is too late for that, and as per my testing I didn't get each sprite vertex information while doing deferred spritebatch, that's why I wasn't able to resolve the issue at the vertex or pixel shader and the normals are not real normals, just baked normals, they all moved with the sprite, so the light source as seen on the asteroid image. While the vertex shader is getting all the vertex information also a tranformation matrix is sent with the vertex data, that means the whole screen transformation that happens for the camera view, which can't be used to compensate the light source for each sprite.

Then why does it works with 3d and not with spritebatch? with 3d you simply go and draw one mesh and do all the transformations for each piece and calculate the light source position for "each" piece, with a deferred spritebatch you can't do that because as I mentioned before is only one mesh of 2048 sprites with different transformations, but there is only one case in which this works, and this is when all the sprites are aligned exactly the same, meaning for example all are rotated 0 degrees, just a plain tileset or like what you see on Legend of Dungeon.

So what now? I can't adjust the light source for the whole list of sprites because simply it is only just one big mesh, but there is a solution for this but it is not nice, I just tested it today and it works. The solution is to actually rotate the light source for each sprite before it is drawn, even if you use spritebatch.begin .... spritebatch.end  you can still change the light source position passed to the shader, but the only way to make this to work is to make the batch sort to immediate, so every sprite is drawn after spritebatch.draw( .... ) so you can adjust the light position for each sprite just before drawing and voila! you have normal maps with rotation rendered at the proper location but I am not sure how slow the end solution will run yet, I just tested with a couple of sprites only, so the next step is to actually try with several hundreds and implement it in Junkcraft Armada.

To improve performance, only the sprites which require normal maps will be drawn using this technique, for any other sprite like bullets I will use the simple spritebatch to run as fast as possible.

I haven't seen any answer to this anywhere else, everyone mentioned how to do it in theory but I couldn't see why it didn't work, or how to implement it without having to code a lot of things at the vertex shader, I wish I could find a better solution with vertex shader implementation , but I really doubt it will work when having deferred sort with up to 2048 sprites in one spritebatch batch, in the meantime this seems to be the only workable solution.

I will post more screenshots during the weekend after I finish the normal maps drawings, I just only have at this moment very rough samples and won't really showcase the new render style of the game., but I am very excited with the preliminary results.

Just a quick sample I made a few minutes ago to test in a single module...

Painful changes in architecture but great rewards - skin system

Spent nearly 6 hours yesterday on a simple idea. I need a more robust and simple way to implement different looks to the same building blocks in Junkcraft Armada. After a painful search and replace of hardcoded numbers and creating a more robust and flexible system which actually doesn't add much to the gameplay except for the look I am very happy with the results.

A quick screenshot showcasing  the difference can be seen below.

The blue parts are actually the same builing blocks as the white ones where you can attach different modules, but do have a different sprite representation allowing me to design custom looks to each part with different shapes without having to hardcode any part inside the game code. The change allows a very large number of skins and will make the game more enjoyable to play since graphics will jump in quality and will add a lot of variety. Players will start with the basic ones and as your ship progress you will be able to change the way your ship looks and also how it plays, allowing the player to design very interesting ships including ships from other games if they want, all the ships provided in game will be original ships but custom parts will allow players to shape the ship as they like.

Modding in the future may be possible for the Windows version, but for the first release I will only allow the standard pieces delivered with the game, otherwise the release date will be too far in the future and I want to release this game before the year ends.

Junkcraft Armada update

Things are moving fast and in good shape, take a look at the first sample screen capture of Junkcraft Armada, which started as my summer challenge game that was supposed to end after 2 weeks but already working on it for about 1 month.

This is about a modular spaceship game, build/design your ship while you play, explore, escort or help transport ships, exterminate pirates and use the remaining modules as part of your ship or recycle them for parts for upgrades or repairs with more than 20 different module types, more than 10 different missions and many different environments that affect how you maneuver and survive, black holes, white holes and many other space anomalies , choose the power distribution of your ship between weapons, shields, thrusters, tractor beams, and many other modules.

The game is physics driven so expect things to behave like in space, you just drift in space even if your thrusters are off after initial acceleration, get your thrusters damaged and you will have some challenges flying/turning your ship, module's mass and many other factors affect how your ship fly and how fast it can accelerate with many different weapons like energy weapons, kinetic weapons with limited ammo/missiles/torpedos and you can upgrade any module up to 5 levels, with only one life expect to have a though time trying to get to the end, get your command center killed and you are done.

Most of the texture modules are just placeholders at this moment and this is a pre-alpha screen captudre just to test how it works.

Summer Challenge end...but not so...

For this summer, I set a challenge to make a game in 2 weeks, at the end of those 2 week I had a running game, "Junkcraft Armada" with around 19 modules enabled, and a single level  with was just kill all the enemies that came to you, I had only 3 kinds of enemies at that time and very simple layout with a very minimalistic UI and no sound at all and no menu, just go to action and kill some time. It was a great experience since I do want to use this to build new games in the future.

So what's next for me? well I had so much fun doing this game, and looking at the state of it at the end of the 2 weeks challenge I don't think I should leave it as it is now, it won't make justice to those 2 weeks of effort. So I decided to extend the time a little bit more, to make it a complete game, it is very fun for me to play it, but it can get boring with just 3 enemies, and no missions and progress, so in the last 2 weeks I enabled different scenarios and a few more enemies, I am thinking to add about 30 enemies to the game and bosses since it is extremelly easy for me to crate one, it takes about 5 minutes for small ships. I wanted to create random enemies by using an AI builder, but even if that tool provides interesting results it will take quite a lot of effort to make just to have some reasonable ship design, so for this version, I will create the enemies and that should bemore than enough, and maybe add the AI builder for a next version for infinite fun and challenge.

What else will I add? different missions, I have 14 types in mind now with different variations and one is finished, add more random events and more environment hazards, plus more upgrades and maybe a few more weapons, I don't want to make a big game with it but more like a rogue like game, adding variety will make it easier and enjoyable to play. So I hope to finish it in the next 2 to 3 weeks so I can return to Elem3ntz! and finish that big game.