|
Devblog
9th January, 2010:Did a little work on the District system. I made the data structure, a few methods and a screen for their creation. This screen still needs a lot of work to be useful for creating districts. I've laid out a few of the next steps below.Next steps: No screenshots for this update 25th November, 2009:Took a long break in development there but I'm still going. I wrote up some more design details and it helped clarify some requirements. A few tweaks were needed before I could start on the District system. Buildings needed a complete overhaul so that each of them has every possible attribute (production, research, power usage etc). That allowed me to simplify the checks for how much production etc a colony produces, removing the reams of if statements. For simplicity's sake, I also removed all of the colony infrastructure calculations and will re-add those later when I've got a better idea of what infrastructure benefits I want to give. With all that done, district's stats can now actually be stored as single Building objects and possibly parsed in the same list as single buildings. Now I can implement the District system.Next steps: See screenshots for this update 6th November, 2009:I got a ton of work done and met loads of the previous development criteria, with a few changes. I made it so you can only build specialised buildings like biospheres or gravimetric water drills on the planets that require them. Buildings are no longer displayed in the colony screen build list if they can't be built. I used a nice quick and dirty hack - using my CanAddBuilding method to see if the building can be built at the very bottomleft corner of the map, which is out of view and thus nobody can build anything there. With no buildings nearby to overlap, this will always return true if the building can be built at this colony. May need to modify this later if I have special subaquarian buildings or buildings that require proximity to each other. For now, this works well.Changed ore deposits to a larger model and area of effect, and then made every drill on an ore deposit produce +3 industry per worker instead of the normal +1. I've made ore deposits an uncommon occurance and only one per planet. Made energy a colony-wide resource again rather than system wide. This was done because I removed the whole "outpost" thing and every planet is expected to be able to run reactors. Might get rid of the energy infrastructure. I'll also have to think of a new use for the experimental reactor. Perhaps it can produce something ludicrous like 1000 energy and then I can have system defence cannons that require 500 each or something. That might be enough to turn worthless planets into strategic military resources as they can be set up as reactor outposts for orbital cannons. Perhaps this and the defence infrastructure could be combined. I'm now ready to begin working on the District system. Next steps: See screenshots for this update 4th November, 2009:I wrote up the Policy mechanics and design concepts into a more formal design document. There's a lot more work to do on that feature than I'd thought but I should be able to do it. The document hasn't been uploaded to the website yet but in the process of developing it, I've made a list of things that I'll need to go back and change in the previously completed screens. As part of the iterative development process, I'm prepared to go back and make these big changes. In some projects, parts of the game or whole screens are designed in completia, implemented and not revisited until the whole game is done. This stifles creativity as each stage of development is handcuffed by the previous one. For example, if I were unwilling to change the colony mechanics I'd have to make a complicated and unweildy policy system. In a project with multiple people, different teams may end up stepping on each others toes by asking for changes to other parts of the game so one design document may help. But for a project that I'm doing on my own, I can do pretty much whatever I want.The next steps for the project involve seriously gutting out the colony screen mechanics and replacing them with ones more compatible with my new goal. Once the massive list of development goals below is complete, I will have laid the ground work for the policy system and will have one of the main components (districts) complete. After that I can work on the other components of the policy system, which shouldn't be as much work. And only after all that can I work on the policy screen UI itself. It's going to be a lot of work getting this system in, but it's one of the central, core mechanics in the game's design. I don't want to do a half-assed job of it. Even though I might have to do a partial redesign later, it's all part of the development process. You can't very well improve a system that doesn't exist yet and you can't tell what needs improvement until you implement it and try it out. This list may take some time to work through ^^;. Next steps: No screenshots for this update 3rd November, 2009:Continued work on the UI. I added information to the slider panels and gave them a little colour. Images will need to be redone later but for now they give a decent impression of what the final UI will look like, which is enough to make stylistic decisions on. The actual data displayed is faked (except the food and RP, that works) as I haven't implemented the mechanics surrounding command points yet. The research panel also won't be able to be finished until the research system is in. When doing this, I've been considering some of the mechanics I'm going to have to implement here. I like the idea that surplus food is sold on a sort of open market. Perhaps if the player has trade treaties with other races, he can choose one race to trade their food surplus to, who would pay more. One race might be willing to pay only 1bc/food, while others might pay 2bc/food or even 3.The Freight costs displayed here are basically the costs of moving food to non-sustainable colonies, like with freighters in MOO2 except without the micromanagement of having to build them. The costs would be high enough to encourage systems to be self-sufficient if possible. The alternative is to produce tons more than you need overall and use the income from the surplus food to offset freighter costs.If there's not enough food, I'm torn between having massive starvation or just a massive cost to buy food from the open market. The former would be complicated to implement and in MOO2 I never felt like I knew WHY certain colonies were starving and others weren't during a food shortage. I didn't really see the colonies that were starving and thus the effects of starvation for a few turns felt like it wasn't a big deal. The second system turns the lack of food into a financial consideration so that you immediately see the effects of poorly managed food production (what would normally be starvation). This second system has the drawback that players may choose to buy their food rather than farming it and concentrate on money-making endeavours to pay for it. This could be avoided by making the costs on the open market high and having them scale non-linearly with demand so you could only really buy so much. Trade treaties could be acquired to reduce the cost by buying some of the food from another race at 1, 2 or 3bc/turn. Another benefit of the second system is that players could switch their entire economy to research or production temporarily at massive cost of cash. And if you run out of cash, your empire would revolt and overthrow you (game over). So money management becomes one of the primary game concerns. Next steps: See screenshots for this update 2nd November, 2009:I added in nice little sliding bits in the UI. I've modified a UIElement class I made a while ago to incorporate animation from one bounding rectangle to another. It transforms from one set of x, y, width and height variables to another in smooth increments over either a specified number of frames or a specified number of milliseconds in real-time. I've used it to implement sliding portions of the UI and as a general container for any UI elements and buttons I need to place on the screen. Three little panels now slide out when clicked and in again when clicked. They will be used to contain important at-a-glance information and the slid-out version will display more detailed info. At the moment I'm thinking of something like MOO2's command points, then food, then a research panel.Next steps: No screenshots for this update 1st November, 2009:I added randomly chosen system names to the stars (the code was just ripped out of my old MOO2 project). Then I made it so you can only go into stars you've visited. Next I made a new system that generates nebulas on the map of a variety of different preset colours. At the moment the nebulas are still just formed by pseudorandomly placing gas particles within a given cuboid and I rely on view angle and overlaps in additive blending to give it a nice look. In future I may implement a more complex algorithm to draw more precise nebulae. At the very least, I think making it place the particles within a sphere would be very useful. I could then simulate a few different shapes of nebula by just using multiple nebulae with different settings. It would also mean testing if something is within the nebula would be easy since I'd have a reference bounding sphere to test with. But before I work on that feature, I'd like to get more of the core work done.I've started constructing a basic UI based on requirements for what screens should be immediately accessible. I've settled on buttons to open a colony management screen, colony build policies, astrometrics, shipyards and fleets. Research is absent as I plan to put it on the right hand side. It's a bit of a throwback to MOO2's interface design but it just feels right to put it above the end turn button. The current UI design doesn't leave a lot of room for information, so I was thinking of a system where there are these little bits sticking out from the right hand side and when you move the mouse over them they slide out horizontally and display additional info. The little bits can just have the info as an icon and a number, then the big slideout version can have a bit of analysis and some words. An example might be farming, where the little icon would just be a food icon indicating whether or not there are any starving systems. When scrolled out, it might show a list of any planets that are starving. Next steps: See screenshots for this update 30th October, 2009:I added a system where clicking on a star brings it up in system view. More importantly, I've managed to make it so load times are acceptable. Colony view takes between 2 and 6 seconds to load depending on terrain type, System view takes 2 seconds (that's total including transition effects) and galaxy view takes 1 second to load (effectively instant but with transition effects). Much longer than that and it would start to impact on gameplay, so I'm quite pleased. The Colony view might need to be reduced to 2-3 seconds as I find waits longer than 3 seconds begin to impact on decisions we make in games. When you're faced with the choice of going into a colony to do something minor or not, I don't want the annoyance of load times becoming a big influence in that decision. The alternative is to cover it up with a themed transition to make it seem like it should be taking an extra few seconds. A little screen saying "Booting up satellite imager" with a picture of the planet and a satelite in orbit and then a quick camera-static transition on load-in might do the trick. Either way there will be some optimisations to put in later I imagine.Next steps: No screenshots for this update 28th October, 2009:I found that rendering nebulas in the HDR but not drawing the actual sprites produced a very nice, smooth effect. It didn't look as solid, but I used it to develop a distributed background nebula system and used the old method for micronebulas. The system currently just has a big box of uniformly distributed particles for the background nebula, the same way as the stars are done. This can be augmented later to produce different colours or shapes of background nebula to draw on top of the background image, so it's a very versatile system.Next I created a sector grid, which is drawn as a translucent plane with lines along it at regular intervals, dividing the galaxy up into squares. The camera was rotated to an angle and locked there as I found allowing rotation on that axismade the static background image noticeable and ruined the visual parallax effect. The camera can be panned up and down within certain limits, zoomed in and out and dragged. The zooming feature now zooms forward in the direction you're looking (like in Galciv) but stays within defined height limits. I think it feels pretty good but it may of course need some tweaking later. For technical ease and gameplay reasons, I've restricted all colonisable stars to the galactic z-plane. The gameplay will essentially be a kind of 2D isometric view in a 3D engine. Although this was one of the complaints about GalCiv, no other popular 4x space game has used a true 3D star map. Having stars in off-plane 3D locations doesn't add much to gameplay, and it makes the sectoring, selection and controls clumbsy. From EVE Online I learned that having to rotate the map on three axis to get an idea of the physical shape of a group of stars or to click on something doesn't add much to gameplay. It has a "flatten map" feature that makes the map a bit easier to deal with but with stars placed in 3D there are some overlaps from any viewpoint that interfere with selection. I've added the graphical component of a sensor grid system where stars you own project a sensor sphere around them. The screenshots show this system with the sphere on and off. For a certain distance around each star you own, you'll have a sensor range within which you can see ships, anomalies, strategic resources, details about star systems etc. I think this will be a really interesting gameplay element and allowing sensor outposts to be built anywhere in space to extend this range will provide another element of tactical gameplay. The sensor range is signified by a circular gap in the sector grid plane that you can see through, an idea partly stolen from K240 on the Amiga. I did it using the stencil buffer and a little cylinder model. I'm quite pleased with how it looks and with my sphere model which is the same size, testing whether items are inside the sensor sphere or not should actually be very easy. Lastly, I've decided against having planets show on the galactic map. While it may be technically feasible, it would be way too much information to put on the galactic map and the zooming in and out to check on planets may actually become more annoying than a 2-3 second wait to load the system screen. I'm trying to follow design principle of not giving the player more than 7 things to think about at once. Studies have shown that people on average can't keep track of more than 7 things at once without the activity becoming very mentally taxing. With the tactical elements of gameplay on the galaxy map, adding in all the system stuff to that may prove too much so I've gone back to the idea of simply clicking on stars to go into the system view. With the current view, an icon system is no longer required but I'll keep it in mind for later. Next steps: See screenshots for this update 22nd October, 2009:I got my hands on a copy of Galactic Civilisations 2 and took some notes on what it does well, what I liked in it and what it fails on. I was surprised at how much basic stuff it fell down on and how simplistic the main galaxy graphics were for a game released in 2006. Nevertheless, it gave me some great ideas for the main screen UI. Rather than a simple MOO2 style star map, I've decided to go for GalCivII's zoomed-in scrollable map idea.I worked out how to get my stars showing in 3D without ruining the graphical quality, which was awesome. Next I implemented a simple control system for the map where you can click-drag it around and zoom in and out with the mousewheel. I created a system to generate thousands of point sprites for stars in the background and render them in 3D space. So the background stars move naturally when the camera moves by an amount depending on their distance. It gives a nice parallax effect when dragging the map around and gives an extra visual frame of reference when zooming out. You can't really appreciate the 3D nature of the map until you see it being moved but I can't be arsed putting a video up for now. Finally, I implemented a system to produce nebulae using additive blending on projected sprites. I don't imagine it's terribly efficient with all those software projection calcs every frame but I plan to tighten it up later and implement an LOD system of sorts. The next step is to add a sector grid, which will double as an indicator of galactic scanning range. Following that, I will then implement an icon system where a simple fixed-size icon is drawn at the location of anything that's far enough away that visibility and mouse selection are impaired. This should make the map system much more scalable and let me decrease the size of the stars without impacting fully zoomed-out gameplay. Both EVE Online and GalCivII use this system very well. Reducing the size of stars reduces the number of stars that can be physically on-screen when zoomed in significantly. I could then feasibly draw the orbit rings and planets around those few stars, hooking up the system screen view seamlessly to the main UI. Clicking on a star would zoom in on it and bring up the System UI's info rather than switching to the system screen itself. I still don't know if this is a good idea but after playing GalCivII, which uses a similar system of displaying planets, I have to test it out and see what it's like. Next steps: See screenshots for this update 18th October, 2009:Took a completely new direction with the galaxy map. I'm just going to provide a variety of backdrops and randomly generate stars on them. A simple 2D system will suffice. I found it difficult to distinguish my stars from those in some of the backgrounds so to help I've decided they should be animated. I've been modifying a copy of my current sun renderer to draw all the stars on a 2D plane and with rotation animations and bloom post-processing. For efficiency's sake, I render a single white star to a little render target, then draw that at the 2D coordinates of each star using that star's size to determine the drawing bounds and using its colour as a tint. Then I apply the HDR bloom to the final image so it appears that I've rendered hundreds of stars when in reality I've only rendered one and drawn 120 sprites or so. As the stars rotate, they sort of animate due to the bloomed areas coming in and out of view.To generate the galaxy map, a simple string seed is taken in. I think I'll achieve this by having the user enter text co-ordinates e.g. "124-50B" or a galaxy name e.g. "Butthole World" and using that as a seed. This should add to gameplay by letting people replay the same scenario with a different race and by letting people share their co-ordinates with each other. It also adds the possibility of specialised features that only appear if certain words are used and special authored scenarios with "passwords". Next steps: See screenshots for this update 14th October, 2009:I implemented a basic 3D starmap which uses point sprites with a colour component. It looks like shit but it's a custom shader so I can play with that to get something decent out of it. I might go for a vaguely animated star with extremely high bloom applied to the final composite image of all stars. I implemented an interesting map generation technique in which an image of a galaxy is displayed and the user selects an area of it. A map is then generated based on the pixel values within the selected square of the galaxy image. I'm not sure if this is a good mechanic or not because it doesn't add much to gameplay.To be honest, I think I'm taking entirely the wrong route with this galaxy map. The systems I've seen work have all been simple 2D systems with very little realism. Perhaps just planting stars on a diffuse galaxy background in 2D would work. I have it working in 3D but I'm not sure what that actually brings to the game. A 2D system would be just as good and would make it easier to create an efficient star selection system. Next steps: Low priority: See screenshots for this update 13th October, 2009:I made power production a system-wide resource and added counters for power and food production on the system screen. Although only one colony per system will be able to produce food, it seemed like something people would like to know while on the system screen. Changed housing built and drills built to special icons that are darkened out if not built. Made production and ore storage into system-wide resources too and added info on them to the system screen. Next I hooked up the end turn mechanics for an entire system and made it so you can't go into a colony that isn't yours.I planned to use a kind of simple 2D array to specify what buildings are in what locations for the purposes of efficiently calculating overlaps and finding a building for demolition. Instead, I implemented this system as a more CPU-intensive distance check against all buildings in the colony. The acceptable distance is set based on the size of the biggest building involved. I'll use this to create a demolition system later but for now that's not core functionality. That's the majority of what needs done on these two screens complete. I fixed the water shader colour problem in the previous update but didn't take any screenshots of how it looks now. I've added those in the screenshots for this update. The next stage is the star map. Next steps: Low priority: See screenshots for this update 6th October, 2009:I made it so you can only place a certain number of drills equal to the planet's richness, then made it so drills placed on mineral deposits output 2 per worker and those not placed on them output 1. I did a similar thing with ancient artifacts and labs. To test that I had to implement labs, which like drills are just using placeholder graphics. You can only place one lab and it gives double RP per scientist on ancient artifacts.Next I hooked up the end of turn mechanics for colonies, including growth rates and adding ore to the silos. I made it so that all of the colony screen's lighting is now tinted by the system's star colour. I had to make the effect half strength on tundra worlds as the white textures ended up looking wrong when tinted. I also added the tint to the model clutter on each terrain and fixed some lighting issues with my model clutter shader and the colours not showing up in my water shader. Finallly I added a little indicator of the current and max population on the colony, the number of housings built and the number of drills built. Next steps: Low priority: See screenshots for this update 3rd September, 2009:I created a "return" button to the colony screen so you can go back to the system screen. I then added an "unloader" for colonies that unloads anything that isn't required to be persistent. Some things do have to be left active in memory to remain persistent between visits to a colonised planet. With the debug version the memory footprint looks to be between 8mb and 24mb per planet after I included content unloaders in each class to null everything that doesn't need to stay. I will have to build a save file system at some point to store the information every 10 turns or so and then unload it. Then loading could simply null-check the data and if null try to load it from the latest save game file. For now optimisation is not a priority so long as performance issues don't hinder development and testing.I made a minor change to the growth rate system. Population growth was positive when there's adequate food and negative when there isn't but I found this made the population flit about between the two values and that was undesirable. I made it so +0 food or water leads to 0 growth to prevent this elastic band type effect. I fixed a whole slew of new bugs that popped up with the colony screen when using different infrastructures on the planets. I altered the colony screen so that the mouse position recentres each frame when placing buildings instead of going out of the terrain's rendering area. I converted the random portions of terrain loading into non-random in the most obvious way ever (can't believe I didn't think of it before). I have each terrain block generate its random numbers based on a seed based on the cumulative heights of a few key points on the terrain. Every terrain type but terran loaded within a few seconds, so I looked into the bottleneck and found a hideously inefficient billboard placement algorithm I'd left over from my masters project. It was very inefficient because I had built the engine assuming it would be done only once. I've now rejiggered it and it loads very quickly. Next steps: Low priority: No screenshots for this update 30th September, 2009:Today I made a bunch of cosmetic changes from yesterday's dev list. The planet in the rendertarget at the bottomright is now viewed side-on and the lighting angle has been tweaked to make it look better. I've also removed the glow-map from the planet shader as most planets are uninhabited and won't have one. Previously the shader would sample a separate nighttime (glowmap) and daytime (colourmap) texture, then blend them based on lighting strength at each pixel location. This meant the nighttime parts of the planet had city lights on them, showing that there's a civilisation on the planet. As an added bonus for removing it, planets now have better contrast and the rendertarget version looks awesome with a little atmosphere tinge around the darkened side.I fixed the gap in the orbit circles and made it so the star colour tints the diffuse light that hits planets in its orbit, which has added some more awesome to the planet graphics. I then edited the sun renderer to include the star colour too, which was trickier than I thought it would be. I increased the size of planets slightly so that the sizes are instantly recognisable and the huge ones really do look huge. Of course the planets are completely out of proportion to the star but that's unavoidable. Putting them to scale would make them tiny little specks and that would be terrible for both visuals and gameplay. Clicking on a planet that is a colony now loads that colony and then loads the colony screen. The next step is to add a back button so you can return to the system view. Load times for the colony screen are now a genuine issue, with some types loading in only 1-3 seconds and others taking up to 12. I'll also have to look into using non-random or pseudorandom methods for the placement of terrain clutter so that it doesn't change between visits to a colony but also doesn't have to keep it in memory until it's needed. Next steps: Low priority: See screenshots for this update 29th September, 2009:Added more to the info pane. A bunch more stuff still to do.Next steps: See screenshots for this update 26th September, 2009:I created orbit rings for the planets, which was easier than I thought it would be. I just adapted an old 2D ellipse algorithm I made for a previous project so that it now draws a horizontally aligned circle from a series of calculated points with lines drawn between them. Then I used XNA's BasicEffect shader to transform the line primitives to positions in worldspace. I have planets placed on a random point on the orbit ring when they're created and they move around it each turn with random orbit speed. I found a very fast coordinate point projection method for transforming the world space location of the planets to 2D points in screen-space and used it to determine whether the mouse is over a planet and if so, which planet.On mouseover, the planets light up and info on them is displayed in the pane below. There's just some basic info there now but I'll expand on this to add more info. The planet being mouseovered appears in the bottomleft with the appropriate size and type. This was done by having it simply rendered to a render-target and then drawing the texture from that to the UI. I artificially set the lighting angle for this view to make it look more appealing. Next steps: See screenshots for this update 22nd September, 2009:I felt sorry for the star and planet graphics in the system view so I went in search of some shaders to use with it. Although I didn't meet any of the development goals from yesterday, it does look a lot more awesome now :D. Check out the screenshots for today's update to see what I mean. I'm still not sure if I want to go for a system with the star in the middle and the planets in orbit around it or if I want to keep the current viewpoint. With the more realistic graphics, I think people will expect more realism and not planets all conveniently arranged in a row or in one tiny arc of its orbit path.The sun implementation was adapted from an example I found online by a CS PhD student named Nicolas Menzel. There's a downloadable implementation over at Ziggyware if you're interested in playing around with it yourself. The planet shader was adapted from an example by a guy that goes by the name of "Nemo Krad". There's a downloadable implementation and a tutorial explaining the shader's creation at XNA-UK that's good to play around with. Next steps: See screenshots for this update 21st September, 2009:Created Planet and Star classes to organise the creation of solar systems. Stars are of a specified solar class from the list Red Giant, Red, Orange, Yellow, White, Blue, Bright Blue, Neutron star, black hole. Mineral content and environment is rolled randomly for each planet and then bonuses and penalties are applied based on stellar class. Orange stars, for example, are very well suited to habitable life, poor in minerals, can have up to 5 planetary orbits and has a 60% chance of each of those five orbits being filled. This will be amended later to include distance from the star as a factor using the planet system I described on the "planets" page linked on the left hand side.Since I'm now at the point where I'll have multiple screens, I've integrated an XNA sample on game states and menu selectors into the project and built a simple menu interface. The colony screen has been migrated from the main game class to its own screen in the new screenmanager system. I've moved on to creating the system view screen using simple textured spheres for the planets and star. The larger a planet is, the slower it rotates to help give a sense of scale. Next steps: See screenshots for this update 20th September, 2009:Since graduating from university, I've used the findings from my masters project on terrain rendering to produce two terrain rendering engines - one optimised for a first person viewpoint and one optimised for a real time strategy viewpoint. Over the past month, I've adapted the real time strategy engine into a configurable terrain renderer for the colony screen in my MOO2 clone. The first step was re-configuring the engine's controls, lighting and billboarding. New textures were added based on photos of the ground I took in Iceland and other online resources. I also made a bunch of building models out of parts of free models and textures found online. It's just programmer art but it's good to have them as placeholders.I created a system whereby the terrain's type can be selected from the list Terran, Swamp, Ocean, Tundra, Desert, Barren, Molten and Toxic. I set the engine up to render to a rendertarget, which I then draw on the screen as a texture, allowing me to resize the terrain area of the user interface. I then built a basic user interface around that terrain area and tied it into new classes to store information on the Environment and its Colony. I also implemented a building list system, so I can select any building on the right hand side and build it at the cost of materials from the colony's material store. Buildings have effects as detailed in the "Buildings" page linked on the left hand side. Different Environments have different effects on geothermal and solar power production, what buildings are needed for housing and what buildings are needed for obtaining water. Racial differences also cause differences in the environments that can be colonised, what types of housing are required there and food production. The colony/outpost system and their corresponding infrastructure upgrades have also been implemented, as described on the colonies and outposts page. See screenshots for this update |