Frogg- Jumpy-Hop-Hop "Remake"

[SharkyUK]

Hot on the heels of @sn00p 's Sonic thread (well, several months after) I thought I'd post up a little bit of info about a Frogger remake I've been working on. Although I can't call it Frogger because Konami gets all touchy about protecting their IP so one must tread carefully. Here's the link to @sn00p 's Sonic thread for those interested...

Powered by insomnia, I started writing sonic the hedgehog

I have pretty bad insomnia, so I try to do something productive when it's at its worst. back in the 8/16-bit days I wrote quite a few games, the last one I wrote was a r-type style game that I did with a friend which was written in assembler and ran under DOS (I had a 386 at the time, probably...

cliosport.net

Why Frogger? Mainly because that is where my professional game development career started, way back in 1998 (or thereabouts). Fresh out of university, looking for my dream job (a job I had wanted to do since I was about 6 years old), and hoping to land my first role and published game. It was tough though. I got a lot of knockbacks when applying to places such as Rare, Sony, Warthog and many other development studios. My lack of experience somewhat counted against me despite my university background and the fact I was able to demonstrate my technical abilities. However, I didn't give up and I eventually landed an interview with video gaming royalty - a small(ish) studio based in Leamington Spa, called Interactive Studios (that would go on to change names to Blitz Games). More importantly, the studio was owned and run by two of my gaming idols - Andrew and Philip, also known as The Oliver Twins (from here on referred to as TOT). Older gamers amongst us may recognise their names or some of their games, especially those that they had published through Codemasters. Dizzy games? BMX Simulator? Fruit Machine Simulator? And quite a few others to say the least...

Home Page | Oliver Twins

A digital scrapbook of the OliverTwins early games

www.olivertwins.com

So yes, it was the summer of 1998 and Andrew and Philip invited me to their studio for a two-day interview. I arrived promptly at 9 am in the morning and I was warmly greeted (and somewhat intimidated meeting two of my idols!) After a quick tour of the studio and a few introductions, I was assigned a simple task. I had two days to write a game of their choosing; they chose Missile Command. Thankfully it was a game I knew well so I sat down at the PC that I had been assigned and began to make a rough plan of action.

However, it didn't quite go to plan.

It was probably around 10:30 am on that first morning and there was somewhat of a buzz around the studio, and an all-hands meeting had been called in the main meeting room. Developers and artists began to leave their workstations and make their way to the said meeting room. I had no idea what was going on so simply knuckled down in an effort to impress and secure a job! A few moments later, Philip popped his head through the door and asked me to join in the meeting. Hmm, this was both exciting and nerve-wracking. I just wanted to get on and write a version of Missile Command!

The meeting began and TOT started to address the attendees. To cut a long story short, they had just received word that one of their games had passed final approval by Nintendo and had gone gold. To those who perhaps don't understand the terminology, "going gold" means that a game has been approved for release. It also means that it can be a time for celebration as years of blood, sweat and tears come together and a tangible product is about to be manufactured and sold to the public. Great news indeed!

It was past mid-morning at this point, and TOT decided to celebrate the news by unofficially "closing" the studio. In other words, time to head into town and enjoy a few pubs and restaurants along the way! Starting at midday. I was requested to join the celebrations with the development team and Andrew and Philip insisted I join them, despite my protestations that I really should be concentrating on writing the game that would, hopefully, satisfy their requirements and land me that all-important programming job! My words fell on deaf ears and I was dragged into the celebrations. Don't get me wrong, I wasn't ungrateful and desperately wanted to be a part of it, but I also wanted to meet - and surpass - my interviewee obligations!

To cut a long story short, the celebrations went on for the rest of the day and into the night. I eventually ended up staying overnight at one of the studio's Directors' houses (yes, it was pre-planned!) The next morning, people were not expected to turn up too early for work (and for good reason!) and I arrived at the studio around mid-morning. I would have preferred an early start but the director with whom I was staying was also my lift, and she wanted to take time to enjoy her breakfast! Hahaha! I think she sensed I was worried and assured me it would not be a problem. Eventually, we arrived at the studio and I sat down to pick up from the previous day. Obviously, my progress was somewhat lacking! There were a few sore heads as folks started to file through the doors and to their working areas!

Lunchtime arrived far too quickly and I was furiously trying to get something together that resembled a Missile Command game. I was nervous as hell. And then things took another unexpected turn. TOT were going from dev team to dev team and rounding up those who had not been available or part of the celebrations from the previous day. And those folks were to head out to the local for a pub lunch (I think it was a Mexican in the end). If nothing else, Andrew and Philip did their best to look after their staff and to ensure all were able to enjoy success when it came their way. So yes, I was asked out on another lunch... It was mid-afternoon by the time I sat back at my PC and TOT asked me how I was getting on. Hmm.

Thankfully, I did have a VERY basic implementation of the game working but it was FAR from being playable. I had gone from having two days to write this game prototype, to eventually having only a handful of hours (if that). I had already resigned myself to the fact that I had lost this opportunity and was not looking forward to the train journey home that evening. To say I was crapping myself when TOT sat down with me at the PC was an understatement. And that's where it got a little weird.

Somehow, they were both impressed with what I had managed to achieve and they then decided to share a little bit of information with me! It turns out that they had been impressed with my portfolio prior to my arrival for the interview, and that they had been impressed with how I had integrated and interacted with the folks when being given the tour the previous day. They were laughing when they told me how they had decided (pretty much immediately) to give me the job regardless of how the remainder of the "interview" had turned out. They knew I was technically capable and they now had proof I was able to integrate and get along with their existing teams (as evidenced by the celebrations!) Boom. I had my first job in game development - let the good times roll!

(I was young, once - I think it was a Tuesday).

Fast forward a few weeks and I turned up fresh-faced at the studio for my first day as a full-time, professional (debatable) coder! Yet the question remained, what team would I be working in and on which game? I didn't have to wait long to find out. About 4 minutes and 17 seconds I think...

(More to come soon - if you're interested(!), and I'll pop some pretty pics in along the way).

 

[SharkyUK]

(Continue from my last post...)

I was literally shaking the first time I walked into the studio, such was the level of excitement and anticipation. I was eager to contribute, learn and make games, but I had no idea what game I'd be working on (nor which team I'd be working in). As mentioned, I didn't have to wait long to find out though...

The Oliver Twins (TOT) had been successful in winning a bid to develop Frogger 2, a game that would be developed in-house and published by Hasbro Interactive. The game, of course, would be based on Konami's original 1981 Frogger game/character. Hasbro Interactive had experience working with Konami and the Frogger IP having worked with a different developer to publish Frogger: He's Back a year earlier (a game which released on PlayStation and Windows PC). And so Frogger 2 came into being - but needed a storyline, design and - most importantly - a team to develop it!

Due to development efforts elsewhere, developer resource was very thin at the time. There were multiple projects and prototype games being worked on and a team was needed quickly so that Frogger 2 could be started. And I effectively became the first person on a new team that would work on realising the game, in a team called Team Spirit (all the internal teams had their own names). A studio space was ready, so I had my desk and equipment set up and ready to go. Over the coming weeks, new team members would join and we would soon have a full team in place. That said, a lot of us were very green and new to the industry due to the fact that the more experienced folks were still working on projects elsewhere within the building.

So, rolling back to that first day...

I was taken into an office where TOT explained what was happening and what my priority would be. The Frogger 2 game would be released on Nintendo64, PlayStation, and PC (and maybe something that Sega was rumoured to be working on, which would turn out to be the Dreamcast). I had been assigned to lead development efforts on the N64 version and to work alongside the lead programmer (who would co-develop the PC version). However, the lead programmer would not be joining the team for a few weeks due to other commitments so I was given a rather interesting task to kick things off. I was given a N64 devkit to hook up to my PC, all the software I needed to work with it, and asked to develop the 3D graphics engine for the game. No pressure then, quite a simple task for a newcomer to the industry and only 1 hour into his career. Specialising in 3D graphics programming and high-performance computing, I absolutely relished the challenge. But f**k me, it was a steep learning curve having never worked on N64 before and with it being such a pain in the ass system to work on!

The above is the SN Systems Unofficial N64 dev kit. The official dev kit(s) from Nintendo were ridiculously expensive hence SN Systems produced their own cheaper version, and this was pitched at smaller studios with lower budgets. I think it still cost a few grand to buy all-in though! It was an SRAM-based cartridge setup that used a PCMCIA SCSI-2 interface to upload ROMs from a Windows PC to the dev cartridge (using SN's Pro-DG software). Yawnfest, sorry. It was cool back then. Still is to be fair... if you're that way inclined.

That's pretty much how my Frogger journey started. The team started to grow, development began in earnest and the game (which would eventually become Frogger 2: Swampy's Revenge) started to come together. It wouldn't be without its problems and issues along the way... but ultimately resulted in 2000 on PlayStation (PSX), Windows PC, and Dreamcast. No N64 version? Sadly not - that got cancelled mid-way into development, so I was switched onto the PC version and onto initial dev work for the Dreamcast version. There were also Gameboy/Color versions but these were very different and were developed externally.

There is a lot of stuff I could go into regarding the development of the game if folks are interested but it might be a bit boring. Or not. I guess it depends on whether it floats your boat or not! To make things look a little prettier, here are a couple of pieces of original concept artwork from early in the game's development.

I have loads of this stuff now as I was able to get my hands on the full release of - well - pretty much everything (50GB compressed archive!) Everything from artwork to press releases to emails and contracts, everything. Some still needs to be checked and redacted but there's some really interesting stuff in there. Again, if folks are interested I could perhaps post a few bits and pieces of content up. The Oliver Twins were very kind in releasing the assets for purposes of preservation (to a select group, more of which I'll get into in a future post). I'm chuffed that I have remained in touch with Andrew and Philip to this day and it's incredible how they are still so passionate about the games industry.

(To be continued...)

 

[Thrust-Rated]

Loved reading this so far! Not boring at all so please carry on and don't hold back on story time

 

[SharkyUK]

Loved reading this so far! Not boring at all so please carry on and don't hold back on story time

Ok mate, thanks. I'm glad you've enjoyed the first couple of instalments!

 

[SharkyUK]

(Frogger story continued...)

I appreciate I still haven't even begun to talk about the "remake" I'm involved with but I'll get to that later. For now (blame @Flat Eric) I'll add a bit more about the general development "story" of Frogger 2: Swampy's Revenge.

I guess I'll start with the fact that the N64 version of the game was cancelled and all development stopped for that particular platform.

I was a little disappointed to say the least, especially as I felt that the N64 version was my little baby and that I was at the reins. It wasn't through any fault of my/our own or because of development troubles (the wider studio was very experienced in working on the N64 platform). It was simply a case of economics, cost and risk management, although any of those aforementioned reasons are far from simple in reality. The sad truth was that the N64's days were numbered and creating games for it was becoming too expensive and uneconomical. Why? Component costs. The N64 was obviously a cartridge-based format and this had many benefits - such as loading speeds and robustness. But they were incredibly expensive to manufacture, and even more so towards the end of the N64 consoles' life. Those of us old enough to remember can probably remember how the cost of N64 games started to climb and climb towards the end of the N64's life (not that they were particularly cheap in the first place). Where games had previously cost £40, we were starting to see games creeping up and past £50. And even £60 plus! Profit margins for development studios were already minimal, publishers had major concerns about losing money on unsold stock sitting in warehouses, and there wasn't really any way to reduce the escalating costs associated with the N64's choice of media. I'll try and explain the situation we found ourselves in...

The studio (Blitz Games/TOT) were developing the game for Hasbro Interactive, who were publishing the game (with permission/under license from Konami to use the Frogger trademark). The studio had clearly defined development milestones to hit and Hasbro would pay the studio upon successful delivery against those milestones. This ultimately meant that it was Hasbro Interactive who were responsible for funding development efforts and for covering manufacturing costs, distribution costs, marketing, and everything else. Naturally, they had concerns over the escalating costs associated with the N64 as a platform. At some point in the future, they would have to make a call and decide on how many units of the game to manufacture for the N64 platform. Should they manufacture 50,000 units? Or 150,000 units? Would the game be a success and shift all their stock, or would they be left with a warehouse full of unsold cartridges? It was a huge financial risk on their part and they didn't have a crystal ball to guide their decision. As said, it was very expensive to manufacture a cartridge - even at scale. It would cost dollars and dollars per unit purely for the raw materials, fabrication and mastering. This was a LOT more expensive than the likes of the PlayStation that used CD optical media, which could be manufactured and mastered at scale for cents per unit. Ultimately, the risk was too high and there were no real options available on the table other than to call it a day and officially cancel the N64 version of the game.

Interestingly, it turned out that that would not be the last we had heard of the (cancelled) N64 version of the game...

Many years after the game had actually been released, two prototype versions of the cancelled N64 version of the game found their way into the public domain. The contents had been ripped and made available for download at various places across the internet, but the actual physical cartridges were something that many games enthusiasts (and prototype hunters) were keen to get their hands on! I believe the physical cartridges exchanged hands for quite significant amounts of money! When I did a bit of research and tracked down the cartridges, they were indeed originals and the very cartridges I had produced myself from the devkit on my desk! There are a few videos on YouTube that show the cartridge prototypes and folks trying to get them to run (with various degrees of success). Sadly, the prototypes did not work so well as a lot of content was missing that allowed them to be playable - they were designed to run as part of a development system and not standalone! Whilst looking through the prototypes, the video presenters show a section labelled "Andy's Play Pen" (or words to that effect). That particular Andy was indeed myself! Anything that got released on the N64 side went through me and I remember putting together the prototypes. They were made to show progress and as evidence of milestone deliverables, for sharing with the published and for internal review. I have no idea how they found their way into the public domain several years after the game had been released!



And still, the interest in the cancelled N64 version continued! A handful of years ago I was approached by a gentleman called Frank Gasking. He was an avid games enthusiast and researcher who was looking to pull information together on a selection of games that had, for whatever reason, been cancelled during development. And Frogger 2 was one of the games he had wanted to cover. He tracked me down through LinkedIn and former colleagues and reached out to see if I'd be interested in contributing to the article. Naturally, I was more than happy to do so and ended up providing content for him and answering his questions (and produced a few screenshots from the prototype versions, too). The book was released a few years ago and is a fantastic read, covering a range of games over the years. I think it's due for a reprint at some point but give it a read if you have any interest in this stuff and can get hold of a copy.

The associated websites are:

https://www.gamesthatwerent.com/ (the author's website)
https://www.bitmapbooks.com/products/the-games-that-werent (the book!)

In my next post, I'll continue the story and talk about another interesting aspect of Frogger 2's development; the decision to drop a rather novel level design feature. In the meantime, here are a couple more pieces of concept artwork from early in the game's design stages.

 

[SharkyUK]

(Continued...)

As alluded to in my previous post, I'll talk a little more about a level design feature that was dropped from the game during development. But, before I can do that, I need to get a little bit techy (not too much) and explain how Frogger's movement was handled and how Frogger 2's game levels were put together. Hopefully, it's not too boring!

If you're reading this then I expect that you are already familiar with the original Frogger game, i.e. take control of your green Frogger character and navigate your way through the traffic, and then carefully cross the water to reach the safety on the other side. (No, I still don't know why this particular frog has an issue with water... and I don't know why it was the same size as a car either. But there you go).

By its very nature, the original Frogger was a very simple game to pick up and play. It was grid-based and, at any given moment, your character could only move in one of 4 directions - up, down, left or right (north, south, west or east) - to move to another grid cell. And that was pretty much it as far as the fundamental Frogger movement mechanism was concerned. Here's a screen grab from the original arcade game (zoomed-in) to help explain it.

(For now, ignore the fact that there are hazards and obstacles to avoid!)

Frogger would start at the bottom of the screen, within the safe zone on the sidewalk/pavement (the bottom part of the white grid area). Pushing up on the game controller would cause Frogger to move up one grid cell. Likewise, moving left would move one cell to the left, and so on. The underlying game had an internal representation of this grid and hence knew exactly where to move (and draw) the Frogger character. This would continue until Frogger reached the mid-point and was required to cross the river. At this point, the player would have to jump from moving platform to moving platform (turtles and logs) to get across. Again, this used a simple grid system, albeit with a simple moving dynamic. That is, each platform (be it a log or turtle) was represented by a moving collection of cells (effectively a grid). The game would know which grid the player was on and thus allow movement within it. So, for example, if the player was in the centre of a short log (made up of three cells) then moving to the right would move the player to the right edge of that log. Of course, if the player moved right again and went off-grid then, well, a life was lost as the player met their demise. However, if the player was on the same log and pushed up then the game would check for the presence of other grid cells within the player's vicinity. Thus, if another log (or row of turtles) happened to be passing by then the player was moved onto that new platform (assuming that there was a sufficient overlap to suggest that the player had made a successful move and not ended up jumping into the water!) It really was that simple. If an adjacent grid cell was available to move into then the player could make that move. This grid-based dynamic would carry forward to various Frogger games in the future, including Frogger 2. But there was a big difference.

The original Frogger games were 2D based and Frogger 2 was very much going to be a 3D game. With that in mind, we had to come up with a way to define the grid(s) for a given level and to make sure that the grid would be "intelligent" enough to allow the player to successfully navigate a 3D environment. The solution was, thankfully, quite simple (although not always quite so simple to implement in practice). The idea was to split any given level into two primary components:

• Render geometry
• Collision geometry

The level's Render geometry was the visual representation of the environment - floors, walls, trees, etc. - that the player would actually see when playing the game. It had no other purpose than to look pretty and to provide the backdrop for various other entities within the game (such as enemies, the player, platforms, and so on). However, it was the level's Collision geometry that was doing the heavy lifting. It was the collision geometry that determined where a player could move within and throughout a level, along with various other attributes that could be set upon it to build a playable level (more information on that in a moment). The collision geometry was not drawn to the screen and existed purely to facilitate movement and physical interactions within the underlying game engine. If a player moved in the game, the game engine would query against the collision geometry (the grid) to determine where they were and where they were moving to. Was it a permissible action? Could the player move there? In effect, could the player move to the desired 3D grid cell?

As said, the render geometry comprised the polygonal data that was drawn to the screen. Due to the somewhat limited power of the consoles of that time, the team's 3D artists had to limit themselves to how many polygons and textures they could use across any given level. I think the budget was a few thousand polygons per level otherwise the hardware of the time would start to struggle! It seems rather pathetic when compared to modern games and technology where millions of polygons can be handled... how times have changed! But, back to the crux of the matter - how was the 3D grid realised in the collision geometry?

As a level was being created by the 3D artists and level designers (that is, the pretty stuff to be rendered to the screen), a simplified version of the level was also created. This simplified version was the collision geometry and represented the playable gaming area of the level (i.e. where the player could move) and, most importantly, was carefully split into a regular grid pattern! The difference, compared to the original Frogger game, was that this happened in 3 dimensions as opposed to just two. Ultimately, it meant we now had a grid system to work with and that meant we could implement Frogger's movement around it. It's probably easier to explain through a series of pics (I generated the pics from actual early development game assets, albeit rendered using some other software I put together as part of another project).

The image below shows an early version of one of the game levels (without textures or details) but is otherwise representative of what would be drawn to the screen.

In addition, a simplified version of the level was created - the collision geometry (shown below). Despite the triangular nature of the polygons, you can clearly make out the grid-like structure that would ultimately determine where the player could move.

Here, I have drawn the collision geometry over the top of the level render geometry to better show how they relate.

And, again, a side-by-side comparison.

Simples! I'll now call the collision geometry a collision grid, or CG for short...

Do you see those colours used on the CG? They weren't randomly assigned! They represented CG attributes. And these attributes were used by the game engine for various reasons. It might be obvious from just looking at them as to what they potentially could mean or represent. If not, then please read on and I'll provide a quick explanation as to the meaning of those grid cell colours.

• Pink - this represented the player's starting point on the level
• Blue - this represented the location of baby frogs (which the player would have to collect in the game)
• Green - the green cells represented the area over which the player could safely move (not taking into account potential enemy encounters!)
• Red - insta-death! If the player jumped onto that part of the grid then they lost a life... unless there was a moving platform for them to jump on in order to stay safe. Hence, red areas would often indicate bodies of water, spikes, lava, and other dangerous parts of the level
• Grey - represented barred areas where the player could not move to
• Yellow - represented so-called link tiles, which facilitated potential player movement between different elevations (of course, too high a level and the player might not be able to jump up it... and too far a drop could result in the player's death if falling from a height)

Hopefully, that gives a brief insight into what the colours mean on the CG and how those simple attributes can be used to put a playable game level together. There were a whole lot more colours used to represent different attributes and states, such as for conveyor belts, but I won't cover those here. Here's another image showing a different level's render and collision geometry.

So yeah - with that cleared up, what was the actual feature that was dropped from the game's development? I think I might have to roll into another post to explain as this grid stuff took longer to get through than I expected...

But before I roll out that post, what would happen if we could take that CG and form it into some weird and interesting shape? Frogger was a flat game by its very nature, but Frogger 2 allowed elevation changes due to how its CG was implemented. Could we take a level and its CG and, say, wrap it around a sphere? Or a torus (donut)? Hmm...

 

[Darren S]

A great read Andy! Read the majority last night and then finished it off this morning.

When's the next chapter?

 

[SharkyUK]

A great read Andy! Read the majority last night and then finished it off this morning.

When's the next chapter?

Thanks mate. I've had to temporarily put it on hold as I haven't had time to pull the bits together I need. I'll try and get the next installment up in a few days time...

 

[Touring_Rob]

Andy this is a great read, enjoying it loads 👍

 

[c4pob]

Can't believe I missed this thread until now. Super interesting and directly relevant to hardware I spent my own money on and thoroughly enjoyed playing.

Looking forward to reading the next instalments.

 

[SharkyUK]

Andy this is a great read, enjoying it loads 👍

Can't believe I missed this thread until now. Super interesting and directly relevant to hardware I spent my own money on and thoroughly enjoyed playing.

Looking forward to reading the next instalments.

Thank you, gents. I'll try and get something up very soon...

 

[SharkyUK]

Sorry for the delay, a lot is going on at the moment and some things have had to take a lower priority! However, seeing as there's a bit of interest here I thought I'd drop in and give another quick update. Just give me a moment to remind myself where I was up to... 🤣



Ah yes, I was talking about collision grids (CG) and looking to talk about a feature that was dropped from the game (which was a shame in my opinion). But before we get onto that, here's a little more early development/concept work for Frogger 2...

These (below) were designs for the main (playable) characters within the game. The player could unlock these additional characters by completing levels and challenges. I haven't included the main Frogger character artwork as I have already shown that image in an earlier post. Do you know which of the characters below is the odd one out? Don't worry - I wouldn't expect you to know as it is an old game and wasn't particularly popular here in the UK (although it did massively well in the USA for some reason). The odd one out is Rooster - who never made it into the final game. In fact, I don't recall the character being taken any further than the concept stage.

The concept artist on Frogger 2 was an incredibly talented guy (as are many of the folks working in the games industry). I remember being wowed by his artwork - on Frogger 2 and his wider portfolio. His work was top quality and the speed at which he worked was mighty impressive.

Talking of team members, it might be worth briefly touching on the "Team Bio" whilst I'm here. The studio was laid out across two floors above commercial shops in Leamington Spa (one of them being a bakery, and the smell of fresh bread and bacon sarnies each morning was the best way to start the day!) We would have a quick morning briefing, a "lard run", and then we'd crack on. The "lard run" simply consisted of heading downstairs to the aforementioned bakery, buying a load of bacon sandwiches, sausage rolls, pasties and pastries, and then returning to the two floors above with arms full of fresh-baked goodies. Anyways, I digress... The studio was laid out across the two floors and comprised of multiple teams working on various games concurrently. I think there were about 50-60 people in total at the time I was there (including directors, admin and cleaning staff!) As already mentioned elsewhere, I was on Team Spirit and it was a very green team in terms of experience. It was also a very small core development team, which is VERY different to today's game development environment! The core team was made up of:

• 8 programmers
• 6 artists
• 1 musician

And that was pretty much it. Sometimes, we would get a hand from someone else on another team if we needed help (or were up against a tight deadline). But, as far as the core team goes, that was it. In addition, we had:

• 1 Producer (from Hasbro Interactive, not internal to the studio)
• 1 project lead (Andrew Oliver, one-half of the Oliver Twins)

Between us, we were responsible for designing the game and then developing it across the following platforms:

• Nintendo64 (which was canned - my baby!)
• Windows PC
• Sony PSX (PlayStation 1)
• Sega Dreamcast

It was quite a tall order in many regards, especially with a limited budget and period in which to get it done and out of the door. It was made even more difficult when we hit major issues with Sony's PlayStation and ended up having to do a major rewrite mid-development! 🤣

It was the best job in the world as far as I was concerned, but it was a challenge and the hours were often long and drawn-out. Those on the outside looking in would see the games industry as this glamorous domain, where the studio hallways were paved with gold. Oh boy, the reality was (and still is) very different. It's certainly a job that you do for the love of it. Considering the level of talent and ability within, the financial rewards fall quite short in comparison to other industries. It was (and still is) the most volatile of industries and not something you go into if you value job stability. One day, all might be well. The next, and without warning, you are packing your bag and have no job. Ultimately, it was a situation just like that that caused me to call time on game development (although with a different studio later in my career). Would I ever go back? Hell yeah. If the pay was better and the conditions were not so volatile... I genuinely miss the buzz and challenge. I'm very lucky, though. My current work means I can keep up with the latest in modern gaming tech (and graphics programming tech especially) as I am still involved in those circles, though not working directly on games or for game development studios. I also count myself incredibly fortunate to have a few doors available to me should I decide to return to the game development fold. Who knows? Maybe one day.

(Dammit, I appear to have gone off on another tangent yet again...)

So yeah, the collision grid (CG)! 🤣

I've covered it already so, to briefly summarise, 90% of the player character movement within the game is dictated/governed by the CG. In addition to the various attributes (indicated by the colours in the previous post) that determine the status of all accessible areas in a given level, the CG also contains internal links that control where the player can move to from their current location. This, typically, would consist of a user input that would result in the player moving up, down, left or right. It was these internal links (internal to the CG) that would then be checked to see whether or not the move was valid (for example, does a vacant CG cell actually exist in the direction that the player wishes to move?) If a grid cell is available, the player is moved to that cell (played out with the appropriate animations, etc. on screen). If there is no available cell then the player cannot move in that direction. Simples, right?

Well, yes and no.

As long as a CG could be created for a given level, the tools we wrote could produce the internal links, etc. and a playable map would pop out the other end. The fundamental and most important thing was that CG. When we think of Frogger, it is a "flat" game that is played on the xy plane. Hopefully, this small graphic explains it better:

A CG is generated by the level designer to closely match the game's rendered level geometry, but the CG is still generally flat. It might have a few "steps" up and down here and there to give a bit of elevation to the levels, but it's still very much in that xy plane.

And that's where we wanted to change things up a bit! Why did that CG have to largely be flat? If we had the game's movement mechanics in place that allowed the player to move from one cell to another across the grid... what would happen if we distorted that CG? It seems such a simple idea yet there weren't any games out there at the time that were doing that sort of thing. Could we distort the grid and still have the player move and navigate across it? It turns out that, yes, we could. The internal links within the CG specified where the player could move, specified its position in 3D-space, specified its normal (i.e. the direction straight-up relative to a specific cell), and a few other properties. This meant that we had everything we needed to move the player around the distorted CG and we didn't really have to alter the already established game movement mechanics. Win-win. There were a few caveats and corner cases, but largely it worked and it worked very well. We could be on to something here, or so we thought... This was the feature I've been alluding to up to this point.

Provided we could lay down a uniform CG (or a reasonable approximation) we could shape it to fit all manner of weird and wonderful level designs.

We managed to find a little extra time to explore the idea further (i.e. in our own time!) As can be seen in my 3D example in the image above, with a bit of careful design and effort the level designers could create a CG that was anything but flat. If we could lay down that grid, we could have the game characters move around it. This opened up the opportunities to create some bizarre and fresh designs, to say the least. With that in mind, the level designers got to work...

 

[c4pob]

another great update. Bearing in mind you were one of the programmers, if you had the desire, could you finish what you started or did the 8 programmers have specific disciplines?

 

[SharkyUK]

It's important to state at this point that the level designs I'm about to share below are actually from the early development days of Frogger 2. However, I have textured and rendered them myself using modern tech (hence they are far removed from what would appear in a game of that era!) Even so, the actual polygonal make-up and collision grids are real and ran in very early development builds of the game (low-poly FTW!)

A typical Frogger level with a spherical twist:

A Venice-inspired theme:

An underground / Hell theme:

A capsule/pill-shaped theme:

Honestly, as a development team, we thought we were on to something pretty cool and new with these levels. With sufficient tweaking and updates to the camera movement, the levels could be made to be every bit as playable as the generic and flat Frogger levels. I recall the excitement through the team at seeing these up and running on the game development kits. I got the first sneak preview (ha!) as I was able to take one of the spherical levels and get it running on the Nintendo64 hardware. I remember calling over team members, then this rippled out to the other teams, and soon we had visits from all manner of folks who wanted to see what we had put together! 🤣

As you can imagine, we thought we were onto something special and that these levels represented a pretty unique hook with which we could draw in punters and - ultimately - have a game that was critically successful both with players and commercially. It did mean that existing levels would have to be re-designed (although most of the level designs hadn't been put together at this point in truth) and the storyline could remain the same, the only real difference being that the levels were now a lot more interesting (or had the potential to be). We couldn't wait to show the external producer from Hasbro Interactive...

Well, things didn't quite go as hoped.

The Producer visited, saw what we had been doing and appeared to be impressed with the potential new "hook". A development build of the game (although calling it a game at that point was a bit far-fetched, it was more tech demo) was produced and he took it back to HQ so he could share it with his seniors, fellow producers, etc. We would await the feedback and what would effectively be a yes/no decision as to whether or not we could proceed with the new level designs. At this point, I think it is pertinent to mention that the Producer was also working on another game as well (a game being developed by an entirely different studio and not related to us in any way). This wasn't unusual; many Producers would have two or three smaller games on their hands during this era and were responsible for overseeing them.

From what I recall, we didn't have to wait long to get an answer and - as you've probably already guessed - it wasn't what we wanted to hear. The publisher wasn't interested in pursuing the game with these new and "different" level designs. It was a bit of a blow. We were to stick with the traditional, "flat" Frogger-esque levels that we had seen in previous Frogger games over the years. And that was that. Our hopes of realising levels on spheres, torii, capsules, and cubes were extinguished. At the end of the day, the publisher was the entity covering the development costs and taking the bulk of the financial risk and the buck stopped with them. The decision was final.

Oh yeah, that other game that I mentioned that the publisher/producer was responsible for at the time? It was called Pacman Adventures in Time. I'll pop-up an image to show you that game...

Maybe it's the cynic in me.

 

[SharkyUK]

another great update. Bearing in mind you were one of the programmers, if you had the desire, could you finish what you started or did the 8 programmers have specific disciplines?

Cheers!

Fundamentally, we (the programmers) were all "game programmers". We would work on whatever general aspects of the game needed attention or were planned for implementation. However, some of us did indeed have specialist knowledge in specific disciplines and we would be utilised accordingly. In my case, I was/am a 3D graphics programmer hence my focus was on creating the 3D rendering technology for the game, the animation system, special effects, and that sort of thing. Another programmer on the team was a script and compiler specialist, so he developed a bespoke scripting language purely for the Frogger 2 game that would allow non-programmers (level designers and artists) to write game scripts that worked in tandem with the game engine to generate scripted actions and sequences. For example, transporting the player back to the start of a level when a baby frog was collected. Or to trigger a moving platform when the player jumps on a specific location in the level. It was basically a simplified programming language running within the Frogger 2 game engine that meant non-programmers could try out new things without having to interrupt the programming team.

In addition, some programmers were brought in specifically for their knowledge of target platforms. So, for example, we had a guy on the team who had extensive knowledge of the PlayStation and his entire job was (pretty much) to convert the game (which was being developed primarily for N64 and PC) and to get it running on that specific system.

When I started on the project I became the Nintendo64 guy as well as having the graphics programming duties. It was a challenge as I had zero experience with the N64 and it wasn't the easiest of systems to get to grips with, especially with the flaky development tools available at the time!

 

[Jonnio]

I saw this and thought of you @SharkyUK



Were you still working there when this weirdness was created? 😆

 

[SharkyUK]

I saw this and thought of you @SharkyUK



Were you still working there when this weirdness was created? 😆

No mate, I missed out on those Burger King ad-games! Damn shame... 🫣🤣 I was working for Rebellion at that point.