New alpha version available (build #17) (2012/12/08)
New version is available, adding dynamic shadows to point lights, weapon recoil, updates to Central map and other improvements and bug fixes.
We now also have the ability to download custom content when joining a server, and there is already one community map available by Leiche. You can test it by joining the community server and using map vote to choose the map.
Build #17 2012/12/08 (public alpha):
- Added dynamic shadows to point lights
- Fixed garbled texturing of some polygons on player model
- Improved dynamic weapon movement
- Added weapon recoil
- Adjusted weapon fire positions
- Slowed down fire rate for SMG weapon
- Added server configuration file
- Added support for downloading custom maps when connecting to server
- Lowered volume of footsteps when walking crouched or aimed
- Added displaying of player name who killed you
- Fixed loading of controls from config file
- Updated Central map
New alpha version available (build #16) (2012/11/14)
New version is available, introducing three new maps, improved leaning, server browser and other improvements and bug fixes.
The biggest news is however that since this year we're now two people team, both dedicated to this game. This is a big boost to development of Resistance Force. BirthNight is audio/music guy primarily but fell love into mapping, modelling and many other things. This allows me to focus more on the game core and together making assets faster and better.
Build #16 2012/11/13 (public alpha):
- Added 3 new maps
- Fixed reloading animation
- Added dynamic weapon movement when moving mouse
- Improved leaning
- Added correct penumbra for dynamic shadows
- Removed tips
- Added server browser
- Added ability to call vote (for map change)
- Fixed head triangles that were popping into view sometimes
- Fixed visible floating weapon at origin when player connects
- Added 64bit binaries for Linux (also fixes problem with ATI drivers)
Resistance Force Map Editor is now available (2011/12/10)
Map editor is now available for pre-orderers. It contains two tools: the map editor itself and composite texture editor. Both are available for all three platforms (Windows, Linux, Mac OS X).
Map editor uses brushes as main geometry along with ability to place models into the map. It works with hierarchy of groups and other powerful blocks, such as duplicators (great for stairs and other repeated things), prefabs and placement tool where physics engine is used to place things precisely on each other.
Composite texture editor is for editing detailed textures that can span over big areas (mostly useful to terrains). You can read more about it here.
To obtain the editor you have to pre-order the game and send me e-mail or contact me through IRC on QuakeNet (#resforce channel), you can also use the Chat page. Provide e-mail you used for pre-order or other proof of purchase (eg. PayPal receipt).
New alpha version available (build #15) (2010/12/30)
New version is available, most notable changes are: improved player model,
added bullet spread and multiple damage zones to players, moved ragdoll
computation from client to server so everyone sees the same death animation
and there is less resources needed for players with lowend hardware.
There is known performance degradation when dynamic shadows are enabled, this will be fixed in next release.
Build #15 2010/12/29 (public alpha):
- Removed usage of float textures
- Moved ragdoll computation from client to server
- Improved netcode robustness when there is little packet loss
- Fixed problem with players occasionally jumping very high and then dying
- Added occlusion queries for dynamic models
- Added support for detail textures
- Improved ambient lighting in regard to normalmaps
- Improved player model
- Enhanced map a bit
- Added bullet spread when firing
- Added multiple damage zones to players
- Increased bomb explosion delay from 40s to 45s
- Allow players to roam on server when there is no player in opposite team
New alpha version available (build #14) (2010/06/11)
New version is available, most work went into adding major features into the engine (static meshes, composite texture, material system, normalmaps) and optimizations. On the game side the current map was enhanced, initial set of detail meshes was added and there is a new gun available.
This release is another big milestone in development of Resistance Force, as the engine is now capable of all basic stuff needed to create content. The focus is already shifting from engine, tools and game programming to content creation, thus accelerating the speed of development of Resistance Force.
Previously the engine didn't support static meshes at all, which was very limiting. Composite texture allows detailed texturing of large areas (terrains), material system and normalmaps allow good visual effects and most importantly it allows to use much lower number of polygons in models while retaining high quality.
Build #14 2010/06/11 (public alpha):
- Renderer optimizations (with shadows disabled)
- Fixed problem with rapidly decreasing FPS with more players
- Added support for static meshes
- Added support for composite texture
- Added material system
- Added support for normalmaps
- Added tips
- Enhanced map
- Added some detail models to map
- Improved chat dialog
- Team chat is now more apparent
- Improved collision detection for objects with higher velocity
- Increased grenade explosion delay from 2.5s to 3.75s
- Increased bomb explosion delay from 30s to 40s
- Added selection of textures quality
- Added new weapon
- Improved bomb defusing
New technology: composite texture (2010/03/06)
It has been some time since last blog activity, more than it should be. It has two main reasons. The one is that I've been distracted with unrelated matters more than usual. The second is that I'm working on a new technology for Resistance Force's engine: something I called the composite texture.
|Screenshot from the map editor with
low resolution preview texture
|Composite Texture Editor - showing
high resolution texture and used layers
When I started working on extending the existing map and adding more details I've very soon ran across
a big problem with detail texturing of large areas like terrains. You can either repeat
some detail texture over and over (as done for regular "blocky" geometry, often called brushes), but
you'll lose control about any details. Or have one big texture for the whole area. But due to memory/speed
constraints you can't have really big textures.
Shows how are textures combined in
texture splatting (source)
Another interesting technique is MegaTexture developed by id Software. It allows you to have one really big texture for all geometry. The big texture is heavily compressed and stored on disk and dynamically streamed from it depending on what area player sees. The advantages are big: in engine it has practically constant performance characteristics so artists can go wild and touch any individual pixel they want to without worrying about anything. There are also disadvantages though: hugely increased amount of disk storage needed (even more for editing) and increased workload for artists, both not much indie friendly.
I've taken different approach for Resistance Force with composite texture: basically I took the idea of texture splatting and extended it by removing limit of number of detail textures (layers) and by ability to use it on any mesh, not just regular grid terrains. By having unlimited layers it also opens new possibilities such as placing any number of decals or even touching individual pixels by transforming some detailed area to decal and editing it in graphics editor. This way I have much more freedom when texturing while maintaining minimal disk storage and performance costs.
WYSIWYG in Resistance Force (2010/01/07)
WYSIWYG (What You See Is What You Get) is a major feature of Resistance Force. Originally
this term is used for describing text processors (like MS Word) that displays exactly the
same layout as the resulting output from printer. But this term also perfectly describes
one of goals for this game.
Actually it's not one feature, but more a philosophy that affects the game across several individual features. For example in most FPS games there is distinction between player model when seen from own eyes and when seeing other players (or yourself using 3rd person camera). They are usually lower detailed "external" model that everyone can see (eg. in multiplayer) and higher detailed weapon with hands only model. This is logical separation for performance and detail reasons. But it also means that the models are not synchronized, in fact the pose as shown by the weapon model doesn't match the external model at all in most games.
In fact games cheat by displaying the weapon model over all other geometry so when you're very close to a wall, your external model is actually intersecting it and visible outside whereas your weapon model is just drawn over all other geometry so you never see that you intersected the wall and it looks nice. This doesn't matter in single player game and makes the life of developers much easier. But in multiplayer it's a big problem as you reveal your position to enemy and what is worse in some games you can be even shot from the other side!
The solution in Resistance Force is to have only one model that acts both for internal and external view. This way you see exactly what others would see, even when you're intersecting the wall. The fix is easy: when near the wall the player will just put his gun down or up so he doesn't touch the wall. The nice thing is that when some bug (eg. in map or game code) results in intersection of the wall the players will immediately notice and can report the bug.
Heavy model with hitboxes from Team Fortress 2 game (source)
In Resistance Force the collision is always tested against the player model and no hit boxes are used. This leads us to next problem, collision detection in network game. The problem is that sending packets from one computer to other over network is slow. I don't mean the bandwidth but the latency (ping). Even on very fast connections it's still noticeable. The naive approach is to have "dumb" client that sends just the inputs and displays what it receives from server. The server has full authority over the game but due to latency the player doesn't see his own actions immediately.
For example, when you look left using your mouse, it prepares and sends packet to the server, the server processes it and send back new view position. The network communication must also handle packet loss and other not nice things that can happen when sending packets over internet. All the processing from moving the mouse to seeing the result on screen has very noticeable latency that results in some sort of motion sickness and is unplayable. Even when playing on LAN it's noticeable, though still acceptable.
The solution to this is to predict movement on server side and do the movement directly on client when pressing the button or moving the mouse. In most cases after the packet reaches the server it concludes the same movement and it's OK. There can be small inconsistencies here and there (due to slightly different position of players as seen on server side, small packet loss, etc.), in that case the server just corrects the client side position and everything is allright.
Most games are obsessive against fighting cheaters to the extent that it actually hurts gameplay for non-cheating majority. Just how many times did you hit someone, the blood was splashing all around and nothing happened? This is direct result of server authority over game and client prediction that is used in most games. This is just effect of latency, you hit someone, the packet is sent over the network and when it finally arrives to the server it's decided if you actually had hit something or not. But for good effect the client has to respond immediately by splashing the blood, otherwise it would look very unnatural. It has to splash blood even when there is no hit because the client can't tell it beforehand, it's not authoritative over the game.
Resistance Force is partially authoritative on client. The movement and stuff like grenades are handled classically, server is deciding stuff and client gets corrected if differs. But the firing is controlled by the client. This allows to have direct response because the client knows and can decide if the other player is being shot or not. This also helps greatly in lag reduction, in fact the lag issue is entirelly shifted from firing player to escaping player. This is good thing, when firing you're directly looking at your enemy (so having no latency is very appreciated), but when escaping you're usually not looking at the enemy so the latency issue is not (that) visible.
More experienced players immediately thought about how easy it would be to cheat in such system and they're right! But this is also easy to detect, so no issue here really. Most game creators are very obsessed about preventing any form of cheating, but they're not thinking in a larger picture. The reality is that preventing any possible cheating also hurts normal players and the cheaters still cheat anyway :) There are better ways how to deal with cheaters without hurting gameplay for normal players, I'll write more about it in some future blog post.
New alpha version available (build #13) (2010/01/01)
New version is available: it brings explosive grenades to the arsenal among with
many bug fixes and small features. There is no need to manually apply this update,
just run the game and it will be auto-downloaded.
Hopefully this version will also fix problem with players testing the game, but each one coming at different time to the server. So many people couldn't test the game. The solution is in defining certain hours so players can gather easier. I've defined 16:00 and 20:00 CET, you can also try to join server at beginning of each hour. This is also presented directly in the game when no one is on the server.
Build #13 2010/01/01 (public alpha):
- Fixed crashing on some video cards
- Disabled initialization of display/sound in dedicated server
- Fixed crashing of server when bad packet arrives
- Shortened prepare time from 12 to 8 seconds
- Added better logging of player connects/renames/disconnects
- Fixed footstep sounds for other players
- Added notification of team change
- Added support for colors in message list
- Added team chat
- Added ability to move just by tiny amount when short tapping the movement keys
- Added invert mouse option
- Added vsync and FPS limiter options
- Fixed occasional death when falling from top of stairs
- Added unlimited number of magazines to engine test
- Added explosive grenades
- Bomb explosion now causes death
- Added notice when no people are playing
- Added ability to start running from crouching, also fixed crouch toggle
Evolution of the game (part 1) (2009/12/13)
Today I was browsing through my screenshot archive and stumbled upon old internal
screenshots from early development versions of the game. They're quite interesting
and covering the rough development path. I've never intended to publish them publicly,
but by browsing them I thought what the heck! It would be fun to show you :)
When I started developing engine for the game in April 2007, I had pretty clear idea how to create 3D rendering part of the engine based on some previous experiments and theory gained over the years. So after month or two I already had pretty screens:
The lighting part in the old version of the engine was based entirelly on dynamic shadow maps and per-pixel lighting. Later I've found this doesn't scale well to bigger maps and more lights. I've realized most lights will be static anyway, so I later redesigned the engine to use static lightmaps that are smoothly blended with dynamic lights and shadows. This is not classic lightmaps, but more of light coverage maps. For each light there is separate lightmap consisting only of luminance. This approach allows to combine per-pixel lighting and lightmaps.
I'll show more about engine evolution in the following parts. In the meantime I was researching human model and how to animate it and create clothes. First approach was very ambitious. I've developed simple tool to load and animate MakeHuman's human model and animate it properly maintaing proper deformations and stuff. Part of it was also clothing. I've created cloth simulator as seen on the screenshots (February 2008):
Unfortunately it proved as futile attempt because of poor performance and complexity. The clothes system was not behaving well at every situation, biggest problem was that the clothes sometimes passed through the body and the simulation was ruined. So the idea was abandoned and I've created classic rigged model in Blender instead. However I've found later some techniques that are much cheaper and stable so it's still possible that some dynamic clothes would be implemented in distant future :)
This is all for now, keep checking the blog for additional parts :)
BTW, currently I'm working on grenades (along with minor bugfixes and missing features such as invert mouse or vsync) and planning next release hopefully next week or so.
How to help development
(voice actor needed) (2009/12/01)
Since the release of alpha version some people asked if I need help with
development, mainly with modelling, mapping and stuff like that. The answer
is no, surprisingly.
One reason for this is that the tools and engine itself is not yet capable of many things and the options are very limited now. You simply wouldn't be able to deliver that much more than current content because the code needed for it currently doesn't exist or there are still bugs which I carefully avoided for public alpha release.
I work on Resistance Force iteratively, this means I do core things first, eg. basic map, human model with all basic animations and game code needed for that. When there is model and code for everything needed I can enter new iteration and enhance existing stuff to be more detailed, map enlarged, etc. This is not just adding content but also code into engine, game code and also the editor. Everything is very connected and it has nice property of unified look of everything.
Another reason is that I have some vision about things and would like to put basic models and stuff myself so others would see where it's heading. I plan to add modding support in future to allow community to create custom maps, models, etc. But currently it's too early for that.
On the other hand we're seeking voice actor for voice chat feature. This is
predefined set of about 30 short messages. If you like the game and you're
interested please contact us.
UPDATE 2009/12/02: We've already found voice actor, thanks :)
Public alpha version released (2009/11/19)
Public alpha version of this game was just released, also the website is now open. This game is in development for over two years and we're glad to finally present you a fully playable albeit limited version of this game. No information about this game was published until this point because we wanted to present you something you can already enjoy and not wait years to finish and then be possibly disappointed.
It's also a great milestone for development because fully playable game means a lot. It means it can be incrementally enhanced and these individual enhancements can be delivered to players in short time.