About this blog
A phase I'm going through
Entries in this blog
A bit dizzy after all those back-flips
Okay, so I know that in my last entry I was talking about using layers of quad-trees to make 3D terrain, but I ended up scrapping that idea and going back to a simple 3D grid. The grid is a bit recursive to save some storage space on completely empty or completely solid areas, but otherwise there isn't anything special about it.
As input into this grid, I'm firing up something I used in a previous (never completed) project: the Diamond-Square algorithm. This will allow me to have fairly detailed-looking terrain without having to spend heaps of time messing with heightmaps or loading large bitmaps from disk. Here's the initial results from shoehorning the algorithm into my project (I apologise for the quality of these images, this will be the last time I use jpeg in my journal, I promise!):
Firstly, a simple test (all series of images are before tesselation, then after)
Here's a random heightfield, tesselated using a standard rough material type:
And lastly, another random heightfield, tesselated using a rough material with the "plateauing" erosion feature turned on:
I'm still tinkering around with these material settings. I'll probably try and explain them a bit better in the updates to come.
And I'm gone...
Just a quick update on what I've been up to. I'm working on some stuff with regards to my game maps. The current implementation is to have a 3D map made up of "slices" of terrain. Each horizontal slice is a quad-tree of materials (rock, dirt, air, water, etc) which will be used to produce surfaces for drawing. Only the boundaries between gaseous/liquid/solid materials will be drawn.
Below is the first "Hello World" for this concept. It is just a wireframe rendering of the quad-tree for a single slice, which is mainly air and a single circle of some solid material.
Very simple at the moment, but I hope to build it into something more impressive soon.
Okay, so I've been building up a lot of boiler-plate engine code and shoe-horning in the latest SlimDX release. I figured it was time to finally put something on the screen, so here is my first offering to the screen-shot gods:
'So what is this wall of green and tan pixels?', you might well ask. Well, this is mainly a test for the isometric camera that I'll be using in this project. It uses an orthographic projection and can be rotated around the Y axis around the look-at point (which can be translated to where-ever you wish to view). What you're seeing is just a randomly generated height-field full of columns for making sure that the perspective looks okay. The app also rotates the camera to make sure that looks fine too.
Next.... something! I'll probably work on the map format and getting textures onto that sucker.
P.S. Contrary to what this screenshot suggests, the desired result will not use Final Fantasy Tactics-style maps. I'll be looking to use regular height-fields with buildings/forests/etc.
Yay for posting about others' blog posts
I have definitely reached a new low. [grin]
So here's a couple of things I read recently which I found interesting. Firstly, care of "Tales Of the Rampant Coyote" we have "The Top 6 Reasons to Support Indie RPGs". I think you could apply these to all indie games, but nonetheless I think his observations are spot-on.
Secondly, here's another entry into the "Why do people pirate games" discussion. In this case, he's asking why people pirate his games, but again, it seems like the responses were more about game piracy in general.
Personally, I still see these reasons as just excuses for what is essentially theft (and that's with the full admission that I used to engage in game piracy in my youth), but I am steadily being persuaded that this attitude is an unproductive one when considering the question: "How do we convince pirates to purchase games legitimately?"
Something tells me I've done this before...
I've been doing a bit of work on my new project. Some of this is stuff I feel like I redo for any new project (output and error-logging stuff). After this project I think I'll have it at a point where I'm happy to just plug it into future projects without having to re-implement too much. Some other stuff I have been able to re-use like this sprite-sheet editor that I wrote back in 2007.
I've also implemented the beginnings of a resource-management module (similar to what is described in "Game Coding Complete" that I mentioned in my last post). The module is a generalised method of loading various game-assets from one or more zip archives (when the engine says it needs them) and passing them through to where they are needed. Currently the only asset types it supports are textures and their (optional) attached sprite-sheet (which specify the coordinates for any sprites and animations in the image), but obviously there'll be many other entries for things like map levels, sounds, save-files, etc. I had to modify the sprite-sheet classes to allow loading and saving to arbitrary streams as the resource-manager loads from the zips into memory buffers.
The most recent addition is that I'm all setup with an interface into SlimDX and I'm ready to start on map definitions and stringing together some renderable-stuff. I guess I'll leak some more info on the actual project as things shape up.
P.S. THX 4 TEH 30K HITS!!!1one
Just passing through. Work has been keeping me pretty snowed-under and unmotivated in the past 3 weeks. Today should be the last day of that situation though. [smile]
Also, I've been reading through "Game Coding Complete", 3rd Ed, as reviewed by John Hattan. It has been a really great read so far. As someone who has been a hobbyist game-dever for at least a decade, I'm finding this to be a really great book for seeing how "the big guys" build their game engines. I've already sponged-up lots of ideas and inspiration for how to make better and easier to maintain core systems within my game engines and I've only just got up to part 3 of the book (maybe 1/3 of the way through). The range of experience has been kinda limited to his personal career so far, but overall I've found the info and advice he's given to make a lot of sense and should be really handy for my future exploits. This really isn't a beginner's book for programming newbies, but a "this is how we do it" book for anyone interested in how the pros work. Anyway, two thumbs up from me. [grin]
With any luck I'll be back with some dev stuff in the weeks to come.
Woah, *cough* there's a lot of cobwebs in here...
May. MAY! May is when I last posted in this journal (hey, at least I'm posting before I also have to state the year). That's quite a while between drinks. What's been going on? Well, obviously not a lot on the gamedev front. My first child was born (in May, coincidence? No.) which has been sucking up most of my time. I'm not complaining, mind you. My daughter is awesome and worth every moment spent.
Gamedev is something I still enjoy and want to pursue though and I'm getting to the point where motivation is building back up, my time-management has adjusted and the little-one's sleeping patterns are much more regular. So yeah, its about time that I get back into it. With work and family duties, that basically means that something (or things) have to suffer in order for that to flourish. Looking at my choices, that will have to either be TV watching or games that take a long time per play ("casual" games should be fine as long as they stay casual). This is another adjustment, but I'm reaching that point where I'm ready to make it.
So yeah. Nothing much to talk about in terms of dev progress. I have a project on the boil atm, but it is very early stages and I think I'll wait until I have a few more things working before I elaborate on it.
Why would you want to???
So as a pitiful alternative offering to the gods of gamedev progress, I offer this somewhat depressing rant on why one should not enter the gamedev industry. I found it to be an interesting read and I think he is right on the money for many of his points. For me, many of these (among others) are reasons why I would prefer not to work for a commercial gamedev company. Personally, I think if the passion for creating games is high enough, one should still give it a go as you're often better off working on something you enjoy doing (in terms of job satisfaction, motivation, etc). What do you guys think?
Damn you HOMM!
Work continues on some of the basic RPG engine infrastructure. Still nothing to see at this point.
So, recently I was doing some research on strategy games. I try to improve my knowledge of some of the more "classic" games as I find they often contain deeper and more impressive gameplay elements than their more recent colleagues. In the process I stumbled across Heroes of Might and Magic. Its kinda embarrassing that I've never played any of the series in my 20+ year gaming history. In fact, teh interwebs are only now illuminating to me the fact that I pretty much managed to avoid the vast majority of good titles throughout my youth! Ahh, if only there had been forums when I was a teenager (well, something more advanced than BBS forums anyway).
Anyway, after reading up on the HOMM series it would appear that several of what I considered to be "innovations" in my project have actually already been done in those games! My initial reaction was to be pretty annoyed with this discovery, but that subsided pretty quickly for a few reasons. For starters, at least it shows that these mechanics do work and can result in a fun game experience. Secondly, while several mechanics from my game have already been used in that series, what I have planned should still be considerably different and stand in its own light (or at least I hope it will). Thirdly, seeing how they did things and the responses from reviewers and gamers will be a great resource for refining my own vision on the basis of solid usability results.
So yeah, a bit annoying, but not that bad after all. Certainly, one of my goals will be to have my title stand out on its own and not be something that people would call "that HOMM clone". If I get some time over the coming months, I may even purchase the latest instalment and have a go to see how it plays.
"The rumors of my death have been greatly exaggerated"
- Mark Twain
Okay, so I haven't been at all active in the gamedev scene in a while now. Lurking on the forums has been roughly the extent of my online presence. Development has been next to non-existent too. Lots of RL stuff have been subtracting from my time, as well as a wretched Travian habit (no I'm not going to link to it, I wouldn't want the guilt of possibly starting someone else on that miserable treadmill). There's still lots of RL stuff around, I'm expecting to become a father sometime in the next 5 weeks. As that's a pretty much a 20-year (if not more) time subtracter, I figure I'm never going to have much more time for game development than I do now (that said, I expect to get nothing done in the first 2 weeks after the birth).
So yeah. I left gamedev, but as usual, gamedev has haunted me like some sort of pale-faced CGI kid in one of those cheap-scare movies. It occupies my thoughts and won't let me go. So I've got another project started up. I'm not going to elaborate too much at this point, but it is a concept that I've been polishing in the dark recesses of my mind since a while before I even left the scene. The genre that would best describe it is strategy/RPG, or maybe tactical/RPG.
What I choose to elaborate on a bit in this entry is the basic attributes that characters will have. Most of these are pretty standard RPG fare, except that I have chosen to use 4 mental attributes. These are based on the Herrmann Brain Dominance Instrument which I encountered in my workplace (mainly as a team-building and informational exercise). Yes, I know that the scores given in HBDI are measures of preferred (or dominant) thinking styles, but I have chosen them to also be used as a measure of a character's performance in these areas. I've always felt that the simple attribute of "intelligence" (with possibly also "wisdom" tacked on) could be fleshed out to give a much better representation of "how" a character thinks, not just how "intelligent" they are. So without any further waffle, here's my set of primary character attributes (that will be used in character creation/NPCs/etc):
1) Agility (quickness, nimbleness) - Pretty self explanatory. In theory, particularly agile characters could perform acrobatics, run faster, be a pretty darn good dancer, dodge more effectively, etc. Basically a license to be someone out of a Matrix movie. Characters with poor agility would move more clumsily, be more likely to trip over things, have next to no chance to dodge things, etc.
2) Dexterity (touch, deftness, sleight of hand) - Yes, I differentiate between dexterity and agility in my system. You could think of dexterity as agility for the arms/hands. Particularly dexterous characters would be effective at picking pockets, picking locks, striking accurately with a hand-held weapon, firing a projectile weapon, hand-to-hand-combat, fine craftsmanship, etc. A character with poor dexterity might have difficulty parrying with a hand-held weapon, be more likely to fumble or drop things, etc.
3) Strength (brawn, power) - Yep, it had to be there. A character with high physical strength will gain bonus damage with particular weapons, be able to carry heavier items, wear heavier armour, etc. Prepare to channel your favourite muscle-bound barbarian. Physically weak characters won't be able to carry much, are more likely to drop their weapon or be unable to block a strong blow in melee combat, can't wear the beefy armour and have a higher chance of having sand kicked in their faces by jocks at the beach.
4) Toughness (endurance, mettle) - again, separate from strength. This defines how resistant the character is to a pummelling, how resistant they are to thinks like disease, poison, etc. How long they can run around before getting puffed and needing a bit of a lie-down (Ie their stamina). A stereotypically tough character would be a dwarf. These buggers seem to be able to take a lickin' and keep on kickin'.
5) Perception (awareness, sensitivity of senses) - basically how sharp a character's senses are. A particularly perceptive character would have a better chance of picking out someone hiding in the shadows, or hearing (and identifying) noises in an adjacent room. Perceptive characters could pick out and and identify enemies at a further distance and will have better initiative in confrontations. Perception (in combination with dexterity) determines a character's hand-eye coordination and so is important for any characters that wish to be able to put an arrow through the eye of some unfortunate target at a distance. Characters with low perception would be unlikely to notice someone sneaking up on them, would be next to useless with a bow or crossbow, are unlikely to notice that shiny bauble poking out from amongst the refuse.
6) Analytical (logical, technical, Problem-Solving) - How proficient the character is in this mode of thinking. A character with good technical problem-solving skills would be more likely to be able to pick a complicated lock, detect when someone was trying to put one over them, understand complex mechanisms or spells, work out a logical response to a problem at hand, find the right spot to attack in order to quickly kill or incapacitate a foe, etc. Proficiency in analytical thought would be advantageous to magic users, characters who wish to make use of speech-skills, leaders, any who wish to create or subvert complex mechanisms or anyone who needs to "think on their feet". A character with particularly poor analytical skills might have difficulty with tasks such as bartering, holding a logical argument, any sort of spell-craft or critical thought.
7) Organisational (controlled, systematic, sequential thinking) - How well a character can follow directions, manage their time, work out fine details, be prepared for possible scenarios. A proficient character would always seem to have the right tool at hand, be more efficient at carrying out orders, organising and disciplining others to follow orders, be able to string multiple actions together quickly (with the appropriate previous preparation) in order to accomplish goals more quickly than others. Highly proficient characters would be excellent at logistics, better architects, manage an agreeable group of characters more efficiently, better at managing their inventories, less likely to get confused or indecisive under pressure and better at handling multiple foes in combat. A character with a low score in this attribute would take longer to follow orders, be more likely to panic or behave erratically in high-pressure situations, be more likely to forget orders, be more likely to focus on one aspect of a problem while not giving enough consideration to others.
8) Interpersonal (emotional/musical/spiritual/speech) - How comfortable a character is with listening to or express ideas, understanding and manipulating group interplay, finding personal meaning (for self or others), etc. A character with high interpersonal abilities is better able to convince others of their point of view, is better able to understand and interpret the ideas and motivations of others, is more likely to be musically gifted, is more likely to be able to "read" an opponents' moves (and thus better at defending or countering them). A character with poor interpersonal skills will find convincing others of their opinions difficult, will be less in control of their emotions (more likely to get angry/frustrated/frightened/etc), be more vulnerable to taunts and have little influence over groups of people. Interpersonal skills will be useful in any conversations (getting one's way in regular conversations, being able to lie convincingly, being able to sooth or empathise, being humorous, giving weight to an argument), in leading groups, in using various mind-altering spells or resisting them.
9) Creative (Artistic/Imaginative/Holistic/Conceptual) - A creative thinker is more likely to take initiative, think unconventionally, solve problems in a creative way, think in terms of the "big picture", be visually-oriented. A creative character will often be the first into the fray, will often surprise their foes with their unconventional approach, would craft unusual and visually appealing works, be more likely to add their own personal touch or modifications to spells, have an advantage in such activities as lying, disguise, etc. Characters with a low creativity score would be predictable to others, would seem "uninteresting" to others, would seem more reserved.
Many of these characteristics might seem inappropriate in a traditional RPG. One might ask themselves: "why would I care if my character can time manage, or be good at finding personal meaning? I just want DPS!!!". Well, to keep things simple, I'll just say that the player's avatar will not be the only character under their control (although they will be the most important). The game will focus on controlling several parties of characters and using the right "man" (or dwarf/elf/whatever or combination of characters) for the job at hand. I'm anticipating there being a need for not only fighters, healers, archers, thieves, etc, but also spies, craftsmen, architects, diplomats, administrators and others. The player would not be required to micromanage these to any degree, and I'll be looking to have systems in place to make choosing that right "man" much easier than wading through pages of character stats.
Back in 5
Apologies for no updates in a while. Been busy with apartment purchase stress. [depressed]
Gettin' kinda shady
I've been muddlin' around about including support for compiled HLSL shaders and different drawing pipelines in my game. Originally I had what I thought was a pretty cool method of supporting different shaders without having to worry about which shaders required what parameters, etc. I'd have a standard set of parameters that my game could supply (transformation matrices, lighting details, textures, etc) and after I'd accumulated all the draw calls for a shader, it would query the shader for what parameters it requires and set as necessary.
This sounded like it would be quite flexible and cool. Then I realised that it would violate my new matra for game dev: "Keep it simple, stupid". While I would allow the game concept to be moderately complicated and the features it implements could have some complexity, I wanted there to be as few "uber-flexible-and-shiny" subsystems as possible. The temptation for me is usually to make a subsystem as general as possible so that I can "use it again next time". The problem is, this usually ends with me spending weeks or months on just implementing this one subsystem and the project as a whole suffers.
So the compromise ended up being that I'll still have a big blob of graphical state data that my shaders can grab their parameters from, but instead of one monstrous generalized "shader handler" class, I'll just have individual classes for each shader I'll use. These classes subclass from a shader superclass that defines some common functionality, but they each define their own drawing function so they can grab whatever parameters they need, set whatever states, etc.
I'm pretty happy with that so far. It's not terribly scale-able though. If I had tonnes of artists using many shaders, this might be a problem. However, since I'm a one-man-team and I won't be doing anything too revolutionary in the shader department, I hope it'll work okay.
Still been progressing steadily with my new project. The diamond-square code seems to be working fine. I've got my editor shell app up and ready to start plugging in editory goodness. Getting re-aquainted with XNA took a little bit of head-scratching. Especially since I forgot that they switched back to a right-handedness-only coordinate system. I was used to left-handedness, so it took me a bit to realize what was going on. The other hitch was that one of my dev machines uses a crappy onboard graphics processor. It's fairly new, but still crappy, so it won't draw batches of primitives over some magical number. It works fine on my laptop (which has a decent GPU) though.
So after muddling around, here's what I currently have to show for it:
FYI: its 5 x 5 random heights, subdivided using the diamond square algorithm 4 times. It's got "some stock texture" applied to it and just default XNA BasicEffect directional lighting with specular applied.
What I'll generally be looking to do is have the initial seed heights set by the level designer (in order to define the rough layout of the map), then have the algorithm subdivide that heightmap to the desired level of detail. As I'm keeping this simple (and the terrain will pretty much always be viewed from roughly the same viewing angle and distance), there won't be a need for any LOD.
The level designer will define the dimensions of the level, set the values for the seeds (height, roughness, texture for multitexturing, etc) and then the algo should spit out a nice level to use.
XNA In Windows Forms
So, anyone who's read my previous journal entries would know that one of my pet gripes with XNA was getting it to work in Windows Forms. The standard XNA Game class wants to create and manage its own windows and doesn't cooperate with controls and stuff. However, I found a nice little tutorial on how to create an XNA control that you can slot into your Windows Forms apps here. This is pretty much the "Microsoft Approved" way of doing XNA in forms and has support for device resets, windows resizing, multiple target render controls and all that junk. Joy [smile].
So I've ported my DiamondSquare code to the new project and slimmed it down a bit to be more of a component than the entire basis of a level. So now that I have XNA 2.0 working in windows forms, I'll be getting some nice heightmaps displaying in the form and start working on an interface for an editor.
Edit: Okay, got off my arse and switched to a non-Christmas avatar.
So I've been plugging in some infrastructure for asset management, etc. In the process, I've improved on my old method of action/error logging. Along with various other customizations (recording various parameters and messages with errors), I wanted to be able to display a message box upon closing the app if there were errors recorded during the run. Also, if a fatal error was encountered, I wanted the app to exit straight away, but cleanly (Ie cleaning everything up and closing without exception boxes, etc).
For the exiting on fatal error business, I just have the app check (in the update() function) for a "isFatal" flag in my error logging class and call the this.Exit() function. Easy.
As for showing message boxes upon closing, that was a little trickier. It appears that any message boxes you create when the XNA app is closing don't get shown as the main window is disappearing. After looking around on the net a bit, I found the following solution. You spawn a seperate thread just for displaying the message boxes. Seems like a bit of overkill, but it works, and since the app is just closing anyway, there's no performance issue.
I created an exiting delegate to be called on closing the XNA game class:
this.Exiting += new EventHandler(Demo_Exiting);
Then I create the seperate thread if there are error messages to show in the delegate:
void Demo_Exiting(object sender, EventArgs e)
ThreadStart errorMsg = delegate
MessageBox.Show(OutputLog.fatalErrorMessage, "Fatal Error", MessageBoxButtons.OK,
string errorsReport = "Errors were reported.\n";
errorsReport += "Maximum error level was MINOR.\n";
errorsReport += "Maximum error level was MAJOR (not fatal).\n";
errorsReport += "Maximum error level was FATAL!.\n";
errorsReport += "See file errors.log for details.";
MessageBox.Show(errorsReport, "Errors reported", MessageBoxButtons.OK,
Thread thread = new Thread(errorMsg);
thread.IsBackground = false;
This works like a treat so now it reminds you if there were non-fatal errors encountered upon closing:
And you get some indication as to what happened if a fatal error as encountered, rather than just rudely dumping you out:
Wow, it's been ages since I posted here. I'd be in line for an epic fail if I didn't post *something* before I switch back from my Christmas avatar. I went pretty off-track (development-wise) during the Christmas/New Year break. Got a Wii and have been playing that off-and-on. Ppl love playing the Wii-sports and more than one of my friends (mainly non-game-geek types) expressed an interest in getting the system just for that game. I'm pretty impressed with the system as a whole. Not top of the line graphics capabilities, but that was never the be-all for me anyway. Mario Galaxy has been wowing me the most. It's the whole package (actually, some sort of multiplayer support would have made it perfect, but you can't have everything).
Okay, so on to the real purpose of this journal. So I'm back into some dev again. Restarting my last project in XNA2. This is only okay in my minds as I wasn't very far on the project anyway. While I haven't been doing any coding during my time away, I've been doing plenty of planning and refining ideas for the project. I'm not going to elaborate until things are a bit further along. At the moment I'm just working on some of my standard infrastructure (asset/scene management, etc). Then it'll be onto prototyping some of the concepts for the game.
That's all for now. Not much to report, but it does feel good to be BACK. [grin]
Back on track soon! I promise!
So yeah, my entries here have been sporadic at best lately [depressed]. House-hunting and Dawn Of War have been taking up a lot of my time. Unfortunately I don't have a house to show for it yet [sad].
However, there is hope in sight! My wife will be going on a 4 week holiday with her sisters, which will mean there's not much point in doing much house-hunting. Also, volleyball and soccer will be finished for the year. Work is likely to be quiet-as for the duration also. In short, I'm going to have a huge block of free time to get some dev done. This will be quite a test of my motivation and while I don't want to put too much pressure of myself, I'm hoping to get a fair bit done. The crunch-period doesn't start until mid December so be sure that my posts will be much more frequent around then.
Resolving the API woes
As you would see if you look at my previous post, I'd been having some difficulties choosing a graphics API that would give me .Net 2.0 and WinForms compatibility. Well, the XNA 2.0 Beta came out and I went to peruse. One of the major features I was looking forward to was WinForms compatibility and I was shocked to find it wasn't going to happen for this release! I'm still pretty annoyed as I'm sure this is a major issue for other developers as well. So anyway, it looks like I'm just going to have to knuckle-down and use the hack-ish method. Basically I just have to abandon the Game class and create the devices & stuff myself. Not pretty, but it'll have to do.
Okay, I'm not going to waste MUCH of your time. [wink]
Still pretty busy with house-hunting/other stuff. I've been fiddling around with my engine, but I've been running into some memory-corruption issues in SlimDX. Considering waiting 'till XNA 2.0 is released (pleeeeeeeeeeeease be early November!) and slotting the engine code into that. Luckily this wouldn't be too big a modification as the engine is nicely packaged as a seperate DLL and a minimum of changes would need to be made to the rendering code to port it across. It's annoying to be jumping between APIs so much, but I guess I have to make these sort of decisions early on in the project. My current thoughts are to use XNA for graphics and possibly input and open-source libraries for sound + networking (OpenAL + RakNet?). I'm not looking to distribute it on the 360.
On a side note, I thought I'd mention that today's IOTD was quite inspiring to see. I especially like the sense of scale in the "wide" shot. Seeing this sort of thing from indies inspires me to get back to coding. [smile]
Time for a boring filler entry.
I'm not a big fan of posting whenever the wind changes, but I haven't posted in a while and thought I should update the millions of adoring fans whose livelihoods depend on my every word.
Not much dev work going on at the moment. I've been doing a little bit of experimenting with SlimDX. Mainly I've been busy with RL stuff. Looking to buy a first house/apartment.
Okay, you can commence holding your breath again. [wink]
Playing with the random values.
Okay, so I didn't get onto displaying the heightmap in a 3d view yet. I've been messing around with my class structure and the random offset generator I use for the height displacements. Mainly this is because I realized that I haven't set it out very well for generating portions of the map at a time. My ideal is to be able to generate the top few subdivisions at map-load and be able to "page" in higher-detail sections for when the player zooms in on particular spots.
I wasn't particularly happy with the method I was using for the random displacements. What I have now I feel is much better. Before I was working with a hard-coded height offset that would be multiplied by a dampening weight on each subdivision iteration. I found this to be too fiddly, so I came up with a much simpler setting. The algo I'm using for setting the midpoint height is:
1) Get average (A) of surrounding height values (shape depends on whether we're in the diamond or the square step of the algo).
2) Get maximum difference (D) between the average and the surrounding height values.
3) Get pseudo-random number (P) between -1.0 and 1.0 for the heightmap coordinate.
4) Height value = A + (D * P * R) where R is a "roughness" constant.
Different values of R give (you guessed it) varying degrees of roughness to the terrain. I could use a particular constant for an entire map, but I also plan on allowing the user to set the constant on a per-seed-cell basis (so you can make some spots on the map rougher and some smoother). Here is the output of 3 iterations, using different values for R:
R = 0.4F
R = 0.6F
R = 0.8F
R = 1.0F
R = 1.5F
Okay, so as I mentioned previously, I'm using the diamond-square algorithm (similar to "midpoint displacement") to generate the terrain heightfield. Instead of starting with a single square and subdividing as needed, I start with a "seed" field of whatever dimensions I desire. I then perform diamond-square as many times as needed to get the desired level of detail. Currently I just have the seed field being randomly-generated, but what I plan to do is allow the user of my editor to set those heights so they can have control over the rough layout of the map. If further control is needed, they can edit some of the values further down the iteration chain. Here's a pic of one three-iteration run (the seed values are iterated three times):
Here I started with 20 x 20 cells (21 x 21 height values) and finished with 160 x 160. Note that the map does not need to be square in shape. The amplitude and falloff of amplitude of the random values can be set by the user. I can imagine that I'll be doing lots of tweaking these values to get the desired result.
Next on the list is to generate and display the heightfield in 3D. Shouldn't be too difficult. SlimDX has been quite nice to use so far, btw. [smile]
At the snow.
Yep, went down to the snowies for a long weekend, so I didn't get much dev-related done. I'm currently working on terrain stuff for my RTS engine. Using user-seeded diamond-square for the heightmap. I'll write some more about it when I have some more to show.
So I've been adding more functionality to my asset database application. Instead of manually adding assets, it now automatically scans the relevant directories and updates itself as needed. As I stated in my previous post, assets are only referred-to by their local filenames (Eg "Textures\Tiles\grass004.jpg"), so it doesn't matter if I add or delete textures, the application automatically adjusts. These names are only resolved to indeces into the texture array on game-engine startup.
I've been pondering a little more about the editor for this game. I'll be working on it again soon, but I'm swiftly realizing how annoying it will be to continue using XNA in a windows form. Currently it works, but you have to do a few crude and un-natural things to your app to get it to work. One of the annoying side-effects is that you have to be designing your form and then copying the modified code into the "real" form code as XNA doesn't play ball with the regular windows-form code. After working on my SpriteSheet and AssetDatabase editors, I've realized that this can involve much tweaking and adjusting of things in the forms designer to get them the way you like. The amount of time spent copying and pasting designer code would really add up (especially if the code modifications weren't easy to identify).
So I've been contemplating my options. My little break into Windows Forms apps seems to be well-timed because there's a few alternatives that are just surfacing:
I'm not too happy with the idea of using something which has basically been discontinued, but I'm not looking to be on the "bleeding edge" for this project and people still seem to be using it successfully. However, swiftly reaching maturity is:
Promit & gang have been putting in a fine effort to push this into the status of "viable alternative". Obviously as an indie library, there'll always be concerns about support and bugs, but it's looking pretty good atm.
XNA Game Studio 2.0
Yep, according to this blog post its on the cards for later this year. Aside from some of the other nice-sounding improvements is this little gem: "Host XNA Framework games easily inside a Windows Form". About bloody time! I'm still not happy with the way XNA handles some things (for one, I don't like having to "add" my assets to the project in order to use them), but this goes a long way towards convincing me to stick with XNA a bit longer.
This may be an option, but it'd be my last one atm. I'm not scared of DX or anything, it's just that I'm enjoying trying out the "Managed Code" thing right now and I'd prefer to stick with it for the current project at least.
Check out my assets... database
Yuck [headshake]. Must wash foul taste of crappy joke out of mouth....
Okay, so I'm taking my experience from the sprite-sheet editor and using it to make an asset-database app. It's been coming along quite quickly so far. The app will basically let me enumerate all of the assets to be used in the game. These include: textures, sounds, scripts, units, levels, campaign layout etc. At the moment it only supports textures and the unit data classes are a work-in-progress (and likely will be for the rest of the game's development). Sound, scripts, level management, etc will be included as I need them. The main purpose of this app is tying the different assets together in a meaningful way. For example, the tab for unit-data editing allows the user to choose the appropriate animations from those loaded against each texture (using the sprite-sheet editor). This is a much nicer approach than hard-coding (in my mind) and it's much more flexible as well. You select textures and animations by their name. This allows the engine to resolve them to indeces at engine initialization time even if other animations or textures have been removed. As long as the texture and animation still exist, the engine will be able to find them and convert into the indeces (texture number x, animation number y) needed. Once everything is resolved, the engine can throw away the names that it doesn't need.
No screenies today, but I hope to have some soon.
Had another busy weekend. I did manage to get some dev stuff done though. The sprite-sheet editor is pretty much finished. Saving and loading the .sheet files is all working fine. I redesigned the classes to be much simpler. I only have a few things left to tweak (I think I'll remove the sprite naming) and then I can move onto something else.
This sub-project has been a great learning exercise for me. I've gained a greater familiarity with C# and windows forms in .Net, but I've also learned more about productivity and when being less elegant is okay.
As I've stated previously, I spent way too much time completing this tool (although, as a learning exercise and considering my busy-ness, it's not that bad). I've learnt that there's two things that need to be of good quality with a tool (especially a tool that will most likely only be used by yourself and possibly a select few others):
1) The user interface should be easy to use and efficient to work with. The primary focus of a tool should be to alleviate the tedium of hard-coding data or assets yourself.
2) The output of the tool should be reliable.
Basically it doesn't matter if your code is horrible spagetti-code (unless you're planning on coming back and working on it later and have to understand what you've written) because the final product (your game) will not touch it. It doesn't matter if there are bugs in your code, as long as they don't affect the usability or the quality of the data output (although I don't think I've got any bugs, fingers crossed! [grin]).
This may seem obvious to others, but it's been a bit of an exercise for me to not put in every feature I could possibly want or re-write for the most optimized and elegant design. I had to just get it done so I could move on.
Keep it simple, stupid
Still learning C# and finishing off my spritesheet editor. Haven't had much time on it lately. I like to think I'll be able to improve this, but we'll see. Some of the lack of progress is due to me spending too much time on other things (*cough*flash games*cough*), some of it is stuff that's going on.
I've spent way too much time finishing this tool off and I realise this is because I've overcomplicated it. I've designed it to use self-managing classes and stuff when all I really need is one class with some Lists of sprite indexes, names, animation frame durations, etc. One of my motivations for learning C#, XNA and doing a "smaller" project was to be able to whack out decent progress quickly. I've certainly learnt that there's no point in over-complicating your tools. Sure, you want your "engine" code to be tight, but there's no such requirement for tools. As long as they're not buggy and do what they're supposed to do. I won't be using the data structures I created for the tool in my engine anyway. They'll just be middle-men for the data on disk.