2 Days To Vegas was a concept developed by Steel Monkeys initially for PS2 around 2003/2004. Mostly influenced by Grand Theft Auto it was crime themed with vehicles and characters. First pitched as a third person game, it was reduced to first person because of animation cost.
The game was ambitious planned with a brand new engine, new editor, new fx, voice overs, multi-layer streaming audio, and much more.
With perhaps 6 senior programmers assigned to tech, some things were technically very good indeed. The editor was what would become a standard editor in the PS3/360 era – an interface to a running instance of the game – where the designer could just ‘drop in’ objects, assign them physics, etc. I wrote what was called the ‘XML transport layer’ – the editor could request all sorts of information from the game runtime, and then inject all sorts of things back. This used TCP/IP (using the PS2 network adaptor) for live work, but the instruction sequence could be ‘baked down’ to files so levels were constructed using the same code-path when the editor wasn’t present.
Unfortunately only 2 coders or so over that time period were assigned to gameplay.. coupled with some poor art assets and limited design resources the demo designed to pitch the game at E3 that year just wasn’t very playable. Publishers are rarely interested in tech alone with a good game to go with it, and this demo was all tech, no game! The game wasn’t picked up and the company folded a month later (ironically the game improved a lot in that last month – but too late!)
Point of Attack aka Outlanders was a concept developed by Steel Monkeys around 2003. Perhaps a little too influenced by Halo it was one of the very first games to combine FPS with vehicles. That probably seems strange now but back then FPS games were very distinct from vehicle based games.
I worked on the engine and I remember doing game audio, HUD, particle effects and logic for the start of level drop ship and end of level helicopter.
The game pioneered a lot of post-processing effects that again are very common day but were ground breaking around 2002/2003. Depth of field, bloom, motion blur, colour grading and ‘fingers of god’ which was a heavy bloom buffer with feedback causing the bloom to stretch & seep over multiple frames.
And none of them appear to be turned on in the screenshots I found! It looked a lot better at the time.
The game was Xbox based, and unfortunately it was pitched around the time the PS2 was becoming the dominant console of that era. With no publisher on-board the game was cancelled.
Fear Factor Unleashed was a project for PC, Xbox and PS2 based on the Fear Factor tv show. The time scale for the project was very short and the company had no existing cross-platform tech so the decision was taken to use the Renderware middleware. At the time Renderware had a good reputation as it had been used in GTA 3 and Burnout. It soon became clear though that GTA 3 and Burnout must have had a lot of programmers working on the engine, because what was in the base Renderware was not very impressive at all. It’s no exaggeration to say we could have built our own PS2/Xbox/PC tech in the time taken working around Renderware problems or unimplemented features.
Regardless the game featured a mix of 3rd person platforming levels, vehicle based levels and special button press ‘eating’ levels to match the TV show. It certainly wasn’t a triple A game, but was certainly competitive with other mid-range PS2 titles from around that time. The game was never released as the publisher went bankrupt and although a few other publishers were interested nothing came of it.
There was some nice graphics tech in the game, such as heat hazes, render to texture effects, projected lights, reflective water on Xbox/PC and blur/disorient post-fx for when your ‘fear meter’ got too high! I was the lead on the Xbox platform, but as it was only a small team (5 programmers total, later 4) I done a lot of work on PS2 and PC as well. In particular I remember working on character collision detection – using a swept ellipsoid representing the character against the landscape triangle mesh. Swept means you are colliding over time as well as 3d space – so you find out what position in the timestep a potential collision would occur. There is a neat trick to swept ellipsoid detection – imagine transforming the world triangles by the inverse of the ellipsoid – so that if the ellipsoid was a perfect sphere the world is now ‘squashed’. Then transform the triangles around the direction you are sweeping in (imagine looking down the movement direction defined and seeing the triangles in front you – essentially a barycentric space). So now your ellipsoid is just really a 2d sphere looking at oncoming triangles – simply solve triangle versus sphere for every triangle and you have all your collision points! (Testing vertex to be inside or outside of sphere, then line versus circle for each edge of the triangle). The ‘depth’ in this space essentially gives the ‘time’ of collision, and you can just transform the results back to world space position & time step proportion when done.