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.
I found an interesting project on a backup harddrive from 2002 which was the ‘Trojan horse’ software I wrote to analyse the software protection device on the Data East Fighters History arcade pcb game.
I doubt the code itself is very useful anymore but the process it used may still be interesting. You can download the files >here
FH used an ARM cpu – ARM cpus are everywhere these days but were still quite rare in 1993! Coupled to this was a copy protection chip that essentially had a range of input ports the CPU could write to and modified results could be read back. By writing game code variables to the chip and the code that read them back ‘knowing’ the permutation that would be applied the copy protection was quite effective. Unless you knew all the hardware permutations game code would at worst crash and at best behave incorrectly – drawing wrong graphics, game moves not working correctly, etc. Because it was close to impossible to guess what the protection chip did just by examining the software the only solution is to run special software on the board that deliberately probes the protection device by writing known values and examining the results returned. Hence ‘Trojan horse’.
Unlike earlier 8 and 16 bit games it was actually feasible to use a modern C compiler to write code to run on this device, so the official ARM c compiler was used (circa 2000) and the flow was C program -> .o ASM file -> patch ASM into original ROM image -> split ROM image into 2 16 bit images -> burn ROMs to EEPROM -> install EEPROMs on board -> get results!
The main components on the pcb board below are A – the ARM cpu (not marked as ARM – they only licensed the design so the chip was fabricated for Data East and is marked as such). B – two 16 bit program EEPROMs – the 16 bit data buses are interleaved to provide a 32 bit stream for the CPU. C – the protection chip itself. The fact it’s mounted on a daughterboard suggests it was added to the hardware design fairly late.
Recently I noticed Charles Macdonald had furthered the work I done on this – http://cgfm2.emuviews.com/new/detech.txt
Around 1995-1998 I worked on a telnet style chat server for Unix and Windows NT. Any trace of it has long disappeared from the web except I found someone that forked it and added it to Sourceforge around 2005!
There’s some vintage old school C code in that project for sure – who remembers declaring C functions like this?
It had some nice features for internet in the 90′s.. the server opened a port for HTTP as well as chat, so web pages could be generated on the fly from the data associated with the logged in users, so names, descriptions, login times, could be mirrored to a web page.
I found one of the last source code zips and placed it here for download.
VCMame archive project has been added – this allowed the use of Visual Studio 6 and Visual Studio .NET to build and debug the MAME project as opposed to the standard GCC/GDB/makefile command line setup.