Sign in to follow this  
  • entries
    9
  • comments
    3
  • views
    5238

Entries in this blog

Since Ludum Dare 35 I'm regularly participating in every one of them and this one wasn't exception. My release thoughts are positive - this time I've again worked with one friend (with whom we've worked also in the past on Ludum Dare), and I enjoyed it a lot. As this is not a post mortem yet, I will not go into details what went right or wrong - meanwhile I'll just show the results and put out few notes...

scattering.thumb.png.e93c15942a95265f703c8173f20b3f7c.png

Yes, that's one of the screenshots from the game (without UI). I'm using this one as a "cover" screenshot - so it should also be included here. Anyways this was my another experience with Unity and maybe one of the last Ludum Dare experiences with it. While I do like it, if I can think about suitable game for my own game engine for the theme next time, it's possible that I won't use Unity next time.

Ludum Dare

Each 4 months or so, this large game jam happens. It's a sort of competition, well... there are no prizes, and I honestly do it just for fun (and to force myself to do some "real" game development from time to time). It takes 48 or 72 hours to create your game (depending on whether you go for compo or jam category), and there are just few basic rules (which you can read on site - https://ldjam.com/).

Then for few weeks you play and rate other games, and the more you play, the more people will play and rate your game. While ratings aren't in my opinion that important, you get some feedback through comments. Actually I was wrong about no prizes - you have your game and feedback of other people who participate in Ludum Dare as a prize.

Unity...

I've used Unity for quite long time - and I have 2 things to complain about this time, majority of all used shaders in Air Pressure (yes, that is the game's name) are actually custom - and I might bump into some of them in post mortem. Unity and custom shaders combination is actually quite a pain, especially compared to my own engine (while it isn't as generic as Unity is - actually my engine is far less complex, and maybe due to that shader editing and workflow is actually a lot more pleasant ... although these are my own subjective feelings, impacted by knowing whole internal structure of my own engine in detail).

Second thing is particularly annoying, related to Visual Studio. Unity extension for Visual Studio is broken (although I believe that recent patch that was released during the Ludum Dare fixed it - yet there was no time for update during the work), each time a C# file is created, the project gets broken (Intellisense works weird, Visual Studio reports errors everywhere, etc.), the only work around was to delete the project files (solution and vcxproj) and re-open Visual Studio from Unity (which re-created solution and vcxproj file).

Unity!

On the other hand, it was good for the task - we finished it using Unity, and it was fun. Apart from Visual Studio struggles, we didn't hit any other problem (and it crashed on us just once - during whole 72 hours for jam - once for both of us). So I'm actually quite looking forward to using it next time for some project.

Anyways, I did enjoy it this time a lot, time to get back into work (not really game development related). Oh, and before I forget, here they are - first gameplay video and link to the game on Ludum Dare site:

https://ldjam.com/events/ludum-dare/40/air-pressure

PS: And yes I've been actually tweeting progress during the jam, which ended up in a feeling, that I've probably surpassed number of Tweets generated by Donald Trump in past 3 days.

Having a pause from handling files and editor is good, to at least update something in rendering and keep motivation high. So I went ahead and implemented voxel cone tracing global illumination (and reflections of course).

Anyways, image time:

screen01.thumb.jpg.35d16b3a5b33dab5f403d3ace70300a9.jpg

Although quite dark, secondary shadows are visible. Note, global illumination is full integrated into the editor.

screen02.thumb.jpg.04620d49665f128df4bf95cbf17482ba.jpg

Reflective box, global illumination debug buffer (in Debug window), and color bleeding visible from spotlight.

Anyways so much for the show - so how is it done? In short:

  • Scene is voxelized, during which phase lights and shadows are injected in.
  • Reflection pass performs cone tracing, the cone angle is defined based on material properties
  • GI pass performs cone tracing for global illumination
  • Lighting pass has 1 fullscreen quad for indirect light (and reflections), and then 1 for each light (which I'd like to replace with tile-based method)

Resolution for reflection and GI pass can be any (therefore even sub-sampling can be done), actually in the images Scene is voxelized into 512x512x512 buffer, Reflection & GI pass are done at FullHD with 1x MSAA, and Lighting pass is done with 8x MSAA. Original G-Buffer generation is done at 8x MSAA. Everything is resolved later (actually even after the tone mapping pass).

I have an option to switch from voxel texture into sparse voxel octree, yet it is still heavily un-optimized (and slower), although having a lot smaller memory footprint. When I manage to find some more time for that, I'd like to switch over to sparse voxel octree only.

If possible, I'd like to re-visit resource management and dynamic re-loading, which would be a bit less 'showcase' and more 'coding' topic. Other than that, virtual shadow maps and virtual textures are going to be visit and attempted by me, hopefully in next weeks.

Side note: If you're trying to implement VXGI or voxelization on the GPU, and having some questions - I'll gladly answer them.

That should be it for today, thanks for reading!

Making editors is a pain. I have a list of thousands of items I'd rather do than this - yet I made myself a promise to drag at least one full featured editor tool over the finish line. There are few reasons for that:

  1. I believe I have quite useful engine, it was my pet project all these years, it went through many transformations and stages - and solid tool is something like a goal I'd like to do with it, to make it something better than "just a framework".
  2. I'm very patient person, and I believe also hard working one. Throughout the years my goal is to make a game on my own engine (note, I've made games with other engines and I've used my engine for multiple non-game projects so far -> it eventually branched to be a full-featured commercial project in past few years). I've made few attempts but mostly was stopped by lacking such tool - that would allow me to build scenes and levels, in an easy way.
  3. And the most important one ... I consider tools one of the hardest part in making any larger project, so it is something like a challenge for me.

Anyways so much for motivation, the tool is progressing well - it can be used to assemble scene so far, various entities (like light or materials) can have their properties (components) modified, with full undo/redo system of course. And so the next big part was ahead of me - asset loading and dynamic reloading. So here are the results:

screen01.thumb.jpg.eb01e06155622181e015b5958eaffbc7.jpg

Engine editor and texture editor before my work on the texture.

And then I worked on the texture:

screen02.thumb.jpg.9c9c207ed626eb3a9ee031815c9b58da.jpg

And after I used my highly professional programmer-art skills to modify the texture! All credits for GameDev.net logo go to its author!

Yes, it's working. The whole system needs a bit of cleanup - but in short this is how it works:

  • All textures are managed by Manager<Texture> class instance, this one is defined in Editor class
  • There is a thread waiting for change on hard drive with ReadDirectoryChangesW 
  • Upon change in directory (or subdirectories), DirectoryTree class instance is notified. It updates view in bottom left (which is just a directory-file structure for watched directory and subdirectories), and also for modified/new files creates or reloads records in Manager<Texture> class instance (on Editor level)
  • The trick is, reloading the records can only be done while they're not in use (so some clever synchronization needs to be done)

I might write out some interesting information or even short article on this. Implementing it was quite a pain, but it's finally done. Now short cleanup - and towards the next one on my editor todo list!

Thanks for reading & see you around!

 

So, I'm slowly progressing with my hobby project. This is the first time I write something about the project directly tied to it, or more likely essential part of it. I'll share few details here about the editor development.

editor.jpg

Making useful game/engine editor that is easy to control is definitely a long-run task. While the engine itself is updated to support Direct3D 12 currently, there was no real editor that could be at least a bit generic. For my current goal with this project, I decided to start with editor and work from there. So where am I at?
 
I'm already satisfied with some of the basic tasks - selection system, transformations, editing scenegraph tree (re-assigning object elsewhere - through drag&drop, etc.), undo-redo system (yet with adding more features this needs to grow), I'm definitely not satisfied with way I handle rotations edited through input fields. Component editing is currently work-in-progress (you can see prototype on the screenshot), and definitely needs add/delete buttons. It is not properly connected with undo-redo system yet, but it works. So what are problems with components?
 
  • They're not finished, few basic were thrown together for basic scenes, but I'm not satisfied with them (F.e. lighting & shadowing system is going to get overhauled while I do this work)
  • Undo/redo tends to be tricky on them, as each action needs to be reversible (F.e. changing light type means deletion of current Light-deriving class instance and creation of new different Light-deriving class instance)
  • Selecting textures/meshes/..., basically anything from library, requires a library (which has no UI as of now!)
 
Clearly the component system has advantages and disadvantages. The short term plan is:
 
  1. Update lighting & shadowing system
  2. Add library (that it makes sense!) with textures, meshes and other data - make those drag&drop into components
  3. Add a way to copy/paste selection
  4. Add a way to add/remove components on entities
  5. Add save/load for the scene in editor format
 
Alright, end of my short pause - time to continue!

Yet another Ludum Dare has come around, and this time I've participated without a real team on development side (I had some help from my sister in audio art, ideas, gameplay balancing and user interface). Before publishing full post mortem I'd like to provide a link:

https://ldjam.com/events/ludum-dare/39/im-an-nuclear-engineer

Last 3 Ludum Dares really encourage me into starting and finishing some more serious game project, although I'm still thinking about it...

Few weeks ago, I again participated in Ludum Dare and yet again in a team. There were actually three of us and we created the game in 72 hours for 'Compo' category. Some time passed and it is finally time to write a post-mortem.

Before going further, I'd like to point everyone out to the game and a walk-through video for it. The game is still available at:

https://ldjam.com/events/ludum-dare/38/run-u-fool

And you can view the video here:

[media]

[/media]

Let me start with short overview of how it went, for me this was actually already 4th Ludum Dare if I'm not mistaken, and 2nd Ludum Dare in a team. The routine is fairly similar each time, we spend afternoon of the Friday discussing what could be made for each possible theme (as in Europe the time theme is shown is during our night hours), then going for sleep as we start working on the game early in the morning.

Originally we have planned a game with small planet or planets, but as we saw multiple people going for the same topic on Twitter, we decided to go different way. The concept originally was based on world getting smaller, while the player's goal was to run away to reach the next level, ultimately reaching another world and saving himself.

What went right?

Separating tasks between each other, while giving others insight every now and then. It all ended up so well, that everyone of us knew what we're doing and what we're going to do. The idea behind the game was a lot more simple compared to our previous Ludum Dare, where the game we mapped on theme was quite complex.

Also having an in-game tutorial this time was definitely a plus. It gave a player perfect idea of how to progress through game, we haven't received any feedback in sense that: players had no idea what to do. Which is definitely a success.

Technical execution of the game. I'm quite proud to what we have created technically within those 72 hours, as all art assets - models, textures, shaders & effects were done in that time frame. I even decided to put few selected effects as appendix into this "post mortem" to explain how we did it to other fellow participants.

What went wrong?

As each competition, time planning. No matter how hard you try - it will always go wrong. While all of us were mostly free on Saturday and Sunday, I was the only one finishing the game on Monday (with help of one another guy, who helped me with some final testing). The rest of the team had to be at work, and I took few hours off, to wrap everything up.

Main menu. That part of the game is definitely the one that is the least complete, with just few text-buttons to start levels. Nothing really interesting goes on there, and sadly we had no time to think off and create some art for it. Yet, it serves its purpose and has all the functionality we needed.

Build for website (e.g. WebGL). I already knew that browser builds are slow, after all I've worked with browser rendering through WebGL in past as a job. That was about 3 or maybe 4 years back. That was on a custom-built engine (mainly for rendering) which was faster than Unity in comparison ... since then browsers didn't really move a lot.
They are still way too slow to compete with desktop based applications (even the ones running on .NET beat them in order of magnitudes of speed). The solution? Reduced effects, reduced physics, shatters have about 1/10th of objects and it is still several times slower compared to desktop build on the same machine (and I'm talking about testing rigs with Ryzen 1700 + Radeon Rx 480 or Core i7 + GeForce 1070 ... on neither of those it was smooth in WebGL build).

Summary

Those were few of my basic points. All in all, I really enjoyed Ludum Dare and hopefully I'll participate also in the next one. It may be as a team, or solo. Which is still unknown, as the next one happens during the summer and I fear that some of us might be out for holiday at the time.

For those of you, who participated in Ludum Dare or are generally interested in what few effects we put out - with little details and/or description, please read the following sections. For the rest, I hope you enjoyed the game, and feel free to share any thoughts you have about the game (or anything you have in mind).

Appendix - Force Field Effect

Once we came up with and idea of the game, it was obvious we need some kind of blocking feature in the way. Such item was a force field. The first model I created was a gate to hold force field, as I was against just putting up a plane with some effect. The basic model looks like this:

[sharedmedia=gallery:images:8602]

Which followed by adding materials, by adding color, metallic and roughness I achieved the final effect for gate that holds the force field:

[sharedmedia=gallery:images:8603]

Now the final effect, done by simply rolling multiple textures one over another - changing intensity and using some random rolled texture as offset. The final animation is in there, although in my opinion it can't be noticed unless somebody really looks at the force field. The last part was lighting itself, which is done with multiple point lights to simulate the effect of area lighting from the actual force field. The final look:

[sharedmedia=gallery:images:8604]

And also a video of effect in action:

[media]

[/media]

Appendix - Chain Physics

As the development of the game progressed on, we realized, that the player can go through the levels without too much effort. So the idea was to block his progress through the game somehow. I spent some time adding some rigid body objects, but those were not enough to block the player.

You can literally go around, or just knock them. Which brought me to the idea, what about some chains that would slow you down. The chains had to react based on the physics of course, and as objects have mass - when you push them it will slow down your speed. But visually they have to behave as 'rope'.

At this point there was no time to write some advanced 'rope physics' from scratch with a lot of parameters. So I've settled with simple idea, use few rings in chain as a rigid body and add hinge joints in between the nodes. The result was this:

[sharedmedia=gallery:images:8605]

And here it is in action, I was surprised how good it looks in movement - so I didn't really touch it anymore. It did its purpose.

[media]

[/media]

Appendix - Shatter

Once our idea for the game was settled, I noted that we do need to have some special effect for floor falling apart. The idea behind everything was to use a 'Voronoi shatter' technique to break down the floor. So I've prepared whole floor model and the one with dozens of objects in which floor shatters.

[sharedmedia=gallery:images:8606]

First idea was to just let it 'explode' downwards, but it didn't look really good. What we did in the end is, that once floor tile was determined to be destroyed, the whole object got disabled, while shatter one was enabled. Each single voronoi cell had rigid body assigned, but without gravity applied and kinematic flag set to true. Along with that we added a random timeout at which the cell gravity was re-enabled and stopped being kinematic only.

By cleverly playing with parameters we ended up with acceptable animation looking like this:

[media]

[/media]

Changelog

5/18/2017 - Initial version published

If only making games was as easy as making custom PCBs

This Ludum Dare was a really interesting experience for both of us. We wanted to do LD36 already together, but one of us couldn't, so we had to wait for a LD37.


sml_gallery_102163_892_70742.jpg sml_gallery_102163_892_32186.jpg


You can grab the game at: http://ludumdare.com/compo/ludum-dare-37/?action=preview&uid=8633

Theme

When planning a evening before, we really hoped for a "Small World" theme and were able to come up with an interesting game in matter of minutes. The other themes seemed lackluster, because they were often too limiting - and One Room was one of them.

When we woke up at Saturday morning and started discussing it, we didn't know for like 3 hours what kind of game to make. There were several options (some of which actually appeared in LD as games - solving murder in one room, time traveling in one room, cleaning a room, ...), but we couldn't think of anything that doesn't need a good storyline. We just knew two things for sure - we DEFINITELY didn't want to do a room escape game, and we wanted fancy 3D graphics.

After joking about stupid ideas, we somehow came to conclusion that conveyor belt game located in one factory hall could be quite nice and went to discuss details more and decided on our PCB factory game.

The development

The entire game was developed by two people -- one was focusing entirely on programming the game mechanics and logic and other one was doing mostly graphics, lightning and other visual things (he implemented Inverse Kinematics for a robotic hand from ground up!).


I guess it's angry and searching for something inside those crates?!
-- Pavel Kou?il (@Pajka) December 10, 2016


In the first day, we managed to implemented conveyor belts, robotic hands and basic movable objects for the transporters. This was a good prototype, and the game already felt like a fun! So we knew we were on the right track.
The second day was dedicated to modeling rest of game objects and programming the rest of the game. At the end of these two days (around 4 am) we had a almost finished game. It still needed some polishing and changes, but it was playable from the beginning to the end.


This is what we managed to do over the weekend. Shame we have to work today, so there will be only small changes, (if any).
-- Pavel Kou?il (@Pajka) December 12, 2016


To make the game totally complete, we really needed that third day - but we were all busy with our real lifes, meaning we couldn't make much progress, apart from just a few bugfixes and polishing fixes. But we think we still managed to do quite a nice game over the course of these 3 days!

The Good

We really had fun when developing our One Room Factory and shared many laughs over TeamSpeak when developing the game - one can only wonder if the game would be even better if we didn't have to work remotely, but could develop in one room together as some other teams did.
Also, since this was a first LD for one of our members (and first released game too!), we definitely learned quite a lot. Not only from the actual LD, but also from the feedback we've gotten. It was definitely an enjoyable and fun weekend!

The Bad

The HW requirements are quite demanding. Also, based on the comments so far, the game is quite difficult to understand; we did a basic tutorial, but because of time constraints (having to work on Monday AND being based in Central Europe cuts a lot of needed time due to timezone), we just didn't have time for a proper tutorial.
Combine this with the complexity of the game (and players not being familiar to conveyor games), this game seems to hard to understand for some people. So, to fix this, we are releasing a video tutorial for people who would still want to play the game!

(Don't forget to turn on annotations)

The Future

Depending on how we do in the LD, we are considering to finish the game and release it - we are reading the feedback people give us in comments and it makes us really happy when people like the game! The most rewarding comments are from people who want to see the finished version (with a proper tutorial) - and it's definitely possible it will happen! ;)
If you decide to check our game out, we will be happy for any feedback you will give us! If not, we are at least thankful you decided to read our post.
To try our game, you can do so here:
http://ludumdare.com/compo/ludum-dare-37/?action=preview&uid=86334
Vilem Otte & Pavel Kou?il

Compilers articles

It's me, bugging around again.

I finally got back to work on my compilers-related series, while it is focused on people untouched by automatons, VMs and compilers in general (or more likely the ones that are using it, while not knowing what goes inside), I tried to keep code-base quite small (and still manageable and readable by average viewer).

The funny thing around this is, that I've never actually worked on any big compiler (like GCC or such). So the series might give a look of someone who tried to understand how it works and how to do it, with formal languages and automatons theory in head (or at least whatever stayed there after university). While doing the compiler by myself as a form of education and challenge, I realized how little of this is covered in general - and that a lot of people don't fully understand what goes on behind the scenes - which motivated me to learn about compilers and languages more in theory and write at least a few-article series to introduce others into this problematic (and possibly help them avoid a lot of troubles I've hit while making my first compiler).

Actually the original final version of the compiler (even before I started working on articles) was able to compile something like this:int test(int* x){ x[0] = *x * 2; return -1;}int mult(int** x){ int* y = x[0]; y[0] = x[0][0] * 5; return -1;}int main(){ int z[3] = {1, 2, 3}; int x = 7; int y = test(&x); y = mult(&z); while (x > 0) { y = y * 2; x = x - 1; } return z[0];}
Into an assembly like this:.data.texttest: mov eax, 0 push eax mov ebx, [ebp+0] mov eax, ebx mov eax, [eax] push eax mov eax, 2 pop ebx mul eax, ebx pop ebx mov edx, 4 mul ebx, edx mov edx, [ebp+0] mov [ebx+edx], eax mov eax, 1 neg eax pop ebx push eax mov eax, 1 add ebx, eax mov eip, ebxmult: mov eax, 0 mov ebx, 4 mul eax, ebx mov ebx, [ebp+0] mov eax, [eax+ebx] mov [ebp+8], eax add esp, 4 mov eax, 0 push eax mov eax, 0 mov ebx, 4 mul eax, ebx mov ebx, [ebp+0] mov eax, [eax+ebx] mov ebx, eax mov eax, 0 mul eax, 4 mov eax, [ebx+eax] push eax mov eax, 5 pop ebx mul eax, ebx pop ebx mov edx, 4 mul ebx, edx mov edx, [ebp+8] mov [ebx+edx], eax mov eax, 1 neg eax sub esp, 4 pop ebx push eax mov eax, 1 add ebx, eax mov eip, ebxmain: mov eax, esp add eax, 4 mov [ebp+4], eax add esp, 4 mov eax, 1 push eax mov eax, 2 push eax mov eax, 3 push eax mov eax, 7 mov [ebp+20], eax add esp, 4 push ebp mov ecx, esp mov ebx, [ebp+20] mov eax, ebx mov eax, edx push eax mov ebp, ecx push eip call test pop eax sub esp, 4 mov esp, ebp pop ebp mov [ebp+24], eax add esp, 4 push ebp mov ecx, esp mov ebx, [ebp+4] mov eax, ebx mov eax, edx push eax mov ebp, ecx push eip call mult pop eax sub esp, 4 mov esp, ebp pop ebp mov [ebp+24], eaxL0: mov ebx, [ebp+20] mov eax, ebx push eax mov eax, 0 pop ebx sub eax, ebx neg eaxjle L1 mov ebx, [ebp+24] mov eax, ebx push eax mov eax, 2 pop ebx mul eax, ebx mov [ebp+24], eax mov ebx, [ebp+20] mov eax, ebx push eax mov eax, 1 pop ebx sub eax, ebx neg eax mov [ebp+20], eax jmp L0L1: mov eax, 0 mov ebx, 4 mul eax, ebx mov ebx, [ebp+4] mov eax, [eax+ebx] sub esp, 24 pop ebx push eax mov eax, 1 add ebx, eax mov eip, ebx__start: push ebp mov ebp, esp push eip call main pop eax sub esp, 0 mov esp, ebp pop ebp
While it was structured as procedural-based compilers it wasn't good enough to be presented. So for article purposes I tried to re-work everything in better structure from scratch. Not covering just practical implementation, but hitting a theory from time to time.

At that point I realized what all I want to put in the article(s):


  • Arithmetic math operations on integers
  • Arithmetic math on pointers and their reference/dereference operators
  • Variables and arrays
  • Standard control constructs (if, do-while, while, for)
  • Function calling (e.g. define and use a call convention)
  • Interaction with host application (the one running VM)
  • More types - shorts, bytes and floats (and of course variable promotion)

    So far, the articles are still somewhere in the middle, slowly getting finished. Although I'm already planning what is going to be next, but let's keep that for next entry.

Dead... or?

I noticed on myself that my activity on forums dropped to almost zero over the last two years, it was quite high before that (gradually dropping while I was working on my diploma), well... I finished it, and started doing more business and less game development, less (non-job related) graphics development, etc.

So I slowly got to the stage where I noticed that I'm starting to be separated from game development, which lead me to a point where I realized I don't want to live a life without making games. Since that point I did two entries to last 2 Ludum Dare competitions ... even though I love making tools, fine tuning my game engine source (which I have actually never used for game), etc. ... I used Unity for that. Anyways - a game is a game.

Nevertheless, to keep myself connected to game development I decided to start doing a journal here, regarding my development ideas, thoughts, post mortem articles and maybe even some progress from time to time. And most importantly, code and articles!

Sign in to follow this