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.