Entries for tag "events", ordered from most recent. Entry count: 133.
# Porting your engine to Vulkan or DX12 - video from my talk
Organizers of Digital Dragons conference published video recording of my talk "Porting your engine to Vulkan or DX12":
PowerPoint slides are also available for download here: Porting your engine to Vulkan or DX12 - GPUOpen.
# My upcoming 3 talks
I'd like to invite you to my upcoming talks:
Tuesday 15 May at Czestochowa University of Technology, Faculty of Electrical Engineering, I will talk about computer graphics. Topic is: "Grafika komputerowa jako kreatywna dziedzina informatyki".
One week later I will give more advanced talk, in English this time. At Digital Dragons conference in Kraków I will talk about "Porting your engine to Vulkan or DX12". Later that week I will discuss the same subject at Nordic Game conference in Malmö.
# A MAZE in Berlin - my impressions
Last week I've been on A MAZE - an event in Berlin advertsed as "7th International Games and Playful Media Festival". I went there together with a large group of people from Polygon - gamedev interest group from Warsaw University of Technology. I liked it a lot because it's something different from what I've attended before, and I've been on many events, like gamedev conferences (e.g. GDC), demoscene parties (e.g. Revision), gaming expo (e.g. Poznań Game Arena), cybersport events (e.g. World Cyber Games), or events decated to retro computers.
A MAZE could be described as independent games festival. Majority of events took place between Thursday and Saturday. Its main part was game exhibition, where booths with many games were available for visitors to play or talk to their developers. They were indie games, so either very artistic, containing some original gameplay ideas, unusual controller, or somehow politically involved. Contrary to expo at GDC, there were no AAA titles, no big publishers, IHVs or middleware developers. There were some really polished and commercially successful games though, e.g. SUPERHOT.
Second big part of the event were talks happening on two stages. Again, they were very "alternative", often delivered by artists or academics. They either discussed some ideas or artistic vision behind some game, touched politics (of course all from the left side of political scene, e.g. about helping migrants, women, and other minorities), or they were purely fun. There was very little about programming and nothing about advanced rendering technology. Most of indie developers use Unity. I attended one of the workshops about Unity, but it was very basic - speaker explained what is bool, int etc.
Besides, there were concerts every evening with bands or DJs playing, VJs making visualizations, lots of beer and other festival fun :) I recommend attending A MAZE at least once to anyone interested in games or game development, just because it's so different from other events. Plus it happens in Berlin, and I love the atmosphere of this city :)
# Memory management in Vulkan and DX12: slides are online
Slides from my talk at Game Developers Conference (GDC) 2018: "Memory management in Vulkan and DX12" are now available online, as part of materials from Advanced Graphics Techniques Tutorial. Access to this PDF is open to anyone, not behind GDC Vault paywall. I've put some additional information in "backup" slides at the end that I didn't show during my presentation. The slides are designed the way that you can learn from them even without seeing the talk.
Update 2018-05-04: Slides from my talk in PPTX format with additional notes are now available (together with many other GDC 2018 presentations) on page: GDC 2018 Presentations - GPUOpen.
# Memory management in Vulkan and DX12 - my talk at GDC 2018
If you happen to come to this year's Game Developers Conference (GDC), I'd like to invite you to my talk: "Memory management in Vulkan and DX12". During this lecture I will not only advertise my Vulkan Memory Allocator library, but I will also show technical details, tips and tricks for GPU memory management that you can use on your own when programming using Vulkan or Direct3D 12.
# Code Europe Conference 2017 Warsaw - Some Random Thoughts
2017-12-07 I've been on Code Europe conference in Warsaw, Poland. Despite happening in just one day, it was a big event, with many talks at the same time, so I needed to choose the ones which seemed most interesting. Some of them were great, some... not that good.
The one that I liked the most was Adam Tornhill talking about "A Crystal Ball To Prioritize Technical Debt". He started by discussing technical debt in general, especially how "interest" accumulates over time, where time could be defined best as a frequency in which developers modify particular file or function. He stated that all metrics for measuring code complexity are equally bad, so the simplest one - number of lines of code - can be successfully used. He then presented a very cool way of visualizing "hot spots" - places that are the biggest pain points and that would benefit most from refactoring. If every circle represents a source file, its radius is its complexity (number of LOC), and the circle is more red the more frequently it was modified, then the files that are both big and red are the clearly visible hotspots.
But then a thought came to my mind: What if an external, well-paid consultant comes in to a software company to do such analysis? He then writes in his report: "After gathering all the data about your project and using sophisticated software tools I found that this particular file and function is very big, sophisticated, modified frequently by developers from different teams and so you should refactor it." Then all the developers of that company are like:
Possibly one of the developers could have a courage to tell the consultant: "You know what? We work with this code every day. We all know it better than you do. Maybe you go speak will our manager and convince him to give us time for that refactoring instead of requesting more and more features implemented or bugs fixed ASAP, which introduces even more hacks to the code. That would be actual useful work."
I liked the presentation of Roel Ezendam from RageSquid about "Applying the programmer mindset throughout your entire game studio". There was a lot about game development, but this talk could be seen in more general context. People tend to look at management, marketing, and other positions as something separate of even opposite to being a developer - a technical person. He showed that running a small company while still being a developer can lead to innovative way of doing things, like developing custom tools to automate certain tasks or make them more convenient (e.g. using Slack webhooks).
I didn't like the presentation of Ahmad Nabil Gohar from IBM "Blockchain.currentState() and How Will it Impact Your Industry?" The content was OK - he mostly explained the idea of blockchain (which I already knew), after which he enumerated many industries that could benefit from using it. But the slides were not prepared in a good way, in my opinion. First of all, there were 120 of them, and they contained a lot of text. Obviously he couldn't explain each one of them to finish his presentation is less than one hour, so he was going very quickly and even skipping some. The slides were also not very readable due to e.g. putting blue text on blue background.
This presentation, as well as some other inspired me to think that there a whole spectrum of types of presentations. I'm talking about both the slides and the speech together. On one end, there is urge to convey as much information as possible, so there are many slides, lots of text, they seem quite boring, the speaker goes very fast and so it's hard to follow him and to remember all of this. It happens when the speaker wants to actually teach people some new subject - a thing impossible to do in just one hour talk, because that's what university courses and books are for.
On the other end there are talks which are more like "shows" - easy and nice, speaker telling a lot of stories and conveying emotions, slides drawing attention thanks to using a lot of pictures and single words. Such presentations are fun, but they don't carry any information - they just leave people feeling good without anything new to take out. It happens especially if a very famous person is invited to talk about anything he wants - it doesn't matter what he says because it's only his name in the agenda that matters.
In my opinion, a good talk is something in between. It should express some idea and communicate it clearly, provide just enough information to understand it, with amount of content and pace of delivery slow enough so it's easy to keep up. Slides should show some meaningful text and pictures, while the speech should augment them with additional information and context.
Besides talks there was also quite big expo with many companies advertising their job offers for developers. Most of them were looking for Java or .NET developers, sometimes also PHP or Node.js. I could feel there how exotic my specialization is. There was one game company, but they make their games in Unity. I found only one company that was looking for a C++ developer - it was Ericsson.
She started from explaining WebSockets. My thought was: "Wow, so it's actually possible to have a persistent connection and use it to send any data, any time, in any direction, without text-based request-response protocol? Then desktop applications are so hipster! They did it before it was cool. Actually they did it like... forever."
But the most shocking for me was hearing that their RPC (Remote Procedure Call) "happens so fast almost like having the function locally". Yeah, right, by sending parameters and receiving results over Internet, where the best latency you can get is few milliseconds... While last week I reinstalled my whole system just because a system function was taking 2.5 microseconds instead of 22 nanoseconds, which was ruining my program.
I'm sorry, I didn't want to sound so negative. I just have a bad mood recently. Overall the conference was very inspiring and though-provoking, which is good. I can recommend it to any developer, no matter what programming language you use.
# Immediate Mode GUI - Theory and Example - Slides
Today I gave a talk at Warsaw GameDev Meetup. Topic of my presentation was: "Immediate Mode GUI - Theory and Example". You can download slides here:
# Few organizational advice for game jams
I have participated in Slavic Game Jam 2017. I would like to share few thoughts that came to my mind during the event and especially during presentations.
Participation in a game jam is like any gamedev project, just on a small scale. All the rules of a successful gamedev project apply. All the rules of doing a software project apply. You need a good idea for a game, so any method of coming up with ideas (like brainstorming) may help. You need the code, so good programming practices apply as well, so you can implement features fast and not drown in spaghetti code or hard to fix bugs in the middle of the project. Experience in game design and level design is useful. Skill in making good game graphics and sound is essential as well. Some project management is needed too. Even the wisdom about work-life balance apply, because having too little sleep makes you less productive the other day (coffee or energy drinks can help a little bit though :)
There are many books about these topics. What I would like to focus on here is something different - some basic organizational things that can have decisive influence on your performance during the jam. Even if you are a great game developer, you won't deliver a good game (or win, if there is a competition) if you fail on some of these basic topics. They are related to both development process, as well as presentation on a big screen.
1. Come prepared. I don't mean making a game in advance and only adjusting it to the theme during the jam. I mean setting up some basic software environment. If you already have your team, or at least some friends who you plan to team up with, meet together before the jam, decide what technologies and tools you are going to use and set them up. This will save you a lot of time during the event.
2. Take as much hardware and cables with you as you can. You never know what you or other team members may need.
3. Finish early. It doesn't mean you need to stop polishing your game long before the deadline. It means you should strive to have a playable game many hours before the deadline, test it as early and as often as possible, and make first build that you could potentially submit at least one hour before the time is up. Maybe you will crunch and apply critical fixes and improvements to your game in the last moment, but your shouldn't count on that. Maybe the organizers will extend deadline by additional hour, but you shouldn't rely on that either. Even something as silly as compressing your game build to a ZIP file on an old laptop can take unexpectedly long time and make you miss the deadline. If you need to upload the game somewhere on the Internet, keep in mind that everyone is going to do this at the same time, so the transfer may be very slow.
4. Focus on making your game looking good during the few-minutes presentation of you playing it. That's how the game will be seen and judged. Making it fun to play for others or fun to play for many hours is a secondary goal. Of course I don't mean cheating like preparing a prerecorded video. I just mean that you don't need to have 20 levels. It's OK to have enough gameplay for just few minutes, like only a single level. It's even better when the game is fast paced and can be finished during the presentation. You may also cheat just a little, like make a keyboard shortcut for invincibility, advancing to next level or showing final credits screen.
5. Make your game easy to remember and recognize. Sophisticated or generic name and content will make people forget about it. Even if there is a list and an order of presenting games, there is often some chaos happening during presentations. Some games have technical difficulties, some teams just give up, and so viewers may be confused about which game is which. If you design your whole game around a single, simple theme (like "a butterfly") and include it everywhere: in game title, logo/menu screen, and in the graphics visible during gameplay, then everyone will be able to easily identify it and so to vote for it. You want them to later say "I liked that game about the butterfly."
6. Give your game build folder/archive some meaningful name. It should contain the title of your game, possibly the name of your team and preferably some ordinal version number. I've seen game builds called "Build.zip". That's a very bad idea. I know that for you this is a build of THE game, but for others it's just one of the games and so they need to be able to easily identify which one is it. (BTW Same rule applies to the file with your resume that you send to potential employers - don't call it "CV.pdf" :) On the other hand, version number is for you. Believe me, there will be more than one version. Calling any of these "final" is not a good idea, because you will end up with "final final", "really final" etc. :) So it's better to call your game build something like "TeamName - GameTitle v01.zip".
7. Prepare your game for difficult technical conditions during presentation. I've written separate blog post about shapes and colors that you should use: 3 Rules to Make You Image Looking Good on a Projector. Here I would like to add that you should test your game on various resolutions. Projectors tend to have small resolutions. You can also meet problems with sound (too quiet or not working at all), so make sure your game is attractive even without it.
8. Use some margin when displaying things on the screen. It is also known as "safe area". In other words, don't put critical information (like GUI elements) near the edges of the screen. It may happen that the projector is not setup correctly and your image will be cropped, making these things invisible. Same applies to time domain as well as to spatial domain: Don't show important content during first three seconds of your game. Leave some "time margin". Projector may need some time to switch to new source and resolution, so viewers may not be able to see the beginning of your game.
9. Control sound volume of your game. If you learned a little bit about giving speeches, you probably know already that you should speak loudly, slowly and clearly. When you present a game, there is another level of difficulty, because the music and sound effects from your game are played at the same time as you speak. Be aware of how loud they are so that viewers can hear them, but also can hear you speaking.
10. Remove all the distractions that your operating system may experience during the presentation. Receiving notification about incoming Skype call in the middle of your presentation would look funny, but it definitely won't increase your chances to win. Same applies to Windows deciding to install new updates in the worst possible moment on antivirus slowing down your system because it just started to scan your entire hard drive. So for the presentation:
11. Finally, prepare for your talk. Decide who is going to talk and who is going to play the game. Consider how long the presentation should be. Determine what do you want to show, what to tell and in what order. Don't do it spontaneuisly, but rather think about the presentation in advance and discuss it with your team.