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.

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.

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.

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).

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.

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.

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).

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.

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!

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.