Hi Lightbringers! After a period of silence we're back to update and improve the game. New patch is out, if you guys still find any problems, or have ideas for improvements please let us know. We're aware that some of you don't like the way our save system works and we're trying to figure out how to approach it, it will probably take few weeks for us to figure out the solution. Rock Square Thunder team

[ 2022-08-05 08:19:56 CET ] [ Original post ]

Hello, Lightbringers! We are all pleased to announce that we are now officially adding support for Chinese Simplified! Seeing as we want as many people as possible to be able to play our wonderful game, we felt that it was only necessary to bring it to as many people as possible throughout the world. So this one's for you, the Chinese speakers of the world. Make sure to wishlist and follow us here to get the latest updates, as they come! Follow us on our social media: Discord Twitter Facebook You can also sign up for the newsletter on the game's official website: thelightbringergame.com Love, Rock Square Thunder

[ 2021-07-27 17:00:04 CET ] [ Original post ]

Hello, Lightbringers! We are very excited to announce that we are officially bringing The Lightbringer to Linux! There is now a Linux version of the demo available for download on the The Lightbringer Demo store page, alongside the version for Windows! After some feedback from the community, we decided to officially support Linux, as we want as many people to experience this poetic journey as possible. Make sure to wishlist and follow us here to get the latest updates, as they come! Follow us on our social media: Discord Twitter Facebook You can also sign up for the newsletter on the game's official website: thelightbringergame.com Love, Rock Square Thunder

[ 2021-07-16 17:00:54 CET ] [ Original post ]

Hello, Lightbringers! A couple of us devs will have fun and play the game together while answering your questions and responding to your input in chat. The stream will feature: Janusz Tarczykowski (CEO) Jessi Szarek (programmer), Arek Klis (programmer) Brunon Lubas (composer) Join in to see the game in action, talk about game development or just hang out for some relaxing fun! The Lightbringer is an adventure platformer featuring light combat and puzzle elements. Travel through 3 distinct biomes (water/islands, sky/mountains, ice/tundras) and fight the corruption that has claimed the lands. Through each level theres a number of light motes you must collect and absorb. Gather enough to cleanse the corrupted monolith, teleporting you to the next level. Use your boomerang to fight enemies and bosses, jump, roll and climb environmental puzzles and find secrets in each level. Throughout the journey, youll be guided by your sisters spirit. Shell comment on everything that happens on your journey (fully voice-acted) and narrates the entire game speaking in verse. Love, Rock Square Thunder

[ 2021-06-17 09:44:34 CET ] [ Original post ]

Agile Game Development Part 3: Working Game vs GDD

1. Introduction In the last post, I mentioned how we should include the team members in the process of creating the game from day one. No waiting for GDD updates for weeks. Id like to elaborate on that. The third line of the Agile Manifesto says: Working software over comprehensive documentation 2. The struggles of communication Communication is hard. Whatever amazing concept for the game you have, it has to go through many filters before it reaches the screen as a playable thing. First, you are trying to put your thoughts on paper. What you have in your head will never be precisely what you will write in the GDD. Something will always be lost in translation. Then people reading it absorb it through their own filters: knowledge, experience, likes and dislikes, what mood they are in, and the last game that captured their heart. So what they think they just read is pretty far away from what you intended. Then there is another filter the ability to turn what they think you want into code, art, level design, etc. Its just a first iteration and you already lost so much in the translation. 3. The Agile Way But if you have an agile mindset, you can turn this to your advantage. Your artist, whos super creative and a mastered Houdini, will create something different than you imagined for sure, but it might be something 10 times more interesting. And your programmer just had an amazing idea for using a cool algorithm to enhance the original concept. And so on. So if we know this will happen why not own it from day one. Dont start on a GDD that is meant for EVERYONE. Sit down with your artists (or at least with the Lead Artist), use the design pillars and a ref board to give them a direction, but also tune in to what they might think and ideas they might have. After this brainstorming session, create a short document specifically for them. But dont treat this document as a rigorous bible with no room for changes. Treat it as a reminder of what youve discussed and the direction for the next couple of weeks. After a few weeks, youll have another discussion. A lot of things have probably changed by then and you might need to create a new one anyway. Same with the other departments, engineering, level design, game designers. Each of them will need different answers and different documents. But those documents are just a write-up of your discussion, when in doubt the team should just talk to you. 4. Ownership You want to encourage your team to take ownership of what they create. But to do that, they have to have some room to be creative and to make decisions. They cant own something they dont have any influence on. After a few iterations, the team will build momentum. Having made a lot of decisions themselves your teammates will be much more open to changes in the design. So what are the downsides of this approach? As I said before: Communication is hard. Some people confuse close collaboration and ownership with the design by committee approach. And some people will expect you to debate every minute detail and convince them of the settings direction. And sometimes they just might not want to be convinced. Others cant differentiate between the genres they like and the genres they make. So they will try to force different directions because their preferences as gamers lie elsewhere. These are all very tricky cases. That's why its really important to create a work culture where people not only dare to speak their minds but where they also understand that they are not making a game for themselves. Sometimes they have to do something they dont like. And that there is a point when debates have to stop, even if not everyone is convinced. Agendas for meetings and not exceeding meetings time are very important. Remember you are making games with a specific target audience in mind, not trying to please everyone. Thats all for this post, thank you for your attention! Have a great day, Janusz Tarczykowski

[ 2021-05-31 16:00:14 CET ] [ Original post ]

Agile Game Development Part 2: Design Pillars

In part 2 of my Agile in Gamedev series, I want to discuss the first line of the Agile Manifesto and how it applies to game development. Individuals and interactions over processes and tools Lets look at some real-world example the story of BioWare. For many years it was a company making the best RPGs on the market. But as Jason Schreier described in his book Blood and Pixels after BioWare was acquired by Electronic Arts, this experienced company (consisting of some of the best people in the industry) had problem after problem. Their next 3 games came out in horrible pain. The biggest issue that caused this was forcing the team to use the Frostbite engine. Up until that time, BioWare had used its own engine, Aurora. It was made specifically for the kind of games they were making and the team knew it well. Frostbite was made for Shooters, not RPGs, and lacked many core features they needed, which resulted in slow development and a huge loss of motivation inside the team. Instead of focusing on the team and the product, they focused on the tools and forced people to use them. I want to give you not only anecdotes but also solutions. So lets assume were making a new game. How should we start? We should start with the Design Pillars. A great example is in the GDC talk The Design Of Subnautica by Charlie Cleveland, you can watch it here. Those pillars should emphasize emotions, what players will experience. They usually shouldnt be concrete features. But this is not a strict rule e.g. on Last Of Us Naughty Dog used:

• Crafting: Ammo is scarce, so to distract or cause a higher amount of damage to ones foes it is better to use items populating the world. This works in unison with the environmental storytelling of how there are not many resources left in this world.

• Story: Last of Us is a linear game that is heavily narrative lead, they want everything to tie in with the story as mentioned with crafting. The game focuses on the story of the two main characters rather than the players own story.

• AI partners: The game is all about building a relationship between the players character with the AI partner Ellie and other partners you meet throughout your journey.

• Stealth: Combat is used in this game, but if you were to run and gun, then the game would make your life extremely difficult. So the player is encouraged to play more stealthily.

The pillars you create should be the Lighthouse that leads your team to a safe shore. Whenever there is a decision to make, its important to remember them. Once youve set those pillars up its time to start making a prototype. You dont have to create a Game Design Document detailing the whole game beforehand. Instead of being the bottleneck of the team, making them wait for the GDD and later for updates and answers to every burning question, make them part of the process. Individuals and interactions over processes and tools. The team should take ownership of what they are doing. Dont become a parent that tells them what to do. Instead, treat them like the adults they are: together you will work to bring the vision to life. Now you can have the team brainstorm some ideas on how to bring those pillars to life coders should start thinking about what technologies and tools to use, how to set up the architecture of main systems. Artists should be looking for an art style that will not only fit the vision but actually enhance it. The marketing team should start analyzing the market for what you want to build. In the next part, I will dive deeper into this phase, but for now, I want you to think about the Design Pillars of the games that you love and the games that youve made in the past. Can you figure them out? Any thoughts? Comment and share this story! Have a great day, Janusz Tarczykowski

[ 2021-05-11 06:08:24 CET ] [ Original post ]

Hello, Lightbringer Community My name is Janusz and Im one of the developers of the game. Ive been working on writing a dev diary for you, where Ill share some tips and tricks throughout the process of developing a video game. If you have any specific topics you want me to bring up, or if you have any feedback on the posts, please let me know. I hope youll like it!

Agile Game Development Part 1: How the sausage is made

Lets start with the Agile Manifesto: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan We will come back to that. But first, lets talk about games. Typical game production looks like this: The company decides to make a game X. Someone prepares a GDD, then the team starts building The Prototype. Very often the majority of the team wants to have documentation of EVERYTHING. They will tell you they cant start building the feature until they receive documentation on the feature they are making, the documentation has to contain all possibilities, otherwise, they will throw a tantrum when they find an edge case that is not documented. So the countless pages of documentation are made by the designers. Engineers start building systems, artists create assets. Things start to shape up and it turns out the game is not fun so far. Or the designers see that what they planned simply wont work. So the changes have to be made. Most of the documentation is now outdated. Designers try to update it all. Some of the team members now have nothing to do, they are waiting for updated docs. The amount of time and money wasted like this in game companies is ridiculously high. After some time The Prototype is ready. Now usually its used to pitch a game to the publishers. In the meantime, the production is being planned. Based on the prototype Leads prepare estimates of how many people with what skills they need. Less experienced teams will simply take the GDD and the prototype and come up with a precise (in their minds) plan, they think they know how much work will be needed. More experienced teams usually will add 30% to their precise plan, cause they know things can go wrong. The publisher Y is interested. But they want a precise budget for the game. And a milestone plan with a precise number of assets etc. Its impossible to accurately make something like this, but everyone pretends it isnt. So they use their precise estimates, do some hand waving to fit it with the team they are planning. They come up with some out-of-air numbers like 20 NPCs, 100 building assets, 5 levels, and so on. They send it to the publisher. If the publisher likes it, they sign a deal, and voila! Now everything will be great, they have a precise plan after all. You can probably guess what happens next. You have probably seen it happen time and time again. Games being delayed. Games released in a terrible state. Your Anthems and Fallout 76 releases. People crunching, sleeping on the floor in the office, divorces, bankruptcies, talented people looking for new work, AAA companies going down in flames. And its pretty much all down to the beautiful lie that the game industry still believes in: That games can be precisely planned, estimated, made on time, and being masterpieces on top of that. Some companies even pull it off. Usually by crunching, sometimes by having lots of cash to set longer milestones. The IT in general had the same ideas and the same problems. Its called Waterfall software development. And boy, did it fail. Time and time again. So people got smarter and came up with Agile. To reduce costly and surprising failures. Some super smart people (including famous Uncle Bob Martin watch his talks on YouTube, cause he is AMAZING) created Agile Manifesto to sum it up. Lets quote it again: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan I think you can see how the typical game production is far from this manifesto. Its the exact opposite of Agile. And its the reason its so problematic and toxic. I think it should be enough for one post. I want you to digest it all and think about what you think should change. How would you approach fixing this mess? And I will share my ideas in part 2 of this series. Have a great day, Janusz Tarczykowski

[ 2021-04-12 18:02:05 CET ] [ Original post ]

We are super excited to finally be able to properly announce The Lightbringer, a poetic puzzle/platformer weve been working on for some time now :) We will share loads more information on this semi-isometric, poetic journey very soon but for now, we happily invite you to join our Discord:
Make sure to wishlist and follow us here to get the latest updates, we have lots planned! Follow us on social media: Facebook Twitter You can also sign up for the newsletter on the game's offical website: thelightbringergame.com Talk soon! Love / Rock Square Thunder

[ 2021-04-06 13:41:47 CET ] [ Original post ]