Entries for tag "competitions", ordered from most recent. Entry count: 36.
# 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.
# Thoughts after Slavic Game Jam 2017
Slavic Game Jam 2017 ended today. I have not only given a talk as a representative of the sponsor company, but I was also allowed to participate in the jam itself, so I teamed up with my old friends, some new friends that I met there and we made a game :) The theme this year was "Unknown". Our idea was to create a game about a drone flying and exploring a cave. You can see it here: This Drone of Mine.
There were 2 developers in our team, 3 graphical artists and one sound/music artist. We decided to use Unreal Engine 4, despite we had no previous experience in making games with this engine whatsoever, so we needed to learn everything during the jam. We didn't do any C++ - we implemented all game logic visually using Blueprints. We also set up Perforce for collaboration, so some of us needed to learn that as well (I am fortunate to already know this tool pretty well).
We didn't win or even make it to the second round, but it's OK for me - I'm quite happy with the final result. We more or less managed to implement our original idea, as well as show almost all the graphics, sound effects, music and voice-overs, so the artists' work is not wasted. It was lots of fun and we learned a lot during the process.
You can browse all games created during the jam here: Slavic Game Jam 2017 - itch.io.
# Slavic Game Jam 2017 and my talk
There are many game jams all around the world. Global Game Jam is probably the biggest and most popular one, but it is a global event that happens at different sites. This weekend Slavic Game Jam takes place - the biggest game jam in Eastern Europe, happening in just one site in Warsaw, Poland.
I will be there not only as a participant, but I will also give a talk, because AMD is a sponsor of the event. My talk will be on Friday at 2 PM. Its title is "Rendering in Your Game - Debugging and Profiling". I will provide some basic information and show some tools useful for analyzing performance of a game, including live demo. This information may be useful no matter if you develop your own engine or use existing one like Unity or Unreal. If you have a ticket for the event (tickets are already sold out), I invite you to come on Friday earlier than for the official start of the jam.
# Global Game Jam 2016 - Postmortem of our project
Last weekend, this year's edition of Global Game Jam took place all around the world. Just like in previous years, I participated in 3City Game Jam - a site in Gdańsk, Poland. It is a big one, with over 150 participants, organized by Playsoft company in their office. Theme this year was "Ritual". Regarding technology, Unity was most popular in our site, with just few games using something else: Unreal Engine, HTML5, GameMaker and C++ with SFML.
We have also used Unity. Our team consisted of 3 programmers. Here you can see our game: Bloody Eclipse, but it is far from being finished or playable. Honestly speaking, in my opinion the project on this jam went exceptionally poor. We didn't even make it to the top 10 best voted games to be presented on a big screen. That's why I'd like to share some conclusions, for you as well as for my future self.
First, it were not environmental issues that caused any problems. We all had our hardware and software set up before the jam, with Unity, Visual Studio, Git client and other tools already in place. Internet worked perfectly with transfer up to 80 Mbps in both directions. Second, it was not a lack of knowledge or skills. Our work in Unity went quite smoothly. We could deal with C#, 3D math and Git pretty well. Third, it was not because of the lack of artists in our team. Sure, graphics is very important for overall experience, but the guys who made The Bad Ritual also didn't have artists in their team and they somehow found a consistent visual style for their game, made it fun and pretty. There are many possibilities to make minimalistic and yet visually pleasant game, just like there are many free assets ready to use in Unity Asset Store.
The biggest thing that was missing in our team was management/leadership. I deliberately don't call it planning or design, because in a hectic environment like a game jam it's not enough to design the game at the beginning and then just execute. Things are changing fast, new ideas come to mind, time is running fast and new obstacles appear (like bugs or difficulties in development), so someone should have an authority to decide what to do next, keep the list of tasks "TODO" and update it constantly with priorities assigned so the most important things are done first. Noone took this role in our team. As the result, we've spent almost whole Saturday developing and polishing algorithm for enemy movement and around half an hour brainstorming and then voting for the game title, while our game used untextured, placeholder cubes and spheres as models until the very end :)
Conclusion: It's not enough to know how to code. It's also important to decide WHAT to code so that best possible result can be achieved with limited time and resources.
But the Global Game Jam as a whole is not a contest (despite our site actually was one, with PlayStation 4 for each team member as first prize) but just a fun, creative event. Despite all the problem we had I think it was fun. I had yet another opportunity to use Unity, which is a great technology. I realized I can handle Git pretty well, despite I don't feel like an expert knowing about "rebase" and such advanced stuff. I realized I still remember how to use the so much unintuitive inteface of Blender, which I learned many years ago to use in my master thesis. I could play many interesting games created on this jam, like my favorite: Witch Rite (it took 3rd place) or the one that won the contest: Acolytes: Ritual of Ascension. And finally, I've met many interesting people who do all sorts of crazy stuff, from running a company that produces medical software and hardware, to visiting escepe rooms and practicing celtic dances :)
# Global Game Jam 2015 - Our game: ComicsTale
Last weekend a big event took place - Global Game Jam. As every year, thousands of people around the world had fun while making a game in 48 hours. I was in a jam site 3City Game Jam (link to site at globalgamejam.org) in Gdańsk, Poland, organized in Olivia Business Center by Playsoft Games. With 163 registered jammes, it was one of the biggest in the world (actually 24th out of 518 sites)!
Theme this year was a question: "What do we do now?" so we came up with an idea for a game that looks like a comics, where player has to choose where to click. Our team was:
Developers: Leonardo Kasperavičius, Adam Sawicki
2d artist: Ryszard Niedzielski
Game designer & producing: Frederic Raducki
And here is our game: ComicsTale (source code on GitHub). It is made in Unity (as most of the games), with 2D graphics and with mobile platforms in mind. In the voting on 3City Game Jam, we took 4th place out of around 36.
It was fun to make game in a weekend. People were nice, atmosphere was great and there was free pizza! I recommend participating in Global Game Jam to anyone interested in game development. It's much more interesting than coding alone at home and submitting games to some virtual, online competitions.
# Simple 2-digit Method of Task Management
Managing some list of tasks to do (or "TODO list") is very important skill that helps in both work and everyday life. I usually use GTD (Getting Things Done) method. But sometimes, like on the recent Hack3city competition, a simpler method is more suitable.
A lot could be said about this subject (maybe some day I write an article or prepare a presentation about it). Generally, tasks to do can be organized based on different criteria, like:
Even after "filtering" only tasks that you can do and you should as soon as possible, they can be sorted in three different "dimensions":
It's obvious that not all the tasks will be done. During a 2-day programmers' competition, just like in everyday life, writing down ideas for doing things is good, but there is never enough time to complete them all. That's why there is a need for some method of deciding what to do next. During Hack3city, I came up with a simple, ad hoc method, which I want to describe here. The goal of developing it was to make the bookkeeping of the list as quick and easy as possible.
During a hackathon like Hack3city, where we created most of our game in just 2 days, the 3rd dimension is not important. Sure sometimes something must be coded quickly because artist or level designer is waiting for it to be able to continue his work. Then I do this first. But otherwise all tasks are equally urgent - they should be done in the short amount of time, during the event. So what I did was I opened the system Notepad and started writing down tasks and all ideas that should be/could be added to our game, one line each. But instead of starting a line with "-" for just a bullet, I started it with two digits, meaning:
Normally I just delete lines with tasks I finished, but since some time during the event, I started to move them to "DONE" section instead to show them later in this post. So here is partial task list from our game:
23 smoke effect when player falls onto the ground
22 flashlight rotates when player dies
23 flashlight rotates following player walking animation
31 spear, shooting from a wall when player pushes a button
12 delay appearance of "game over" text
22 push button
12 door that can be opened
13 red eye of zombie should pulse and blink
13 graphics in the menu instead of text
31 sound effects
33 fix ladder climbing animation
31 fix double-jump bug
22 walking sound effects should be played randomly
12 parallax for moving background
21 bug: player death animation doesn't work
11 playsoft logo
12 zombie: add hysteresis to the decision weather approach the player
21 death from the spikes
12 turning flashlight on and off
22 there are some bugs/spiders walking on the floor
33 a spiked ball on a chain, hanging and swinging from the ceiling
Of course the list of tasks was constantly changing as artist, level designer and me came up with new ideas or decided that something is more or less important, found new bugs during testing etc. But I tried to concentrate on finishing one thing at time. When finished, I picked up next task to do according to following rule: I reviewed whole list to find a task with the smallest sum of its numbers. So the order in which I was doing the tasks was:
This way we managed to accomplish most of the tasks we planned so we were quite satisfied with our game as it looked and worked pretty much as we planned. That's why I believe this simple 2-digit method of managing task list is good for hectic, time-constraint and constantly changing work environment.
# Hack3city 2014 - Review
5-11 May 2014 there was first edition of Hack3city - a hackathon in Gdańsk, Poland. It was interesting and unusual in many ways. First of all, there were 4 different tracks, so each developer could choose what is interesting to him.
Teams could have up to 3 people. Of course I was in the Playsoft track. We made a game together with Arek Duchnowski and Marcin Szymczak, who work in aideMMedia.
On Monday evening there was an official beginning (and free beer :) That's when themes of each track were announced. During the week we could work on our projects from home. On Saturday and Sunday (including the night) we were invited to work all together in an open space in Starter.
Also on Saturday organizers announced additional "diversifiers" (like on Global Game Jam). Fulfilling them was additional plus. For games, they were like "graphics is black and white", "game is controlled with one button" or... "game includes Playsoft logo". You could imagine how such logo might be used in a game themed "fear of the dark" :)
On Saturday and Sunday we have 3 meals - all for free (and free beer at the end :) There were mentors representing the sponsoring companies available in place so we could ask them for help.
There were totally 19 teams participating in all tracks. Most of them were in the gamedev track. Projects were evaluated by a jury based on a 5-minute presentation and there were winners selected in each track. Some teams just presented their applications, while others focused on delivering a PowerPoint presentation. Finally we took 3rd place. See also more about Our game from Hack3city 2014.
But the event was not only about programming. Maybe because it was organized by and in the Starter, it had a "startup feeling". For me it looked like many people, while being programmers, were more focused on money and business than technology. Maybe the culmination of it was presentation of an application that helps with first aid - shows information about how to help injured person, helps measuring rate of artifical respiration etc. Someone from the audience asked a question: "Do you have business model?" Someone else from the audience answered jokingly: "If you want to save someone's life, please first watch this ad".
Overall I think the event was well organized. Rules and general feeling was somehow similar to Global Game Jam, still quite unique and different in many details. I don't know if it's a good idea to announce the theme on Monday and allow working during whole week. Developers with lots of free time have advantage over these who study, have family or a full-time job. I also didn't like the idea of presenting each project 3 times instead of only at the end. It took lots of precious time that we could spend on coding and also made the final presentation less of a suprise. Everything else was great (did I mention free beer?), so I recommend attending this event when it will be organized next time!
# Hack3city 2014 - Our Game
I just came back from Hack3city - a programming competition. Participants had to develop their applications over this week - Monday to Friday working from home, while Saturday and Sunday working in Starter, Gdańsk. There were 4 tracks. We participated in track organized by Playsoft, where we had to create a game. The theme of this competition was "fear of the dark". We took 3rd place.
As I promised to some of you, I publish playable version of our game today. The game is created in Unity and can be run in web browser if you have Unity Player installed.
Our game is called "Jason McBrady Dark Adventure". It's a 2D platform game. It's about an adventure seeker exploring ancient tombs full of dangers like zombies, who want to kill you, but run away from from the light. It's quite difficult :)
We called our team NOQA. Credits are:
In the next post, I will write more about Hack3city. See: Hack3city 2014 - Review