We're just a bunch of developers, trying to do something, creating experiences that stand out, creating fun. Sometimes we succeed, sometimes we fail but for us, it's not always about whether you win or lose, it's about how you make the game.
You can read all about the latest stuff in the blog or check out these featured articles:
Even though my LD33 game is still unfinished, it's time to talk about progress. And, well, there's been quite a lot of it.
...it's all about not doing too much of it, all the time.
The goal here was to make it possible to skip the lightmapping step as often as possible (especially while doing minor edits to level, configuring path points and things like that). As I've already tested it while making the level for my LD33 game, the goal has been reached already.
It took about 30h to implement, which was 3x more than my initial estimate, 10h. The system consists of a "level graphics container" that handles all the meshes, surfaces, lights, lightmaps, sample tree and some other things. Entities, patches, and blocks were updated to manage their graphical representations through LGC. This all seems very simple but it required quite a lot of new code so bugs appeared, as expected.
This also didn't include the time spent on multithreading the lightmapper, which was required to run it in parallel to editing. I don't generally edit the level while my lightmaps are being compiled but I've made sure it's very much possible.
Another minor thing to mention - mesh lightmap size is not mesh size-based anymore. This seemed like a good idea in the beginning but usually just leads to lightmaps incompatible with the texture coordinates made for them.
...because plain freezing up is no longer in fashion!
I wish I had more to show here but, looking on the bright side, this image is small enough to download and can be understood quickly. :)
Not sure what to put here yet, currently it just fades in, slightly animates the text and fades out in the end. A progress bar would be welcome, as would some description of expected adventures but all that can come later.
Connecting all things scripted...
Two types of them are currently implemented - hinge and cone/twist constraints. No limits yet but there are 4 constraint slots that can connect any of the (up to 4) bodies with each other or the world.
This was mostly done as research towards ragdolls but who knows where else I could apply it someday. Swinging dynamic lights are quite cool on their own as well.
Not quite ragdolls but of similar importance.
As some could probably guess, this is made to simulate deformation created by applying external forces (gunshots, punches, explosions etc.). In the animation above, the force is applied approximately in the same orientation that the camera has.
This was created to avoid the explosion of animation variations regarding response to external forces. Hopefully it will make gunfights more visually interesting as well.
As for ragdolls, I've actually gotten quite close to having them, the character editor already supports joint editing, the file format contains all the necessary structures. I just have to apply final modifications to the editor, implement a basic generator, add the constraint limits and implement ragdoll behavior in the character system. All goals very reasonable and within reach, though I'm not sure when will I be able to get to them.
...is still in development, though I do have something to show:
Since I've discovered lots of issues that should be addressed, such as...
...I'm probably going to address these first. Maybe I'll try to poke around embedded devices (Android perhaps, this time?) as well, try to make something work for them.
I've got so many games to rate as well so the next update might be delayed due to there not being much to slow after two weeks.Add a comment
After another two weeks of mostly doing various fixes for existing tech, it's time to report. Let's start with an image:
Solid glass that cracks on the first shot and, well, bleeds bullets on the next. It's rendered in two layers, one is for darkening and the other is for damage (stains, cracks).
It was time to finish up, so editor support for scripted items was implemented.
What was necessary:
Additionally, some fixes were done for the whole system:
All of this was successfully implemented so the last thing left is just making a game entity that holds a scripted item. It's expected to be done fairly soon as there's just not much to do.
...is more or less done, after some redesign and some added functions
Designed to support mouse scrolling, clicks, up/down buttons and some keyboard shorcuts. Using the new multiline text rendering function that was ported from sgs-sdl library, which was in turn ported from whatever previous engine I was working on. Has basic UTF8 support, not that I need it yet, but it's nice to know it's there.
Transparency, particles and decals.
Lots of things were done to make this look good.
Facts, vision, hearing.
Enemy AI now is capable of storing bits of recent information about the state of the world. From that, it can partially extrapolate some other data, such as positions of other AI characters and the player.
The reason for the delayed blog post.
Shadow generation was upgraded and optimized. Now high quality soft shadows are unbelievably cheap, thanks to the idea of using raymarching for soft shadows and some hard work on my part, implementing AABB trees for efficient distance sampling.
There's still some optimizations to be done so it might take a bit more time to appear in game screenshots. But I'm getting there.
I should mention that this was not initially the part of the plan, though. I was implementing AABB tree and two-level raycasting (mesh instances/triangles, previously there was one big triangle soup) for the option to disable specific mesh instances when certain samples are rendered (in case I wanted to fix lighting for samples inside meshes they're about to represent). But I do like the results and would like to have them in the game.
Since LD33 is coming soon, I'm inclined to participate (in the Jam this time, can't release the source yet, and hopefully by making a FPS). This means I have 1.5 weeks left to prepare for it. I have a quick checklist for things that I should really implement, starting from most important to least important, with the expected amount of time it could take.
Having about 40h of free time left, it should be possible to do all of this, if that's all I do and there are no issues to deal with on the way. Realistically, the last one or two tasks will probably not get done.
We'll find out how it goes soon enough.Add a comment
These two weeks involved lots of different activities, including content creation (crouch animations, particle effects), code cleaning and developing new systems.
Some of the work can be seen in this animation:
Design upgrades & implementation.
The design was simplified to reduce some coding issues and make it easier to understand. Used more artistic representations (strikethrough lines and question marks) instead of words and clever groups. Double readability of everything (words + symbols) seems like a good rule for accessible UI.
The implementation required refactoring some of the systems made for the previous (mini-)game to include things like radio buttons and control themes. This is more or less the current state of the implementation:
I expect to finish this up in the following weeks as the UI is ~50% done.
Interactive entities defined fully in SGScript code.
I needed some way to easily produce destructible/dynamic items, which was the reason behind the design of scripted items. Currently they support:
Most items will probably work according to these few rules (which are fully supported now):
However, there are still a few things that might be necessary to add for proper effect coverage:
Some future wishes:
Minor upgrades that are still quite important.
In the end, I'd just like to mention this one idea that popped up recently - producing a storyless, arcadey, gameplay-test shooter that would be released before TACStrike and contain pretty much just the shooting aspect of the game. Full alert mode, minimal stealth, no exploration, just fighting against AI in different environments, trying to survive various encounters.
The reason behind the idea is that I've been struggling with the shooting aspect of the game due to the chosen perspective of the game (aiming is currently somewhat unintuitive at the moment) and I'd like not to bet on too many moving parts with a big game. Exploration takes time to be fun, fights require tweaking. I'd like to tweak first and take the time later (preferably with some funding gained in the process).Add a comment