These two weeks I've worked on various parts of the game and the editor. Generally speaking, I'm closing in on having some idea what it's going to look and feel like and I've been taking detailed notes along the way. But more on that some other time.
Projectors
Also known as those dark things under the characters.
These things are actually rather complicated, if one would care enough to get into detail. And, believe me, for this - you do have to care a lot. Let's quickly break down the necessary steps:
- generating camera matrices and culling data (just some typical math stuff)
- culling meshes with camera frustum (finding out what the projector "sees")
- clipping meshes with camera frustum (cutting away precisely the bits that are outside our projector)
- generating additional texture mapping data (more typical math stuff)
- putting all meshes together and generating index data (math, not even once)
All these steps give us a brand new mesh, which must be regenerated on every frame, which is why these things are usually limited to projecting on the big, outliney stuff, not the extra detail, and definitely not anything involving vertex animation.
And of course, there's some additional stuff to be done, like allocating a renderer processing step that does all those things and renders the result in a specific way.
Decals
Also known as "static projectors" or "dirt, holes, stains, street art and anything in between".
My first test case for these things was bullet holes. But, be not afraid, there will be blood.
The image above could use a title "do you miss me?", referring to the character standing in the middle of a lot of bullet holes, but to nail it properly, I should be doing it the way it was done in Ali G Indahouse, in the beginning of the movie. Damn these tech preview images for being useless for jokes. :(
But technically, odd as it may seem, the hard part is to figure out how to manage lots of them cycling over and over again, deleting the old ones to avoid eating up all the memory, letting the browsers do that instead. Figuring this out involved walking around the room for a rather long time, which is my usual way of thinking, so I expect to find on me a pair of legs twice as thick after this project. It's not all bad to be walking in circles though, since, if and when some idea decides to appear, I'm not too far from trying it out.
The final algorithm that I could come up was extremely simple:
- append all the new decals during the frame, recording their contribution to vertex/index buffers in a decal buffer (two integers per decal)
- before uploading, count the number of oldest decals to remove and simply remove those parts from beginning of the [vertex;index;decal] buffers
- adjust the indices according to the number of previously removed vertices
Those of you who've dealt with dynamic arrays, should notice that I'm doing one of the most evil operations here - removing elements from the beginning. But as long as they're plain data and I can remove all I need to remove in one operation, and I'm not reallocating memory, it doesn't actually hurt.
Also, the bullet system is mostly implemented as well (needs filtering and raycasts). It supports penetration distance testing for shooting through corners and those very same impact decals from the image above.
Editor
Also known as the way to put game levels together without typing & testing all day long.
I've been hunting for workflow lately. After finishing My Flag, the current state of the editor seemed rather depressive. So after contemplating possible makeover scenarios, I realized that I had no workflow in mind.
This was easily fixed by fishing around for some Hammer (Source - HL2, CS, L4D, etc. - map editor) / Radiant (Quake / CoD map editor) tutorials that would explain how other people do things. I was increasingly doubtful about the possible ways to decorate a level, and then I found out that AAA studios still do a lot of the stuff by hand. First they make the rough structure using basic blocks (this I knew before, but not in detail) and then they add extra detail with subdivision surfaces and texture blending (this was a bit of a "wow").
I was looking at some funny decals in CoD: Modern Warfare, thinking that there was no way this kind of art could be done even semi-automatically, they must be using some special tools. Turns out, I was right about the first half - it wasn't anything special, just the ability to edit the so-called "terrain patches" and a team of level designers (I'm guessing those are the people under "Design and Scripting"). Problem now is, even though I'm completely clear on how they made those decals, I'm now puzzled over their ability to produce those amazing, natural-looking terrains with those basic terrain patches.
The thing is, a terrain patch is simply a subdivided rectangle. Well, not "simply" - the texture tools contain a healthy bit of "automagic" generators. You just have to choose the scale and press on the button that you think will generate the right layout for you. But the simplicity involved in that decision is amazing. For example, all your vertices are at all times addressable using one or two indices (it's always a 2D grid). This makes it extremely easy to insert edge strips (end-to-end cuts with vertices) anywhere, just like in Excel. Texture coordinate generation that follows the "flow" of this quad list is simple as well.
Getting back to my editor, this is what I've upgraded so far:
1. Texture auto-fitting. Setting how many times to repeat a texture on a surface in one or both axes and letting the editor take care of the rest. Useful for texturing walls. This is the first change I decided to implement because it's the easiest.
And here's a picture of a wall that looks a bit more real:
2. Object groups. Here I was imagining how I'd construct buildings - they could be turned (solved using per-group transforms), would need cutting out window/door areas (not solved yet, but the idea is to use group-local subtractive blocks). Also present would be specially modelled interior objects that could be sketched out geometrically in the editor, to be fully replaced later (solved by group block export to .obj).
3. No guest feels truly welcome without house preparation and no new feature works best without refactoring. So I started fixing the code. Split the huge file into several, extracted editor actions from the huge "main frame" class. Easily summed up in a few words but took many hours to accomplish.
4. Map layout-stage workflow implementation. I was watching this video and suddenly thought - hey, this is what I want. So I started working on block transformations that would allow me to easily make such modifications to the level, except - without two views. I don't like the concept of multiple views much because it cannot be as easily extended to off-axis editing. So, given such a constraint, I first reimplemented block moving - with the ability to lock onto axes and planes, like in Blender.
Then I implemented "extending", which is a really cool feature. It allows to stretch the selected blocks according to the selected point, automatically limiting scaling and movement axes.
Those points also automatically appear or disappear, based on the camera angle - if the point is more likely to damage the transformation (allows movement in direction towards or away from camera), it will be hidden and other points (that don't have destructive effects) can be reached easier.
This change has allowed me to quickly sketch a room layout like this in 1-2 minutes:
Looking towards the future, I have but one major thing left to do in the editor now - vertex editing has to be reimplemented for convenience. I'm already working on it, not much is left to be done.
Game UI
Just something I designed a few days ago. The font is not the right one but fits rather well just the same.
The weapon "slices" of the inventory were a concern technically. I considered various ways to render those. Including a special shader:
With some very simple functions, I can draw some slices easily. The only problem - it would be designed specifically for one kind of inventory and it would not scale. So in the end I guess I could just integrate nanovg path tessellation code or something. It was a nice proof of concept, though.
By the way, that thing in the picture - RenderMonkey. I still use it due to its simplicity, even though it is discontinued by AMD. Great for prototyping, in my opinion. Could use a way to support other editors, though.
Another concern were those button icons that I needed to put next to fonts, without knowing their resolution. For those, I think I could use "fake fonts" - generating these icons on the CPU and using them as if they were just different fonts.
Conclusion & ending notes
Can't wait to design a graphics-demo style level with the new tools, can't wait to have full game UI in the game. Generally just excited about the opportunities right around the corner. Still got some work left to get there. Trying to get over imposter syndrome that comes from using other people's code. Shouldn't be that big of a deal since back in the day I have done just about everything myself. Got less things left to prove with every minute.
If you think I can keep up the development, and if you're interested in what's going to be made here, please visit the Steam Greenlight page and vote for the game. It would mean a lot to me.
Add a commentTACStrike+: the last few weeks (up to April 27th)
Trying to slide back into action. I've been working on various things lately. All of them being rather relevant but they don't bring me closer to my goals just yet.
Direct3D11 support
I've implemented a large part of the Direct3D11 renderer (currently I have only D3D9 supported fully), learning more about the new APIs and refactoring the engine on the way. This research & set of modifications will also help me implement support for other rendering APIs when it becomes necessary.
This work also includes Windows Phone support, for which I managed to compile a part of the engine.
None of this is finished, though - it was mostly done to see how easy it would be to get it done. So far the biggest issue seems to be with logistics for libraries on multiple platforms, not the coding work itself.
Decals / projectors
I've planned the development of the necessary systems to implement both decals and projectors (dynamic decals). Not quite done but getting close. I'll be using these for shadows and environment decoration. Currently the character appears to be floating in air, making the scene look less understandable. And some variety is in order, that's what the decals are going to be for.
Virtual file system
This is a way to implement loading from multiple folders at the same time. To keep things simple, currently "multiple" means "two". This is generally used to have one "common" folder and many "project" folders, one for each project, so that all of them could reuse the common files. In this case, I was going to use the structure for my LD32 game, which might just miss the deadline, and for good reasons.
However, this is also going to help me quickly prototype all kinds of things with the engine, in a minimal environment, without having to keep all the tests in game source, commented away, in case I might need them anytime soon (or not so soon).
I consider this highly necessary as I've discovered issues with me communicating the vision of my game both via the game itself and the advertising media. Until this is resolved (by working on these issues in projects of a slightly smaller scale), it would appear that working on bigger projects would be much closer to gambling and thus a waste of time.
The game that wasn't...
I was making a stealth/hacking game for LD32. Yet, as always, I was focusing on mechanics, finishing a list of things to implement, disregarding the theatrical side of it, filling it with whatever filler content I can produce. Luckily, the graphics had some thoughts put into it. Though, not enough.
For example, I have no sneaking animation. Nothing expressive enough to make player movement feel pleasant. No "serious walking" animation for the enemies, with straight legs and all. Enjoyment can't be sketched out with guidelines and filler content, all sorts of little bits of fun and theatrics have to be put here and there to make it work.
And that's exactly what I want to do now. But not in this game, it does not seem to have the necessary appeal to continue development on it for myself. It's time to go back to TACStrike, and finally complete the prototype.
Oh, and one more thing...
Music
Got myself a MIDI keyboard. Trying to regain some of my playing skills while experimenting with improvization, making various synths and making noise with other virtual instruments. Just over 12 hours ago tested the M1 Le synth. It has lots of good sounds I'm not sure how they even produced. They sound just right, close to perfection. Someone's clearly spent years on these, yet I got them almost for free (with the MIDI keyboard). It's mind-blowing.
Yet it makes me feel uneasy, the effort people put into the things I have founded my creations on. I can't stop wishing I used them better. Makes sleeping at night harder.
If you think I can keep up the development, and if you're interested in what's going to be made here, please visit the Steam Greenlight page and vote for the game. It would mean a lot to me.
Add a commentThis week was full of highly practical developments. Gameplay building blocks, editor and lightmapping upgrades.
03/16 - implemented a basic messaging system
03/17 - started to build the other game (more on that later)
03/18 - worked on movement physics
03/19 - built more of the level, restored minimal skybox support into the engine
03/20 - working on lightmapping upgrades, restored light flares, added obstruction testing
03/21 - started working on the first puzzle room, you can see mesh arrays in action here...
...and later implemented interactive object queries and switch entities
03/22 - implemented a particle effect entity...
...then implemented damage effects and additional interaction...
...and finished room 1 interactive system design shortly after that.
Then I worked on more scenery and a jumping puzzle, adding all sorts of workarounds on the way. Click on images to view them in full size.
Finally, I did some more work on the level and tweaked the flares in the process. Some say they look much better now.
03/23 - Created the second puzzle - 3 doors and 3 switches.
About this new game I've been showing here: it's a new 2-week project for a local game development contest I mentioned in the previous post. It's a 3D FPS puzzle platformer. Puzzles are physical (jumping) as well as usual (interact with things until a new path is opened).
The idea largely comes from the Counter-Strike KZ jumping maps. They required the player to make lots of successful jumps to get to the top of the map, however usually there was a manual checkpoint system that made things much easier by allowing the players to save their progress anytime.
The scope of this project is to create one map that would provide more varied activities leading up to at least 15 minutes of fun on an average playthrough. We'll see what I have to show in a week.
Finally, these are editor/system changes not included in the images:
- A particle system picker was created. Allows to add nice environmental as well as on-demand particle effects using the new particle effect entity.
- Lightmapper was multithreaded in a way to provide maximum performance for lightmap and ambient occlusion rendering. Additional features and optimizations are expected to appear after some time.
- Scripting interface was extended to support the new objective system. Did I say that I have an objective system?
- Editor has a new feature - surface painting. It's possible to pick/paint any surface of any block.
- A new mesh entity was created (with support for dynamic lighting sampling, disabling collisions and changing lightmap quality).
Since most of the game content plan is complete, I'm moving to finish that and polish the game afterwards. Probably in the form of sounds/music and UI.
If you think I can keep up the development, and if you're interested in what's going to be made here, please visit the Steam Greenlight page and vote for the game. It would mean a lot to me.
Add a commentBetter late than never! It was time to submit my entry in the competition, so this week was all about polishing, exactly as I expected.
Download the game: My Flag (Windows 7+, 32-bit)
03/23 - finished the level
03/24 - implemented vertex shader effects (moving in the wind)
03/25 - created FMOD sound system wrapper, working on sound effects
03/26 - started working on UI, created a basic menu
03/27 - started working on additional controls, created a sound options screen with sliders
03/28 - even more UI controls, created input options screen with remapping buttons and a slider
03/29 - did additional polishing work, created a graphics options screen - this includes fixing internal systems to support changing resolutions on the fly
So once again, a very busy week. This time, sound, polishing and UI hacking.
Just a couple of things to add:
- FMOD works really great. That's basically the reason it's at the top. A very solid library, easy to work with. They've thought of all my basic needs.
- The UI "library" is one big reusable, extensible hack. A very good hack but it's by no means a library or a platform for designs, merely a way to get pre-developed designs done in a rather clean way. And I don't think there's anything significantly better to be done with my resources. For TACStrike, I'll probably improve it and hardcode some design into it.
- I wish there was a UI compiler system - one that would take a design and allow compiling it into code, for maximum performance and extensibility without having its functionality fixed (along with the overhead of all unused features).
- I now have an almost-fully featured Windows game engine that supports all kinds of ideas. This would call for profitable side-projects.
- The editor is annoying me again. I'll upgrade parts of it to full 3D support. Possibly including a mesh editor of some kind, if I can think of a good way. Making anything detailed was a bit of a pain, quite unnecessary.
- Due to my participation in the contest, I'll reduce my workload for a few weeks. Will try to get something out regardless.
- My current main concerns for TACStrike were: character animation (aiming and ragdolls), game systems (like the ones I implemented previously) and porting the old enemy code. That's what keeps me away from publishing a small demo.
- The lightmapper was good enough to ship the demo but I smell some issues around the BSP tree implementation as well as lack of nearby sample merging and found some light leaks as well. None necessary to be fixed for the demo so I might leave things as they are for now.
If you think I can keep up the development, and if you're interested in what's going to be made here, please visit the Steam Greenlight page and vote for the game. It would mean a lot to me.
Add a commentThis week was a mix of all kinds of work. Radiosity, ragdolls, scripted entities and automatic doors. I would say that all the hard things in the life begin with "ra" but I couldn't think of a third one. Those two are definitely hard.
03/09-10: working on radiosity lightmapping, finally achieved good results but they took way too much time, thought of an optimization
03/11: finished hitbox generation - this is going to be useful for gunshot detection later...
...and created a trigger entity with script function picking (which means scripting integration was done, too)
03/12: worked on polishing things and did some post-FX sketching:
03/13: started to work on scripted entities, first goal is to remake the trigger entity completely
03/14: finished initial work on scripted entity, trigger is available...
...started to work on a mesh array entity...
...and later finished it so that meshes become compiled into the level
03/15: implemented ragdoll animator, verified body alignment to bones...
...then upgraded scripted entity system to support a new entity - door that opens when information-emitting entities are detected nearby...
...then thought of one way to improve block creation in editor...
...then got the auto-door entity fully inside the game world...
...and finally implemented that editor upgrade idea:
03/16: finished the editbox that had no use for me until now, created a sliding door editor entity without proximity trigger
This week had a fair share of ups and downs regarding technology and some revelations weren't hiding anymore. Though to me it seems that it ended on an extremely positive note and should continue that way for quite some time.
One of the main reasons for that is, a new contest has begun and I'm rushing to get a preview of the engine out with a different game. Lots of stuff in common and I'll make sure that I don't spend much time for now on things that aren't going to be used in both games.
As for the weekly tech info:
- using SGScript for scripting/serialization (obviously)
- found some serious bugs and other issues with the code, fixed all, going to push changes back soon
- currently only editor entities are scripted, gameplay entities are simple enough to be implemented in C++ (and I didn't have to spend time on game binding code yet)
- reason the work is currently paused on radiosity is that it's super-slow, anything more than 10000 samples has great potential to be intolerable - so I'm going to implement a method that keeps sample counts that low and keep compensating other parts of the global illumination lightmapping with ambient occlusion
- the reason for implementing a static mesh array entity is simple - stairs, ladders and anything of that kind - I don't want to revisit the modelling app in case something changes in the specification, I just want to tweak a slider (or in my case, a number wheel) - now I can do just that
If you think I can keep up the development, and if you're interested in what's going to be made here, please visit the Steam Greenlight page and vote for the game. It would mean a lot to me.
Add a commentMore Articles...
Search
Latest images
