Blogposts about games developed by us. Most of them are non-technical.
Hey guys! I've developed a game in 48 hours for the game console that I have been working on lately!
The following Youtube video contains all of the info about the gameplay as well as a bit info about how this game were made. Please do watch it! :)
It isn't possible to develop a game within 48 hours without any preparation work. Therefore, I did spend quite a bit of time on preparing it. The preparation includes:
I wish I could get a third party to review this game. Unfortunately, it isn't possible for anyone else to play this game for now because the game console isn't released yet. So here's my self-review of this game.
As a game developed within 48 hours, I'm rather satisfied with the result. Thanks to my preparation work as well as my previous experience on game jams, I'm able to finish this game on time.
The game is rather challenging and well-balanced. The game is made interesting by having the player keeps try picking up coins. That's the only way to score in the game. For each coin the player had picked up, the game gets a little bit more difficult until the player couldn't hang in there and lose the game. With randomization of various elements in the game, including the spawn rate of conveyors and hostile entities, the position of the objects, etc. The difficulty of the game is partly based on the luck of the player. That makes it a fun game for players with any level of gaming skill.
For the program of the game, it's rather sad that there's quite a bit of code duplication in the game. That's partly because I'm on a memory-constrained system. Another reason is that there's a time limit for the jam. Anyway, the game jam had ended. I'm not going to fix that. :P
This game demonstrates that the game console I'm developing is capable for running games! It shows the system API of the game console is good enough for game development. Therefore, I am able to move forward to further develop this game console. In the future, this game console might become an alternative to PICO8 for game jams participants.
I'm sorry that I didn't update about the progress of the development of the game console for a while. A lot of progress were being made lately!
The second prototype of the game console is ready! It's soldered on a perfboard. There're a few upgrades made in this new prototype. Here's the specs of the second prototype:
The PCB to be designed will be based on this second prototype.
Despite that I had professional experience in embedded programming, I'm rather green. Therefore, I've discussed with some veterans in embedded programming about the design of this game console. Since this game console works by loading the game from SD card to the internal flash of the microcontroller by self-flashing, they immediately pointed out that performing frequent self-flashing would wear off the flash of the game console quickly.
I've checked the datasheet of STM32F030K6T6. The guaranteed number of flash write cycles is merely 1000 cycles. That's a little bit small and it will cause problem to our game console. Interestingly, the 1000 number of write cycles is "Guaranteed by design, not tested in production". For other microcontrollers produced by STMicroelectronics, the number of write cycles is often 10000 and it's "Guaranteed based on test during characterization".
It just doesn't make much sense to have this little number of write cycles. Here're some theories I have about the number:
In long run, maybe I should do my own research on figuring out the actual number of flash write cycles of the microcontroller I'm using. I refuse to believe that the write cycle is 1000 cycles in room temperature. If the write cycle is like 3000 cycles, it's kinda acceptable because that'd mean that the user can load 10 games every single day for 300 days until the game console breaks. And I doubt that there's such an enthusiastic player of this game console anyway. But 1000 cycles is really a bit too little.
To reduce the number of flash write cycles, I've modified the bootloader firmware so that it only perform flash erase and rewrite if the source ROM on SD card is different from the previousy self-flashed game inside the microcontroller flash. That would cause self-flashing not to be performed if the same game is launched again after a reboot. This should help reducing the flash writes by quite a bit, especially if the player is repeatedly playing the same game over and over again.
Another issue that those professionals pointed out was the Game Flash and RAM Offset. They raised an interesting idea about the offset of Flash and RAM.
In the past, I designed the Flash and RAM layout like this:
There's a huge problem with this design. For the flash, if I ever update the firmware and the size of the firmware got increased, that would cause the offset of the Game Flash to be changed. That'd require the game to be rebuilt to work on the newer version of the game console. The same issue goes for the RAM.
Therefore, I've modified the layout. Now it looks like this:
For the Game RAM, I put the bootloader-exclusive RAM at the end. This design allows the bootloader RAM to expand without changing the origin offset of the Game RAM. In addition, if I ever upgrade to a microcontroller with more RAM, the entire RAM space would be expanded. And I would push the Bootloader RAM to the end of the RAM, and the Game RAM space would also be expanded. Since the origin of the Game RAM remains unchanged, I can still run the game that's built for the pre-upgrade version of the game console.
The same story goes for the flash. However, it's a bit more tricky because I need the bootloader to take the first sector of the Flash. That's because the first sector contains the interrupt vector and boot-related stuffs. I have to take the first sector so that the bootloader would be loaded on power up instead of the previously flashed game. Other than the first sector, the remaining part of the bootloader is put at the end of the flash space. That brings us the same advantage of putting the bootloader-exclusive RAM to the end.
This thing was done long time ago. But I've been too busy to blog about it. In the past, we made something called EXTIF to allow the game to call the functions located in bootloader by using a software interrupt, just like how BIOS work. It turns out that this design is utterly dumb because there's a function calling convention for ARM. It's called Procedure Call Standard for the ARM Architecture(AAPCS). As it's the go-to standard for functions compiled for ARM microcontrollers, it's possible to call any functions compiled by any compiler with any amount of parameters as long as you have the address of the functions.
For this reason, I just made a veneer on a fixed address for each of the system API functions. The veneer redirects the function call to the actual address of the function inside the bootloader. To call the system API function, the game declares all of the system API functions available in the bootloader and assign those fixed addresses of the veneer to the function declarations. With GCC, it's possible to map a function to an address by using the --just-symbols parameter when you invoke the linker.
The latest bootloader firmware is able to redirect almost all of the interrupts of the microcontroller to the Game ROM. A veneer interrupt handler were used for calling the interrupt handlers in the Game ROM. That enables the game developers of this game console to perform low-level programming. Along with the high level API inside the bootloader, this game console allows its game developers to learn about both higher level programming and low-level programming.
Here I've managed to complete the 4th Alakajam by developing a game for my game console. :)
Now that the firmware of the game console is ready. The next step of the development of this game console project is to design the PCB. After that, perhaps I'll also draw a case for the game console. If I have the time, perhaps I'd also develop an emulator for it. Since the microcontroller behind this game console is an ARM one, it should be possible to modify a Gameboy emulator for running games developed for this game console.
Just as I planned, I expect this project should be completed some time in 2019. Maybe the emulator would be available in 2020 if I end up working on one.
That's it for this blogpost. I'll update you guys soon! :)
As of 15th Oct 2018, I'm currently in between jobs. I was an embedded programmer of thermostats with a bit more than a year of experience. I did firmware development, Python automation scripts as well as tools for internal use, including setting up MQTT server and web server on a Raspberry Pi. In addition of that, I have been a hobbyist programmer for 9 years since I was back in middle school. Currently I plan to learn further about Python and modern web development technologies, mainly the back-end and devops ones. Then I'll start actively looking for another job. I prefer to go for a remote-working job. It can be full-time, part-time or freelancing.
If you're looking for someone to fill in any sort of programming-related positions, feel free to contact me via "hire dot me at sadale dot net". Alternatively, you can look for me on Freenode for having informal conversation with me. My nickname is "Sadale" there. Keep in mind that you have to identify (i.e. login) on Freenode in order to PM me. That's a new policy of Freenode to deal with the recent IRC spambots.
I'm thinking about making an AVR (non-Arduino) portable game console. I'm evaluating the type of display to be used (including multiple 8x8 LED matrix, graphical LCD, TFT/OLED screen, alphanumeric LCD and combination of them). Then I came up with a weird idea. What if I use a alphanumeric LCD as a graphical LCD? That'd cut me quite a bit of the cost compared with using graphical LCD of the same physical dimension.
I'm a bit bored today. I feel like tinkering around with Arduino and 1602 LCD that has been around in my home. Here's what I've got as a result of hours of boredom. An Arduino-based 1602 Snake Game:
Check out the source code in this github repository!
The hardware is roughly based on this official Arduino LCD Hello World tutorial, with an addition of two push buttons.
The left push button is connected to D8, while the right push button is connected to D9. Both push buttons are pulled-down. For other connections, please refer to the schematics in the tutorial.
HD44780-compatible LCD driver supports up to 8 custom characters. By carefully defining those 8 characters, it's possible to subdivide each character into multiple "pixels". That can effectively turn the alphanumeric display into a graphical LCD display.
My design subdivides each character two rows. Each row on the character can be either empty, snake, or apple as shown below:
There're two "pixels" in each character. Each pixel can have three possible values. Therefore, the total combination is 3^2 = 9. Since one of these combination is visually empty, a space character were used to represent that. At the end only 8 custom characters are needed. So the 8 available characters in CGRAM of HD44780 are just enough for our purpose.
To reduce RAM usage, each pixel is represented by 2 bits. So a byte can store 4 pixels. Everything is cramped into a
uint8_t graphicRam[GRAPHIC_WIDTH*2/8][GRAPHIC_HEIGHT]. At width of 16 and height of 4, only 16 bytes of RAM are taken for the graphic! Had I used a uint8_t for each pixel, 64 bytes of RAM would be required.
After the completion of this project, I've found other designs like spliting each character into three rows, or try making use of all pixels by generating the CGRAM on-the-fly. I'll consider using these techniques for my future projects.
To make the position looks random, we need to somehow seed the random number generator. For computer programs, we usually seed it with the current time of the machine. However, this couldn't be done on Arduino because it doesn't have a real time clock.
My solution is to make a menu screen of the game. When the user start the game, the time of the moment that the user pressed the button is used to seed the random number generator. The micros() method of Arduino Time library were used. This has the equivalent effect of using system time.
I was having fun playing with this game. I thought that it was reasonably bug-free because I had played it for a while. I've also asked one of my family members to try it out. I swear. We haven't spotted any bug.
Until I tried to record a video of the game play, something funny happened. I realized that I haven't implemented self-collision detection of the snake. I was like "Wow. How come no one had notice that earlier?". Hah. What a terrible failure!
Upon the discovery of the bug, it was fixed in no time.
Seems that using alphanumeric LCD as graphical LCD is promising. I'll consider going for this solution for the portable game console project. Of course, I won't be using Arduino for that. Arduino is good for prototyping. But it isn't as efficient as lower-level C/C++ programming.
I've played this game for many times. While it's technically possible to win, I haven't managed to do so. And I haven't tested the code of winning the game. I doubt that anyone could beat it anyway. I guess I'd just leave the code there as it is. :P
Alright. That's enough fun for today. Gotta sleep.
This year, I have done another Global Game Jam. I did it in Hong Kong again. Mainly because I was being too lazy to try out other jam site for this year. :P This year I had done something different. I did music instead of programming.
I had spent quite a while for practicing using Musical Palette - Melody Composing Tool, LMMS, LabChrip, sfxr and Audacity. I've figured out an efficient method to produce music. That is to come up with melody and chord harmonization by using Musical Palette, then import them into LMMS to further process it. I managed to produce a few pieces of good quality 1 minute music, each of them was produced within 24 hours.
For the LabChrip and sfxr, it's nothing more than about using the randomizer and manual fine adjustment of the parameters. And Audacity is even easier. It's just useful for noise cancellation and applying effects.
Just like the previous years, I came to the site without a team. As I planned to do music this year, it isn't possible for me to do it alone. So I sought for a team right after I entered the jam site. I tried requesting joining a random team by asking them and got politely rejected. Then another team with three existing members waved at me and asked if I was alone. I answered yes, told them that I made music and got accepted into the team. Then I had a dinner provided by the organizers. Here's a pic with more than 300 jammers begging for free food:
In the midway of our game design discussion, two of the team members had left their seat temporarily. Since I had no idea about the roles of other team members, I asked the remaining member about their role. He told me that he did art, one of the other team member did programming, and when he tried to explain the role of the last team member, his was like "uhm... uh... he's... uh... good at coming up with, uh... uh... ideas and presenting, uh... the ideas". :P Then I ended my question with "Ah. He does marketing. That's good." What I thought was that "He gotta be an idea guy!" :P
When all of the members were back to the seat, we ended up with a consensus on the game design timely.
Then we started connecting to the internet with WiFi. It was very unstable. Then I tried using mobile data by USB tethering with my smartphone. Surprise! Even mobile data is stabler than the WiFi connection provided by the organizers. Since I had a data cap, I had to use my data wisely. So no youtube for me.
I had started to draft a piece of music in the first day. Musical Palette were used for drafting the music.
In the second morning, I managed to caught the shuttle bus provided by organizers and arrived at the jam site early. I had breakfast. There's some open area in my jam site. It's rather interesting to see those people standing and eating outside. Some of the jammers had a bit distance in between possibly because they don't know each others.
After the breakfast, we got back on working. I gave the on-site WiFi another shot with no luck. And I used my mobile data again.
Then I was sitting along with the marketing guy. I sporadically took a peek on what he's doing. That was funny. Most of the time he had his Mac laptop playing youtube video, surfing facebook or chatting with instant messengers. At the same time he was holding a smartphone playing games on it. That was impressive. He was taking multitasking to the next level. To be fair, offering critical opinion requires playing others games. Anyway, he did spend a bit of time to look for info about how to make an awesome trailer for games, and studied about the good indie games.
Then the real fun begin. I continued making the music and completed composing with Musical Palette. Then I started working with the same piece of music with LMMS. However, it didn't went as smooth as I thought. In the midway of making the music, I asked my teammates to review it. Then the marketing guy complained that. He demanded a piece of music with abstract wordings that I couldn't understand. :P As you know, musical stuffs is difficult to be described by words.
After a while, he provided me an example of music that he's interested in. That was the BGM of Plants versus Zombies. It was a piece of music with drums without melody.
Then I toss away the old piece of music, made a new one and came up with this in Musical Palette:
I had never made this sort of music before. Using the same chord over and over again for 16 segments (or phrase in that program). Chord variation techniques were used. It isn't the sort of music that I like. The music sounds extremely stressful like playing airport traffic control games. But it does fit into the theme of the game. Then I mastered the piece using LMMS:
That's crazy. The same chord is played for a long time as shown above. I had added some sidechaining to it. Then I showed my teammates this piece of music. And they're ok with that. It seems to me that it isn't perfect to the marketing guy. But apparently he compromised and told me that this music is ok. That's possibly because of worry of time constraint.
Then I started working on the sound effects. That was rather easy to me. Depending on the sort of sfx, I used LabChrip, sfxr or remixing recorded voice with Audacity.
Working with LabChrip and sfxr was easy. Just click on those randomization button until I get a sound that's close to the one that I want. Then I adapt it a little bit and that's it. Using Audacity is still easy, but it has a bit different workflow. For the sound effects that's simple, I just performed noise cancellation and reverbed it. For sound effects that has like having many people saying the same something, like wow, or laughing sound, what I did was to record the sound for multiple times myself. Then performed noise cancellation, overlapped those recorded sounds, and reverbed it a bit and here we have it.
Speaking of noise cancellation, I'm rather surprised at the noise cancellation capability of Audacity. Behold a screenshot showing the power of the noise canceling effect:
We were in a noisy room with a lot of discussion from parallel teams sitting right next to us as shown below:
The result was brilliant. I seriously thought that I had to get out of the room for recording the voice. I'm not sure if it's solely Audacity, or it's that I was using a headset (Kingston HyperX Cloud Core) that allows me to put the microphone closely to my mouth for clear recording. But still, considered the environment noise, the result of the noise cancellation was very impressive.
At the end of the second day, I went back to home. All of the teammates claimed to stay overnight.
In the third day, I woke up a little bit late. So I couldn't get on the shuttle bus. I arrived the jam site by myself. After arriving at the site, I've found that our programmer had got back to home last night. And he would be doing remote working for our team for the day.
The third day was relaxing. There wasn't much for me to do. After goofing off for a while, our team had started producing the promotion video for our game. The rule of our jam site is to make a one minute trailer for the game. So I had make a piece of music dedicated for the trailer. The art guy did the video and synchronized the text with the music. The resultant video was quite good. The programmer had uploaded the game and our team members were happy about the game and the trailer. I haven't had time to try out the game that our team made, tho. That's because I was on linux, which is unsupported by the game.
After that, the marketing guy had come up with a story written in the description of the game. Then I extended the story with better wordings. Right after the game submission deadline, the artist and the marketing guy left because they were exhausted of staying overnight. At the end the marketing guy didn't do much other than giving critical opinion and discussing the game design. It seems to me that that guy is more like a quality control guy.
I had got a bit of time to chat with a few interesting jammers on the site. Before I had the time on socializing with them. presentation session had started. It mainly comprised of playing those 1 minute trailers. When it was my turn, I was rather surprised that the volume of our trailer were so low. I don't know if it's the audio of the vid itself, or the staff had set the volume level to too low. After that, the sponsors gave awards to some well-performing teams. And that's the end of the Global Game Jam of 2018 to me.
We took shuttle bus to a major metro station and got back to home.
After getting back to home, I tried playing the game that our team made. I was rather disappointed with the game. It was severely bugged and it isn't even remotely playable. Despite that the trailer looks good, the game itself sucks. Then I tried out other games produced in our jam site. They had similar problem. Super buggy. Not playable. Good or mediocre trailer, but no fun to play with at all. Wow. Seriously?
I guess now I've finally figured out the truth of Global Game Jam in Hong Kong. Almost all games here sucks with funny or semi-interesting trailer. Many jammers are just interested in getting an award. That's something that I truly hate because it isn't what a game jam about. If you like 48 hours game development competition, you could have just joined Ludum Dare!
I don't know. If I have enough spare time, I should seriously consider joining Global Game Jam elsewhere next year. The Macau one seems to be feasible because the guys there speak Cantonese, so there wouldn't be any language barrier to me. And the bridge connecting Hong Kong and Macau should be completed by next year. That'd make it easy for me to travel to there. :)
Despite that this jam isn't perfect, it's good enough. I'm happy about it. :)
Now I've a few pieces of music laying around. Some of them were produced for practicing making music before the jam. One of them is incomplete and was produced during the jam. Perhaps I can write a few songs with those music in the future.
And I also have some sound effects produced. Maybe I can create an asset pack with them.
This year, I've developed the game E. M. Wave Jammer. It is the world's first telephone game in Global Game Jam, which is playable by dialing a telephone number.
I FUBAR'd in last year's game jam. Fortunately, I did much better this year.
This game is for entertainment only, no political message intended.
For Hong Kong SAR phone numbers, dial 54839953. For non-Hong Kong SAR phone numbers, dial +85254839953 with skype. We do not accept international non-skype calls to save our operational cost. This game has Cantonese(Press 1), Mandarin(Press 2) and English(Press 3) version. Please notice that this phone number is temporary. It will be changed after I've finished setting up my phonesite.
The game happens in Japan during Cold War era. In the game, North Korea is using advance electromagnetic waves technology for sending signals to Cuba. They are plotting to attack Japan. In the game, the player plays as the role of the commander of telecommunication department. The player is responsible for jamming the signals between them.
For the ease of command, Japan is divided into 6 zones. The electromagnetic waves from North Korea will propagate via zone 1, zone 2, zone 3, zone 4, zone 5, zone 6, all the way to Cuba.
The player is required to use limited amount of electricity to build jammers. Electricity are consumed for building the jammers. No electricity is required to operate the jammers. The more electricity you spend to build a jammer, the more powerful it is. For example, a 5W jammer can attenuate the signal by 5W.
The remaining non-attenuated signal will become military information end up on enemy's hand. When the information level reaches 100%, you lose. The information level is increased by the Wattage of signal received divided by the Wattage of signal sent. There is no way to reduce the information level.
The player starts with 20W of electricity. To generate electricity, generators have to be built. They generate electricity when signal pass thru its zone. For example, a 5W generator will cost 5W to build, and generates 5W of electricity.
Each zone can only have one structure(e.g jammer, generator). New structure building on a zone with existing structure will demolish the existing one. Structures cannot be sold.
After wave 6, there will be Accelerated E.M. Wave signal. It is able to bypass Zone 2, 4, 6. It is sent via Zone 1, 3, 5 to Cuba.
After wave 11, there will be Narrow-band E.M. Wave signal, which includes low frequency E.M. Wave Signal and high frequency E.M. Wave Signal. Ordinary jammers are half as effective against these signal compared with other signals. Therefore, the player is able to build LF Jammers and HF Jammers to defend against these signals. A 10W LF Jammer can attenuate LF Signal by 20W, Ordinary Signal by 5W, and cannot attenuate HF signal. A 10W HF Jammer can attenuate HF Signal by 20W, Ordinary Signal by 5W, and cannot attenuate LF signal.
After wave 16, there will be E.M. Wave from Cuba to North Korea, which propagates via Zone 6, 5, 4, 3, 2, 1 to North Korea. Accelerated E.M. Wave from Cuba propagates via Zone 6, 4, 2 to North Korea.
After wave 21, there will be FM Signal. FM Signals is immune to Ordinary Jammers. It makes non-LF, non-HF FM waves very troublesome to be dealt with because they couldn't be attenuated by ordinary jammers. Yet, HF and LF jammers are only half as efficient to deal with non-LF, non-HF waves.
Before the Jam, I've developed the hardware Dinbo Prototype B as well as its library libdinbo. I've also made a template for developing any telephone system based on this library.
In addition of the telephone system, I have also practiced using LMMS, Labchrip, Audacity, SoX, just all of the software that I planned to use. I also planned to practice Aegisub for making video subtitles. Unfortunately, I didn't have enough time and the Jam day had come. :(
Just like the last year, the 48 hours game jam spanned across three days.
In the first day, I've arrived at the venue, before the event started, I've found a bug on the library of Dinbo Prototype B that made it failed to detect DTMF touch keys properly. Fortunately, I fixed it right before it started.
After that, I've listened to the briefing. After the theme Waves was announced, I came up with this game design quickly. Since I was working solo in this jam, this process went way quicker than the jam of previous year. :)
Here is a photo of my game design document. As you see below, it is only one A4 page. It is poorly-organized because I'm the only intended audience of this document. :P
Some of the features are strike'd out at the design stage because I foresaw that it couldn't be completed within 48 hours.
Here is a photo taken from day 1 of the event. Sorry for phone camera quality:
There were many jammers in our Jam site, and the Hong Kong SAR was the 8th largest out of 700+ jam sites all over the world in 2017!
With the experience of last year, I won't sleep on-site because I couldn't. At the end of the day, I went to home and took a rest.
Although I slept much better than last year, I still didn't sleep enough. Therefore, I woke up late. I started programming. Feeling dizzy, I took a nap after an hour of development. Then I woke up again and continue. To save some traveling time, I decide to jam at home this day because I was solo and I didn't need to go to the site to collaborate with my teammates.
With software emulation feature of the libdinbo, I was able to develop the game without dialing the phone number. It saved me some cost of calling the number.
With existing code base, the development went smoothly. I managed to implement the game play. After midnight, I started translating the game into Mandarin as well as English. I have also synthesized and recorded some sfx. Originally I also planned to make music and recording the Cantonese voice myself. Considered that I need to prepare for the presentation, I decided to drop these features and went to bed. All of the development works ended here. However, I still haven't deployed it on the Dinbo Prototype B hardware.
I (almost) dedicated this day for preparing for the presentation. I decided to prepare for the presentation before deploying it to the hardware. That is because the deadline of submitting the presentation was very tight. And preparing presentation before the deployment can buy me a bit extra time.
I started with recording the gameplay audio using the voice log function of the libdinbo in its software emulation mode. It went quite well and I've recorded a 9 minutes audio. I had cut down the audio to 4.5 minutes.
Then I asked the volunteers about the time limit of presentation. Turned out that each team would only be given two minutes to present their game. Well, I thought that I had 5~10 minutes. :/
After that, I further cut down the audio to 1.5 minutes. Even the gameplay instruction were removed.
So how did I explain the gameplay? Simple. I used Libreoffice Impress to make some presentation slides to visualize the game play frame by frame. Then I played the gameplay audio and used vokoscreen record the voice and the presentation slides. I clicks as I record and play the gameplay audio. After that, I used ffmpeg to trim beginning and the end of the video. Then convert the video format to webm. Here is the demonstration video in Cantonese.
After that, I prepared another powerpoint file. I planned to use the powerpoint before playing the demonstration video.
Everything went well, except that the deadline was very tight. I had to do everything I said above within like 3~4 hours. Then I uploaded my video to the website of Global Game Jam and sent the powerpoint to the staffs. After that, I have deployed my program to the Dinbo Prototype B hardware.
Here is the presentation session(the guy who is presenting in the photo is not me):
It didn't went very well when it was my turn. I thought that I could access a presenter's mouse so that I could show my powerpoint with animation. I thought that I could click the powerpoint myself. Unfortunately, the presenter's mouse wasn't working somehow. Then the staff of my jam site just random clicked his mouse, causing the slides shown up earlier than it was supposed to be shown. After that, the staff was trying to click on the gameplay demonstration video link inside the last slide of my powerpoint. But he forgot to enter presentation mode and couldn't click on the link. It looked very bad for the audience. :/
Nevertheless, the gameplay video was found to be funny by many fellow jammers. I enjoyed their laugh and applause at the end, and I earned a certificate of participation. :)
After that, I have introduced my final year project to my fellow jammers. Then I have interviewed some of them about my project. That is helpful for me to improve my final year project. :)
Finally, it was the closing ceremony of the event. As I have expected, I got no award because I'm solo. Apparently the sponsors of our site is reluctant to give out awards to solo teams. :P
Anyway, I have completed the game during the 48 hours. I have proven that libdinbo is working and I have shown my final year project to others. It is a great success compared with the previous jam.
After the jam, I have talked about the event with people from other jam sites via the Internet. Someone who joined the site of Tokyo University of Technology shared an interesting photo of the site(photo used with permission by the copyright holder of the photo):
Apparently the jammers in Tokyo University of Technology site had more fun than we do. Instead of giving out awards to well-performing teams, they had a pizza party! And the award was the game itself that the jammers developed. It is a better match to the sprite of Game Jam.
I'm performing much better in this game jam than the last one. And this year is much more fun for me. Here is what went well:
Overall, The Jam of this year went pretty well. And it was a quite memorable experience. :)
The Game Jam of this year is very special for me. It has some strategical value. As you may have noticed in my previous blogpost, Dinbo Prototype B will be a successor of the existing telephone system, Dinbo Prototype A. Dinbo Prototype B will be used for the following purposes:
This game jam helps improving the code base for Dinbo Prototype B, particularly, the internationalization functionality of the code base was enhanced during the jam. In addition, it's also a good way to test whether the entire system works. If a game can be developed for this system, then it would definitely be possible for me to develop my final year project using the same system.
That says, my mission of Global Game Jam 2017 is accomplished. Now I got to work on my final year project as well as my phonesite. :D
Want to read more? A parallel jammer in Japan had made a blogpost of his game - Super Smash Tokyo
As you might knew, I've joined Global Game Jam last weekend. It was a, well, interesting experience. I learned a lot. :P
I thought that I was well-prepared for the jam.
Months before the jam, I've developed the game Half N' Half within 24 hours as a practice of gamedev within very limited time. The project went well.
Later, I've joined Ludum Dare 33 compo and developed Poopie: The Flying Monster within 48 hours. The project went well too. The rating isn't great. But at least it's completed within the time limit. I even got a few hours of spare time.
A few days before the jam, I started preparing for it by playing around with HaxeFlixel.
Unfortunately, the team that I joined didn't complete the game What's life in the jam.
The Global Game Jam is a 48 hours event that require me to attend to the jam site physically. On the jam site that I joined, The 48 hours spanned across two days, two evenings, beginning with an evening.
In the first evening, we were supposed to form teams. Being an self-taught amateur game developer, I went to the site alone because none of my friends was interested in the event.
Right after the theme Ritual released, I didn't have any idea in my mind. Therefore, I walked around in the site to check whether there was any interesting idea I wanted to work on. Then I found a group with such an idea. Then I joined them as an artist. Since they decided to use pixel art, and I had no experience on it, I did programming instead of art, tho.
The team had nine members. It includes 4 programmers, 4 artists and 3 game designers. One of the game designer was also an artist. One programmer was also an artist.
Right after I joined the group, the game designers argued with each other for exceptionally long period of time(like 5 hours+) over an idea. Being impatient, I asked them to gave me something to program or give me some art to work on. As you know, as long as a part of the game design is settled down, programmers and artists can start working on it. This would allow programming, art and game design to perform concurrently, which will definitely save time. Surprisingly, one of the game designer told me that we can't work on it until the completion of game design. He even insulted me by saying things like "apparently you're the sort of people who write articles in exam without thoroughly planning it". To avoid escalation of the tensions, I shut up. Somehow I didn't leave the team.
During the design process they somehow decided to use phaser.io despite I strongly object to it. Out of four programmers, none of us had worked with phaser.io before. Obviously phaser.io wasn't the choice if we want to complete the game. That is because we would need to spend a few hours to figure out how does the library work. Interestingly, one of the game designer suggested that the spirit of a game jam is to experiment with stuffs.
That game designer is indeed pretty interesting. Apparently, the ideas in his mind isn't very consistent. While he thinks that the spirit of a game jam is to experiment with stuffs, he keep mentioning that some companies joined the jam with many game engines ready. And those companies adapt those engines for the theme. He keep telling us that those games won't get any awards. Implying that he thought that we have a chance for an award. At the moment, what I was thinking was that it's pretty unlikely that our team would get any award because our game probably won't be completed.
After that, I slept on the site by crossing my arms and put on head right above them. The noise of argument of the game design continues. Anyway, at the night the game designers have settled down the complete game design. One of them started working on the Game Design Documentation.
Speaking of Game Designer Document, I found that the document was funny. It was six-pages long. As a reference, behold the equivalent documentation for the game design of Poopie: The Flying Monster, which was a game I developed for Ludum Dare 33:
The document above was designed in like 30 minutes. I wonder how come they need to much time to argue about the game design. Who need a long documentation for a 48 hours game? We got no time to waste. Head on the develop the game already!
While I was asleep, I was still semi-conscious because the sleeping environment was very poor. The light above my head was so bright. Sleeping there is a joke for me. I heard something interesting while I was sleeping. That game designer told another teammate that I was not clever to suggest to work on an idea before it's completely designed. He said that he will "reeducate" me some time later. It was pretty funny for me. I don't see arguing over simple matter for a long time in a 48 hours game jam is a good idea. The longer they argue, the less time we got to develop the game.
The next day, as expected, the programmers, including me, have spent a lot of time on figuring out how does phaser.io work without working much on the functionality of the game. We also setup stuffs like Slack, git, etc for the purpose of collaboration.
One of the programmer started reading the game design documentation. I haven't read it. Just by skimming thru it, I found that it was very long! What I knew was that the game is a platformer. I hate reading long stuffs. Therefore, I just wait for other programmers to read the document. :P
One of the funny thing about the game designer is that he got work to do that day. He wasn't available in the site until evening. Fortunately, we didn't need to understand the document because our progress on figuring out how does phaser.io work was too slow. :P
The game design guy was back. One of the programmer who have read the game design documentation asked for clarification. Turned out that the documentation was misinterpreted. It was really funny. The entire purpose of the documentation is to specify the whole game design. How come it is worded ambiguous enough that it can be misinterpreted? This evening, the game designer seems to have lost his coolness that he had in last evening.
Still, our progress was very slow as of the evening. We only got a character walking with semi-working ladders. Then I decided, with permission of other programmers, to switch to HaxeFlixel myself as a backup plan. Just in case they couldn't make it work with phaser.
Meanwhile, the game designers argues on the design of the game again. It doesn't matter anyway because we didn't program to a point that game design matters.
Then I tried to sleep at night again. Well, again, it's a joke. Since the lighting of the site is too bright, I slept in a couch of a garden near the site. That place was dark enough for me to sleep. In the midnight, a mosquito flew over my ear and woke me up. I couldn't sleep after all.
In the second day, I was exhausted of not having enough sleep for two nights. I keep saying "I'm very sleepy" without helping much on the team. Fortunate enough, the other two programmers somehow managed to make ladders, characters and infinite world work. Out of tiredness, I was switched from proactive programming mode to on-demand programming mode. That day, I only programmed when I was asked by other programmers. I was probably sick since this day. But I didn't aware of it. And one of my groupmate started complain me of keep saying I'm being tired, I did find it being offensive. Anyway, I tolerated it.
At the end, we did get a sort of working game. At least it's playable. But it's nowhere from being complete. And somehow I and the groupmate who previously complain me of saying being tired ran into an argument. It was weird. I have a feeling that it was ok for me to be insulted, but it was not ok for me to insult others as a defensive measurement. It was pretty difficult to get along with the game designers in the team. :/ I was getting along well with other programmers and artists, tho.
I and probably other programmers in the team did foresee these issues at the first evening. It's sad that we couldn't do anything on it at all. I regret that I didn't leave the team in the first place.
Right after the jam, I found myself suffered from severe illness. I caught cold and I got fever. :(
The fever is now gone. But I'm still having a cold. And now I need to sleep like 15 hours every day. That's why I made this blogpost so late. :(
Alright! After I get well, I'll continue to work on Cellphone Diver!