So in Modularizing Lumote Part 1 I covered our reasoning as to why we decided to break the world down into smaller pieces. In part 2, I’m going to cover what the breakdown looked like how the world assembly system works.
As was discussed in the previous post, we had a bunch of world and wanted to break it down into single rooms that could be easily snapped together and re-arranged to adjust the pacing and difficulty of the game. The first step was deciding a minimum size that a level could be, all levels will be within a box that is a multiple of the minimum size to help us easily snap them together.
Voxel engines like the one in Lumote generally work by segmenting the environment into smaller pieces called chunks. These chunks allow for local modifications to be less computationally expensive when recalculating rendering and physics information. As it turns out, our levels happened to be almost exactly a multiple of our voxel chunk size which is 32x32x32.
For my sanity and yours, I’m going to present the world as a 2D grid through out this post.
We need to define a box for each level to fit in. Levels aren’t restricted to a 32x32x32 cube, they can be any box but the box dimensions are always a multiple of 32 voxels. Once we’ve properly defined the box for a level, we specify up to 4 evenly spaced connection locations on the vertical faces of the level. Pink for exits, and blue for entrances. This configuration allows us to define modular levels that are can be almost arbitrarily arranged while not restricting the internal design of the levels too much.
Once all the levels have their bounds defined, we use a custom flow charting tool to define the connectivity of the world which is then used to create, rotate and translate the levels that form our world.
Filling in the gaps
As you can see from the above level arrangements, we just have a bunch of floating levels. Lumote is a single world, there are no level load screens, just one big puzzle game all visible to you at once. This means we can’t just have a bunch of weird floating platforms everywhere, we want to make the levels feel grounded and solid. In order to fill in all these missing walls and pillars, we enlist the help of our voxel engine and we simply extrude lowest part of each level downward to “infinity”.
And finally, here is an example of a bunch of levels all stitched together using this system, this constitutes about 26 individual puzzles.
Since we last posted we’ve done a big overhaul of the game both visually and mechanically.
Visually we’ve replace all of our cubes or at least added living creatures protected by the crystal shells. Lumote especially went through the ringer to break out of its shell and now is hopping through the world in all its glowing glory.
Step 1) Make a Cube
Step 2) Make the rest of the Game
For gameplay we’ve added more emphasis on the possession mechanic and made the struggle between Lumote and the Mastermote a more central part of the game. Instead of facing the Mastermote at the end you’re now confronted with the it’s power in the first world and each mote can be possessed by either Lumote or the Mastermote which will determine how they behave.
There’s still a lot of work to do and we want to keep refining everything, but thought it best to come out of the cave and show everyone what we’ve been up to.
As you may have seen we’ve gotten funding from Creative BC, huzzah! You probably also notice that the time between our this post and our last one is almost a year old. The truth is we derailed for a while, last summer we submitted to be part of the Indie Megabooth at PAX and failed. It was pretty demoralizing.
After Pax, we went through a moment that I think all Indies go through where they wonder if they’re ever going to finish. You’ve been working so hard for so long just to look up and realize there still an immense amount of work still to do. The thing was we still loved the concept of Lumote, but had been working on it for two years. What did we need to do to actually ship.
We took some time to rethink what we were doing. One of the things that really helped was we started having meetings about Lumote again. We talked over arching gameplay and individually what our expectations were. We narrowed in on our weak points, for example we had great tech but little content and some enemy types were pretty jank in moments of gameplay. For working on Lumote so long, the world was still pretty undefined.
We rescheduled ourselves and broke the project down into manageable chunks for the amount of time we wanted to keep working on Lumote. We were getting back on track but still unsure. We decided to apply for Creative BC, to see if we could convey to an outside organisation what made Lumote great and on track to actually succeed, which is what we failed to do with PAX. Because at the end of the day we are building a game and if we can’t convince people that it’s great and worth playing we’re not succeeding.
Luckily we did get funding, external validation! If we hadn’t gotten the funding, I think we would still be making Lumote. It would definitely have been a big blow and made us take an even bigger step back, but we would still be making Lumote. I think that’s important to the progress of making a game. When you stall or things don’t go well, to take some time and think. Why did people not like this and how do I improve. While the funding is great, I also think it’s good that we now have to be kept accountable by something other than ourselves. This has pushed us to finish a bunch of paperwork that was long overdue. Plus we have added incentive to stay focus on meeting our deliverables for Creative BC and hopefully to anyone who’s actually reading this and thinks Lumote is great enough to follow along.
To read more about Creative BC go here!
We would like to welcome a new addition to the team, Paul Ruskay. Paul is a seasoned veteran in the video game audio world, so we’re excited to hear what he does with Lumote.
Paul was born and raised in Kingston, Ontario and was initially studying to become a dentist at Queen’s University, but switched degrees after he managed to convince the Dean of Music to let him into the music program. Then in the early 90’s he moved to Vancouver to attend Music College, and shortly after was swept up in the growing video games industry. Now 22 years later, he’s still producing audio every day and loving every moment of it.
Paul’s initial start came when he was hired on by Radical Entertainment for a short-term contract position, and then subsequently given an audio lead role in 1994. After staying with them for close to five years, he decided to venture out and start his company, Studio X Labs. This premiere full service audio production studio has worked with many top developers and publishers (Disney, EA, Nintendo, THQ, Take2, Activision, Rockstar, Sega, Microsoft), and gone on to win multiple Leo awards. The most memorable project he’s worked on is the original Homeworld (1999), and his top three games to play are Robotron (stand-up, coin-op, only), Super Metroid (SNES) and Half Life 2.
Paul loves producing audio for game worlds, and follows a mantra that involves using his creative intuitions and coming up with unorthodox solutions to create memorable experiences. He’s a true audiophile at heart!
I’ll be the first one to admit we’re not the most savvy at marketing and social media. We prefer putting our heads down and working on the game to self promoting. Which is really one of our downfalls as any dev will tell you that marketing yourself is key to success.
One of the problems I have is recognizing what is noteworthy, I tend to agonize over every tweet and post on whether they’re good enough to post or not. Or I procrastinate writing something in lieu of working on the game saying “we need something more interesting to post about”. This just ends with nothing being posted for weeks.
Recently we found out that Christian Valentin covered us on indiegame.com. We would have never known had we not been contacted by nice fellow at Curve Digital who referred to the article in his email. I went back and searched Lumote and realized we missed out on a little pocket of buzz created by the article. This was a missed opportunity and instead of using the articles momentum to reach more people what momentum it had fizzled out within a week of the article.
Marketing is a marathon not a sprint, along with the game we need to keep working on our social presence. Otherwise at the end of this we can have an amazing game that will just end up being thrown into the void.
One of the things we should have done at the beginning was turn on Google Alerts, this was just a rookie mistake on our part. The other thing we’ll need to force ourselves to do it schedule time for social media. We started using HacknPlan (check it out) to help us stay headed straight and hopefully it’ll keep us on target!
As we’ve had more people play Lumote, we’ve discovered that our puzzles were forcing players into committing suicide in order to progress. The nature of Lumote’s open-air level design means that it’s easy to lose a moving piece and puzzles are only reset to a solvable state upon death. However, forcing the player to kill themselves to reset a puzzle quickly leads to a sense of helplessness and frustration, which is what we want to avoid.
This is a horrible situation to put players in, it leaves them lost and confused and ultimately feeling cheated by the game. Once players caught on that the only way to reset, was either from the pause menu or jumping into the abyss themselves. It was only a matter of time before they put the controller down. On the other hand, we also have challenges where players would die plenty, but want to keep going. These timing and platforming skill tests can be punishing, but players felt they were fair. In those situations they always resolved to get better. We knew we needed to make the puzzles much less frustrating while keeping them difficult and dangerous.
To resolve the frustration we had to address 2 issues: Dropping things into the abyss and putting a piece where you can’t get it.
1. The first, is easy. When piece’s are lost, respawn them. Now each time you lose something, it will always reappear where you first found it.
2. Make sure so that no matter where in the level you brought a piece it could always be brought back to where you first found it. That way players could retrace their steps to figure out what was needed and the puzzles can’t be put in unsolvable situations.
Having as many people as possible play the game has been invaluable for refining Lumote, things that seem like a good idea are put to the test and iterated on. We’ll continue doing this till we have something we’re satisfied with and can present a Lumote we’re proud of.
So I know I promised a part 2 for Modularizing Lumote. However, we’ve been extremely busy putting together a video and demo build of Lumote to submit to the Indie MEGABOOTH for Pax Prime in September. With that now out of the way, we though it would be fun to share the video part of the submission with you.
Wish us luck!
When we initially set out to take our UE4 game jam entry Bump and extend it out to be Lumote, we knew we wanted to make it one giant map. The game is extremely dark and as you progress you illuminate the world. Because of this, we wanted to not only give you some larger sense of progress, but also offer some nice vistas to show where you’ve been and what you’ve accomplished along the way.
With that in mind, we started laying out the world. It’s made up of a central hub surrounded by towers; you go up one side of a tower and down the other where you exit into the hub and progress to the next tower. We began by roughing in the flow of the first tower, making sure you can’t reach places you shouldn’t, and winding around so that you can get some nice views of where you have been. As we progressed, we were also building the challenges (puzzles and platforming rooms) which fit nicely into the flow. However, we soon came to realize that constructing the world this way caused some problems.
First of all, the entire game world was in a single file. This meant that we could not iterate on the high level flow of the world and design new challenges at the same time. We knew this would be an issue in advance but made the concession that since there are only two main level builders, we could work around each others’ schedules.
Secondly, we have always had aspirations for Lumote to offer either user-generated challenges or procedural world assembly, or maybe even both. While this isn’t a feature on our road map for the initial release, it is something that we would love to see one day. That means, having the entire world as one massive asset really limits the possibilities.
The third, and most important, issue was adjusting difficulty and pacing. Each time we added a new challenge, there was often the realization that we had made something that would be more appropriate earlier or later in the game. Often this meant that all edits were destructive, replacing a challenge literally meant that the old one was gone. If it was really good we might save off a copy of the map so we could isolate it and reuse it later, but that wasn’t ideal and became quite time consuming.
After getting back from GDC 2016, we started discussing how we might overcome these problems as we continue to build out the game. The result was a fully modular version of the world, where we can snap challenges together and easily swap them out or reuse them to adjust the pacing and difficulty of any part of the game.
As you can see in the above example, this area is roughly the same before and after modularization.
Check back next week for part 2! We’ll be discussing how the world is broken down and some of the technical problems we needed to solve.
After letting the public loose on Lumote at Full Indie, one of the main things we knew we needed to fix right away was the way we visually communicate actions to the player. We had put this off thinking that we had other higher priorities, but watching people play proved to us that this was wrong. Our core game loop is; explore, discover, possess and we were failing on all accounts to make this a natural and interesting experience for players.
Lumote is all about pushing through he darkness. As you move through the world you light it up, creating your own breadcrumb trail. For our Full Indie build we used a star like shader that lit up the ground making it twinkle to show players where to go. This pattern was a hit (aesthetically) with the crowd. However it made it difficult for players to tell where the edge of a the ground was which left them frustratingly falling to their death more than we’d like. To improve that we’ve now made the glows at edge more concentrated, making it much clearer where players can walk and jump to.
Players were constantly getting lost and turned around when they ended up behind an object and had to swing the camera around. They would swing it wildly to find themselves and then not know which direction they needed to go. In order to solve this we added a camera reset button that will reposition the camera to an unobstructed view of the player. We’ve also added in x-ray vision that shows you the outline of Lumote and some of the local environment when the camera is obstructed. There is now none of the panic to re-find yourself and players can move the camera in a more thoughtful way.
The world of Lumote is alive and full of possessable creatures. By resonating on them, each creature can be controlled and also has an action that you can perform (Hunters dash, Guards shock things, etc). There was very subtle visual and aural queues that anything was happening and most players had to be directed on what to do. By adding ripple effect whenever you resonate and a burst of particles when the possess action is triggered, players are now able see that these are special actions and that prompt experimentation in different situations.
Now that these improvements are in and more to come, we can’t wait for the next Full Indie to see how people react. The more people play the more we can improve and make Lumote into something that’s Luminawesome.
One thing devs are always worried about is showing their games to the world while still in the development cycle. You’re always afraid it’s too soon, and that first impression can really make or break the reputation of a game. Well, last week team Luminawesome threw caution to the wind and went to Full Indie Meetup Vancouver. We showed our game for the first time to people who aren’t bound to tell us nice things due to familial ties and it went great! Lumote was well received, people were really drawn in by the visuals and we were able to get some great feedback on how to improve the game. There were some issues we knew about but had yet to address. Watching people play helped us prioritize what needed to be done.
Full Indie gave us good training for “meeting the public” as it were. Kyle showed people the game and watched them play, while Michelle fielded observers and explained the game concept. Aside from ways to improve the game, here are some additional things we learned:
- Eat beforehand! Interacting with people while low on energy is no bueno.
- Have your stuff in an easy to reach place. We ran out of business cards and had to hurdle a table to get to the extras.
- Talk to all the people at the start of the night! At first we were shy and only talking to the people who were upfront and obviously interested. Later we noticed some people would glance at our game from afar but not come over, so we stepped up and started approaching them and had some great conversations. Now we fear nothing! 😉
The most important thing we got out of it was a boost of confidence. Watching people have fun and hearing their overall positive feedback really invigorated us. It’s easy to get discouraged when working in a void and things are slow-going. We can’t wait to show off our new changes and improvements at the next Full Indie!