• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
  • entries
  • comments
  • views

Entries in this blog

Vilem Otte

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:


And you can view the video here:



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).


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:


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


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:


And also a video of effect in action:



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:


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.



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.


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:




5/18/2017 - Initial version published

Vilem Otte

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


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:
Vilem Otte & Pavel Kou?il

Vilem Otte

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.

Vilem Otte

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  
Followers 0