GameCamp 2017: 3 Peliä

Tiimi: Hannes Salo (ohjelmoija) – Teki kaiken

Graafikoiden puutteen takia päätin tehdä pelejä täysin itsenäisesti. Muutamien eri kokeiluiden ja perehtymisten ohella sain tehtyä 3 yksinkertaista local multiplayer peliä. Näiden pelien tekemisessä kesti noin 2 viikkoa per peli. Pelit ovat ohjaimilla pelattavat ja niitä voi pelata yhteensä 4. Teoriassa pelit on kyllä tehty tukemaan kahdeksaakin pelaajaa. Niissä on myös jonkin verran lisäkehitys potentiaalia. Grafiikka on hyvin yksinkertaista mutta näyttää hyvältä, muutamia vaihdettavia Unity perus-assetteja lukuunottamatta.

Laser Taisto

Laser Taistossa pelaajat lentävät ympäriinsä ja yrittävät osua toisiinsa lasereilla. Lasereita voi ampua suht nopeaan tahtiin mutta ne kulkevat aikakin hitaasti joten niitä ehtii hyvin väistää. Laserit myös kimpoilevat seinistä ja omiin lasereihin voi myös kuolla. Pelissä on siis tavallaan tarkoitus rajoittaa toisen pelaajan liikkumismahdollisuuksia ja täyttää kentä lasereilla! Laserit on tehty partikkeliefektien kautta. En keksinyt yksinkertaista tapaa saada laserit kimpoilemaan toisistaan joten ne kulkevat toistensa läpi.

 

Blob Blaster

Blob Blasterissa joka pelaajalla on oma “maali” ja tykit sen sivuilla. Tykeillä voi ampua palloja joilla on tarkoitus osua toisten pelaajien maaleihin. Pieniä palloja voi ampua nopeaan tahtiin tai sitten pitää ampumisnappia pohjassa kasvattaakseen isompaa palloa. Kun omaan maalin on tullut tarpeeksi palloja niin pelaaja häviää ja pelaajan paikalle tulee seinä. Ideana oli saada jonkin verran taktisuutta peliin tekemällä isoista palloista voimakkaampia. Nykyisellään peli on kuitenkin aika kaoottinen, sitä voisi ehkä vielä muokata hidastamalla ampumisnopeutta hiukan. Yllätyin hiukan että Unity jaksoi pyörittää suuria pallomääriä ilman ongelmia, sillä useimmiten aina tulee ongelmia.

 

Multiplayer Pinball

Multiplayer Pinball on nimensä mukaisesti moninpelattava flipperipeli. Kentän keskelle syntyy lyhyin väliajoin uusi pallo joka singahtaa ympäriinsä. Pallon osuessa pelaajan maaliin pelaaja eliminoitu ja hänen paikkansa korvataan seinällä. Tällöin myös pallo uudestisyntyy keskipisteseen. Näin pelissä pallot jatkuvasti lisääntyvät kunnes kenttä on niitä pulloillaan! Kenttä on 8 pelaajalle suunniteltu oktagoni. Tein kuitenkin alkuun kaiken 4 pelaajalle sopivaksi joten yhdessä versiossa on 4 paikkaa ja muut ovat valmiiksi korvattu seinillä. Toisessa versiossa on kaikki kahdeksan paikkaa mutta jokainen pelaaja ohjaa kahta maalia (neljää flipperiä).

 

GameCamp 2017: Boom

Tiimin jäsenet:

Immo Ahola (Graafikko) – Pelikarttojen suunnittelu ja vastuullinen 2D grafiikasta.

Sami Flink  (Graafikko) – Vastuullinen 3D gafiikasta ja aseiden suunnittelu.

Lauri Leponiemi (Ohjelmoija) – Senior ohjelmoija, vastuullinen vihollisten tekoälystä ja bugi fixeistä.

Oskari Jaakkola (Ohjelmoija) – Mapin toiminnallisuuksien ja aseiden ohjelmointia. Pitkälti parikoodausta Villen kanssa.

Ville Karuaho (Ohjelmoija) – Aseiden ja ammusten efektien ohjelmointia. Parikoodausta muissa pelin asioissa Oskarin kanssa.

 

Boom

 

Pelin tarkoituksena oli tehdä Doom uudelleen käyttäen Unity pelimoottorin mekaniikkoja. Projektiin osallistui viisi TAMKin opiskelijaa, joilla jokaisella oli omat vahvuudet ja heikkoudet. Projektia tehtiin yhdessä neljä viikkoa ja tarkoituksena oli käyttää jokaisen kehittäjän taitoja mahdollisimman paljon. Ryhmäämme kuului kaksi graafikkoa ja kolme ohjelmoijaa.

Boom Screenshot 1 - Start of first level

Työtä tehtiin pääosin TAMKin tiloissa, tai etänä jos tietokoneiden prosessointi teho ei riittänyt mallinnusohjelmien pyörittämiseen. Projektin päätyttyä kaikki olivat sitä mieltä, että pelistä tuli juuri sellainen kuin kaikki halusivatkin ja kaikkien mielipiteitä kuunneltiin työtä tehdessä. Jotkut kehittäjät pyrkivät noudattamaan vakavaa asennetta ja pitämään pelin Doomimaisena, ja toinen osapuoli pyrki lisäämään vähäsen Nicolas Cagea jotta pilke pysyisi mahdollisimman hyvin silmäkulmassa.

Boom Screenshot 2 - Side area from level 1
Peli koostuu kolmesta pelikartasta joihin on ripoteltu kahta eri vihollis tyyppiä, lentäviä irtopäitä ja leijuvia luurankoja. Pelaajan tehtävänä on juosta kartta läpi ja selviytyä hengissä seuraavaan tasoon. Viimeisessä tasossa on tyypillinen pomo tappelu, joka ampuu pelaajaa mahdollisimman paljon. Pelaajan tehtävänä on vastata tähän tuleen samalla mitalla ja lahdata viholliset jotta peli päättyy.

 

Tekijöiden kommentit:

Tuli siinä lomailtuakin, mutta kyllä siitä peli tuli. – Lauri Leponiemi
Pelistä tuli just semmonen kun ajattelin, mutta mikä siinä Nicolas Cagessa oikein viehättää? – Immo Ahola
Pääsimme hyvään lopputulokseen, ilman suurempia ongelmia. Pelistä tuli myös sellainen kuin alunperin siitä halusimme. – Sami Flink
Muuten hyvä mutta olisi tarvinnut enemmän Nicolas Cagea – Oskari Jaakkola
Cagen määrä oli juuri sopivassa balanssissa – Ville Karuaho

 

[ LATAA PELI TÄSTÄ LINKISTÄ ]

 

Kontrollit:

WASD: Liiku
Hiiri: Tähtää
LMB (hiiren vasen): Ammu
Hiiren rulla tai 1-5: Vaihda asetta (osa aseista lukittu pelin alussa)
E: Avaa ovi, paina nappia tai käytä kentän exittiä

Boom Screenshot 3 - Later half of second level

Solarid

by Noscope

Solarid is a sci-fi third-person-shooter set in a egyptian desert temple setting. The end goal of the game is to relieve the sun-scorched planet of drought by activating the ancient machinery at the center hub of the temple. To do this, the player has to retrieve four power-crystals from around the temple. Player can engage in combat with three types of enemies using their pistol and psychic-abilities

Player engages in combat with chargers
Player engages in combat with chargers

Development process

Development started late December with some of the team already established. The original idea was to make an action role-playing game with player progression. We also wanted to release the game on steam. Needless to say, the scope was too big so we scaled the game down.

We got the basic gameplay fairly early in the development process with blink being the first skill to be implemented.  We had a couple of different skill ideas in addition to blink but we ended up going with vortex and clone abilities since they flowed well with the shooting.

Last weeks of development have consisted of bugfixes and making the game more polished and player friendly with the addition of tutorials and cutscenes.

Cutscenes highlight points of interest in the levels
Cutscenes highlight points of interest in the levels

The progress hasn’t been so fast during May since a part of the team are busy with jobs and others are busy with coursework. Our personal deadline for the project is 31.5.

Latest build of Solarid can be found behind this link . Final version of Solarid will be released on itch.io at 31.5.2017!

Final version of Solarid is coming before June!
Final version of Solarid is coming before June!

Project Monolith by CELESTiAL BIT

Team

Teppo Hyttinen

Programming  |  Game Design  |  Writing  |  Level Design

Jaakko Takalo

Graphics  |  Game Design  |  Music  |  Audio

 

Others Involved

Lassi Kähärä – Audio Engineering

Mike Bernstein – Voice-acting

 

The Game

“This place is like a vacuum, almost as if time itself was being compressed here.”

Project Monolith is a first-person, narrative-driven puzzle game with heavy exploration elements. The player controls a man who has died in an accident. He has woken up in a surreal place lodged in the intersection of birth, life and death. He must explore this strange world, solve puzzles and riddles and find out why he is there and not simply dead. In order to do this, he must find the mysterious, looming Monolith.

The main mechanic of the game is the pylon puzzle system, where the player interacts with a pylon, and the camera will be moved to the pylon and the player gets to aim the pylon at specific endpoints and by clicking the mouse, the player can attach a beam from the pylon to the endpoint dynamically. The puzzles in the demo are mostly about figuring out what pylon should shoot beams into what endpoints. Careful examination of the beautiful levels is required to find all of the endpoints and figure out what pylon belongs to what endpoint. This system was designed to uphold the core values of the game. We had beautiful levels, so it made sense to make the player to really look at the levels by finding the endpoints and not just rush through all of the rooms. Also, since the player has to use the pylon’s camera, it means that there is a reason for the game to be a first-person game. It all comes together in the end.

 

Development

“The things that this place represents, we have no name for. They are beyond human comprehension. Our minds are clouded, but I have been given clarity.”

Development of Project Monolith started officially in January 2017 but Teppo had already began preliminary testing in December 2016 but none of the testing development made into the final project. The game was under active development throughout the entire spring semester, being worked on almost every day. We decided to work on this project as a small team to make sure that everyone stays on the same page and everyone’s vision is in alignment with the rest of the team. In other words, we didn’t want to have a third or fourth member in the team. We believed that we would get more done in a smaller, but more focused team.

The game was initially inspired by some “walking simulator” titles such as Everybody’s Gone to The Rapture (Developed by The Chinese Room and published by Sony in 2015) but right from the start we wanted Project Monolith to feature much more gameplay on top of the narrative and exploration elements. We felt like the most suitable genre for Project Monolith was a puzzle game. The surreal setting for it made it easy to justify problem solving, as it made sense in the given context.

We concentrated first at the first demo session where we already showcased high quality level design as well as fully thought-out audio (excluding voice acting). After the first demo session, we started almost the entire project from scratch. We used everything we had learned up to that point, to make the same thing again, but much better. We revamped the puzzle mechanics, we re-wrote the story and we made a new, much bigger and much more open level for the final demo.

During the final weeks of development, we had a voice-over recording session where Lassi Kähärä worked as an audio engineer and Mike Bernstein did the voice acting for the protagonist.

 

The Future of Project Monolith

“The fabric is so thin here… I can feel it… The presence… It’s so near…”

Now that the semester is almost over and the project has been wrapped up, we are looking at the future of Project Monolith. This was so much more than a school project for both of us and we are planning on taking this further, by making plans on going commercial with Project Monolith. The game will most likely go through dramatic changes before we get that far, but we’re burning for this project, and we want to see how far we’ll be able to take it.

If you’d like to follow development of Project Monolith, be sure to follow us on Twitter and Facebook (Links down below)!

 

Download Project Monolith Demo 2.0

LINK

 

Contact

Twitter

Facebook

celestialbit@gmail.com

Last wave at Statron

Last wave at Statron

Team Statroware: Hannes Salo, Eetu Maunuksela, Eeva Säilä, Jonas Forsman, Terhikki Kataja, Lassi Kähärä

The game

Last wave at Statron is a scifi themed RTS/Tower-defense game set on an alien planet. Defend your main base from aliens for as long as you can by building units and structures.

The player starts out with the main base and a couple light units. A few enemies start attacking towards the main base. The player can choose to build generators to provide more income, start making more units through a barracks-building or build defensive turrets to deny enemies coming from a certain direction.

The enemy “snails” and “whales” rush towards the base in ever-increasing amounts, wave by wave. Try to build up an effective defense quick and you might just survive for longer than last time.

Progress

Hannes had the original idea about Last wave at Statron, which was basically just to make some sort of a scifi RTS. So we started to develop the game from there. At the beginning we had several options on how to approach and execute the game from the original idea. We had long discussions between the group, and had some direction from our tutors in order to make the game doable within the timeframe we had.

We met every week, and discussed about what everyone is going to do each week. At first our scope was too big for this time frame, but in the end we were able to make a playable game.

Link to game:  https://statroware.itch.io/last-wave-at-statron

Wheelsnipe

Hello. We are team Wheelsnipe, a three-man team consisting of two programmers and one artist. Our project, which we will call “Kiekkokamut” in this blogpost to avoid unnecessary search engine hits, is kind of like a multiplayer action minigolf game combined with bumper cars. Confusing enough? Well, they say a picture says more than a thousand words, so here’s one:

At least 9000 words here

So basically a hockey game, but with weirdly shaped arenas, a bouncing puck, fat animals and trail render effects. So basically nothing like hockey. Not even ice, necessarily. Totally not hockey. Just the good parts of it, with a touch of videogamey goodness.

As the project didn’t initially attract a whole lot of classmates during pitching phase (mainly due to people having already decided their teams beforehand), the original team was just two people, Pyry and Kalle. These two brave warriors set out to prove that the game would be possible to make even without an eight-member megateam and were, in fact, the first team to get something playable ready. Glorious as this was, two became three very quickly, as Penuel joined the team and provided much-needed graphical input.

Speaking of input, one of the core principles of, er, Kiekkokamut, is that the game is easy to just pick up and play. Left stick and face buttons, nothing more. You move, aim and maneuver the puck around your character all with the same stick, and perform the simplest functions (shoot, hit, steal, drop). However, the game has a very high skill ceiling, as mastery of these simple mechanics makes one a true puckhandling ninja and real-time geometrical strategist. Easy to learn, hard to master. That is what we live by.

Sparta? No, madness.

When faced with the reality that we wouldn’t have a massive art and animation team at our disposal, we figured out a clever way to make character animations without the need for rigging and skinning: limblessness. With characters that don’t have arms or legs, only hands and feet rotating around a spherical body, animations could be made with simply keyframing rotations and positions of body parts. All of the animations of the game were made in just a few hours; the animator system itself turned out to be more problematic and time-consuming than the actual animating.

Yes, this is Satan.

For our level design, we first started with some basic minigolf-inspired (but symmetrical) shapes that would provide fun deflection angles and inventive gameplay. On some levels, we added obstacles that work in a predictable manner and allow nifty passes, evasions and shots.

We ended up with 6.

Each level has a screen (a Jumbotron or a TV) from which the players and bystanders can get another view of the playing field and see replays of goal-scoring plays. The replay system constanty records the latest image data from a RenderTexture to a rotating array of Texture2Ds (stopping recording only when a goal is scored), enabling us playback of the last few seconds.

Due to us being a very small team, Unity Asset Store was utilized in all the things that helped take the pressure off Penuel’s artsy back. The true art was in choosing wisely and complementing the look of those imported assets with self-made stuff: unlike in many games where Asset Store is overutilized, we actually managed to get a look where nothing really looks out of place.

Spinning logs bolted onto glass on an airship = not out of place

On the project management side, we used Trello and a simple Google Sheet for tracking working hours. Sometimes the Trello got really bloated with stuff to do, but nothing too big that a little re-organizing effort wouldn’t fix. On the whole, our team worked really well in finding initiative in ourselves when needed and being there for each other when team effort was crucial.

What we’re most proud is that the game is actually fun to play, with great gameplay feel. This primary goal of the project was achieved quite early on, and all the bells and whistles could be added on to a solid foundation  on the side of fine-tuning the gameplay. But what would a school project be without the last few days of development being a crunchy clusterfuck of quick fixes and added features? Probably not a game as good as this turned out to be 🙂

Thalassa


Team Hexapus
Game project spring 2017

Antti Heikkinen, Samu Aaronen,
Oona Laakso, Helmi Pirinen, Ida Tuominen, Annika Aarnio

The Game

Thalassa is an atmospheric game where the player rides the underwater currents of an endless ocean in a speedy little submarine, weaving their way through dangerous waters, deeper and deeper into the abyss.

During the spring of 2017 our team, the Hexapus, developed a deep sea “Race the Sun” -like game with a submarine as the “player character”. The game has technically an endless cycle of atmospheric levels full of dangers ranging from dark caverns and falling obstacles to moody carnivous sea creatures.

The game is very stylized and almost minimalistic. There is no shooting or combat mechanics, but the player’s progress and skill is avarded with speed and shield boosts. The player is encouraged to race for the highest score by online and local scoreboard feature.

Development process

On the programming side the focus was on the shader effects and the underwater feel since it was very crucial for the atmosphere of the game to be just right. The art and design side concentrated to create simple, compact and functional audio visuals that would still remain clean and stylish.

When our group was formed we decided unanimously to have as small of a scope as possible for our game so that we could fully concentrate on making the final result clean, cool and fun without having to cut the corners.

In the end we still ended up with a bit of a time issue and learned the hard way that no matter how simple you try to make something, making it well will always eat your hours. We had to make big compromises with the theme and the mechanics to save time and the last few weeks were borderline hellish especially for the programmers. It seems to have been worth it; The game was released 14th of May 2017 to itch.io with a “Pay What You Want” option. It can be played on PC with either keypad or a controller. We are still looking into the possibility of a Mac release.

The game can be downloaded from here.

 

 

4 Crosspaws

Team Sloth+

Graphics: Veera Tikkamäki, Jutta Urama
Programming: Joni Tasala, Antti Tuomisto, Joel Vidqvist
Design: Joel Vidqvist
External advisor/comic relief: Maks L. Ouhio (name changed)

The game

4 Crosspaws is a cooperative puzzle game for four players. It was developed for PC and requires four controllers to play. Each player controls their own character, all of which are cats.

The game is set in a tower which the players have to ascend by solving puzzles together. Items that can be found on different floors of the tower play a big part in overcoming these trials. Besides puzzles based on the items found on them, the floors also have their own colour schemes.

Crossbow is the most important of the game’s items and also the only one players have from the start. It can be used as a weapon and to get through puzzles. Mana can be collected to upgrade the bow up to two times. Other items include boots that enable the characters to jump, and a monocle that reveals previously hidden objects.

Development process

The development process took about four months. It was the first 3D game our team, Sloth+, had worked on. The team consists of five members: three coders and two artists. The game was built  with Unity Engine. Blender was used as the modelling software for the 3D assets and programs like Adobe Photoshop and Paint Tool SAI for textures and other 2D assets.

It took us a while before we knew what kind of game we were going to make. Eventually we agreed on a Legend of Zelda: Four Swords-like four-player puzzle adventure. We decided to make the characters cats to differentiate it from its inspirer. And also because everyone likes cats. The game’s visual style is simplified, lowpoly, and cel-shaded.

The development process wasn’t without its problems. It turned out that the scope was too big for the time we had. We also learnt that making four playable characters, even if they are relatively similar, causes more work than you’d expect. We had to leave out some of the planned features. For example, originally there were going to be four different items besides the crossbow (boots, monocle, magnet, and sword). We were also planning to have more enemy types and minibosses. The game was supposed to end on top of the tower, but this idea had to be scrapped as well, at least for now.

Having to rethink what was actually going to make it to the game so often caused confusion within the team as to what we should be doing and what wasn’t necessarily needed. In hindsight, we probably should have spent more time planning, scheduling and, once it became clear that everything we intended to make wasn’t going to be finished, reprioritizing features. All in all, our team definitely saw the importance of trying to keep the scale of four-month projects relatively small.

The team gathered at TAMK more or less regularly; some were there almost daily, while others preferred to work at home. The entire team met about once a week. The team also regularly got some external help testing the game.

Sceenshots

4 Crosspaws Donwload link

Forge Wizard

by team.ToString()

The Game

Forge Wizard is a top-down 3D twin stick shooter, in which an apprentice wizard must regain control of his master’s home. Armed with only a few simple spells (game mechanics), the player has to run, dodge, dash, shoot, and collect his way through four wings of content, each with a thematic boss. From the outset of the project, it was our main goal that we control our scope and present a finished game by the end of the course, and we have. Forge Wizard is ready for release, and will be free on itch.io soon after the submission of this report.

The Process

Our team is proud of the hard work we put in, and the game is ready to publish. We feel it’s on par with some of the indie offerings on Steam, which makes it an ideal portfolio piece. The process wasn’t always smooth, and in fact we made several early changes to our concept that were rather large (setting, camera angle, scene building methods, etc)… but all team members were deeply invested in making a finished, polished game, and that was enough motivation to learn and adapt as we went along.

We used a few basic strategies to reach this point. First, we prioritized gameplay first and fit the art and sound design around working gameplay elements. Second, we avoided feature creep by maintaining the same few core player mechanics at all times… even removing our secondary attack early on in the process, to streamline gameplay. And finally, good programming practices were held up throughout the project, never relying on buggy behavior or half measures. This kept our builds relatively bug free, and made those we found easier to chase down.

There was an initial slow start, as ideas formulated and format changes were made (camera angle, for example). The programmers were familiar with the genre and quickly set about prototyping, but the artist was inexperienced in 3D work and took a couple of weeks to study up, to the point of generating game-quality assets. This caused a little friction on the team at first, but an understanding was reached and assets started to flow soon thereafter. This kind of acclimation period seems normal among new teams.

Feedback was vital to the process, so we’d like to thank the various classmates, playtesters, and of course teachers of the course. The game will be released on itch.io for free in the coming week, pending the creation of a trailer and other publishing media.

Screenshots

Download Link (available until itch.io release):  Forge Wizard on Dropbox

One Monolith of a Project

I met a team of two enthusiastic game makers, Teppo Hyttinen and Jaakko Takalo during their weekly scrum-style meeting at a coffee house in the center of Tampere. They are working on a promising 3d-game title called Monolith as part of their Games Academy spring semester studies.

The idea for the game called Monolith was born already a few years back when Teppo was mostly thinking about building 2D-games, but then got this idea that he thought might be simple enough for him to implement in 3D even without much prior experience in building 3d-games. Then the school and other projects started and the idea was left to simmer for a while, but after a challenging 2D-game project Teppo felt like he wanted to go all in during the 3D-half of the Games Academy and felt like this idea had a small enough initial scope so that he might realistically get it done during spring.

In December Teppo started looking into Unity and doing some early tests. Jaakko Takalo saw some of those early versions and decided he would very much like to join in on the project. This was more than welcome for Teppo as he felt they would make a good team and he knew about Jaakko’s advanced 3D-modeling skills. With the now expanded team, they decided to widen the scope of the game a little bit from  a purely narrative-based game into more of a puzzle game.

Teppo knew from the start that he had to tackle learning Unity 3D in order to realize the game. He started by watching a few basic tutorials online. He went on  to build a test level from simple cubes. He remembers having trouble with getting the lights baked and batching which led to the the FPS (frames per second) not being very impressive.

Jaakko was mostly familiar with the 2D-workflow of Unity, but had to now tackle the 3D-workflow, including a proper PBR (Physically Based Rendering) setup. He is using Maya for the 3D-modeling part and Substance Painter for creating the various texture files. The first weeks required watching hours after hours of tutorials online, but with the right motivation even such a task can  be overcome. Both team members knew that they are building a serious project and thus there was the feeling that these things absolutely had to be figured out. The hour requirements for a school project were exceeded already during the first month, but since the work was so much fun, they didn’t have to force themselves to perform it.

Teppo had to not only learn the Unity interface, but also how to bring the game together with C#-code. He compliments the drag and drop system of Unity which makes assigning scripts quite intuitive. There are still many challenges to solve though; at the moment Teppo is looking into dynamic parenting. As an interesting detail, he was actually dreaming about a solution for a coding problem, and when he woke up in the morning, he knew how to solve it. This project is big enough to even  penetrate the dreams of the team. The famous Stack Overflow -internet community has also proven helpful during this project.

Graphically the big challenge has been getting the various materials to appear realistic, with the right amounts of roughness and glossiness for example. Jaakko has also been learning Z-Brush as a sculpting and retopology tool. He takes the retopologized sculpts to Maya for unwrapping and cleanup, then he brings the cleaned up low poly to Substance Painter along with the high poly version from Z-brush for baking the normals maps and height maps. Substance Designer allows node based parametric texture creation while Substance Painter is the tool for painting in the various textures.

Substance Designer outputs small files that are then used to generate  the textures in Unity. This helps to for example keep the installation file size small, since the graphics don’t need to be packed in as bitmap images.

The Games Academy spring semester games will be published during the TAMK International Week on Friday 28th of April. By then this team expects to have their second level ready for gaming. They have been creating this new level for more than 60-70 hours and it’s starting to look good. They will also display a completely revamped puzzle-system, which is more fun than the original.

There will be a chance to test the level during the International Week session, so if you are curious about the game, make sure to head over to Mediapolis during Friday. The demonstrations start at 13:00.

You might also want to check out the Twitter and Facebook accounts of the Monolith team here:

https://twitter.com/CELESTiAL_BIT

https://www.facebook.com/celestialbit/