Saturday, November 11, 2006

omg, LARGE!

As you can see, the conversion to 32x32 tiles is completed for the existing build. The are a few issues with the enlarged tiles, which probably already were in the previous builds, but never showed up due to the small size of all the objects:
  • Sometimes, when 2 units overlap each other partially, you'll see a strange alpha overlay. Not sure how to fix this, but I'm looking for a solution
  • Some of the images didn't get through the enlargement process very good. For instance, the Ornithopter looks VERY good, while most of the infantry units are broken. They need to be fixed, but the problem with that is that I need someone good at pixel art to do that. And to be honest, I suck at pixel art.
  • I decided to go with the standard D3DXSprite as it is. I currently load each image, replace the colors in the image, and then write the image to a texture. The biggest downside of this all is that it takes a lot longer to load all the data. I need to fix this.
Currently, this is my to-do for now(Chronological order):
  • Re-write movement code
  • Weapons in game
  • Weaponry to rules.ini
  • Handling of device lost
  • UI components
First thing for now to do is to re-write my movement code. It's not very well written, and it has issues with movement, as it almost always reserves tiles the unit shouldn't be moving over while moving diagonally. This mean that it usually just uses the tiles left/right to the current tile for 2 or 3 pixels, and then continues onto it's target tile. Result: If that tile was in use, the unit occupying it is removed. It renders itself, but it' no longer selectable/attackable/whatever.

After that, I'll add weapons and combat in. Lots of work to do.

Thursday, November 09, 2006

About Spritesheets, explosions, infantry and enlargement...

First of all, I have done quite some work in the past few days. I needed something to do, because I was low on workload. I decided to start coding again, and before I knew it, I was on a coding spree.

I finished the spritesheets, which had quite a few issues in the first attempt. Eventually I narrowed it down to being the code that was responsible for finding the proper location inside the sheet. I re-wrote it in a more manageable manner, and it worked. This is the result(The blue is used for debugging purposes, and will remain blue. This will automatically show the programmer what's going wrong.):

Spritesheet in action, showing 1 subsheet

After I finished the spritesheet system, I decided I needed to do some front-end work, because I was bored with doing things without results shown in game. So, I ended up working on explosions. Yes, you read it correct: Explosions.

The system is quite simple: There's an Explosion class which houses the necessary functionality to run through the explosion sheets, do the timing and rendering. It's a GameObject, so you just shove it in the SceneManager and forget about it. When it's done, it informs the SM that it would like to be moved into the trash can for recycling. From the Explosion class, I derive a subset of explosion types: LightUnitExplosion, HeavyUnitExplosion, and the most interesting one: ExplodingBuilding.

Light/HeavyUnitExplosion refer to the number of steps and the used images. An exploding Light Unit(Quad/Trike) has 2 explosion steps, while a heavy unit has 5 steps. And there's only 1 image for an exploding light unit, and several for an exploding heavy unit. It picks the explosion in the constructor and then runs it. Now the interesting part:

The ExplodingBuilding was more tricky, because it needs to be dynamic in size, and look 'realistic'(As realistic as you can get with graphics from 1990, you get the idea). So, I started out by creating a BuildingExplosion class, which handles the explosion of 1 single building tile. It picks a random explosion from the list of explosion sprites for buildings and does it's thing. However, creating an M x N explosion in this way would look strange. All the explosions would start/end at the same time, and that would just look fake.

So, in the ExplodingBuilding, I build a list of each section(Say, 3x2, a refinery), place a random delay on it between 0.0 and 0.5 seconds and put an timer on it. When the timer expires, I stop it, spawn a random explosion at the section coordinates and start it. After all the delay timers are expired, the ExplodingBuilding removes itself from the SM. The BuildingExplosions then expire at some point and are removed aswell. The result(Including some failures):

As you can see, random explosions for heavy units. The selection rectangle shows up because of the rigged mouse. More on that below.

In the above image, I rigged the mouse to create random 4x4 ExplodingBuilding objects when clicked. I hacked it in, so when you'd drag the mouse, the selection rectangle wouldn't go away. Anyway, in this image the explosions REFUSED to go away, they kept going on forever. Turns out: Never ever use a .NET struct in a list. It will not retain variables you change.

And the last screenie demonstrating the delay system: A huge 20x20 explosion to see it in action. In the bottom you see the FPS rate from FRAPS. Also, the shown revision is incorrect, it should be 14. There's a problem with my PostBuild step, so the revision number doesn't update.

After this I was on a spree and added Infantry units. Infantry units ARE a bit different than other units, since they have only 4 directions, and have moving legs. Most other units are reasonably static, except the carry-all which has 2 states(Tanks with turrets are 2 sprites, so they're still static). At first, I decided to go with the standard Unit class, which didn't cut it due to the movement and the Direction property. However, I discovered you cannot overload the C# Properties, so overloading this in the Infantry class doesn't work(Would have saved me the hassle of going through the pain of using a bigger texture and some work).

However, I noticed that Stefan had a 2nd sheet of infantry/trooper sprites. 8 directions, just repeated for the wind directions. So I used that and just had to overload the Update function in the Infantry class. 43 lines of code and an hour of work.

However, I discovered that the infantry was rather, erm, small. And with small, I mean, near invisible. They're 8x6 or something, so you have to look REALLY hard to see them. And Ravuya said the exact same thing:He then continued to link to me HQ2X. An application to enlarge images and still look smooth. Have a look at the examples, it looks really good. So I experimented a bit with that. The results are astounding:
That's a Quad enlarged 2x. Looks very smooth. Only problem with HQ2X is that it can't work with palletized bitmaps, and converts them to 24-bit images, which is a problem.

I intend to let HQ2X loose on ALL the images for the game, and enlarge the entire game to 32x32 tiles instead of 16x16. However, I need a way to change the colors during runtime. I've been suggested to write my own Sprite replacement, which is what I did. It works, but only for single textures. I intend to add support for multi-texturing and use the Fixed Function pipeline to do some color changing for me. I'm still working on that, so I'm not sure how long it's going to take.

Until it works, I'm going to use the original images for everything and alternate it with doing some real work. Before I want to make the pass to enlarge everything, I want to have at least ALL the units in. This means I have to add the ornithopter, the frigate and the sandworm(Those are the ones still not done). Not a lot of work, but I need to make some changes in the code, and move all the aircraft specific code into a separate class to make full use of it.

That's the end of my long story for now.

Thursday, October 26, 2006

Spritesheets partially working...

I've done quite some work on the spritesheets(Which took me ~3 to 4 hours, where I could have done it in 1, IF I wouldn't be distracted all the time).

The individual subsheets work, in the sense of: You can add new textures to it, it finds a suitable location(If any), reserve it, and then copy it actual bytes onto the main texture.

Right now, I need to work on the main sheet, which should create a large texture depending on the total video ram(The less ram, the smaller the texture), and I'll add a constructor where you can specify the sizes of the sheet. Then I need to add in code to automatically create new subsheets(If there is any space left on the larger sheet of course) when there are no more free blocks in any subsheet, or when an image is bigger than any cell size currently allocated.

I'm not sure what to do IF there isn't any space left for new subsheets and it requires a cellsize not yet allocated. I technically could search all the subsheets for the largest used block size, attempt to put it in there, and if not, find the next largest cell size, etc. If none of the subsheets can house the texture, an exception should be thrown, and the TextureManager should either attempt to spawn another SpriteSheet or give up.

I'm currently using the default size of 256x256 subsheets, so it's highly inadviseable to use a sprite that's any larger than that. Ofcourse, it'd be a weird sprite if it's that big. For animated sprites, you just as well cut them up in smaller ones and load those.

Monday, October 23, 2006

Work in progress

I'm back on working on the game again. I'm currently working on the spritesheets.

Friday, October 20, 2006

I'm not death!

A little update, I've been very busy for the past 1.5 month, and haven't done anything on the game itself.

However, I want to spend a little time implementing a quad tree this weekend, and then get going where I left off: Implementing automatic spritesheets.

Tuesday, September 12, 2006

Aaah~~ Busyness!

I haven't done squat in the past days, since I'm busy with all sorts of things:
  • Procrastinating
  • Visiting clients and earning money
  • School
As you can see, I have loads of other things to do. I regret I can't work on the game, but since it's a hobby project right now, and my own business/school is more important, I shifted my priority to those 2.

Tomorrow I'm busy the entire day with work, visiting the orthodontist(Yes, I'm 23 and getting braces) and when I get home, finish some assignments for school.

However, when I have time, I hope to start spending some time on implementing a sprite-sheet system, which loads individual bitmaps and slams them onto a larger sheet. Should be done by the weekend.

Thursday, September 07, 2006


Well, not completely, but here it is:

As you can see, there are 2 sides on the screen, and I'm the blue one. The units are assigned to a Player, and during the mouse-over / click events, I check what's under the mouse, and perform an attack.

Right now, I'm thinking about how to store the increasing number of sprites and prevent it from causing an enormous slowdown. With the explosions and ammunition, I add at least ANOTHER 23 bitmaps, add that to the 22 bitmaps I already have, and you get the idea(Since my game isn't done yet). After that, I can make the actual bullets fly and do some damage to units. Once units reach < 1 HP, I remove them, add an explosion and VOILA! Instant action.

Tuesday, September 05, 2006

College is starting again...

Today my classes officially started for my minor. I'm doing Small Business Skills, and while I only have 3 'contact hours' a week, I need to spend at least 30 to 40 hours a week working on my assignments and other stuff.

They figured, these people are here for their own company or want to start one in the future, and therefore should work a lot for themselfs. And, half of the curriculum is done is student prepared classes, where ALL students need to provide a powerpoint presentation, and have a 1 out of 9 chance to stand in front of the class and present what they prepared. There is a 1 out of 9 chance, because there are 9 workgroups.

In matters related to the game: I coughed up a new texture manager, which replaces the default manager, and provides functionality to store each bitmap in a different color. All the ORIGINAL images are in red, and this is what it looks like with a small change:

As you can see, it works superb. Also, Textures are stored using their ARGB value in the TextureManager, so that harvester.bmp results in harvester.bmp_ARGBVALUE, so that each color is generating a unique name. I choose for this, because that way, I didn't have to change too much in the workings of the TM.

As for new features: I'm adding a base Player class, which will be used in the future to derive the actual players off, such as LocalPlayer, NetworkedPlayer, AIPlayer, etc. This way, updating will be very simple as networked players receive their changes, and put them to work at client side.

I hope to get it working before the weekend, so I can demonstrate it with 2 players(A LocalPlayer and an AIPlayer) and start working on weaponry. But I'm not sure if I'm able to, since school might require me attention.

Sunday, September 03, 2006

New input handler

So, in the past few days, I've been working my ass off to re-implement the entire input handling code, and seperated it out in a seperate class.

This means I cut approx. 300 lines from the actual playstate class and placed this in a seperate class, making my code alot more easier to maintain, update and fix.

Also, I added all functionality needed for the sides in the input manager(Attacking, unable to select, etc.), put it's all commented out as for now. But, I should more or less have this functionality working in a few weeks, as I want to start working on weapons, and for weapons to work, I need enemies.

Tonight I finally fixed a bug in updating the colors in each image, so I can now create colors needed for different sides. First step in this is to add a PlayerController or something similar, which owns a set of units/buildings. Next step is to provide a custom made texture manager, which loads the different textures, but also takes a Color param, which is used to update the palette to the required color(This also adds the option of being able to play with 8 players without the problem of having to have 8 different textures for each player).

After having controllers I enable the code in the input handler, and then work out weapons.

In other news: I bought a Laser printer for 78 euros today(Well, ordered it), printed out a 40 page document which I need for my minor which starts tuesday(Small Business Skills) and I came home from my parents in law and was shocked at how much of a fucking mess our place is. I'm off emptying the dish washer now...

Tuesday, August 29, 2006

Carry-alls are completed.

Carry-alls are completely done now.

Fixing up the code that moved the unit to the nearest tile was easy as cake. Didn't go much wrong there. After that I added a small SignalPickup() function, which took a reference to the carry-all which was fulfilling the request, so that the unit can cancel the request at all times without searching through all units.

After that I finished the tiny bit of work that made the carry-all fly to it's end, drop the unit and continue it's path. The carry-all also nicely slows down before the pickup/drop off point, and then picks up/drops off the unit.

Here is a short in-game video, demonstrating a devastator on the move from 1 side to the other.

Right now, there is 1 little bug related to the carry-all, and that's at the drop off. The unit appears to flash shortly on it's old position for some reason. I need to track that and fix it. After that, I'll fix 1 bug related to scrolling, and re-build the input handling code(In a seperate class).

After that, I'm going to add in weapons.

Monday, August 28, 2006

Carry-alls nearly done...

Right now, carry-alls are almost done.

I ran into a whole bunch of problems when implementing the carry-alls. First of all, my math was rusty and I had to fix that up. After that, flying circles and flying towards the target was easy to work out.

However, once above the unit, the carry-all seemed to rotate slightly, and then stall at a random direction. It took me quite some debugging efforts to find out that the carry-all was attempting to rotate towards the target and right after that attempted to rotate to face the same direction as the unit was. At some point, it ended up rotating one time Clockwise and another CounterClockwise, in the same frame. The fix was easy.

Right now, I'm coding up the parts that signal the unit that it's request for a carry-all has been granted, meaning it needs to cut down it's path to the nearest node and wait there for the carry-all to arrive. The carry-all already picks the unit up, so it's a matter a adding a state to the Unit class, do some actual path remodelling.

After that, I need a way to cancel the request in case the unit is destroyed or reached it's destination without the carry-all. The first would be a bit more difficult to handle, the latter is simple, since at that point, the request would still be in the queue. I will probably cancel the request if the unit is within 3 tiles distance from the target tile.

I should probably be able to implement that all tomorrow. For today I'm done coding.

Thursday, August 24, 2006

Carry-alls are a little bitty delayed :P (And some more RTS ideas)

Ok, I was supposed to add carry-alls in a little bit more than just having them fly around in circles... But, I forgot all the maths a bit, so I need to refresh that a bit before continueing.

This is the problem: When the carry-all pilot is chilling in this cockpit flying circles, and a unit wants to be picked up, it places itself in the carry-all queue. All the idle carry-alls check the queue each update cycle, and when there's a unit in it, it will take the unit from the queue, fly it's circle into the correct angle, and then set course to the unit. However, I for some reason, couldn't get the correct angle out of the calculation. So, I'm going to spend some time on working out the maths for it. Probably a few sinuses and cosinuses.

I hoped to work that out today, but I ended up helping a friend with her house. I helped her paint, and since I had to travel to my hometown by train, I spend 3 ~ 3.5 hours in the train total. So I'll do that tomorrow in the train.

New RTS idea - Auto-repairing

I think most of us hate it in most RTSes, during an attack, quickly click on the repair icon and click like a maniac on all buildings to make sure they're in top condition. At least, I hate it.

What I want, is another screen where you can set the auto-repair settings, ranging from "No auto-repair" to "Keep at maximum health". This also means it's easy to keep your buildings in top shape, so I might add a little bit of difficulty to it: You get the first 70% for free, and by doing upgrades, you can increase the percentage up to 100%.

Also, I'm also considering to add a money cache, in which you can say: Keep at least XXX credits for repairs. When you set this to 200 credits, all construction halts at 200 credits, and the remainder of the money is used for building/unit repairs. This is extremely usefull in case your base is undersiege so you don't run out of credits.

Awaiting pickup icon

I've been playing Dune 2000 in the past 2 days(Man, it kills production), and in D2K units have a green arrow pointing upwards when they're awaiting carry-all pickup. I might add that aswell, since it's quite annoying to see a unit standing idle(for instance a harvester), you order to return to the refinery, and the pickup order is cancelled and re-issued.

That's it for tonight. Right now: I'm going to spend 15 minutes on the math stuffness, and then I'm off to bed.

Monday, August 21, 2006

Carry-alls are being added...

Whoa... That's 9 days of doing nothing related to coding. Bad bad me!

Today I put myself to coding again, and I did a little bit of coding and some file managing.

First of all, I fixed a little problem with the rendering, where units had a fixed position on the screen, and at some point, they would disappear because they moved outside the viewport. I changed the render related code so all units first calculate their on-screen position. During the rendering, I traverse all game objects, check if they're within the screen boundaries, and render them.

However, I was just testing my newly added carry-all(Which is currently stationary on the screen), and noticed that when I scroll 3 or more tiles from the top, the unit healthbars and the harvester loadbar no longer show up, and when I scroll less than 3, they're displaced. That's something I'll have to look into tomorrow first, before adding more logic to the carry-all.

Anyway, in 5 weeks we have to move again. *sigh*. Also, the new owner of the current building is coming to visit tomorrow, and from what I've heard till so far, it's a whiny little bitch. For instance, last saturday I got my dad's car, and drove it onto the terrain, but didn't close/lock the fence. I was loading our bed sheets since we were staying the night at my parents, and some car drives onto the terrain. I walk up to the car, polite ask who he is and what he's doing on the terrain. He responds he's the new owner, asks who I am, and I tell him I'm the squatting guard. After that, he leaves.

This morning, I noticed I had a voicemail, listened to it, and he apparantly called the real-estate agent that the fences were open and that we were probably mis-managing the building. I was shocked, and more important, insulted.

He's coming over to inspect the building tomorrow, so I'll get up early and do some additional vacuuming and mop the floor(which could use a good mop anyway).

Saturday, August 12, 2006

Some interesting ideas...

I was recently thinking about what direction I want to go with this game. I want to put more S into this game than any previous Dune game ever.

First of all, I want to get rid of the "build buildings, units, select units and attack". I want to get to: Build a base, build units, create attack groups, lay down (attack) orders, and initiate multiple attacks at the same time.

First of all, the way Dune II played is going to be the same as in the original. However, I want to add some more functionality to it which allows players to focus more on strategic parts, such as attack patterns, defensive patterns and sneak attacks. Also, for future strategy games, I want to make the game act more realistic. More about that later in this entry.

Combat Interface

I want to accomplish this through a combat interface(CI). The CI allows players to compose attack groups(AGs) of units and give them buffered orders. These orders are stored in a general buffer shared by the attack groups, and aren't executed until ordered. Also, attack groups can be ordered to wait till for other attack groups.

The orders can be seen as way points, supported by many strategy games but not used much. Instead of just moving, they can also mean attack, defend, distract, wait for AG signal. Signals are used by AGs to inform they're ready and waiting.

So, in order to implement a classic pincher pattern, you need 2 AGs, each containing move orders to the left and right side of the base. When an AG reaches it's position through the way points, it's raises a signal and waits for a signal of the other group. When the other AG reaches it's position, it raises it's signal and waits for the signal for the first group. Since this group raised the signal before, it doesn't wait and immediatly initiates attack.

This forces the other side to actually balance it's defenses well, and perhaps come up with a strategy to effectively counter the attack pattern.

Factory Refitting

This forces a player to re-think it's building strategy and perhaps construct several factories. For instance, take the Heavy Factory from the game. It constructs Harvesters, Light tanks, Heavy tanks and Rocket launchers. In most strategy games, you click on a bunch of icons, and wham, it starts building it.

However, in a future game, I want to insert a refitting period for each unit. Say you're constructing a MCV in your HF. Once done, you start building 2 heavy tanks, 5 light tanks and 7 heavy tanks. If you retain that order, and with refitting, the factory would be inoperable between for say 20 seconds between each unit switch, to refit it's construction facilities.

Because of this, players could decide to build 3 HFs, which auto balance the construction as much as possible. Which also brings me to the next point:

Multiple unit constructions

Most RTSes I've seen using the classic C&C interface have 1 short coming: Even tho you built 8 factories, you're still building 1 unit. The construction time went down a bit per each factory, but you're still only constructing 1 unit at a time. Imagine the Germans and Russians construct 1 tank at a time with 4 factories each.

I want to change this, also in my D2 implementation: If you have 2 factories, both are constructing units. I'm aware of the consequences of this: You need a massive amount of cash flow to keep them all running and the player with most factories wins because he can construct massive amounts of units.

A good way to counter-act this is to make running factories consume more energy. Say an idle heavy factory comsumes 15 energy. A running factory then consumes 30 energy units. Therefor, if you want to hit a player that's building a lot of units hard, you attack his power supply, and knock out a few factories because of that.

Yes, I said a few. I dislike the power management in most RTSes aswell.

Power Profiles

Again, the C&C games act strange when it comes to power: When you consume too much power, all your energy dependant facilities lose power and grind to a halt. Again, I want to change this aswell. When you lose a wind trap, and you do not have enough power to keep your 4 factories running, 1 will stop construction to provide the others with enough power to work.

In order to give the player several options on how a low power situation is handled, I want to introduce power profiles. Profiles where certain types of buildings get a higher priority than others. For instance, the "Defend Base" profile will first opt to turn off factories in order to keep the defenses online where the "Construction" profile will turn off the base defenses first.

When a building loses power, it needs to restart after obtaining enough power, and is therefor knocked out for an additional 1 or 2 seconds. This forces players to think about their power profile, because when you're constructing with offline base defenses it gives you an advantage when you can quickly switch when you're attacked(Between the attack waves, you can switch profiles to quickly finish off 3 or 4 units without being defenseless at all).

That's all for now. I really want to hear feedback on these ideas.

Thursday, August 10, 2006

Just scrolling around...

Scrolling around the map now works, and it works quite good.

Implementing it was fairly easy. Check if the mouse cursor is 16 pixels off the edge of the screen, and then check if the viewport wasn't at it's minimum/maximum on that side. Then, do the actual scrolling based on the scrolling timer.

The scrolling timer makes it possible to change the scrolling speed in some form of settings dialog. Also, if there is some actual scrolling done, the mouse cursor neatly changes into an arrow and all other actions are ignored(Such as selecting/attacking).

And I made the console react to the tilde key to hide/show it. Now I really need to start working on the render layers, because my units are all messed up now with rendering.

Sunday, August 06, 2006

Harvesters nearly done

I finally implemented harvesting! It's not fully done yet, as the harvester keeps on harvesting when it's full, and it doesn't accurately search for new spice when it's done with the current tile, but those are improvements I'm going to make over the course of the coming days.
Harvester enroute to the spice, MCV is moving in the background

Harvester feasting upon some spice

As you can see, harvesters have a 2nd indicator showing their fullness. Also, when I was writing the harvester code, I already implemented quite some code needed for attacking.

I initially thought about adding a Harvest() function, but soon figured out that a harvester would basicly attack the spice, so I override the Attack() function from the units now.

Coming week I'll finish the harvester completely by making it search better for spice, clean up some code and fix all the mess I wrote in the mouse handling code. Oh, and work out a better way for mass selected units, so that Harvesters don't attack units/buildings(Or attempt to) and that regular units don't attempt to attack the spice(Which would be catastrophic, as I intend to make the value of spice tiles decrease when they're hit with gun fire).

Tuesday, August 01, 2006

Unit health bars are now working

Today I added the health bars to show up above units when they're selected or when the mouse cursor is hovering over them.

Creating the bar as a total of 10 minutes of work, and another 5 minutes to make the texture when I discovered that Sprite.Draw() doesn't allowed me to stretch the texture(Perhaps I should have used Draw2D(), but I'm a bit lazy).

Below are 2 screenshots: First one shows an empty health bar(Where the unit basicly should be removed from the battle field) and the 2nd one shows a selected devastator and the mouse hovering over the light tank.

(Click to enlarge)

(Click to enlarge)

So, I also started with the harvesting progress bar, which is basicly the same thing, using a different texture and a different location to render it all. That should be implemented tomorrow, and there should be a harvester unit that 'works'(Ie. move around, show an attack cursor over spice).

That's it for today. Hopefully I have time to code tomorrow, but somehow, I doubt it.

Wednesday, July 26, 2006

What's up with me

So, my previous contained all my update logs(And this one will contain a little bit aswell, including a screenshot).

First of all, the new place I'm in rocks: It's air-conditioned, we got a dishwasher, a large kitchen and it's not housemates.

Also, since I'm currently having vacation from college, I'm spending most of my time working. I got a vacation job as foreman. We travel through the country and install TFT monitors at all locations of a company. It are a few thousand monitors, so I'm sure I have at least 6 weeks of work.

The pay is ok and I get to drive the truck. While that's ok, it's a horrible job aswell: The installation locations are ALWAYS in the middle of the city, and the streets are usually thight, crowded and shit to maneuver a huge truck in without too much experience and a drivers license for driving trucks. I'm not illegal driving this truck, on paper it's a car. However, it handles as a truck. Due to this, I damaged the truck twice(GAAH!!). My girlfriend told me it was the risk they took, but that didn't do much about the guilty feelings.

So, today I was home early, so I took a nap and when I woke up(I had a muscle cramp in my leg, not a funny way to wake up), I decided it was time to code. So I finished off my debug log and log console. It was quite easy to work out. The log itself stores lines, and can flush them to disk aswell, and the console is the visual part. It takes it's own height, calculates how much lines fit in it(It first calls a MeasureString()), minus one, and then takes the last x lines from the log.

It's rendered to an alpha blended texture only when the log updates. That way, it's cheap to render. I still need to make it re-sizable at runtime(Perhaps turn it into a GUI widget or place it on a GUI widget, such as a re-sizeable panel). Also, I need to make use of it in the actual game code.

I didn't mention it in my previous log entry, but I also optimized the map rendering, and it gave me a 30 fps performance boost. Which is nice. And I made the tile reserving/occupucation work properly. So, when I have time again(Which is probably friday), I fix the drag selection which I disabled, do some work on actually making sure device lost events are properly handled and then really start working on the harvester(Well, after I made a new map).

Internet is back up: More updates!

I've been without internet for a full 3 weeks, and I have a vacation job, so I don't have an awfull lot of time to spent coding. However, I did keep track of my development log while I was offline, so here are my notes for the past 3 weeks(Not a lot, since I didn't have much time to code):

Sunday 16th july 22:33 :
I've done more coding today and I've ran into a few problems, did a few changes and gave stuff some thoughts.

I have to work out movement a bit better, because at the moment units are constantly calculating a new path to follow when entering a tile after reserving it.

Also, I ran into a trouble when rendering the selection: When the position has numbers after the dot, the selection marker will be (partially) faded. Solving this is quite simple: Make sure the X,Y positions of the marker don't have any numbers after the dot. That's not very difficult, but adds some more pointless information, and I don't wanna resort of a new Vector3 every render loop.

It all takes more time than I anticipated, so I think it's gonna take ages before I can start adding buildings, and/or UI components.

Sunday 16th july 00:43:
I haven't had much time to code friday and most of the saturday I've been away, but tonight, I finally managed to get movement working properly.

It involved quite some changes, such as adding a SceneManager to maintain all objects on the map, and coordinate them. At this moment, movement is veru rudimentary: The unit itself moves to the middle of the last tile in it's path without actually facing the correct direction or reserving tiles.

That is my next step: Have units rotate their nose in the correct direction, and then move. After that, I need to have the SceneManager(SM) update the tiles correctly, and allow units to mark a specific tile are 'reserved'. A reserved tile means that a unit marked the tile to move to it. Not doing this might result in multiple units occupying the same tile.

After that works, I'll do a new commit and start working on optimizing map rendering a bit. After that, I'm not sure what I'm gonna do first: Harvesting and weapons. I probably go with harvesting, because the harvester is really cool, esp. with the sand falling out of it in the back ^_^.

Anyway, a bit back to work and then I'm off to bed again.

Thursday 13 July 23:30:
I've decided to write a development log offline until I have internet access on tuesday next week, and then publish these notes in 1 single blog entry.

OVer the past days, I've done quite some work, and it payed it off. New additions to the game at this moment in time are(Taken from this morning's SVN commit log):
- Added PathFinding
- Added a test map for pathfinding
- Added batch file to extract current Revision
- In-game now FPS and current revision is visible
- Added a GameObject class
- Derived Unit from GameObject
- PlayState now keeps track of all units
- Added a UnitFactory which spawns new units
- Added the graphics for quad, trike, harvester, light tank and siege tank.
- Created a rules.ini to contain definitions for units
- Re-organized DuneRemake project
- Added hotspot to mouse

Over the day, I also added the graphics for the Devastator, Deviator, Sonic Wave Tank, MCV and Rocket Launcher. Due to some errors in the spacing, I had to re-do the Devastator image, but everything works fine now.

Also, I added a new class called TurretedUnit, which is basicly a tank with a turret(Duh, like you couldn't figure that out). It relies on the base Unit class to draw the tank base, and then draws the turret on top of it.

Now that I added the graphics, I'm thinking off a way to store the units in the map so they can move properly. My main problem is that I currently can't think of a way to store both units and aircraft/sandworms in a tile. Because, there can be a carry-all hovering above a unit to pick it up, and a sand worm underneath preparing to have lunch. I gave an ArrayList or List a thought, but I'm not sure. It would cause a lot of additional overhead, which isn't very good for performance.

I am planning on adding a global GameObject list to keep track off all game objects, and using that to update them all. Having to walk a 200x200 map just to update a total of 8 objects isn't very efficient.

I technically COULD walk the list twice, check if said object is within the viewport, and if it is, render it. Or while updating all game objects, place the objects that are within the viewport in a 2nd list and when rendering, only render those objects.

On the matter of pre-mature optimizations: After I got units moving over the map fine, I'm going to change the code for the rendering of the map. I'm going to render the visible viewport map to a texture, and only when it changes, I render it again to the texture. At the current screen size, rendering it tile-by-tile, it takes 1200 render calls. Changing that to only 1 call will increase performance a bit.

That's it for tonight. It's 23:47 now, and I think I'm going to take a shower and crawl against my girlfriend in bed. No screenies for today, sorry!

Saturday, July 08, 2006

Pathfinding works

I've successfully implemented A* pathfinding. A* is pretty simple to implement, once you understand how it works. Here are 2 screenshots:Click to enlarge

The next step now is to actually have my mouse cursor support a 'hotspot', so that changing the cursor doesn't alter the general behaviour(Right now, the attack cursor will show as long as it's hovering over a unit, even if this includes the bounds of the cursor). So, when I use a hotspot, changing the cursor doesn't show unnatural.

Also, when that works, I'll work on adding the selection thingies around the units and making them actually move.

However, for the coming week, or perhaps 2 weeks, I won't be able to post new updates, as I'm moving and my phoneline/DSL line haven't been transferred to the new location. Let's hope I get to live at least 6 months at that new location before I have to move again.

Sunday, July 02, 2006

We're developing again!

Finally, after almost 2 months of no updates, I have time again to code on the game. In the past 2 months, I've been too busy with school and other projects, so I had to put this project in the fridge for a little while.

In the past days I've coded quite a bit, and I did the following:
  • Fixed a mouse related bug
  • Fixed a bug in the map editor where the 3x3 tile brush wasn't working properly
  • Added a base unit class
  • Added a Drag Selection rectangle to the game
  • Added unit selection to the game
  • Coughed up a map for pathfinding
The next step for me is to actually show unit selection and after that, implement movement and pathfinding algorythm.

I can't show any screenshots at the moment, because there isn't anything special to see, unless you like seeing a screenshot with nothing but sand and a unit standing on it...

I hope I can show a little big of screenshots for movement in 2 or 3 days.

Tuesday, May 02, 2006

Map Editor completed / Comments opened to public

I just completed the map editor! It incorporates all the features I wanted to include, and I left out a few non-vital functions such as auto-saving, Dune 2: The maker map format loading/saving.

Here's a screenshot of the 3x3 brush in action:

Also, I opened up comments to the anonymous public, since not everyone wants to register with blogger just to comment in my blog.

Up next: Loading units in the game, and changing their palettes to right colors.

Thursday, April 27, 2006

Loading/Saving almost done

I finished the Saving part, and I'm currently working on loading files from disk.

I decided to go with an XML fileformat, as it's easiest to read and understand by humans. Since I don't store a lot of information, it's seemed logical I make it human readable. The format is really simple, but I'm not yet quite happy with it. It seems a bit, uhm, disorganized/illogical mapped out.

I'll work it out a bit better tomorrow, and see what it turns into. Also, I got the New Map dialog in(Altho without Author information and map name), display which tile the user has selected(That is, the x, y coordinates within the map, relative to 0, 0 of the map, not of the screen) and I display the map dimensions.

I did add the UI for the 3x3 brush, but I haven't written the code for it yet, but that's pretty simple.

So, I got everything down to:
  • Auto saving
  • Finish loading
  • Save Dune 2: The maker files
  • The code of the 3x3 brush
That's pretty minimal work to do. Sounds doable in a day. Downside is: I don't have time tomorrow, since I need to go to a 2 clients, and finish some work there. Well, it's money, that's important.

Tuesday, April 25, 2006

Tile edging works

Today I managed to push myself to finish off the code to calculate all the proper edges for each tiles. It was a tedious job, as it was a giant block of if statements and bitwise ORs and ANDs to determine which side was connected.

The code is ugly, but there wasn't much alternative to it. These pieces of code are in the category of "Never touch it again". And that's exactly what I'm going to do: Not touching it anymore, since it's working perfectly.

For those of you who want to see it all in action:
Looks sexy eh? It contains all the tiles, and shows how smooth each tile is getting the right edge, including the tiles that rely on a specific underground(Such as mountains).

The todo list for the editor is now down to:
- Add New Map dialog
- Saving
- Loading
- Adding a 3x3 brush, to quickly cough up large areas
- Use the statusbar to display some information about the map, such as height, width.
- Autosave function for automaticallly save unsaved work every 5 or 10 minutes in a special temp file.

I was thinking about adding a minimap, but I'm not sure if I'm going to do that. If I am going to do it, I need to do it in WinForms code, since I can't render outside the D3D panel, and it would be annoying to show the minimap in the editor screen itself. I'm probably going to leave it out for now, but I can always add it in, it's not something that requires a complete overhaul all the sudden.

Wednesday, April 19, 2006

Editor delayed

Due to a very high workload for college, I'll have to move the completion of the editor by a week. In my original planning, I wanted to finish(and perhaps release) the editor by the end of the week.

However, there is just too much work to be done for school, that I'll have to postpone it. I rather not work on my private projects, than fail any of my school projects.

Tomorrow morning I have a presentation for one of the school projects(In fact, I have less than 3 hours before my alarm goes off, but I can't sleep). Next week I have another presentation and I have to get some work graded.

I also have to complete some work for a few clients, so I rather give those jobs a higher priority. Coming week I except to:
  • Finish the editor
  • Release some ideas on how I want to approach a few problems
  • Release a more accurate project goal
  • Come up with some design models
Tune in coming tuesday for more updates.

Tuesday, April 18, 2006

Map Editor nearing completion

The mapeditor is nearing it's completion. It was quite fun to develop, and it's a bit of a shame I'm almost done with it.

There are some radical changes in it, such as that I stepped of the DirectInput mouse. At my first attempt, I attempted to initialize DirectInput for the mouse, and use that to handle the input. Problem was: I had to make up a fancy way to detect wether or not the mouse exited from the rendering area and unacquire(). In the end, it turned out the mouse was moving faster in Windows than it was under DirectInput(strange?), so I stepped off the DInput mouse.

I know process the MouseEnter, MouseLeft, MouseMove and MouseClick events off the panel where Direct3D renders in. Then I call a class member function of the TileBrush to set the new position of the square. When the mouse leaves or enters the area, I either make the square visible or invisible, so the little square doesn't sit at the corners doing nothing. This is how it looked liked:

That's quite sexy eh? This screenshot also shows the TileBrush in action. The TileBrush class is responsible for drawing tiles into the map, and to check if it needs to draw some extra tiles. For instanece, if I want to draw a Spice Dune(The dark area in the screenshot), it has to be in the middle of a spice field. To accomplish this, I first check if all 8 tiles surrounding the tile are of the required tile type. If not, I set them, and after that, I finally add the tile itself.

It's funky, but not completely flawless. I can still place those tiles, and replace all the spice with sand. My next entry contains how I solved it.

When I made the brush work, I wanted to go to bed. I just had to implement scrollbars, and make them work. Scrolling is simple: The horizontal scrollbar has a maxvalue of map.Width - map.ViewPortSize.Width, and the same for the vertical scrollbar. When the bars are scrolled, I can then just set the viewport positions. Simple, yet very effective. This is the final result:

Now I only need to work out an algorythm to round of the edges of the tiles(so they don't look all squary), remove certain tiles if they're not surrounded by their required tile, show some map information, make a "New Map" dialog and loading/saving.

Friday, April 14, 2006

Map Editor on the way!

One of the basic things in Dune II was the map. So I decided to dedicate myself first at making a proper mapformat, have it load and look good.

I first started with a normal WinForms app, but soon decided I needed to share a lot of common information between this and my ingame map class. So I decided to have my editor use Direct3D itself for the map rendering, and shove all the map specific things(And probably more) into a common DLL.

Right now, I have the DLL and the normal game working again, and I was working on integrating it all into the editor, when I decided I needed to install my Windows 2003 server(I now had access to a spare monitor and keyboard and the space to set it up).

So, I installed it, and at the moment, I'm installing all the necessary services on it, and then continue to install Apache, PHP, MySQL en Subversion on it. So I can host some sites, do work for clients and run Subversion of the server. Then I can free up some space and resources on my own machine.

Too bad this prevents me from doing more work on the editor and the game, but it's important to get it running.

Wednesday, April 12, 2006

Incorporated ToolEngine and got the mouse working.

Yesterday I integrated my existing 3D engine into the Dune II Remake project. I changed the Engine class a bit to support 2D operations using the Microsoft.DirectX.Sprite class. However, I added all the functionality directly into the Engine class, which seems a bit bad. The same class, for both 2D and 3D. I'll split them out in a Engine2D and an Engine3D class later this week.

After that, I spent some time reviewing my old InputManager code, and to be honest, it was quite solid. I added in a little bit of code to initialize both the keyboard and the mouse, and experimented a bit with the CooperativeFlags. I still haven't figured out if I want to go with Exclusive or NonExclusive, but at the moment, I use NonExclusive, and I don't really like it.

After the mouse worked, I added a simple class to render the mouse pointer to the screen. It works, but without transparancy. I did specify Palet entry 0 as transparancy, but for some reason, it still shows the black I used in the bitmaps. Trying to figure out why.

If I got some more time tonight(Which I doubt, because there's a giant pile of dishes to do since yesterday I had my birthday), I want to add in a first unit, the trike. I want to create a Unit class, then derive a Vehicle class from that(Because there are also infantry units) and then try using some sort of config file for the units.

Or I might try to whip up a map loader and editor, because at the moment, I don't really have any good map that I can use. I might try to work out the format for the Dune II: The maker maps, and use those until I can whip up my own format and editor.

Sunday, April 09, 2006

First entry :)

I've decided to start blogging the development progress of my Dune II clone, so here I am.

I decided to use Blogger instead of my own journal system mainly because I use my own site for business purposes now, and having my journal on in, while not linked to on the mainpage is a bad idea.

In this journal I will keep to shed light on the status of the project, share ideas, screenies, progress and development decisions.

At the moment I don't have much to share, except that I just started development, and that for once, I want to try and finish the project. Perhaps having some audience to "encourage" me will keep me motivated, esp. when people are sharing their ideas with me.