Part 11. Dark light.
Graftgold Memories.
At Graftgold we used to try to get new games signed with a publisher early on in the dev. process so we could get them to fund the development. That was always an issue because although we had a really good reputation a publisher really wanted to see the game with finished graphics and tuned up playability to make a judgement. In the later years we tried to take them a sample of gameplay supported by a video of artwork mock ups and a specification of the game. That was the hardest part as our best games evolved during the development so it was extremely hard to lay out all the details up front. We would book up interviews with many leading publishers and present our ideas. I can remember the presentation for Fire And Ice, we really did not have much in the way of gameplay.
We presented a demo of Cool Coyote playing the piano which became the intro of the game. That was enough with Andrew Braybrook's reputation as a game designer and the publishers desire to work with Graftgold. As games and budgets got bigger the work going into the presentations needed to be much higher quality and content and we could spend many man months working on the design.
We tried to come up with a catchy name and think out the scenario of the game. The main character would usually be designed with some test animations. We used to supply a lot of paper artwork showing concepts for levels and the various types of screen in the game. I used to draw up a development plan from this showing monthly milestones. The publishers always wanted a linear plan with level 1 as the first milestone, level 2 as the second but programming is not like that. For level 1 to be complete you need probably all the main characters programming plus all the systems controlling everything else. I used to add a few extra milestones on the front to cover this. They had to be visual things that the publisher could see. One usually was, main character animated, another background building and scrolling. We found it got harder and harder to sell a new idea: publishers wanted little risk and wanted a game like last years big hit. Some of our best ideas never got past the prototype stage. We just didn't have the money to develop what we wanted. The money needed to develop a game rose exponentially so that even if we had the whole income saved from every previous game it would still not cover the dev. cost of the next game!
In space speed is relative, you might be orbiting the sun at thousands of mph but be stationary relative to your local surroundings. I opted for a display that shows your speed relative to the locality. When you make a turn that's the speed you want to maintain. You wouldn't want to turn say 90 degrees to your orbit and go shooting off at thousands of miles an hour.
Putting in thrust displays showed up a couple of issues in the engine programming. As with custom ships you can have loads of engines powered by loads of generators each component has to know how much to be on and all the outputs have to be summed. I calculated a desired thrust and then let the engines each contribute towards this. To give a smoother more realistic display I let the engines ramp up power rather than just toggle on and off.
I designed a multiple target system for the custom guns. For small ships the player probably only wants a single target but for big ships with loads of turrets the player probably will control the forward guns and let the ai control others. I decided to allow the player to assign guns to a number of banks which can be targeted separately. Expert players could pick out targets for all the banks and let the AI do the tracking and firing. Xmas interrupted programming this so its on the to do list.
Getting back to it in January I started playing around with the graphical look so I can get some screen shots. Doing the HUD I realised I might want a control panel for some displays. So I thought I ought to pin this down so I could decide what was a HUD display and what was a panel display.
I wanted immediate stuff to be easily seen on the HUD and stuff you used more for reference on the panel. I want a sexy energy display on the panel that showed the various generators , batteries and consumers. Also I want to integrate all the computer displays that the game will have such as ship building, trading, navigation, status etc. so that you click on a panel display to expand it to a screen sized display. I thought I would try an experiment to see what the game looked like with a cockpit so I borrowed a cockpit from the internet as a test graphic. I adjusted the size to act as a template for my graphics which I shall do later. I like the way a cockpit enhances the 3d ness although some players like to see their ship in view. I will probably include both views. At the moment I also have a fixed camera view so I can see the ship from any angle but its a devil to control when your back to front or upside down.
I tried to turn a light on to get a better screen shot but all it did was make the models completely black! How hard can it be , back to the instruction manual. Enable lights set up a light give it a vector and a light colour, set the light on , yes done all that. Well it works in DX demos , checked all my settings, all look the same. Spent a day getting nowhere what am I missing? I hate that about DX. I follow an example and get nothing, no errors but no result, nothing I can debug. It ends up as a trial and error change each setting until I stumble onto something they forgot to say, or rereading docs over and over showing how easy it is. Tried to fire up the DX demo but It wont compile on my new machine, cant find some headers. I really haven't the patience to sort this out at the moment put it on the to do list.
The effect editor showing lighting turned on!
I thought I would clean up by graphics engine a bit, might throw some light on the issue. A year or so ago I added DX effects only to learn last year the were depreciated in later DX versions. I already had my own effect object that could have a pixel shader and vertex shader so had added a DX effect to this which covered all options but had a lot of redundancy. So removing the DX Effect code simplified things again and still let me use shaders. That meant converting my sky routines from a DXEffect to shaders. Shaders are little routines that run on your graphic card doing all the sexy graphic stuff. They usually need data passing to them to control the effects they produce. I wrote a system to store the required data and pass it automatically to the shaders allowing me to generalise the drawing process. Samples usually hard code every single draw but its good practice to separate drawing and game functionality and I like to have a few well written draw routines rather than dozens. That way its easier to convert to other formats or to upgrade.
While in the graphics routines I thought I ought to sort out the format of my graphics. I was still loading everything as 8 bit palette graphics. This makes loading quick but gave me poorer quality textures. I was going to have a shader decode the paletted texture so I could squeeze 4 times as many textures in the game but nowadays shaders add several textures and this takes longer if it has to decode palettes as well. I decided to support several modes including packed textures. This meant an upgrade to my graphic import tool. This tool converts source graphics to the game format and arranges them in texture blocks.
The basic method is one of subdivision. You start of with a single box for the whole of the program/routine you are thinking about. You draw the next level underneath the first box rather like the next level of a family tree. Your program consists of... Initialisation flowed by its main body followed by Termination. Note each level (unlike a flowchart) represents the whole process cut into finer pieces. We link the boxes to show the parentage, sequence is taken for granted reading left to right. Then we proceed to split up each box on the lowest level thinking this process consists of ...
I used this method to produce highly optimised low level graphics routines as well as provided by high level program organisation. You should aim to fit the top level diagram on a single sheet of paper. Then some of the process boxes are expanded to become their own diagram on another sheet.
This is also a good way to understand somebody else's code. You find all sorts of mistakes just charting out a routine, it also gives you a map allowing you to figure out how to change it.
Part of the Main Structure of Seiddab Attack.
At Graftgold we used to try to get new games signed with a publisher early on in the dev. process so we could get them to fund the development. That was always an issue because although we had a really good reputation a publisher really wanted to see the game with finished graphics and tuned up playability to make a judgement. In the later years we tried to take them a sample of gameplay supported by a video of artwork mock ups and a specification of the game. That was the hardest part as our best games evolved during the development so it was extremely hard to lay out all the details up front. We would book up interviews with many leading publishers and present our ideas. I can remember the presentation for Fire And Ice, we really did not have much in the way of gameplay.
We presented a demo of Cool Coyote playing the piano which became the intro of the game. That was enough with Andrew Braybrook's reputation as a game designer and the publishers desire to work with Graftgold. As games and budgets got bigger the work going into the presentations needed to be much higher quality and content and we could spend many man months working on the design.
We tried to come up with a catchy name and think out the scenario of the game. The main character would usually be designed with some test animations. We used to supply a lot of paper artwork showing concepts for levels and the various types of screen in the game. I used to draw up a development plan from this showing monthly milestones. The publishers always wanted a linear plan with level 1 as the first milestone, level 2 as the second but programming is not like that. For level 1 to be complete you need probably all the main characters programming plus all the systems controlling everything else. I used to add a few extra milestones on the front to cover this. They had to be visual things that the publisher could see. One usually was, main character animated, another background building and scrolling. We found it got harder and harder to sell a new idea: publishers wanted little risk and wanted a game like last years big hit. Some of our best ideas never got past the prototype stage. We just didn't have the money to develop what we wanted. The money needed to develop a game rose exponentially so that even if we had the whole income saved from every previous game it would still not cover the dev. cost of the next game!
Deepest Blue Progress.
It doesn't seem that a month has passed since the last blog. Even though I really missed my laptop I found it really difficult getting going again after the Xmas break. I suppose its like taking a rest in the middle of marathon. I ended the year writing HUD routines and refining the gun targeting. It was a welcome change doing something where you see the result on the screen quickly. That's why I liked programming the Spectrum. It was really easy to get something on the screen so you could see if your code worked or not. I added a simple speed and thrust display to balance up the left side of the HUD.In space speed is relative, you might be orbiting the sun at thousands of mph but be stationary relative to your local surroundings. I opted for a display that shows your speed relative to the locality. When you make a turn that's the speed you want to maintain. You wouldn't want to turn say 90 degrees to your orbit and go shooting off at thousands of miles an hour.
Putting in thrust displays showed up a couple of issues in the engine programming. As with custom ships you can have loads of engines powered by loads of generators each component has to know how much to be on and all the outputs have to be summed. I calculated a desired thrust and then let the engines each contribute towards this. To give a smoother more realistic display I let the engines ramp up power rather than just toggle on and off.
I designed a multiple target system for the custom guns. For small ships the player probably only wants a single target but for big ships with loads of turrets the player probably will control the forward guns and let the ai control others. I decided to allow the player to assign guns to a number of banks which can be targeted separately. Expert players could pick out targets for all the banks and let the AI do the tracking and firing. Xmas interrupted programming this so its on the to do list.
Getting back to it in January I started playing around with the graphical look so I can get some screen shots. Doing the HUD I realised I might want a control panel for some displays. So I thought I ought to pin this down so I could decide what was a HUD display and what was a panel display.
I wanted immediate stuff to be easily seen on the HUD and stuff you used more for reference on the panel. I want a sexy energy display on the panel that showed the various generators , batteries and consumers. Also I want to integrate all the computer displays that the game will have such as ship building, trading, navigation, status etc. so that you click on a panel display to expand it to a screen sized display. I thought I would try an experiment to see what the game looked like with a cockpit so I borrowed a cockpit from the internet as a test graphic. I adjusted the size to act as a template for my graphics which I shall do later. I like the way a cockpit enhances the 3d ness although some players like to see their ship in view. I will probably include both views. At the moment I also have a fixed camera view so I can see the ship from any angle but its a devil to control when your back to front or upside down.
I tried to turn a light on to get a better screen shot but all it did was make the models completely black! How hard can it be , back to the instruction manual. Enable lights set up a light give it a vector and a light colour, set the light on , yes done all that. Well it works in DX demos , checked all my settings, all look the same. Spent a day getting nowhere what am I missing? I hate that about DX. I follow an example and get nothing, no errors but no result, nothing I can debug. It ends up as a trial and error change each setting until I stumble onto something they forgot to say, or rereading docs over and over showing how easy it is. Tried to fire up the DX demo but It wont compile on my new machine, cant find some headers. I really haven't the patience to sort this out at the moment put it on the to do list.
The effect editor showing lighting turned on!
I thought I would clean up by graphics engine a bit, might throw some light on the issue. A year or so ago I added DX effects only to learn last year the were depreciated in later DX versions. I already had my own effect object that could have a pixel shader and vertex shader so had added a DX effect to this which covered all options but had a lot of redundancy. So removing the DX Effect code simplified things again and still let me use shaders. That meant converting my sky routines from a DXEffect to shaders. Shaders are little routines that run on your graphic card doing all the sexy graphic stuff. They usually need data passing to them to control the effects they produce. I wrote a system to store the required data and pass it automatically to the shaders allowing me to generalise the drawing process. Samples usually hard code every single draw but its good practice to separate drawing and game functionality and I like to have a few well written draw routines rather than dozens. That way its easier to convert to other formats or to upgrade.
While in the graphics routines I thought I ought to sort out the format of my graphics. I was still loading everything as 8 bit palette graphics. This makes loading quick but gave me poorer quality textures. I was going to have a shader decode the paletted texture so I could squeeze 4 times as many textures in the game but nowadays shaders add several textures and this takes longer if it has to decode palettes as well. I decided to support several modes including packed textures. This meant an upgrade to my graphic import tool. This tool converts source graphics to the game format and arranges them in texture blocks.
Programming Tip.
As my design method I use structured programming. Its probably considered old fashioned but it is the basis of most modern programming languages. What I like about it is it works at a high level dealing with major blocks of code or at the smallest level writing say a routine do draw something by code onto a drawing surface or texture. It is a means of restricting code to a set of well known constructs that you can individually test and get working. You can prove a well structured program works. It minimises paths of flow through the code. In the old days languages were littered with GOTO statements. making the number of paths through a program huge if not infinite.
Jackson Structured programming gave me a diagrammatic way of designing code, far better than flowcharts, which are just like code with GOTO's.
There are just a few simple constructs really these are the elements of a decent programming language.
Sequence Step.
Represented by a rectangle with a meaningful name , steps that follow are shown by rectangles side by side.
Iteration.
Represented by a rectangle with a * symbol in the top left corner this represents a program loop.
Condition
Represented by a box with a ? in the top left corner (or a small o in Jackson's scheme).
To these I add a Synchronise box marked with an upwards/downwards arrow for routines that receive or send a signal to others to extend the system to multi threading.
I used this method to produce highly optimised low level graphics routines as well as provided by high level program organisation. You should aim to fit the top level diagram on a single sheet of paper. Then some of the process boxes are expanded to become their own diagram on another sheet.
This is also a good way to understand somebody else's code. You find all sorts of mistakes just charting out a routine, it also gives you a map allowing you to figure out how to change it.
Part of the Main Structure of Seiddab Attack.
Definately a +1 for use of Jackson charts. I still use them in preference to uml sequence diagrams even if they don't find their way into the formal design.
ReplyDeleteI'm guessing invert the indices would solve the pure black texture problem on your models.
ReplyDeletehttp://www.gamedev.net/topic/652923-texturing-problem-model-appearing-pure-black-assimp/
Hi Steve, I've just stumbled across your blog and am find it fascinating and extremely enjoyable. I'm a huge fan of Quazatron (bedroom-coded a fan version myself over a couple of years!) and am excited to hear how this develops. Also loving the stories of 'back in the day'. Keep them coming! :)
ReplyDeleteFlowcharts are a great way to implement computer programmes. I've done some when I was doing simple algorithms to in computer science class. You can find some good flowchart examples and templates here.
ReplyDelete