Max Payne is an oldschool FPS ?
-
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
Incline Ion Fury (formerly Ion Maiden) - Build Engine powered FPS by Duke Nukem 3D mappers - now with Aftershock DLC
- Thread starter tormund
- Start date
LESS T_T
Arcane
- Joined
- Oct 5, 2012
- Messages
- 13,582
https://steamcommunity.com/games/562860/announcements/detail/1712950695562032118
BIO: Dr. Jadus Heskel
Once a leading mind in the field of technological augmentation and prosthetics, transhumanist researcher Dr. Jadus Heskel turned to evil after controversial side effects associated with his treatment resulted in his program losing funding and his life's work being outlawed altogether. Vowing vengeance against the GDF and anyone else who stands in his way, Dr. Heskel will stop at nothing to achieve his vision of rebuilding humanity in his twisted image.
Likes: cyborg armies, software piracy
Dislikes: fleshy limbs, small animals
Sounds like a nice guy, dunno why they call him evil. Fake news!
GrainWetski
Arcane
- Joined
- Oct 17, 2012
- Messages
- 5,367
The cunt played it on his oldschool Xbox.Max Payne is an oldschool FPS ?
- Joined
- May 5, 2014
- Messages
- 1,677
NEXT GEN TECHNOLOGY ANNOUNCED!
30 October - Frederik Schreiber
You wanted it, we're bringing it!
Introducing next-generation 3D technology in Ion Maiden ..... VOXELS!
30 October - Frederik Schreiber
You wanted it, we're bringing it!
Introducing next-generation 3D technology in Ion Maiden ..... VOXELS!
Astral Rag
Arcane
- Joined
- Feb 1, 2012
- Messages
- 7,771
NEXT GEN TECHNOLOGY ANNOUNCED!
30 October - Frederik Schreiber
You wanted it, we're bringing it!
Introducing next-generation 3D technology in Ion Maiden ..... VOXELS!
I hope my pc will still be able to handle the game with this feature enabled.
- Joined
- Apr 16, 2004
- Messages
- 6,927
That's a good eduke32 add-on for Duke 3d too, fyi. It's been out for a while.
Duke3D Voxel Pack v1.21. Does not require the HRP, I'm using the voxel pack without it.
Duke3D Voxel Pack v1.21. Does not require the HRP, I'm using the voxel pack without it.
So when is this game coming out?
- Joined
- May 5, 2014
- Messages
- 1,677
Level Design Dev Blog
https://3drealms.com/devblog/dev-blog-1-3d-build-engine-and-ion-maiden/
https://3drealms.com/devblog/dev-blog-1-3d-build-engine-and-ion-maiden/
Build engine games like Duke Nukem 3D, Blood, TekWar and Shadow Warrior all boasted 3D capabilities and it was all the rage. But like many know, Build wasn’t an actual 3D engine.
Let’s focus a bit on one of the most important bits in First Person Shooter world design: 3D.
Build engine games like Duke Nukem 3D, Blood, TekWar and Shadow Warrior all boasted 3D capabilities and it was all the rage. But like many know, Build wasn’t an actual 3D engine.
What aspects are there to 3D? Here are some of the generation gaps and the importance of height:
First step - Wolfenstein3D and the birth of FPS genre
Wolfenstein 3D was revolutionary for its time. It shared the core of classic FPS world design: Branching paths and non-linearity. However, game play wise it was still fundamentally a quite limited top-down game with 3D projection and was often hard limited to a single height. Game worlds themselves generally were designed with a tile based editor you’d use for an 2D game. Due to this, walls were limited to fixed widths and corners at sharp 90 degree turns.
Second step - Exploring the limits
Games such as ROTT (Rise Of The Triad) took this further and allowed some rudimentary height differences where designers could now place obstacles which you had to conquer by adjusting your height by using various platforms and jump pads. Some games added 45 degree angled walls, texture mapped floors, outdoor skies, and actual map height variation, although this still often required actual transition areas such as elevators or complete map changes.
While game worlds still suffered from the same limitations as above, developers came up with clever ways to introduce height variety to game worlds, often in cumbersome ways.
Now that action was no longer limited to a single plane the game play was finally becoming 3D.
Third step - Integrating height as a fundamental part of level design
It wasn't until games such as Doom where height became fundamentally inseparable from both game play and world design. Now you had stairs, pillars, various branching alternate routes, elevators and hazards on different levels. It was a game changer. Around this time is when designers started to experiment with clever visual tricks such as parallax skies. With some care you could fool the player into thinking that buildings had rooftops or other technically impossible architecture despite those not existing. However, one big limitation still lingered: rooms and alternate paths could never overlap. While Doom games worked around this limit by forcing the player to run over various "intersection pits," the player still couldn't “jump! Ascending always happened by a set of stair steps or elevators. Still an excellent game and its immense success guaranteed that various "Doom clones" would start to emerge with a common goal: To be more ambitious than the one before. This included Build engine games.
The Build Engine
When approaching 3D in Build, you could split it in to following parts:
Sectors - Create rooms, stairs, balconies for enemies etc... could even be sofas, tables or cars! With sloping you can do much more believable objects than many engines of the time.
Sprites - No longer just player facing objects but also as wall or floor aligned flat objects. By combining these you can create rudimentary 3D shapes with with few unfortunate drawbacks. You can combine these with sectors to enhance the visuals.
Shading is very flexible and any floor/wall/slope/sprite can be individually shaded or palette swapped to create numerous variations and make objects really pop out.
Voxels (Volumetric pixels) Available only on later versions, these are essentially 3D sprites.
So what makes Build so special ? The biggest "3D" was that finally you could do overlapping sectors, which resulted in intersecting paths and overlapping areas referred to as SOS (Sector Over Sector). Still, there was one severe limitation: These sectors could never see each other at the same time! This did still allow vertical branching paths for the first time, you could submerge underwater, have sprite based platforms that could form solid looking floating objects that the player could jump on, air ducts, and staircases.
But that’s not the craziest part: Build is actually portal based and non-euclidean! Unlike typical approach with visibility at the time, the engine only cared about which sectors the player could see at any given time. Any sector boundary was essentially a portal to another sector. Visibility calculation was done in real time and this not only allowed everything to be completely dynamic but also nearly anything from rotating gears to moving trains to be built. One lesser known side effect was possibility for impossible geometry that could happily overlap even on the same coordinates as long as both areas weren’t seen at the same time. For more on how the engine treats visibility, there is an excellent article by Fabien Sanglard that explains this in detail: http://fabiensanglard.net/duke3d/build_engine_internals.php
Due to the myriad of options, vertical interconnection and overlapping areas ended up being a staple of any good Build map.
Some examples on how developers got around this limitations with overlapping areas:
(Left) Stairs that overlap a tunnel. Visual blocking in the middle ensures that you never see any overlapping parts at the same time. - Powerslave / Exhumed MAP01
(Middle) Same as above but squeezed to a bare minimum visual overlap block. Granularity for what gets considered as overlapping is determined by the sector size (each step) - Duke Nukem 3D E1L1
(Right) Impossible geometry with a 720 degree loop. Despite being able to see both of the areas from the middle, it still works. This shows that height changes are optional and the only thing that really matters is whether sector boundaries overlap or not. - Duke Nukem 3D E2L11
Some later game developers did go further by coding in their own ways to bridge the missing 3D gap by allowing you to see these overlapping sectors at the same time, referred to as ROR (Room Over Room). Despite common belief, ROR was never a feature of Build. Each game developer did their own take on this by utilizing clever projection hacks and these often came with their own limitations that the mapper had to design around.
Later Build games featured ROR. This really helped to enhance visuals and game play.
Shadow warrior (Left) Blood (Middle) Redneck Rampage Rides Again (Right)
Build is a strange engine, by looking at the games it seems like you can do a lot. Then you study it more and realise that everything is still practically 2D drawings on a paper and it seems that you can’t do anything cool with it, until you learn it even more and realise that it's actually a pandora's box. This extreme flexibility is what keeps many coming back to Build mapping. So what tricks do we utilize to make the world look more “3D” ?
Diagonal pillars
You might have seen in the preview campaign and something that many level designers love to do. It heavily uses the sloping feature of Build engine to create diagonal shapes that you’re more used to seeing in more modern engines
From left to right:
(1) We will start by creating two rectangular sectors, shown as green. Red pillar in the middle acts as a filler to give us a better overall shape.
(2) Add some basic sloping, with a handy script we can easily copy the slope to the other side
(3) Make the triangles fill the sides of the red wall and you end up with a diagonal pillar. This is where the filler area also helps with padding out the dimensions to make it more rectangular
(4) After some extra shading and smoothing out the corners, you end up with one damn fine looking diagonal pillar!
(5) Bonus: This is an example lifted from the very start of the Preview campaign. Green parts represent lowered ceiling and brown parts are raised floors.Without any red in the middle, both parts have to work together in tandem to form a sensible diagonal shape.
Overlapping areas
There are quite a few of those in the Preview campaign, here is one from quite early on:
(left) If you look closely, it looks like the tunnel definitely goes under those offices and it sort of does, but actually great care was done in order to make sure that neither area ever gets drawn at the same time due to the strategic window placement. This is another case of “just enough” to prevent any overlap. (right) Let’s remove some of those safeguards. By ignoring the areas that the tunnel’s ceiling blocks and the windows, you will start to see some weird things as the engine is deperately trying to render both areas at the same time, commonly referred to as “SOS glitching”
Building these cool overlapping areas comes with its own challenges other than just avoiding simultaneous visibility. Due to Build still being fundamentally like drawing on paper, any overlapping areas end up being drawn of top of each. What this means is that there are no other perspectives such as side view available for the geometry creation, it’s all top-down 2D.
Opening a map with overlaps with the editor can end up looking a mess!
Visibility is determined by sector shapes that the player sees.
Red lines are walls that act as sector boundaries for portals
You need to make sure that the player never sees any sector overlap
How we approach this is to first create the basic shapes for overlap (left) and make sure that there is no SOS glitching present with the bare minimum sector splits and visual blocks.
After that the overlapping part can be relocated away from play area and detailing for both parts may begin (right). It’s important to keep the “welding bits” intact so that it can easily be placed back for any actual game play testing. After some practice even complicated areas can easily be managed and typically, even 3-4 layer constructs are manageable.
It’s recommended to keep a working copy with separated parts and have another copy for actual gameplay where the parts get combined. While you could do nearly seamless SOS with a huge amount of red walls, each split still acts as a portal and it will increase visibility calculation. At most a map can have 16384 walls.
A word about sprites
There is a lot of advanced sprite platform use throughout the game and a lot of effort goes in to finding the correct look that doesn’t glitch out. We could actually get around a lot of these limitations by ditching classic 8-bit rendering but where’s the fun in that?
New to the table are clip barriers, which get used quite extensively along with sprites to guide the game with it’s rather lacking sprite collision code. While things cans good on the surface, the game has a tendency to automatically lift the player up on pretty much anything that is shorter than the clip barrier itself seen here.
(left) One of the action packed sections on the latter half uses a lot of sprites to create hanging balconies. In order to get angled railings at the stairs, the whole floor has to be raised here.
(right) Many floating objects require constant manual correction with clip sprites.
Outdoor skies, and our take on it
In order from left: (1) In-game (2) How the geometry is actually laid out (3) Off-map Skybox
It might not be obvious but old FPS games didn’t really have true exterior areas like you might think. What separated outdoor areas from indoors was simply the use of a special sky texture that wasn’t relative to the game world. This instantly gave the impression that there was more out there than what you saw. Later games evolved this in to cubic skyboxes that essentially gave you a 360 panorama to look at. We decided to do something similar to what Source engine does by placing a camera in to a miniature area that gets blown for the player.
We got some wild ideas for this one so expect to see a trick or two!
Additional 3D through lighting
Last thing important to 3D is shading. Build is extremely flexible when it comes to shading and colouring objects but with one major drawback: Everything is manual labor. Every surface, every corner, face of an object, sprite, and everything else you see has to be manually adjusted by ticking one shade unit at a time. The more detail you add to a room, the more shading you need to do!
There is no hand holding, no light maps, no automation. It’s all on you.
(Left) Before shading (Right) After a shading pass
As you can probably see, areas tend to look very dull until you do shading passes.
Remember those sectors that we talked about? Every directional light or addition of contrast relies on the mapper manually drawing each and every red line where he might want even a tiny bit of variance. Shading is easily one of the most time-consuming parts when it comes to mapping and a skilled mapper will try to re-use any sector boundaries that he might have created.
Although through a different lens, this can present additional opportunities for sector overlaps.
In total, all the 5 surfaces you see here had to be manually punched in.
There is no automation for lighting.
Even without textures, objects immediately come to life with some basic shading in place.
Excessive “polygon counts” won’t help you here. Almost 50 sectors to shade by hand, get busy!
These are just scratching the surface on what cool lighting tricks you can do with the immense flexibility that Build gives you, this is something we’d love to return to later!
Thanks for making it this far! if you like what you saw then please consider checking out Ion Maiden on steam (which is on sale as of writing!) at https://store.steampowered.com/app/562860/Ion_Maiden/
On behalf of the whole Ion Maiden team, I’d like to thank for the overwhelming support we’ve received and we hope to return with some more behind the scenes stuff later on!
Signing off,
- Max ‘oasiz’ Ylitalo / Level design lead
Let’s focus a bit on one of the most important bits in First Person Shooter world design: 3D.
Build engine games like Duke Nukem 3D, Blood, TekWar and Shadow Warrior all boasted 3D capabilities and it was all the rage. But like many know, Build wasn’t an actual 3D engine.
What aspects are there to 3D? Here are some of the generation gaps and the importance of height:
First step - Wolfenstein3D and the birth of FPS genre
Wolfenstein 3D was revolutionary for its time. It shared the core of classic FPS world design: Branching paths and non-linearity. However, game play wise it was still fundamentally a quite limited top-down game with 3D projection and was often hard limited to a single height. Game worlds themselves generally were designed with a tile based editor you’d use for an 2D game. Due to this, walls were limited to fixed widths and corners at sharp 90 degree turns.
Second step - Exploring the limits
Games such as ROTT (Rise Of The Triad) took this further and allowed some rudimentary height differences where designers could now place obstacles which you had to conquer by adjusting your height by using various platforms and jump pads. Some games added 45 degree angled walls, texture mapped floors, outdoor skies, and actual map height variation, although this still often required actual transition areas such as elevators or complete map changes.
While game worlds still suffered from the same limitations as above, developers came up with clever ways to introduce height variety to game worlds, often in cumbersome ways.
Now that action was no longer limited to a single plane the game play was finally becoming 3D.
Third step - Integrating height as a fundamental part of level design
It wasn't until games such as Doom where height became fundamentally inseparable from both game play and world design. Now you had stairs, pillars, various branching alternate routes, elevators and hazards on different levels. It was a game changer. Around this time is when designers started to experiment with clever visual tricks such as parallax skies. With some care you could fool the player into thinking that buildings had rooftops or other technically impossible architecture despite those not existing. However, one big limitation still lingered: rooms and alternate paths could never overlap. While Doom games worked around this limit by forcing the player to run over various "intersection pits," the player still couldn't “jump! Ascending always happened by a set of stair steps or elevators. Still an excellent game and its immense success guaranteed that various "Doom clones" would start to emerge with a common goal: To be more ambitious than the one before. This included Build engine games.
The Build Engine
When approaching 3D in Build, you could split it in to following parts:
Sectors - Create rooms, stairs, balconies for enemies etc... could even be sofas, tables or cars! With sloping you can do much more believable objects than many engines of the time.
Sprites - No longer just player facing objects but also as wall or floor aligned flat objects. By combining these you can create rudimentary 3D shapes with with few unfortunate drawbacks. You can combine these with sectors to enhance the visuals.
Shading is very flexible and any floor/wall/slope/sprite can be individually shaded or palette swapped to create numerous variations and make objects really pop out.
Voxels (Volumetric pixels) Available only on later versions, these are essentially 3D sprites.
So what makes Build so special ? The biggest "3D" was that finally you could do overlapping sectors, which resulted in intersecting paths and overlapping areas referred to as SOS (Sector Over Sector). Still, there was one severe limitation: These sectors could never see each other at the same time! This did still allow vertical branching paths for the first time, you could submerge underwater, have sprite based platforms that could form solid looking floating objects that the player could jump on, air ducts, and staircases.
But that’s not the craziest part: Build is actually portal based and non-euclidean! Unlike typical approach with visibility at the time, the engine only cared about which sectors the player could see at any given time. Any sector boundary was essentially a portal to another sector. Visibility calculation was done in real time and this not only allowed everything to be completely dynamic but also nearly anything from rotating gears to moving trains to be built. One lesser known side effect was possibility for impossible geometry that could happily overlap even on the same coordinates as long as both areas weren’t seen at the same time. For more on how the engine treats visibility, there is an excellent article by Fabien Sanglard that explains this in detail: http://fabiensanglard.net/duke3d/build_engine_internals.php
Due to the myriad of options, vertical interconnection and overlapping areas ended up being a staple of any good Build map.
Some examples on how developers got around this limitations with overlapping areas:
(Left) Stairs that overlap a tunnel. Visual blocking in the middle ensures that you never see any overlapping parts at the same time. - Powerslave / Exhumed MAP01
(Middle) Same as above but squeezed to a bare minimum visual overlap block. Granularity for what gets considered as overlapping is determined by the sector size (each step) - Duke Nukem 3D E1L1
(Right) Impossible geometry with a 720 degree loop. Despite being able to see both of the areas from the middle, it still works. This shows that height changes are optional and the only thing that really matters is whether sector boundaries overlap or not. - Duke Nukem 3D E2L11
Some later game developers did go further by coding in their own ways to bridge the missing 3D gap by allowing you to see these overlapping sectors at the same time, referred to as ROR (Room Over Room). Despite common belief, ROR was never a feature of Build. Each game developer did their own take on this by utilizing clever projection hacks and these often came with their own limitations that the mapper had to design around.
Later Build games featured ROR. This really helped to enhance visuals and game play.
Shadow warrior (Left) Blood (Middle) Redneck Rampage Rides Again (Right)
Build is a strange engine, by looking at the games it seems like you can do a lot. Then you study it more and realise that everything is still practically 2D drawings on a paper and it seems that you can’t do anything cool with it, until you learn it even more and realise that it's actually a pandora's box. This extreme flexibility is what keeps many coming back to Build mapping. So what tricks do we utilize to make the world look more “3D” ?
Diagonal pillars
You might have seen in the preview campaign and something that many level designers love to do. It heavily uses the sloping feature of Build engine to create diagonal shapes that you’re more used to seeing in more modern engines
From left to right:
(1) We will start by creating two rectangular sectors, shown as green. Red pillar in the middle acts as a filler to give us a better overall shape.
(2) Add some basic sloping, with a handy script we can easily copy the slope to the other side
(3) Make the triangles fill the sides of the red wall and you end up with a diagonal pillar. This is where the filler area also helps with padding out the dimensions to make it more rectangular
(4) After some extra shading and smoothing out the corners, you end up with one damn fine looking diagonal pillar!
(5) Bonus: This is an example lifted from the very start of the Preview campaign. Green parts represent lowered ceiling and brown parts are raised floors.Without any red in the middle, both parts have to work together in tandem to form a sensible diagonal shape.
Overlapping areas
There are quite a few of those in the Preview campaign, here is one from quite early on:
(left) If you look closely, it looks like the tunnel definitely goes under those offices and it sort of does, but actually great care was done in order to make sure that neither area ever gets drawn at the same time due to the strategic window placement. This is another case of “just enough” to prevent any overlap. (right) Let’s remove some of those safeguards. By ignoring the areas that the tunnel’s ceiling blocks and the windows, you will start to see some weird things as the engine is deperately trying to render both areas at the same time, commonly referred to as “SOS glitching”
Building these cool overlapping areas comes with its own challenges other than just avoiding simultaneous visibility. Due to Build still being fundamentally like drawing on paper, any overlapping areas end up being drawn of top of each. What this means is that there are no other perspectives such as side view available for the geometry creation, it’s all top-down 2D.
Opening a map with overlaps with the editor can end up looking a mess!
Visibility is determined by sector shapes that the player sees.
Red lines are walls that act as sector boundaries for portals
You need to make sure that the player never sees any sector overlap
How we approach this is to first create the basic shapes for overlap (left) and make sure that there is no SOS glitching present with the bare minimum sector splits and visual blocks.
After that the overlapping part can be relocated away from play area and detailing for both parts may begin (right). It’s important to keep the “welding bits” intact so that it can easily be placed back for any actual game play testing. After some practice even complicated areas can easily be managed and typically, even 3-4 layer constructs are manageable.
It’s recommended to keep a working copy with separated parts and have another copy for actual gameplay where the parts get combined. While you could do nearly seamless SOS with a huge amount of red walls, each split still acts as a portal and it will increase visibility calculation. At most a map can have 16384 walls.
A word about sprites
There is a lot of advanced sprite platform use throughout the game and a lot of effort goes in to finding the correct look that doesn’t glitch out. We could actually get around a lot of these limitations by ditching classic 8-bit rendering but where’s the fun in that?
New to the table are clip barriers, which get used quite extensively along with sprites to guide the game with it’s rather lacking sprite collision code. While things cans good on the surface, the game has a tendency to automatically lift the player up on pretty much anything that is shorter than the clip barrier itself seen here.
(left) One of the action packed sections on the latter half uses a lot of sprites to create hanging balconies. In order to get angled railings at the stairs, the whole floor has to be raised here.
(right) Many floating objects require constant manual correction with clip sprites.
Outdoor skies, and our take on it
In order from left: (1) In-game (2) How the geometry is actually laid out (3) Off-map Skybox
It might not be obvious but old FPS games didn’t really have true exterior areas like you might think. What separated outdoor areas from indoors was simply the use of a special sky texture that wasn’t relative to the game world. This instantly gave the impression that there was more out there than what you saw. Later games evolved this in to cubic skyboxes that essentially gave you a 360 panorama to look at. We decided to do something similar to what Source engine does by placing a camera in to a miniature area that gets blown for the player.
We got some wild ideas for this one so expect to see a trick or two!
Additional 3D through lighting
Last thing important to 3D is shading. Build is extremely flexible when it comes to shading and colouring objects but with one major drawback: Everything is manual labor. Every surface, every corner, face of an object, sprite, and everything else you see has to be manually adjusted by ticking one shade unit at a time. The more detail you add to a room, the more shading you need to do!
There is no hand holding, no light maps, no automation. It’s all on you.
(Left) Before shading (Right) After a shading pass
As you can probably see, areas tend to look very dull until you do shading passes.
Remember those sectors that we talked about? Every directional light or addition of contrast relies on the mapper manually drawing each and every red line where he might want even a tiny bit of variance. Shading is easily one of the most time-consuming parts when it comes to mapping and a skilled mapper will try to re-use any sector boundaries that he might have created.
Although through a different lens, this can present additional opportunities for sector overlaps.
In total, all the 5 surfaces you see here had to be manually punched in.
There is no automation for lighting.
Even without textures, objects immediately come to life with some basic shading in place.
Excessive “polygon counts” won’t help you here. Almost 50 sectors to shade by hand, get busy!
These are just scratching the surface on what cool lighting tricks you can do with the immense flexibility that Build gives you, this is something we’d love to return to later!
Thanks for making it this far! if you like what you saw then please consider checking out Ion Maiden on steam (which is on sale as of writing!) at https://store.steampowered.com/app/562860/Ion_Maiden/
On behalf of the whole Ion Maiden team, I’d like to thank for the overwhelming support we’ve received and we hope to return with some more behind the scenes stuff later on!
Signing off,
- Max ‘oasiz’ Ylitalo / Level design lead
Last edited by a moderator:
Hobo Elf
Arcane
That was incredibly monocled.
Drax
Arcane
Level Design Dev Blog
https://3drealms.com/devblog/dev-blog-1-3d-build-engine-and-ion-maiden/
Build engine games like Duke Nukem 3D, Blood, TekWar and Shadow Warrior all boasted 3D capabilities and it was all the rage. But like many know, Build wasn’t an actual 3D engine.
Let’s focus a bit on one of the most important bits in First Person Shooter world design: 3D.
Build engine games like Duke Nukem 3D, Blood, TekWar and Shadow Warrior all boasted 3D capabilities and it was all the rage. But like many know, Build wasn’t an actual 3D engine.
What aspects are there to 3D? Here are some of the generation gaps and the importance of height:
First step - Wolfenstein3D and the birth of FPS genre
Wolfenstein 3D was revolutionary for its time. It shared the core of classic FPS world design: Branching paths and non-linearity. However, game play wise it was still fundamentally a quite limited top-down game with 3D projection and was often hard limited to a single height. Game worlds themselves generally were designed with a tile based editor you’d use for an 2D game. Due to this, walls were limited to fixed widths and corners at sharp 90 degree turns.
Second step - Exploring the limits
Games such as ROTT (Rise Of The Triad) took this further and allowed some rudimentary height differences where designers could now place obstacles which you had to conquer by adjusting your height by using various platforms and jump pads. Some games added 45 degree angled walls, texture mapped floors, outdoor skies, and actual map height variation, although this still often required actual transition areas such as elevators or complete map changes.
While game worlds still suffered from the same limitations as above, developers came up with clever ways to introduce height variety to game worlds, often in cumbersome ways.
Now that action was no longer limited to a single plane the game play was finally becoming 3D.
Third step - Integrating height as a fundamental part of level design
It wasn't until games such as Doom where height became fundamentally inseparable from both game play and world design. Now you had stairs, pillars, various branching alternate routes, elevators and hazards on different levels. It was a game changer. Around this time is when designers started to experiment with clever visual tricks such as parallax skies. With some care you could fool the player into thinking that buildings had rooftops or other technically impossible architecture despite those not existing. However, one big limitation still lingered: rooms and alternate paths could never overlap. While Doom games worked around this limit by forcing the player to run over various "intersection pits," the player still couldn't “jump! Ascending always happened by a set of stair steps or elevators. Still an excellent game and its immense success guaranteed that various "Doom clones" would start to emerge with a common goal: To be more ambitious than the one before. This included Build engine games.
The Build Engine
When approaching 3D in Build, you could split it in to following parts:
Sectors - Create rooms, stairs, balconies for enemies etc... could even be sofas, tables or cars! With sloping you can do much more believable objects than many engines of the time.
Sprites - No longer just player facing objects but also as wall or floor aligned flat objects. By combining these you can create rudimentary 3D shapes with with few unfortunate drawbacks. You can combine these with sectors to enhance the visuals.
Shading is very flexible and any floor/wall/slope/sprite can be individually shaded or palette swapped to create numerous variations and make objects really pop out.
Voxels (Volumetric pixels) Available only on later versions, these are essentially 3D sprites.
So what makes Build so special ? The biggest "3D" was that finally you could do overlapping sectors, which resulted in intersecting paths and overlapping areas referred to as SOS (Sector Over Sector). Still, there was one severe limitation: These sectors could never see each other at the same time! This did still allow vertical branching paths for the first time, you could submerge underwater, have sprite based platforms that could form solid looking floating objects that the player could jump on, air ducts, and staircases.
But that’s not the craziest part: Build is actually portal based and non-euclidean! Unlike typical approach with visibility at the time, the engine only cared about which sectors the player could see at any given time. Any sector boundary was essentially a portal to another sector. Visibility calculation was done in real time and this not only allowed everything to be completely dynamic but also nearly anything from rotating gears to moving trains to be built. One lesser known side effect was possibility for impossible geometry that could happily overlap even on the same coordinates as long as both areas weren’t seen at the same time. For more on how the engine treats visibility, there is an excellent article by Fabien Sanglard that explains this in detail: http://fabiensanglard.net/duke3d/build_engine_internals.php
Due to the myriad of options, vertical interconnection and overlapping areas ended up being a staple of any good Build map.
Some examples on how developers got around this limitations with overlapping areas:
(Left) Stairs that overlap a tunnel. Visual blocking in the middle ensures that you never see any overlapping parts at the same time. - Powerslave / Exhumed MAP01
(Middle) Same as above but squeezed to a bare minimum visual overlap block. Granularity for what gets considered as overlapping is determined by the sector size (each step) - Duke Nukem 3D E1L1
(Right) Impossible geometry with a 720 degree loop. Despite being able to see both of the areas from the middle, it still works. This shows that height changes are optional and the only thing that really matters is whether sector boundaries overlap or not. - Duke Nukem 3D E2L11
Some later game developers did go further by coding in their own ways to bridge the missing 3D gap by allowing you to see these overlapping sectors at the same time, referred to as ROR (Room Over Room). Despite common belief, ROR was never a feature of Build. Each game developer did their own take on this by utilizing clever projection hacks and these often came with their own limitations that the mapper had to design around.
Later Build games featured ROR. This really helped to enhance visuals and game play.
Shadow warrior (Left) Blood (Middle) Redneck Rampage Rides Again (Right)
Build is a strange engine, by looking at the games it seems like you can do a lot. Then you study it more and realise that everything is still practically 2D drawings on a paper and it seems that you can’t do anything cool with it, until you learn it even more and realise that it's actually a pandora's box. This extreme flexibility is what keeps many coming back to Build mapping. So what tricks do we utilize to make the world look more “3D” ?
Diagonal pillars
You might have seen in the preview campaign and something that many level designers love to do. It heavily uses the sloping feature of Build engine to create diagonal shapes that you’re more used to seeing in more modern engines
From left to right:
(1) We will start by creating two rectangular sectors, shown as green. Red pillar in the middle acts as a filler to give us a better overall shape.
(2) Add some basic sloping, with a handy script we can easily copy the slope to the other side
(3) Make the triangles fill the sides of the red wall and you end up with a diagonal pillar. This is where the filler area also helps with padding out the dimensions to make it more rectangular
(4) After some extra shading and smoothing out the corners, you end up with one damn fine looking diagonal pillar!
(5) Bonus: This is an example lifted from the very start of the Preview campaign. Green parts represent lowered ceiling and brown parts are raised floors.Without any red in the middle, both parts have to work together in tandem to form a sensible diagonal shape.
Overlapping areas
There are quite a few of those in the Preview campaign, here is one from quite early on:
(left) If you look closely, it looks like the tunnel definitely goes under those offices and it sort of does, but actually great care was done in order to make sure that neither area ever gets drawn at the same time due to the strategic window placement. This is another case of “just enough” to prevent any overlap. (right) Let’s remove some of those safeguards. By ignoring the areas that the tunnel’s ceiling blocks and the windows, you will start to see some weird things as the engine is deperately trying to render both areas at the same time, commonly referred to as “SOS glitching”
Building these cool overlapping areas comes with its own challenges other than just avoiding simultaneous visibility. Due to Build still being fundamentally like drawing on paper, any overlapping areas end up being drawn of top of each. What this means is that there are no other perspectives such as side view available for the geometry creation, it’s all top-down 2D.
Opening a map with overlaps with the editor can end up looking a mess!
Visibility is determined by sector shapes that the player sees.
Red lines are walls that act as sector boundaries for portals
You need to make sure that the player never sees any sector overlap
How we approach this is to first create the basic shapes for overlap (left) and make sure that there is no SOS glitching present with the bare minimum sector splits and visual blocks.
After that the overlapping part can be relocated away from play area and detailing for both parts may begin (right). It’s important to keep the “welding bits” intact so that it can easily be placed back for any actual game play testing. After some practice even complicated areas can easily be managed and typically, even 3-4 layer constructs are manageable.
It’s recommended to keep a working copy with separated parts and have another copy for actual gameplay where the parts get combined. While you could do nearly seamless SOS with a huge amount of red walls, each split still acts as a portal and it will increase visibility calculation. At most a map can have 16384 walls.
A word about sprites
There is a lot of advanced sprite platform use throughout the game and a lot of effort goes in to finding the correct look that doesn’t glitch out. We could actually get around a lot of these limitations by ditching classic 8-bit rendering but where’s the fun in that?
New to the table are clip barriers, which get used quite extensively along with sprites to guide the game with it’s rather lacking sprite collision code. While things cans good on the surface, the game has a tendency to automatically lift the player up on pretty much anything that is shorter than the clip barrier itself seen here.
(left) One of the action packed sections on the latter half uses a lot of sprites to create hanging balconies. In order to get angled railings at the stairs, the whole floor has to be raised here.
(right) Many floating objects require constant manual correction with clip sprites.
Outdoor skies, and our take on it
In order from left: (1) In-game (2) How the geometry is actually laid out (3) Off-map Skybox
It might not be obvious but old FPS games didn’t really have true exterior areas like you might think. What separated outdoor areas from indoors was simply the use of a special sky texture that wasn’t relative to the game world. This instantly gave the impression that there was more out there than what you saw. Later games evolved this in to cubic skyboxes that essentially gave you a 360 panorama to look at. We decided to do something similar to what Source engine does by placing a camera in to a miniature area that gets blown for the player.
We got some wild ideas for this one so expect to see a trick or two!
Additional 3D through lighting
Last thing important to 3D is shading. Build is extremely flexible when it comes to shading and colouring objects but with one major drawback: Everything is manual labor. Every surface, every corner, face of an object, sprite, and everything else you see has to be manually adjusted by ticking one shade unit at a time. The more detail you add to a room, the more shading you need to do!
There is no hand holding, no light maps, no automation. It’s all on you.
(Left) Before shading (Right) After a shading pass
As you can probably see, areas tend to look very dull until you do shading passes.
Remember those sectors that we talked about? Every directional light or addition of contrast relies on the mapper manually drawing each and every red line where he might want even a tiny bit of variance. Shading is easily one of the most time-consuming parts when it comes to mapping and a skilled mapper will try to re-use any sector boundaries that he might have created.
Although through a different lens, this can present additional opportunities for sector overlaps.
In total, all the 5 surfaces you see here had to be manually punched in.
There is no automation for lighting.
Even without textures, objects immediately come to life with some basic shading in place.
Excessive “polygon counts” won’t help you here. Almost 50 sectors to shade by hand, get busy!
These are just scratching the surface on what cool lighting tricks you can do with the immense flexibility that Build gives you, this is something we’d love to return to later!
Thanks for making it this far! if you like what you saw then please consider checking out Ion Maiden on steam (which is on sale as of writing!) at https://store.steampowered.com/app/562860/Ion_Maiden/
On behalf of the whole Ion Maiden team, I’d like to thank for the overwhelming support we’ve received and we hope to return with some more behind the scenes stuff later on!
Signing off,
- Max ‘oasiz’ Ylitalo / Level design lead
I really want this game to come out soon.
Nothing really compares to build mapping. It just is something else.
I think I spent like two weeks making a single map. Just for fun and for the challenge.
I think I spent like two weeks making a single map. Just for fun and for the challenge.
- Joined
- May 5, 2014
- Messages
- 1,677
Art Dev Blog
https://3drealms.com/devblog/dev-blog-2-art-ion-maiden/
https://3drealms.com/devblog/dev-blog-2-art-ion-maiden/
Dev Blog #2: The Art of Ion Maiden
Plenty of modern independent games return to more old school visual styles. Often those call back to the era of 8 and 16 bit 2d console games, but not as many developers attempt making retro styled first person shooters, especially ones using the original technology. How do you approach creating artwork for such a game?
Tech as part of art direction
Available technology and its limitations always influenced the visuals of video games, especially with 3D games. Before GPU rendering became the standard at the end of the previous century, games had to rely on raw processing powers of the CPU to render scenes. 3D games of the '80s used wireframe polygons, later giving them solid color fills. Arcade machines had the benefit of being able to use specialised hardware, however, polygonal environments on home computers had to be simplified even further or be rendered at frame rates, which from a modern standpoint would be completely unacceptable.
Stunts (1990) vs. Quake 3 Arena (1999). 9 years can make all the difference in the world.
The next decade saw a huge leap in terms of graphic capabilities. With lower hardware costs, 256 color VGA graphic cards and Intel 386 processors became available to the consumers - the exact hardware that made the immersive, fast paced and texture mapped Wolfenstein 3D (1992) possible, and so, kickstarting the FPS genre. Released only around 18 months later, Doom (1993) pushed graphics way beyond what Wolfenstein could offer and things just snowballed from there.
Evolution of realistic settings: Nazi fortress in Wolfenstein 3D (1992), streets of L.A. in Duke Nukem 3D (1996) and the industrial part of the science facility in Half-Life (1998)
Back when the First Person Shooter genre was still new and fresh, it provided the players with a lot of novelty and excitement, but created new challenges for the artists behind them. I’d like you tell you more about them, since by choosing the original Build engine, we had to face many of the same challenges as the developers did in the '90s. Our engine choice and goal of being faithful to this era of gaming, also greatly influenced our artistic decisions.
Three dimensions in service of flat images
Until the second half of the '90s, most games were not completely three dimensional. To make things simpler to process, or to add detail that wouldn’t be otherwise possible, some elements were still were conveyed using flat images. Since first person games feature fluid exploration of three dimensional spaces, environments had to be 3D, while characters, weapons and objects were depicted using 2D sprites.
Lo Wang’s sprite from Shadow Warrior (1997) - three out of eight angles are mirrored.
In order to give them an illusion of three dimensionality, they had to be shown from different angles. Most static objects work well with a single camera-facing sprite or no animation, but the enemies were not only animated - they could be seen from all-angles in game. Creating all frames for such a monster, adds a lot to the artist’s workload and maintaining the same level of detail and consistency can be a challenge. Most artists quickly started looking for a better and faster way than painting them manually.
“Digitising” seemed like an obvious way to go - a term not used often now, digitising meant either scanning flat, hand-drawn or painted artwork to be used as a base for in-game pixel art (Many adventure games backgrounds were done this way), or capturing footage of real life objects with video cameras. Games like Doom (1993) or Blood (1997) used specially constructed poseable models for capture.
Turntable and models used to create sprites in Doom
Creative use of common objects or actors could also give great results - Doom’s weapons are based on store bought toys, and 3D Realms has digitised its own employees to be used as the enemy cultists in Rise Of The Triad (1994). A similar approach was used in William Shatner’s TekWar (1995) however, without adjustments, editing and polish done on the digitised sprites done by an artist, the end result looked rough, grainy and uninspired.
In comparison to Tekwar (right) ROTT offers a much more polished look.
3D graphic suites and computers became more powerful, and availability to artists increased in the '90s. Use of pre-rendered sprites, particularly in 2D games, felt fresh and exciting, and became a huge appeal of games like Donkey Kong Country (1994) on the SNES. 3D tools were an attractive prospect for the artists providing accurate perspective, lighting, material effects and automatic interpolation between keyframes which allowed for the creation of smooth animations, without animating each frame manually. The ability to freely place a camera and rotate objects in 3D was a great asset to the sprite artists working on FPS games.
Original 3D model of the Protector Drone from Duke Nukem 3D
In Ion Maiden, we decided to go with 3D modelling as base for our sprites. After agreeing on the direction based on concept art, the enemies are modeled in 3D. Unlike modern games, our 3D models are not the end result. This allows our 3D artist, Arturo, for a faster and more loose workflow. The focus is placed on general look and three dimensional form, many small details are omitted - despite using very large sprite sizes in comparison to past Build games, these details often gets lost after scaling the renders down to the target resolution.
Concept art, WIP 3D model, render and finished sprites of the Lesser Culist
After the model is complete, I take over and set up the light conditions for the render, pick specific frames of the animation and render out all frames in all angles. Afterwards, the renders are taken to Photoshop for overpainting in 2D - I clean everything up for a crisper, more pixel art look, bring back any lost details, polish the sprites and add a bit of stylisation for a consistent, Ion Maiden style. More time than you’d expect goes into this stage, but in the end it makes a huge difference!
Sprites can’t exist in a vacuum though, so let’s move on to the next aspect - environments!
Paint your PBR!
Nowadays “texture” means only one of whole set of images, which create a “surface” or a “material”. Game engines allow for a lot more visual fidelity than twenty years ago. With more complex geometry, real time lights and reflections, using materials with specific defined parameters (using either numeric values or image data) like reflectivity, specularity, normal/bump/parallax mapping for added illusion of three dimensionality, creates much more realistic and impressive results.
This kind of workflow started taking off around the time of games like Doom 3 and Half-Life 2 (both 2004), with computer hardware becoming strong enough to rely less on precalculating everything. Late '90s games added in some minor effects like specularity or using reflection maps, but back then the textures did all the heavy lifting. With low poly geometry and no dynamic parameters besides the light value (either pre-set by a level designer like in Build, or precomputed from lightmaps), it was all up to the artist to create a believable illusion of a high tech computer, a rough cliff casting deep shadows, or a biotechnological alien hive.
Redneck Rampage (1997) even added light effects in its textures.
Essentially, in a retro engine the textures are the wallpapers that make up your whole environment, together with the geometry created by the level designer. They play a huge part in making the game look interesting as well as communicating specific things to the player - from warning them that something can be damaging, interactive, or communicating the setting they’re placed in. The technical aspects of making textures is both complex and challenging, from conveying the reflectivity of glass to creating minute details of machines and technology. It's a time consuming process. However, by giving complete control over it, directly to the artist, textures can be quite expressive.
A few texture examples from Ion Maiden with varying complexity.
With Ion Maiden’s setting somewhat grounded in reality, many textures have been referenced from photographs, or based on photo sources, but photo textures are never used directly. Photographs available for use are very high resolution. Meanwhile our textures appear in very low resolution - 128x128 being the usual standard. High detail crammed into a such small image never ends up looking good - the clarity and readability get lost, and details turn blurry or change into unnecessary noise. My approach is to recreate such a texture based on photo material from scratch. This way it’s easier to choose what is unnecessary, remove it and have a very crisp, “pixel-perfect” image. I can also more fluidly enforce certain stylistic rules I have established, like the specific way I depict CRT screens, or the types of angles/bevels in “3D” constructions.
Inspiration and the finished texture.
No matter what the quality of your textures or spritework, there is one more factor that can make it or break it completely - color palette.
The dictatorship of VGA
I’m sure that the jump from EGA’s 16 predefined colors to VGA’s 256 colors (out of possible 262,144) was quite a leap for both developers and gamers back in the day. From today’s point of view, 256 seems like a ridiculously low number. All artwork is bound to this limited color palette, so it was something that had to be chosen early, and chosen well. With those 256 being the only colors you can choose, it has an enormous impact on how the game looks.
256 color palette of Ion Maiden
Creating such a palette really is challenge. The hard limit forces to you to find a balance between the number of different hues, and the number of lightness values for each color. The number of light values is especially important - different light values and the very characteristic dark fog effect of old first person shooters are something that made their environments a lot more alive, varied, and immersive. Not enough colors in a color ramp may cause a lot of degradation and loss of detail in dark areas and reduce the fog to a very unconvincing “step” effect. More values will allow for a much smoother look, but will limit the amount of different colors you are able to use - possibly limiting the number of themes you’ll be able to convey, or the effects you can create.
Because of all those limits, it was difficult to have enough colors in the palette to depict light color influencing the environment, so most artists went for choosing local colors of the objects they needed for their environment - green for grass, brown for ground or wood, red for blood, gray and blue for metal and skies, etc. Although it sounds like a “coloring book” approach to color, it still left a lot of room for individuality and was used with great results. In Ion Maiden we decided to put more emphasis on different colors, most of them having two variations. We were able to optimise the palette by making some of the darkest shades shared between the colors. This allowed for pretty varied and vibrant environments at the cost of having to work around some color banding - old school dithering or adding extra detail to break up a surface works well!
Light effects in Ion Maiden
Despite the limited color count, the developers found ways to show off quite a few cool visual effects. Transparency had to use predefined lookup tables that would tell the game what would be the intermediate between the foreground and background color, additive and multiplicative transparency would be possible using this system as well. Color lighting has found its way to the build engine - it was difficult to do it gradually and subtly, so artists and level designers went for a very colorful, contrasted look, by shifting whole areas into specific colors. We have used this approach in Ion Maiden as well, but we have expanded it with specialised light and shadow sprites using add/multi transparency allowing us to create fluid transitions and more realistic/modern lighting effects! And, all of that can be controlled by the level designer!
Power to the people!
One of our design goals was to make the available assets flexible for creative use by the level designers - inspired by Duke Nukem 3D, and over 20 years of custom levels made for it. Besides adjusting the scale and panning of textures, Build games featured the ability to shift the colors of their textures and sprites for visual and gameplay variety. This has not only been brought back in Ion Maiden, but greatly expanded. Besides shifting the whole texture to a specific color, most of the art uses special blue colors that can be shifted to any other hue from our palette. We also have grayscale, color inversion with tinting, lowering/boosting of saturation or contrast and others.
Two versions of the same room
Together with the assets designed for this, it really brings control into the hands of the level designer. This is drastically different from the approach seen in modern games, where the main concern of level designer is creating layouts that will create good gameplay and progression which is then passed to separate “set-dresser” designers/artist who populate the layout with specifically crafted assets. With the visual complexity of modern games it is a necessity, but by using the Build engine we could go back to the 90s very hands on workflow of the past - the same one that allows the designer’s individual creativity to shine and create experiences that you remember twenty years later! And since we’re planning to release the modding tools with the full game, we hope you will enjoy this expressive approach as well.
That was technical…
Making any game is demanding and you’re bound to run into problems, which you have to solve along the way. With the path we have chosen for Ion Maiden, the challenges we had to face, were more technical than creative, but I guess that comes with being a trailblazer (or crazy!) - after all, we’re making the first Build engine game since 1999! I admit I’ve lost a bit of hair over some of the sprites or textures, but making a '90s style first person shooter has always been my fantasy and it’s coming true right now. Being a part of it, is a really fun ride and I hope you’ll enjoy our game, not only for it’s shooting action, but also its pixelated art style.
-Aleksander Kowalczyk, Art Lead
Plenty of modern independent games return to more old school visual styles. Often those call back to the era of 8 and 16 bit 2d console games, but not as many developers attempt making retro styled first person shooters, especially ones using the original technology. How do you approach creating artwork for such a game?
Tech as part of art direction
Available technology and its limitations always influenced the visuals of video games, especially with 3D games. Before GPU rendering became the standard at the end of the previous century, games had to rely on raw processing powers of the CPU to render scenes. 3D games of the '80s used wireframe polygons, later giving them solid color fills. Arcade machines had the benefit of being able to use specialised hardware, however, polygonal environments on home computers had to be simplified even further or be rendered at frame rates, which from a modern standpoint would be completely unacceptable.
Stunts (1990) vs. Quake 3 Arena (1999). 9 years can make all the difference in the world.
The next decade saw a huge leap in terms of graphic capabilities. With lower hardware costs, 256 color VGA graphic cards and Intel 386 processors became available to the consumers - the exact hardware that made the immersive, fast paced and texture mapped Wolfenstein 3D (1992) possible, and so, kickstarting the FPS genre. Released only around 18 months later, Doom (1993) pushed graphics way beyond what Wolfenstein could offer and things just snowballed from there.
Evolution of realistic settings: Nazi fortress in Wolfenstein 3D (1992), streets of L.A. in Duke Nukem 3D (1996) and the industrial part of the science facility in Half-Life (1998)
Back when the First Person Shooter genre was still new and fresh, it provided the players with a lot of novelty and excitement, but created new challenges for the artists behind them. I’d like you tell you more about them, since by choosing the original Build engine, we had to face many of the same challenges as the developers did in the '90s. Our engine choice and goal of being faithful to this era of gaming, also greatly influenced our artistic decisions.
Three dimensions in service of flat images
Until the second half of the '90s, most games were not completely three dimensional. To make things simpler to process, or to add detail that wouldn’t be otherwise possible, some elements were still were conveyed using flat images. Since first person games feature fluid exploration of three dimensional spaces, environments had to be 3D, while characters, weapons and objects were depicted using 2D sprites.
Lo Wang’s sprite from Shadow Warrior (1997) - three out of eight angles are mirrored.
In order to give them an illusion of three dimensionality, they had to be shown from different angles. Most static objects work well with a single camera-facing sprite or no animation, but the enemies were not only animated - they could be seen from all-angles in game. Creating all frames for such a monster, adds a lot to the artist’s workload and maintaining the same level of detail and consistency can be a challenge. Most artists quickly started looking for a better and faster way than painting them manually.
“Digitising” seemed like an obvious way to go - a term not used often now, digitising meant either scanning flat, hand-drawn or painted artwork to be used as a base for in-game pixel art (Many adventure games backgrounds were done this way), or capturing footage of real life objects with video cameras. Games like Doom (1993) or Blood (1997) used specially constructed poseable models for capture.
Turntable and models used to create sprites in Doom
Creative use of common objects or actors could also give great results - Doom’s weapons are based on store bought toys, and 3D Realms has digitised its own employees to be used as the enemy cultists in Rise Of The Triad (1994). A similar approach was used in William Shatner’s TekWar (1995) however, without adjustments, editing and polish done on the digitised sprites done by an artist, the end result looked rough, grainy and uninspired.
In comparison to Tekwar (right) ROTT offers a much more polished look.
3D graphic suites and computers became more powerful, and availability to artists increased in the '90s. Use of pre-rendered sprites, particularly in 2D games, felt fresh and exciting, and became a huge appeal of games like Donkey Kong Country (1994) on the SNES. 3D tools were an attractive prospect for the artists providing accurate perspective, lighting, material effects and automatic interpolation between keyframes which allowed for the creation of smooth animations, without animating each frame manually. The ability to freely place a camera and rotate objects in 3D was a great asset to the sprite artists working on FPS games.
Original 3D model of the Protector Drone from Duke Nukem 3D
In Ion Maiden, we decided to go with 3D modelling as base for our sprites. After agreeing on the direction based on concept art, the enemies are modeled in 3D. Unlike modern games, our 3D models are not the end result. This allows our 3D artist, Arturo, for a faster and more loose workflow. The focus is placed on general look and three dimensional form, many small details are omitted - despite using very large sprite sizes in comparison to past Build games, these details often gets lost after scaling the renders down to the target resolution.
Concept art, WIP 3D model, render and finished sprites of the Lesser Culist
After the model is complete, I take over and set up the light conditions for the render, pick specific frames of the animation and render out all frames in all angles. Afterwards, the renders are taken to Photoshop for overpainting in 2D - I clean everything up for a crisper, more pixel art look, bring back any lost details, polish the sprites and add a bit of stylisation for a consistent, Ion Maiden style. More time than you’d expect goes into this stage, but in the end it makes a huge difference!
Sprites can’t exist in a vacuum though, so let’s move on to the next aspect - environments!
Paint your PBR!
Nowadays “texture” means only one of whole set of images, which create a “surface” or a “material”. Game engines allow for a lot more visual fidelity than twenty years ago. With more complex geometry, real time lights and reflections, using materials with specific defined parameters (using either numeric values or image data) like reflectivity, specularity, normal/bump/parallax mapping for added illusion of three dimensionality, creates much more realistic and impressive results.
This kind of workflow started taking off around the time of games like Doom 3 and Half-Life 2 (both 2004), with computer hardware becoming strong enough to rely less on precalculating everything. Late '90s games added in some minor effects like specularity or using reflection maps, but back then the textures did all the heavy lifting. With low poly geometry and no dynamic parameters besides the light value (either pre-set by a level designer like in Build, or precomputed from lightmaps), it was all up to the artist to create a believable illusion of a high tech computer, a rough cliff casting deep shadows, or a biotechnological alien hive.
Redneck Rampage (1997) even added light effects in its textures.
Essentially, in a retro engine the textures are the wallpapers that make up your whole environment, together with the geometry created by the level designer. They play a huge part in making the game look interesting as well as communicating specific things to the player - from warning them that something can be damaging, interactive, or communicating the setting they’re placed in. The technical aspects of making textures is both complex and challenging, from conveying the reflectivity of glass to creating minute details of machines and technology. It's a time consuming process. However, by giving complete control over it, directly to the artist, textures can be quite expressive.
A few texture examples from Ion Maiden with varying complexity.
With Ion Maiden’s setting somewhat grounded in reality, many textures have been referenced from photographs, or based on photo sources, but photo textures are never used directly. Photographs available for use are very high resolution. Meanwhile our textures appear in very low resolution - 128x128 being the usual standard. High detail crammed into a such small image never ends up looking good - the clarity and readability get lost, and details turn blurry or change into unnecessary noise. My approach is to recreate such a texture based on photo material from scratch. This way it’s easier to choose what is unnecessary, remove it and have a very crisp, “pixel-perfect” image. I can also more fluidly enforce certain stylistic rules I have established, like the specific way I depict CRT screens, or the types of angles/bevels in “3D” constructions.
Inspiration and the finished texture.
No matter what the quality of your textures or spritework, there is one more factor that can make it or break it completely - color palette.
The dictatorship of VGA
I’m sure that the jump from EGA’s 16 predefined colors to VGA’s 256 colors (out of possible 262,144) was quite a leap for both developers and gamers back in the day. From today’s point of view, 256 seems like a ridiculously low number. All artwork is bound to this limited color palette, so it was something that had to be chosen early, and chosen well. With those 256 being the only colors you can choose, it has an enormous impact on how the game looks.
256 color palette of Ion Maiden
Creating such a palette really is challenge. The hard limit forces to you to find a balance between the number of different hues, and the number of lightness values for each color. The number of light values is especially important - different light values and the very characteristic dark fog effect of old first person shooters are something that made their environments a lot more alive, varied, and immersive. Not enough colors in a color ramp may cause a lot of degradation and loss of detail in dark areas and reduce the fog to a very unconvincing “step” effect. More values will allow for a much smoother look, but will limit the amount of different colors you are able to use - possibly limiting the number of themes you’ll be able to convey, or the effects you can create.
Because of all those limits, it was difficult to have enough colors in the palette to depict light color influencing the environment, so most artists went for choosing local colors of the objects they needed for their environment - green for grass, brown for ground or wood, red for blood, gray and blue for metal and skies, etc. Although it sounds like a “coloring book” approach to color, it still left a lot of room for individuality and was used with great results. In Ion Maiden we decided to put more emphasis on different colors, most of them having two variations. We were able to optimise the palette by making some of the darkest shades shared between the colors. This allowed for pretty varied and vibrant environments at the cost of having to work around some color banding - old school dithering or adding extra detail to break up a surface works well!
Light effects in Ion Maiden
Despite the limited color count, the developers found ways to show off quite a few cool visual effects. Transparency had to use predefined lookup tables that would tell the game what would be the intermediate between the foreground and background color, additive and multiplicative transparency would be possible using this system as well. Color lighting has found its way to the build engine - it was difficult to do it gradually and subtly, so artists and level designers went for a very colorful, contrasted look, by shifting whole areas into specific colors. We have used this approach in Ion Maiden as well, but we have expanded it with specialised light and shadow sprites using add/multi transparency allowing us to create fluid transitions and more realistic/modern lighting effects! And, all of that can be controlled by the level designer!
Power to the people!
One of our design goals was to make the available assets flexible for creative use by the level designers - inspired by Duke Nukem 3D, and over 20 years of custom levels made for it. Besides adjusting the scale and panning of textures, Build games featured the ability to shift the colors of their textures and sprites for visual and gameplay variety. This has not only been brought back in Ion Maiden, but greatly expanded. Besides shifting the whole texture to a specific color, most of the art uses special blue colors that can be shifted to any other hue from our palette. We also have grayscale, color inversion with tinting, lowering/boosting of saturation or contrast and others.
Two versions of the same room
Together with the assets designed for this, it really brings control into the hands of the level designer. This is drastically different from the approach seen in modern games, where the main concern of level designer is creating layouts that will create good gameplay and progression which is then passed to separate “set-dresser” designers/artist who populate the layout with specifically crafted assets. With the visual complexity of modern games it is a necessity, but by using the Build engine we could go back to the 90s very hands on workflow of the past - the same one that allows the designer’s individual creativity to shine and create experiences that you remember twenty years later! And since we’re planning to release the modding tools with the full game, we hope you will enjoy this expressive approach as well.
That was technical…
Making any game is demanding and you’re bound to run into problems, which you have to solve along the way. With the path we have chosen for Ion Maiden, the challenges we had to face, were more technical than creative, but I guess that comes with being a trailblazer (or crazy!) - after all, we’re making the first Build engine game since 1999! I admit I’ve lost a bit of hair over some of the sprites or textures, but making a '90s style first person shooter has always been my fantasy and it’s coming true right now. Being a part of it, is a really fun ride and I hope you’ll enjoy our game, not only for it’s shooting action, but also its pixelated art style.
-Aleksander Kowalczyk, Art Lead
Astral Rag
Arcane
- Joined
- Feb 1, 2012
- Messages
- 7,771
Stunts is awesome
I'm really excited for this game.
Who does the voice of Shelly "Bombshell" Harrison? Is it the same actress as in the 2015 game?
Should I get this on early access?
Not really. It's just a demo. Since the release we just had an extra game mode and a couple of patchs for optimization and tweaks. We should have a multiplayer beta before the end of the year, but I think it was just my misunderstood because we have nothing and 0 news.
That's unfortunate. I definitely want to see more of this game by way of weapons, enemies, and maps. It brings me back so damn much.
As an Amazon Associate, rpgcodex.net earns from qualifying purchases.