SourceForge.net: Project lipsofsuna

Welcome to the biannual Lips of Suna lack of progress update! Not a whole lot has happened since the last update, apart from some rather fruitless coding and even more fruitless modeling attempts. The lack of progress mainly stems from the need to redo large parts of the game because parts of the design simply didn’t work in practice. Unsure of how to fix the issues, I lost my motivation and ended up working on my other projects instead.

However, since I’m now bored of the other projects instead, and since I think I have some pretty good ideas that should solve the problems I had before, I’m back working on this again. As some warm up, I’m going to outline some of the problems and solutions here, despite there probably not being any audience due to the FGD planet having the RAIDS.

Terrain

When I decided to go for destructible terrain, I kind of knew that there would be some obstacles on the way, but I never guessed that it would get this bad. All those problems that have arisen and all those compromises needed are the main reason for the inactivity. I’m still not entirely sure if I’m heading to the right direction, but surely something will come out of this.

The primary problems with the old terrain system and all the prototypes I have written since were that they either used tons of memory and processing power, were too hard to edit even for me, or were just too limited to be interesting. Basically, there’s no way to eliminate all three issues when you have a huge map that players can alter at will so a lot of compromising is necessary.

The best plan I have come up with so far is to implement the terrain with simple 3D tiles that are rendered as static 3D models. The biggest problem with this approach is that even with rather large tile edge lengths, the number of visible non-empty tiles increases to tens of thousands if you set the draw distance to what people expect from modern games. While various optimizations could eliminate some of the tiles, it might be necessary to reduce the draw distance to keep the frame rate acceptable.

The reason why I’ll probably end up choosing this system is that, even though it’s expensive and limited in many ways, it’s the most map editor friendly system out of the available options. Tiles can be modeled in Blender like all the other models, and selecting them in the level editor and placing them to the map should be rather easy to learn. Manually modeled tiles also offer some interesting gameplay possibilities over plain procedurally generated surfaces, and they’ll probably look better too.

Equipment

I initially wanted to do all the equipment graphics with separate models glued on top of the naked player mesh. While attempting to create content for the miserably delayed next release, I concluded that, even though it works pretty well for small items, doing clothes and armor this way is hopeless. If the equipped item is large enough to be influenced by multiple bones, preventing the base player mesh from penetrating the item mesh is such a huge pain that it’s easier to just create a new character with the equipment in question permanently modeled into it.

I was originally hoping to give the player a lot of freedom in mixing and matching different armor pieces, but I’m going to give up with this idea now. There will only be one equipment slot for a whole armor set, meaning that you won’t be able to choose individual armor pieces. Even though there will be many other equipment slots for items such as shoes and gloves, only changing the armor set and weapons will alter the graphics of the avatar. Items in other slots will just affect the abilities of the character.

Indeed, this decision is unfortunate, but I just can’t see the original plan happening. Anyway, I don’t think the gameplay would have benefited that much from the individual armor pieces so the loss is mostly cosmetic. Avatars could probably be made more customizable again later with some texturing hacks, but it’s not that important at this point, I think.

Others

I have found the third person camera to be quite annoying in small corridors, and I think the game will have so many of those that I might have to switch to a first person perspective. I’m also considering deferred lighting as the main lighting algorithm because the polygon and light counts of the scene might get quite high. That would mean that you’ll need an OpenGL 2.0 capable card to play the game at all. When it’s playable, that is, which will probably be about the same year when the majority of gamers are running Hurd.

With the help of some feedback and ideas from #freegamer, I have been able to document the main aspects of the gameplay. Since there seems to be demand for advanced AI and physics features, I have reduced the estimated player count the server can handle to around 30. I also drew hasty concept art for the rest of the races so most of the important design stuff should be sorted out now. I’m rather pleased with the design so I advanced the SF.net project status from planning/pre-alpha to pre-alpha.

Since the last release, a lot has been happening in the scripting and gameplay front. The most notable additions include a new inventory and container system, a simple quest system, better combat scripts, the ability for monsters to attack and damage the player, and various use scripts for items. This means that it’s now possible, for example, to open containers and move items between the container dialog and the inventory. It’s also possible to chat with quest NPCs and complete a silly quest by finding a gem by mining and bringing it to the quest NPC.

I have been working on the engine a bit too and gotten some of the missing terrain system features implemented. I then refactored the map generator quite a bit in order to make it able to generate voxel terrain, but the lack of a working UI is still blocking generation of usable maps. I have been working on this problem a lot recently, but the amount of effort the required features have taken and will still take is scary. However, I’m expecting the map generator to provide such a huge boost to the gameplay that I’d be ready to endure all the pain and a good whipping in addition to get it working.

Lastly, I have decided to switch to a three or four month release cycle, at least for now, because stabilizing and packaging the game takes quite a lot of effort while being of limited use at the moment. Releasing will take even more effort now since I need to build and test Windows binaries, and I don’t really want to invest so much time on all that right now. Since progress is currently fueled solely by lesbian newspaper delivery girls^W^W^W^Wme and my time, I think that I should continue to focus on the interesting bits and release when there’s much more pressure. For this release cycle, I still want to get the map generator to a usable state and perhaps work on the skill and feat systems some more.

After two weeks of designing and prototyping, I finally got the basics of a new terrain system up and running. It’s still horribly ugly, bugged, and limited, but I’m quite excited about it regardless. Why? Because of mining. You can create and destroy terrain on the fly with it, freely in all three dimensions, so things like mining, terrain-destroying explosions, and collaborative map editing are all doable.

How will this make the game fun, you may as. True to the traditions of roguelikes, we could hide gems, crafting materials, and secret rooms here and there in the terrain for players to find. Some monsters could be made able dig so that they could attack from below or drop from the ceiling unexpectedly. Players could dig pits and moats to defend towns against attacking quest monsters. Even voxel-based water and lava streams might be possible.

The most valuable feature of the new terrain system, however, is that editing the map is much more intuitive than it was before. Instead of having to create and align tons of wall or corridor pieces just to create a few rooms, you can simply choose a material and paint the walls and corridors with the new system. When it’s all implemented, I’m hoping that map editing will finally be easy enough for almost anyone to do.

An ugly screenshot is unfortunately all that I can showcase for now. The code only exists in my local repository because it breaks too many existing features and, honestly, there has basically been zero interest for the project so far. However, it shouldn’t take long for the code to stabilize enough to be pushed to the central Git repository. Furthermore, I think I’m going to make this the last feature for 0.0.2 so expect a new release in a month or two if everything goes well.

By the way, if someone actually read this post, or at least glanced at it, be aware that no one has suffered a painful death or anything yet for contacting me. I’m a nice and calm guy, after all. Point-blank. The lack of casualties has absolutely nothing to do with you being the first one to ever try so feel free to give commenting or email feedback a shot.