nukomod

Members
  • Content count

    25
  • Joined

  • Last visited

Community Reputation

598 Good

About nukomod

  • Rank
    Member
  1. Resuming Work

    I'd taken a break on this project as something really interesting had come up at work and I was quite enthusiastic to spend my time on that. Sadly that didn't work out due to reasons beyond our control, so I'm resuming work on this project with more of my free time. As I've not worked on this since November a few things are rusty in my mind and I can't quite recall what my plans were for everything! That was the point of this blog to help me have my thoughts written down so I'm back here writing entries as I go :) I'm picking up the actual generation code again so my next post will be talking about procedurally generating lamp posts. You'll see!
  2. A good while ago I stumbled across this video on youtube about a theory that the earth grew in size and the tectonic plates 'float' on top of this expanding sphere. [media][/media] Now despite this being somewhat scientifically questionable it did get me thinking that it might be fun to model a procedurally generated world using this technique. Typical procedural generation techniques using perlin noise or similar often lead to quite random looking continents: (Apologies if these are your images and you don't like me referencing them!) This approach can get good results, but it's easy to just get noisy terrains. Leveraging the 'expanding' earth idea I'm going to build a model for fun where a verlet cloth sits on an expanding sphere. The cloth will become the terrain of the planet and I'll see if I can get it to 'rip' in nice ways as the sphere expands. One approach I'll try is to randomly assign each of the points on the cloth parameters such as mass or friction, and randomly assign the strength the links have to adjacent points. When the stress on the links reaches a critical point they can 'rip' free. The remaining cloth can be considered land and the rest sea. Another approach could be to 'inject' cloth into the stress points as the sphere grows, and allow the cloth to exist with a height on top of the sphere, allowing wrinkles as material builds up. Then a sea level can be chosen and the coast lines would be a result of that. I think it's an interesting idea, I'll post pictures of any results I may come up with. If nothing else perhaps it will give others a new idea to play with too
  3. Argh, bitrot.

    It's twisted enjoying another mans debugging pain but I admit I did! I guess I love a good mystery, but it's even better when it gets solved. Please let us know how the next debugging session goes!
  4. Brain dump: considerations for organizing code

    Have you seen code bubbles? http://www.andrewbragdon.com/codebubbles_site.asp I think their approach may be of interest to you.
  5. Big Procedural Game Dev

    Pictures marking the development of my 'Big Procedural Game' :)
  6. Geodesic Spheres

    From the album Big Procedural Game Dev

  7. This time I'm giving an update on the status of the code itself. It's still early days but at the moment I've been working on mesh generation helper code. The first mesh generation function I have working is for geodesic spheres, a cool piece of geometry! It's built from an icosahedron as the base which then has each triangle tessellated to the level of required detail. Each new vertex is then projected back on to the surface of the sphere to complete the job. I'm not generating UV coordinates yet, just normals. There are lots of uses for these guys and they have the cool property of evenly distributing surface area across the faces. [sharedmedia=gallery:images:5534] The process of creating and rendering this mesh is proving out the renderer and scenegraph behind the scenes which is cool. It's also using my framework for generating and storing meshes. I want this process to be asynchronous in the near future. I'll go into more detail on future posts, but I don't think it's anything particularly new or exciting.
  8. Dynamic Narrative in The Hit

    Great overview. I'm working on something similar myself buy you've clearly taken it further. I hope you'll write more articles in the future showing some more the technical details. Hope all goes well with your project!
  9. Scripting languages can be a can of worms. I want to make sure I open that can for the right reasons! I want the code that does any heavy lifting of the generation to be in C++ for performance reasons (and debugging!). I also want the generation steps of objects to have rapid iteration in a forgiving environment, as in without hitting asserts or crashes. My game framework allows this to potentially be in C++ as it supports reloading DLLs on the fly so generation logic could be in DLLs, but it's not what I'd call 'rapid' iteration. Other approaches are runtime CPP compilation, JIT (C#) or byte code scripting language. I'm going to try to not tie myself down to one particular approach if I can help it. Easier said than done though. I'll probably start with a simple game targeted scripting language such as GameMonkey or Angel Script. Also aside from scripting the generation having a scripting language hooked up to your engine makes auto testing easier. Having good tests is going to be a life saver in the long run. I'll put down some sketches of how I imagine the generation process for objects will work and how scripting will help in the near future, with some examples.
  10. To make a universe more than just a static diorama things have to change. Time should have an effect, so planets spin and the sun can rise, but more importantly the players actions should have an effect. If the player gets their hands on a planet destroying super weapon it would be very unsatisfying if they destroy a world to find it magically reappear when they reload, or even just visit the next solar system and come back. These changes need to be saved permanently to the players save data. I'm planning for save data to be like a patch that is applied over the top of the procedurally generated data. So if you kill someone when it comes to generate their info when it's finished it will stamp 'dead' over the top of their status. It will maybe go on to generate different things off the back of this, maybe give them a grave or something. A planet will be patched with 'exploded' and perhaps an asteroid field will get generated. This approach will require that the generation algorithms be exactly the same as when the patch data was created. So save games will not survive updates to the game that change these. They will need to be bound to a release version and people should complete their adventures before upgrading, if they want. Not sure if there's an elegant way around that.
  11. Having a big universe to play in is going to require some thought into how to locate things. The Milky Way is 120kly (ish) according to Wikipedia. That's kilo-light years. That sounds big! Ok lets say I want to positiom things with millimetre accuracy. A light year is 9.4605284 x 10^18 millimetres (thanks Google!) So the milky way is approx 1.13526341 x 10^24 millimetres across. 1135263410000000000000000 mm. How many bytes are needed to store a number that big? My calculations put this at 10 bytes. That's a nice chunky number. If we want multiple galaxies or more accuracy we need more bytes too. I'd probably round this up to a lovely 12 bytes. So I have a super number which can store galaxies to mm precision, except its too big to fit in CPU registers and so all math is horribly complicated and slow. No thanks! For a game to have a chance of managing this I need to keep the coordinates in a useful form. There are a few solutions to this problem and I'll outline the one I'm going to try first. I'm going to keep rendering and physics working in lovely floating point numbers. The main reason is that everything is simple when using these, though they lose accuracy pretty quickly. To deal with this I'm going to have reference points evenly distributed across the universe, creating a classic nested coordinate system. All floating point numbers will be local to one of these reference points. These reference points will have a volume of space defined around them so they overlap the next reference point by 50%. When you move far enough from your ref point the game will switch which point you're anchored too. I need to be careful that these switches dont introduce too much error or performance penalty. An objects coordinates will be split into a local space floating point position and a reference point ID. The reference points may also need to be put within a nested coordinate space to get extra space, and that can be repeated as many times as necessary. I'm considering only allowing interactions between objects living in the same reference point, as it will simplify things. We'll see how that plays out. Finally from a gameplay point of view I'm planning to allow the scale of the generated universe be controllable. I doubt very much that a real size scale for most things will be the default setting. I don't want people dying of old age travelling. I'll aim to reduce how much boring space there is between interesting things without breaking the illusion. This applies to many things, not just the distance between planets. The distance between cities or continents or any feature of interest. Sure people can have 1:1 if they want though! I suspect that space travel will still need FTL drives, stasis pods or wormholes to get around and not die of boredom!
  12. The narrative generation will work within high level constraints placed by the player. Or the Plyer can leave it to be entirely random. The UI for this will be a page of simple sliders for the highest level of story control, but clicking through into the advanced settings will reveal many ways the player can customise the experience. Example settings: (not including standard world generation options) - Approximate narrative duration.. 30mins, 4 hours, 1 month, ongoing etc. - Force include characters - with character designer. - Force include species. - Force include locations. - Force include plot arc. - Difficulty preference. - Action level. - Mystery level. - Comedy level. - Drama level. - Narrative scope.. Right word? Whether its one town or whole universe. The system will work on several layers. On the top is the Narrative Director. It's the only thing that knows the whole story and the intended ending. It's job is to try to keep the story on track and provide the desired levels of suspense or action etc. Ideally it will do this without affecting a character directly.. It would be easy to let it dabble in the mind of a character but I want it to affect them indirectly. This is because I want to keep the integrity of the characters actions intact. If it wants a character to attack the player they should have a reason provided rather than do it mindlessly. A mercenary is paid, for example, while in a more elaborate scenario the Director could arrange a situation to make a character hate the player. Perhaps the character is lied to or sees the player doing something that incites hate. The director arranges these scenarios. The characters have their own AI brains. They have their own knowledge of the world and other characters (which may be wrong). They have their own goals to achieve. Different characters require different kinds of brains. Animals are simple compared to people. To keep things sane a random person in the crowd may run a very simple crowd brain until they interact with the player in a way that requires them to 'upgrade'.Also different characters will run at different speeds. The story plan is built up by searching a state graph. Nodes are states of the story and edges are actions that can be taken. This is an expensive approach, but I think conceptually simple. It should give me a system that works well, if slowly, and I can improve and optimise it in time. Heuristics will be employed to trim down the possible actions needing to be searched. Exactly how these will work will be fun figuring out :) The human player will also get a character. This will try to guess the players mental state and relationship to other characters through their actions. It will then use this proxy in the system like any other character. In theory the plater could let their proxy take over and they will continue to play the game in the same way. These AI approaches are very expensive. I'll be using level of detail in the system and running things asynchronously to keep things going. OK that's all for now. This post has mostly been me writing down my thoughts. I'll go into more detail on each part mentioned here as I approach implementation :)
  13. Languages

    This time I going to talk a little about my early plans on incorporating languages into the game. I want all the text you encounter in the game to mean something, even if it is in a made up alien language. To do this I'm going to generate (somewhat) meaningful sentences that are converted to the alien language. I'm thinking that simply using a generated font may be enough and it allows the player the chance to 'learn' an alien language by recognising which symbols mean which letters. I could take this further though. But having it all make sense underneath allows me to have universal translators or even subtitles on what you're trying to read :) Though I don't think subtitles work well on HMD. Perhaps something more like Word Lens would be cool. With generating English I think I can pull this off to a hopefully acceptable level but I doubt I'll be able to do the same for other languageslanguages as I just don't know others well enough and the rules for building sentences can be quite involved. My best hope would be to generate in English and then run the result through a translation Api like Google translate.. and keep my fingers crossed! No doubt the results will be hilarious... :p