Dune II: The remake

Dune II allowed as college project!

2009-03-29T13:01:00.001-07:00

After much deliberation at my college, I managed to get it accepted as a project that will provide me with some grades that I need. There are 336 hours scheduled for Dune(Which comes down to 42 full days, or 1.5 month of work fulltime).

This should give me plenty of time to actually get anything done on the project. However, after reviewing the old code and an attempt to get it to compile again under Visual Studio 2008 on Windows 7, I have decided that certain parts of the game are utterly useless. Managed DirectX support appears to be dropped by Microsoft, and is replaced with XNA.

Because of this, and the insane difficulty I had with integrating a network component into the game, I've decided that I'm going to partially re-write Dune. I will completely replace the rendering layer with XNA, and I will start bottom up this time. Instead of working on the game logic at first, I will start out with the networking engine, and build a game on top of that. This allows me to focus on writing a solid network component first, and then slowly integrate parts from the game into the simulation.

However, since I spoke of a partial re-write, you might wonder what I will re-use. Well, I will re-use all the logic components I've written till so far. I will still use many of the components from the original engine(Such as the manager for gamestates, tasks) and try to port as many things over to XNA. One of the first things on the list is the Window Manager because I'm going to need it on short term.

I started testing out some code on networking and NAT punchthrough last monday using the latest Lidgren Network Library, and I must say, it's great! I wrote a little test application that creates a P2P network with 1 host and 2 clients, and I was able to generate a solid, working p2p network. They all saw each other, and it could connect over a home router and a corporate firewall(Microsoft ISA). The codebase I know have, is derived from that, and has a working lobby that recognizes new players, sends game settings around and at the moment, I'm working on setting up an actual simulation, that will start out by running a few rounds, and the host sending 1 to 2 orders around to all clients, have the clients execute these and then have them send the results back.

I'll report back later. I hope to have some screenshots by then too.

Synchronisation bug in the server...

2008-06-06T00:46:00.000-07:00

Well well, what a surprise! More updates on Dune :).

I've coded a bit on Dune in the past few days. Not an awful lot, because I had other things aswell, but I managed to code up a few bits on the train while traveling to/from college.

Units are moving again

Yes, first thing I did was re-enable the controls to move units and scroll around the map. Sure, they don't actually send stuff over the network, but units are moving, and I found a few bugs in there related to the MCV(ie, MCV can attack, but isn't supposed to). I intend to fix this first, before actually buffering the calls to order units around.

I also need to build the turn-system for the packets. I guess I should buffer up the commands first, and then actually start working on the system that collects the packets from other sources and hands down the orders to the correct player.

DebugConsole is now a real UI object

I updated the DebugConsole, because it didn't quite behave like I wanted it to behave. It was the first 'UI' control I built, and wasn't based on the later written UI system. In other words, it was a dirty hack that rendered itself to a texture and constantly drew the texture when needed. Obviously, that was faster than the current approach, but made it more difficult to make the console support features like real UI objects, such as resizes and adding of sub-controls.

I think the next iteration of the console replaces the current code with a Textfield / Textbox in which I draw the text, and a 2nd textfield / textbox to type in. That would make it much easier to add in support for scrollbars, and other various snazzy features. But, that doesn't have an awful lot of priority at the moment.

Synchronisation bug!

And of course the bug I mentioned in the title. I have a really weird bug in the Server code related to loading. It's a few days old, and I've been trying several times to patch this up, but it didn't quite work.

The problem is as follows: When I enter the NetworkPlayState, this will create a new state called NetworkLoadingState which is responsible for loading all assets and synchronising all the clients with each other so that each game starts around the same time. However, when the server is behind on loading than the client(On my machine that is. The game having the focus will load slightly faster than the background window), it will be done loading by the time all the clients are done loading too. It will see that everyone is done, and trigger the OnStartGame event, which in that case, will report that the server hasn't completed loading yet. This will mean the client will push a new NetworkLoadingState onto the stack and voila, the game will start throwing exceptions.

I have no idea yet on how I'm going to solve this. I'm considering the just ditch the current asynch approach, get rid of the events of the events and start using blocking functions instead, to make sure things will run in proper order. Alternatively, I might just build in a 1 second delay on the server side to prevent this from happening, but that would be a dirty hack I rather avoid. First step is to figure out where it actually goes wrong, and then find a way to solve the issue neatly, without fudging up my code too much.

Unexpected progress!

2008-06-02T13:59:00.000-07:00

Some people probably gave up on me(or Dune or both), but don't worry, I haven't given up yet. It's just that I've been way too busy with other things in my life(Which got twisted upside. But I didn't move in with my auntie and uncle in Bel Air).

Last friday, I had my laptop with me and I was like, what if I open up Dune and start coding for a bit again? And so it happened. I coded, and debugged the code I had written, and debugged more, and yelled at my laptop. I really had to look back at older code to see how far I was, and how I solved certain issues. And to be honest, I solved quite a lot of things in a clever way.

Last weekend, I managed to finish up the lobby / loading / synchronizing part. It now successfully manages to synchronize all the data between the lobby/clients, and then starts the game, including units. Each player gets an auto-assigned starting location when they connect(At the moment, since I haven't added in start points to the maps yet). After the game is done loading, it shows everything like a regular single-player game, except the controls are currently disabled.

Lobby-server awaiting another player to join. Player numbers are currently fixed.

Minor bug with the sidebar during loading. Still need to fix that, but it's not too important at the moment.

And we're live! This shows up on both sides.

Next step is to re-enable the player controls. But instead of immediatly executing all the actions, I need to buffer them, send them to the server and have the server distribute this to all clients again. I already isolated the calls which I need to buffer, so I only need to build the mechanism to actually buffer them, broadcast them around and execute them when needed. Still need to figure out how I'm going to do that.

Happy new year! (And progress updates)

2008-01-02T09:08:00.000-08:00

Happy new year! May 2008 be a good year!

As in updates: I've managed to complete the loading of all assets and the game actually ends up being started. So, the next step is to place some units on the map and start building the turn system.

I'm not entirely sure on how I'm going to implement the turn-system yet. I intended to send a StartTurn to all clients, which then starts each turn. But, as lag increases, the game would hang for a short period of time with this system(Perhaps not even noticeable). So I could send them out sooner, but that would mean I could miss packets with commands in them. Not sending StartTurn packets is even worse, as the game would continue to run(And go out of synch) when the connection is temporarily congested. Not a good thing either.

I think I need to experiment with this a bit, and when I have a good working alpha test release, do some real testing with 2 or 3 people to see how it works out.

I hate coursework...

2007-12-17T11:32:00.000-08:00

There's a small delay in finishing up all the Game handshaking and getting the initial scene up. I'm currently occupied with a load of coursework which I have to finish because I screwed over a bunch of courses last year and the year before.

Really stupid, but if I want to start my graduation by the end of the college year, I better get all these courses patched up. And because of that, I have less time to work on Dune.

But, I found out I also have to re-do Network Programming(Why I failed that course is still a complete mystery to me), so I'm going to attempt to convince the professor to allow me to submit the network code of Dune. Mainly because it's more cooler than writing lame ass chat server(Using UDP and RMI), but also because it gives him a really cool example to show during classes.

So, I need to finish 1 more assignment for data structures / algorithms(Write an AVL Tree), and then I can submit all the code. One down so to say.

I need to re-think my class structure a bit...

2007-12-12T11:44:00.000-08:00

I was reviewing my network code in the train on my way home today, and I came to the conclusion that I should think it over a little bit before I start expanding the code.

At the moment, on both the hosting and the connecting side, I have either a Server or Client as Task. The task is placed into the TaskManager and therefor updated each frame. Both the Server and the Client implement various properties via an interface(INetworkConnection). This is the connection status, connected players, etc. This is fine.

However, I also need to receive information back FROM the Task, such as when a new client connects, or when the user interface needs to update information. For this, the INetworkConnection is insufficient, because I need various events which come either from the lobby or the game. Such as PlayerConnect, PlayerForfeit, etc. It's a really bad idea to go from lobby -> Server/Client -> LobbyState. Messages would be re-routed via the INetworkConnection, which would slow things down AND clutter the INetworkConnection interface with too much useless crap.

I intend to counter this by creating ILobby and IGame interfaces, which the LobbyServer/LobbyClient and GameServer/GameClient would implement. These interfaces could then contain the function specific things for the lobby/game(such as a joining player for the lobby, and a forfeiting player for the game).

Using this system would probably be more efficient in terms of code maintenance than cramming it all into 1 gigantic interface. It would also prevent the Server/Client task from having to add GameStates, which keeps the seperation of UI / Logic intact.

I should have some in-screen screenshots soon, altho I probably need at least till sunday to buffer up all the player interaction with the game and send these commands over the network to the server. I need to change quite some code in the PlayerInput.cs file(Which basically contains all the code related to interaction from player to game).

Background loading of assets

2007-12-07T14:46:00.000-08:00

Before I wanted to start out with the actual networking part, I wanted a way to load the assets from disk in the background, and before the game was actually running. This to prevent slowdowns in the network simulation when a new building/unit was constructed and the asset had to be loaded from disk.

In order to do this, I wanted a nice front-end(A progressbar to display the loading progress) and a back-end: A background thread which did the loading and put each asset into the TextureManager.

I started out with the ProgressBar, as the asset pre-loader was half done. It just needed to be modified to be able to work in a thread.

The progressbar is just another Control for my game. It basically draws it's outline, and based on a Value it shows a nice (blue) bar. I initially had a problem with the outlines not showing up. But, this is related to the way how D3DSprite and D3DXLine render. I solved the issue by doing a Sprite.End() RenderLine Sprite.Begin(), but that cuts down on performance, so I need a better way. I reported it as a 'tweak' in mantis, so I don't forget about it.

Loading, please wait...

The background asset loader was also heavily modified. I initially wanted to try and run it while performing my normal gamestate functionality, but I found out it's way too slow for that. The change was that when I constructed the Preloader, it would parse the list of assets to load and store these, and then with a call to LoadNext() it would take the next asset from the list and load it. So, I shoved that into my BackgroundLoader class, and all was done. The BackgroundLoader is a thread that keeps running until all loading is done, and once it loads the next asset, it will increase a counter, so I can poll how many assets are done and then update the progress bar.

However, I was quite shocked when I tested out the background loading process. It's slow as hell! It took 94 seconds in debug build and 87 seconds in release build to load all 58 assets in just 2 colors. Image how long it'll take when you're playing with 6 friends...

Slowpoke is slow :(

So yea, background loading is in, except it's terribly slow. In fact, it's so slow, it's unusable to develop the network play with, because having to wait ~1.5 minute before being able to test something out is too much for me.

For the coming tests(The actual network gameplay), I'll be testing with a reduced preload set, just a handfull of units / buildings.

A peak into Dune's protocol

2007-12-04T16:33:00.000-08:00

I'm currently happily coding away at the Lobby for the game. Most of the code is in now, with the exception of colors / factions / map. I'll add in which map will be loaded soon to the host as a command line switch (dune -host 2 -name Host -map mp_test.map). I also added in most of the code for the LobbyClient. When connecting to the server, it will display a nice "Connecting..." text and when handshaking between client/server has been completed, it will show the same text as the lobby(ie, n out of m connected players).

Now, let's dive into the messaging system:

I decided to cut up the system into small, manageable components. This means there's a Server, LobbyServer and GameServer. The Server object manages the connections and routes the messages to the sub-system. The responsibility of the LobbyServer / GameServer should be obvious.

Because I wanted to seperate out the systems, the first byte in a message is the 'targeted' sub-system. The 2nd byte is the message and the 3rd and beyond bytes are message specific:
1 byte 1 byte n bytes
[Sub-System] [Message] [Message Specific Data]

There are no fields in my messages which specify the length of data. Because Lidgren handles all the low-level stuff, it will wrap my data into UDP packets, and reading data back is as simple as msg.ReadString() / msg.ReadByte(). No need to check for correct length, or if all the data is valid: Lidgren does that terrible work for me.

The pro of my system, is that I don't get insanely long switch statements to handle all the messages. This is how my 'main' message pump looks on the server:

It's quite simple, and adding new sub-systems is a matter of seconds.

The ProcessMessage() then reads the next byte in the message, which contains the message, which is used to pass it to the correct handler. That looks like this:

How each message is composed isn't really that important. I can give you the exact details, but it sounds more boring than interesting.

We get signal!

2007-12-03T14:22:00.000-08:00

Hmmm, I think I used this title before… Not sure. And who cares anyway? It’s Sunday evening 22:45 now, almost time to get some shut eye before heading off to work.

Before diving into my bed, I’ll write up some nice post on my progress on the Dune Networking Components, and post it when my internet connection is back up again.

At the moment, I can connect clients to the in-game lobby. It will accept their connection, and once it receives a handshake, it will return their player ID, and a list of all connected players. This needs to be expanded with a faction and a color, but that isn’t in yet.

This is how the Lobby looks like server side:

Looks pretty sweet eh(I think I broke my FPS counter… There is no way in hell that runs at 35 FPS)? Well, it’s far from done, but I’ll get to that later on. This is what the basic lobby still needs:

Handling of disconnects
Player colors
Player factions

There are more things required for the lobby, such as map selection, game options(Starting credits, starting units, how do we handle starting points(fixed / random), spice blooms, etc.). But for the sake of simplicity, I don't add those in. It would only complicate things while I want to get basic networking up and running.

Don’t get me started on the client side… That one just connects and sends the handshake. Nothing else yet. That's next up.

For the networking library I’m using the Lidgren Network Library. It’s pretty awesome if you’re working in .NET. It’s extremely easy to use and does all sorts of things for you, such as internal clock synch, message re-sending, etc. Speaking of which, I should see if there's a new version out the library. The version I'm using is a few months old.

No technical details to explain to you guys yet, so you have to wait a bit longer. The cool technical details come when I start working on synchronizing the simulations.

Let's get connected!

2007-12-03T14:13:00.000-08:00

It’s been a good month(!!!) since I did a update on the devlog. So I figured I’d give you guys a new update on how things are going. The updates are going in a bit weird way this time, because I made an oopsie with my internet bill(I accidently forgot to pay a month, and they put a nice “Please pay us and you get internet access again kthx” banner whenever I browse to any website.

That’s the annoyance with all the moving around, you miss a bill and then they shut you off. However, they put a filter on my line at Friday afternoon 18:30, 30 minutes after closing their billing department. If they did it an hour earlier, I’d fix them up the bill immediately and there wouldn’t have been a problem.

But, this is good news for Dune. As I can’t waste my time on the internet, I decided to start coding up the network components for Dune.

Design

As opposed to earlier posts, I decided to actually go with a Client / Server setup instead of a star setup. The P2P star is difficult to set up and I couldn’t figure out a way to be 100% be sure all clients would have the correct amount of data to make sure they don’t go out of synch.

Downside in my current approach is that the host will have to have at least n times as much bandwidth as regular players, where n is the amount of players – 1. But, in a time of broadband, I doubt that’ll be a problem.

I still intend to go with the turn-based approach: Each set of commands is send 1 (or 2) turns ahead of the current one. Turns are executed at a determined interval(for instance, 200ms) on authority of the server. So, when turn 1 is running, and the server knows all the clients have received the commands required to execute turn 2, it’ll send a StartTurn 2. However, this will mean, that if 1 client has a roundtrip time above the turn-length, the game will start to lag at some point. In order to prevent this, I intend to add some form for heuristic to automatically adapt the turn-time based on client pings. However, this won’t do magic, because if pings are above 300 ~ 400ms, turns will take too long and players will notice lag between commanding a unit and actually executing it.

Implementation

At the moment, I’m implementing the basic server / client code. The server runs as a Task in the game, as it needs to be updated at least once per frame. Next to it the client runs its normal simulation at the moment.

I’m still doubting if I give the server its own simulation: That would mean the hosting player would run the game twice: Its own copy, and a server copy. On slow machines, this would mean it would lag(Or to be more precise, run at low FPS).

However, I could hand the Server task a reference to the client simulation and use that as a base. It could generate checksums of that and request checksums from other clients to compare and kick out-of-synch players. But, that’s too far ahead.

I intend to write the code that hosts a basic lobby and let’s other clients connect. No graphical goodness tho, just basic command line stuff like:
dune2.exe –host 2 –name or dune2.exe –join -name

Once a client can connect to the server I can add the code to start a game and just show the same scenario on both game instances. I think that’s a challenge on its own already.

Updates!

2007-10-25T03:34:00.000-07:00

So, let's explain what I'm up to all this time.

Personal situation

Last summer I landed a job as System Administrator at a company. The company itself had about 150 employees, and my job was assisting the sitting sys. admin to keep the servers up and running, fixing issues, etc. While the job was fun at the start, it become pretty boring in the long run. Esp. when the main sys. admin was on vacation, I had almost nothing to do. But, I needed the money to pay for college coming year. This was one of the reasons I stopped development on Dune: I came home from work after around 18:30, had to make dinner, eat and clean up again. By the time everything was done, the last thing I wanted to do was code.

Eventually, when classes started again, I worked there for 2 days a week, as it was a nice solid income. However, after a few weeks, I got an e-mail from a professor, with a job pamphlet. An acquaintance of the prof was looking for a student who wanted to do some C++ / OpenGL development on an existing CAM software package. So I called the guy, went in for a job interview and got hired.

So, right now, I'm working 2 days in the week as C++ programmer on CAM software. The software itself loads a CAD model on which the user can then do several operations to prepare the model to be cut out in wood, plastic or metal. Editing the model has to be done in CAD software, so the transformations are mostly simple ones. A pro of this job is that it pays 50% more of my old job, which is even better.

I also have a load of school assignments to do, which have a higher priority than Dune has.

Dune 2: The remake

I never intended to permanently cancel the project, I just didn't have any time to work on it. The downside of hobby projects eh? Anyway, I intend to continue development in the coming months and pick up where I left off: The networking engine.

Last night, I was considering my options on what I could do to get it working across the internet. Initially, I intended to go with a Star Topology network using UDP. Each client would connect over TCP to the host, which would then assign a port number to the client. Using NAT Punchthrough, the client would then connect to the host over UDP over the assigned port, and disconnect. The other clients would then connect to the client as the port would still be open. However, this is quite complex, and I do not know if it works. Since UDP is connectionless, the UDP port should stay opened in a router for a short time span, even after "disconnecting". However, I would need to test this to verify that it actually does.

If it won't work, I'll to go with a traditional client/server approach. However, I still intend to go with the same approach as AOE, go with turns, etc. However, this would be a problem in a P2P setup, because how do I ensure that each player executes the same commands?

For instance, consider player 1 moving units 10 and 11. These orders will be send around the network to be executed for gameturn n. Each client will respond back to player 1 that they received the orders. But, how do the other clients know that all the other clients have received the order aswell? If one client does not have these orders, and all clients execute the turn, this client will run out of sync, and gets kicked. So, I need to work out a little bit on how we're going to do this. I could technically let each client send a hash / CRC of all received commands from the other clients to the 'host', which then determines which commands get executed and which get re-scheduled for the next turn.

As you see, lots of thinking to do. I should make a few diagrams of this, as it's quite confusing in words only.

More info tomorrow!

2007-10-24T15:58:00.000-07:00

I'm writing this in my bathrobe as I'm preparing for bed, but I got quite some ideas. I intend to work these out a little bit more tomorrow(Technically today, but it's tomorrow since I haven't slept yet :P) in a blog post, and try to examine the different possible solutions. Especially geared towards the networking engine.

I shall also try to explain my current personal situation and the amount of time I have at hand to work on the project, because I also need work 16 hours a week, and have class.

On a sidenote, someone commented that I used the term "fans", and said some of them are interested onlookers. I never meant this in the way of, "wooo, I got sum fans lol!", just as a little joke / term to described people interested in the project. But, the onlookers and die-hard Toolmaker fans(The ones having my name tatoo'd all over their body), rest assured, I shall try to work on the game a bit :). Good night for now.

Not dead yet!

2007-10-23T02:37:00.000-07:00

Sorry guys! I have been really busy with a lot of things, so I couldn't spend any time working on Dune.

Last summer I worked the entire summer(I needed the money to get through this college year) and when I got home, I didn't really feel like coding anymore, even tho it was a system administrator job. After summer vacation was over I dived into school and got covered in work.

I recently started a new job as C++ programmer, for 2 days in the week besides to school. I didn't do a lot of coding for the past few months, so perhaps this will get me rolling again. I feel like coding a bit on Dune later this week. I don't have an awful lot to do this week.

Again, sorry for the lack of updates and the lack of progress. I know my "fans" are watching :D

Networking

2007-07-20T00:31:00.000-07:00

I've started to look into the networking code for Dune. While I'm currently still in a phase of trying things out in a sandbox environment, I will work on the networking code from now on. Once that's in, I will add the other missing features in Dune.

I initially read a few articles on other (commercial) RTS games and how they did their networking. For instance, Age Of Empires used a Peer-to-peer setup to communicate with all the other players. The game was a perfect simulation on each client. They accomplished this by make the game 'turn-based'. The player input would be registered, packed up and send to all clients. Each action would be executed in a turn, and when the data was send out to all the other clients, it used current turn + 2. So, when the current turn was 1000, and the player wanted a villager to go and chop down a tree, the actual ordering would happen in turn 1002. Since turns only lasted 200ms each, the player wouldn't even notice the delay between clicking and seeing the action.

However, in such systems, it's problematic when lag is 500ms: A packet send with orders scheduled for turn 1002 would arrive during turn 1003. AOE would adopt to this by either halt the game(In severe cases), or stretch up the time needed for each turn. In the case of 500ms lag, it would increase the turn time to 250 or 275ms, giving each packet more time to arrive.

This seemed to work well(I tried AOE2 to test it out) and it ran like a charm. So, I wanted to implement a similar to that of AOE2. However, setting up a P2P network between clients is a pain in the ass. Esp. when you take NAT into consideration. The system would have to work like this:
- Each client connects to host
- On start game, the host opens a series of new ports, one for each client.
- Each client connects to this port and disconnects directly
For each client:
- The host sends all other clients to which other client they should connect by handing out the IP and port number.
- The clients connect to the other player since the NAT port is now opened up

- Host is done when all players are connected to eachother.

It's quite complex, and I'm not sure if it would even work. Perhaps I should give it another shot and try to set it up. Once it works, it should work like a charm.

Bugtracker update #2

2007-07-14T14:32:00.000-07:00

It's been a while since I updated... I've been really busy. Since the summer vacation begun, I found myself a summer job. Right now I'm a system administrator at a large company. My job is to check out how Windows Vista will fit in the existing environment and how the group policies behave in them, since Vista doesn't eat the older formats. I also have to take over the responsibilities of the other system administrator when he's off on vacation.

I just continued with experimenting with bug trackers. I tried to install Trac, and failed. The reason: It seems it can create an sqlite database, but no matter where I try to create it, it just fails. If I create it in the root of the C drive, it fails with the error Access Denied, and if I use an existing directory, it screams that I can't create a new directory(Well duh!). So I gave up.

One of the biggest downsides of Trac is that it requires quite a lot of external dependencies. In order to run, you either need a running Apache configuration with CGI / FastCGI / mod_python installed. You need sqlite(Since MySQL is very experimental. And to be honest, I don't like to run experimental stuff on my development environment).

So: Bugzilla is left. I've decided not to install / try any paid trackers, since those are outside my budget anyway.

One a sidenote: I did have some more time with Mantis this week. Even tho it lacks SVN integration, it's still a pretty nice system. I like it, and if Bugzilla doesn't behave better, I'll go with Mantis and setup a SVN integration system. I can't remember the name right now, but it's capable of glueing Mantis / Bugzilla to SVN.

Bugtracker update #1

2007-07-10T11:39:00.000-07:00

I haven't done a whole lot of research on bugtrackers in the past days, but that's because I've been doing some other things aswell(Like snowboarding the entire day. Yes, in the middle of the summer.). However, I can do some reporting on things I've done.

First of all, I installed Mantis. Since I already had an instance of Apache running, I could just install PHP for it, install MySQL and voila, done. After that I added a few bugs to the system to see how it works and looks.

A few downsides of Mantis:

Documentation on the site is lacking
The My View is kinda cluttered
Not possible to assign a bug directly to a developer while reporting it(Actually, you can, but you need an advanced report for that)

But, it also has a few nice features:

Easy to install(Just open the index page)
Detailed report information
Multiple projects in 1 database
Projects can be made (in)visible to certain users, users can have roles in projects

So far, I like Mantis. But, I still have to look into a glue system to glue it into SVN(Which is out there), since it's pretty nice to be able to link repos updates directly to bugs.

I also made a start with installing Trac, but that requires quite some more work...

Counting the credits

2007-07-07T13:35:00.000-07:00

I implemented the credits counter today. It's a simple little UI component that I managed to whip up in about 1.5 hours, including sexy 'animation'. After setting the credits, it compares the amount with the visible credits. In then calculates the difference between the 2 and divides that by 2(seconds). During each frame update, it multiplies the pre-calculated value with the deltatime and voila, you get to see an update animation.

It's not exactly like the original, that seemed to rotate around, but that's too much work to implement for now.

The credits counter in the top right

I'm also looking into using a bugtracker. Right now I'm using the SVN commit logs to document bugs, but that's not the most efficient way. So using a bugtracker might help with bugs that I intend to fix on a later date. As for now, I keep forgetting to document all the bugs, remember them AFTER the commit and write them down. And then lose the note with the bugs.

So, I'm looking at Mantis and a few others, and I'll make my decision soon(probably tomorrow). After I fixed my server... Yes, fixed... I decided to remove a bunch of server roles which I installed for testing purposes. However, after I removed the Terminal Server role it had to reboot. After the reboot I could no longer login remotely, so I'm trying to fix that now.

Carry-alls and harvesters... An excellent combination

2007-07-05T12:45:00.000-07:00

Today I added in all the goodness for carry-alls to pickup harvesters and deliver them into the refinery. It was quite some work to get that working, since I had to code in a few extra special cases(is this a harvester, does it have clearance for the refinery, is the landing area actually the refinery, etc.). But, now harvesters DO get picked up by a carry-all, if around, and they'll fly em into the refinery. And flying is SO much faster than driving :).

Carry-all just picked up harvester enroute to spice field.

Also, a newly built refinery now will receive a free harvester, which is dropped off in style by a carry-all, which will depart immediatly after dropping off the harvester. After the carry-all leaves the onscreen boundaries, it will delete itself.

Fully loaded harvester being returned to refinery

The carry-all which delivers the reinforcements into the field is a little special carry-all, namely a ReinforcementCarryall. I wrote a special class for it, since I didn't want to implement the code for leaving the field in the regular carry-all. That would really pollute the code. Also, this new Carry-all makes it possible to have regular reinforcement drops too, which is pretty sweet. Including stuffing 20 units into it.

But, there's a little issue with the carry-alls right now: When a tile is used, it won't be able to drop off it's payload, and just keeps hanging there, until the tile becomes free. So, that's what I'm going to solve next: find a free tile and unload there.

I already wrote a similar thing for the harvester to find spice tiles, so I'm considering to make it a general helper class and use a generic Comparable kind of thing. It's code that won't be called too often so speed isn't a really big issue here. And added goodness is that I can 'smear' out the search over multiple frames. In the case of finding a spice field which needs 200 steps to be found, it will cause severe lag. Being able to do this is say, 40 frames, it will only be 5 steps per frame, and therefor no big deal.

After this works, I'm going to fix a little bug with the selection rendering, constructing and then finally implement the credit counter control.

Spice must flow!

2007-07-02T08:15:00.000-07:00

And flow it will! I spent the weekend implementing harvesters and refineries. Right now, a harvester is capable to driving to a spice field, happily seperate the spice from the sand, find a refinery, drive back and enter the refinery. Once in, the refinery will empty the harvester, provide credits to the player and when the harvester is empty, it will deploy it.

Our initial state: Idle harvester and refinery

Most of the harvesting code is still the same as it was before, but I also changed quite a lot. Most of the changes are in the refinery, which now has a 'landing zone', the area where the harvester has to land in order for the spice to flow. Initially it used the building coordinates to find it's way into the refinery, but this meant the harvester would drive to the center of the building. Also, I updated the images concering the harvester and the animation, so they use up less VRAM(Altho it came with a dirty hack: I have to figure out in which directions to displace the animation, otherwise it looks dislocated)

The harvester is collecting spice

When a harvester is full, it will request a list of all known refineries. It will traverse this list and attempt to find the most suitable refinery. That is, with the shortest queue or no queue at all. When it comes by an idle refinery, it will stop searching. When it has found a refinery, it will inform the refinery that it's enroute, lay out a path and start it's dangerous journey back home(Esp. when no carry-alls are around). The refinery will now start 'blinking' it's landing zone(when idle), or otherwise just queue up the harvester.

Harvester returning to the refinery, which has a blinking landing pad

When the harvester has reached the refinery, it will wait for clearance. The clearance means the refinery is ready to receive the harvester and refine whatever goodness it brings. When the harvester receives it's clearance, it will roll onto the landing zone and remove itself from the scene. This is important, because it will otherwise keep rendering itself, which will look weird: A harvester ontop of a refinery with a harvester in it. The refinery stores the harvester internally, so when the refinery is destroyed, it will automatically destroy the harvester aswell.

Refinery processing a harvester

It takes 35 seconds for a fully loaded harvester to unload(20 credits per second). When done, a harvester will ALWAYS be deployed, even when a carry-all is signaled to pick it up. This is done because it might take a while before the carry-all arrives, and when deployed, it gives other harvesters the chance to enter the refinery. This was something that annoyed me in the original game: When a harvester was waiting for a carry-all to arrive, it took a while, so other harvesters had to wait, while I was already low on cash.

To do:
- ~~Have harvesters return back to the spice field~~
- Limit the number of tiles searched for new spice
- Harvester spice dunes first, then normal spice
- ~~Fix bug related to tiles not being free'd~~
- Have a carry-all unload the harvester into the refinery
- Have carry-alls bring a harvester to a newly placed refinery

Epic debug sessions

2007-06-22T06:37:00.000-07:00

I'm currently busy with some epic debug to fix a some major bugs in the movement code. It suffered from units running over other units, where the unit that was being ran over disappeared. It still rendered, but it no long accepted orders, could be selected, etc. I also had units that would not clear tiles they occupied properly, so that in some cases, tiles were still used while the unit was half a map further, which led to other units behaving strangely when driving. And last, units sometimes 'jumped' to other tiles and started vibrating. Yes, vibrating... No idea what causes that.

I fixed in the past week the run overs, which is nice. By fixing this, I haven't seen units warp since I fixed that, nor vibrate. So it seems that I only need to fix the clean up. I made a nice function which runs a check on the entire map and shows which tiles are used by what unit, and if this unit is actually positioned on that tile. And if not, it shows a [ERROR] tag. In combination with the debug log I hope to find out where it goes wrong.

After this works, I'm gonna make units 'defend' themselfs from others. ie, if attacked, they'll start attacking their attacker.

Let the vehicle construction begin!

2007-06-11T11:56:00.000-07:00

I got unit construction in. Wasn't a lot of difficult work. It basically was adding an additional check to the techtree retrieval function, and if a tech item was a unit, place the icon in the Unit strip, and otherwise the building strip.

The rest of the system is the same: The building asks the ConstructionManager if there's a job waiting for him, and if so, it takes the order and executes it. When done, it will now check what kind of object is done. If it's a unit, it will check if there's a free spot around the building, and if yes, it will deploy the vehicle there. When there are no more tiles free around the building, it will show a nice message in the debuglog telling me to implement carry-all's to pickup tanks from buildings(Which is actually really friendly).

I still have to implement showing a deployment animation when a unit is deployed, but that's not that difficult. It's a matter of minutes to implement the additional class(ConstructionBuilding) and the code to trigger the animation.

The next step is to give each unit / building a unique ID which is also linked to it's owner. I'm running into some nasty bugs, which makes debugging difficult if you got 20 units on the screen and 1 flips out...

Bugs I have at the moment: When a unit runs into an obstacle along it's path, it will try to find a new route. If it can't find one(Because the blocking object is the end-tile), it suddenly changes it's position to 1 tile back and starts vibrating... Very odd.

The other bug is related to units popping their states off the stack for no apparant reason. That only happens when moving in groups tho, so I need IDs to track them.

Units after their construction

To do for next time:
- Add IDs for units and buildings
- Fix movement bug
- Fix state popping bug
- Add deployment animation
- Add icon sorting to the construction bars. It's annoying to have the order change depending on how you build the buildings(Or if you lose your barracks half way) and the icons end up in the bottom.

Bug fixes, loads of them!

2007-06-07T13:19:00.000-07:00

While technically still in development I hunted down and squashed a load of bugs in the past few days. Having a laptop and being able to work in the train is awesome. Every now and then I see people take a peak at my screen to see what I'm doing. Earlier this week there was a guy who just kept looking at my screen, and back outside, back to the screen, etc. Esp. when I fixed a little thingy and ran the game again to see how the changes worked out.

First, the list of bugs I managed to strangle(For those not interested, skip down, there's imagery there).

Fixed bug where buildings would be placed 1 tile to the left and 1 tile up
Lowered scrolling threshold to be Tile.Size / 2(So scrolling only happens on the edges, instead of 1 complete tile)
Fixed bug where you could order buildings to move/attack(Would cause crash)
Dragselection rectangle / Building placement rect don't show up when hovering over UI components
Renamed Radar to Outpost(Needed for Reflection to work)
Fixed bug where placement rectangle would be rendered OVER UI components while while the mouse was outside the component
Buildings can no longer be added to the building manager of a different owner
Fixed debug log text
Added a little bit more debug output
Fixed an issue where the CheckMouseOver() function would read out of bounds
Fixed an issue where the mouse handling code would respond to mouse clicks in the UI

As for the new feature: I added concrete slabs. Not very special as you can see below, but still, it's in. I think the next step to this is to allow buildings to build units. After that I think it's time for refineries to 'order' a harvester reinforcement.

I also noticed that the revision number updates weirdly... I have a pre-compile step which runs an svn lookup batch file to determine the revision of the repository, turn that into a sexy class with getter and store it all. However, it doesn't always(read never) run when compiling. Pretty weird, and annoying. Probably only runs on a full re-compile, so I usually just run the batch file manually after commiting my code. Not the best solution, but it works.

I also started committing more often, since I used to do too much work between commits. If my laptop would either explode or get stolen, I would probably lose a week or 2 of work. Not really that appealing...

Building placement is in

2007-06-06T06:22:00.000-07:00

In the past 2 days I put the code together for placing buildings on the map. While not completely done yet, I also found a few bugs in the code relating to writing to the debug console, finding items on the map and the techtree.

I'll be going to fix these issues before adding in the construction of vehicles and implementing the credits counter. But after I cleaned up the input handling code.

First some screenshots:

Debug console display we started building a new WOR. Note the 'built by' bug.

Placement of our new building not allowed here, see debug console for next error

And voila, our new building is placed, including sexy deployment animations(Not included)

The next step is moving all the input code into the LocalPlayer class. Hooray for .NET partial classes, since this will prevent my code from turning into a huge pile of steamy mess that could make even the most seasoned developer cry himself to sleep.

After that, I will first fix all the bugs I've found till so far and then I'll implement the placement of concrete(yay!), the penalty of placing a building without concrete and construction of vehicles. If those work, I'm considering implement a basic network framework(!!!) and then start polishing up basic features. When these features are implemented (Which will take a while), I have a basic playable RTS.

Construction is in... Now building placement

2007-06-01T02:07:00.001-07:00

Over the past few weeks I've slowly implemented construction of buildings. It's possible to now select a build icon from the sidebar and add it to a construction queue. Each building checks every update cycle(But only when idle) if there's a queued up item, it takes from the queue and starts 'building' it.

When done, it informs the player object about it, which can then take the appropriate action. A human player will see a message / hear a sound and an AI will place it directly.

I'm currently working on implementing the building placement. However, I still don't know how to fully implement it. I currently have a GameInputHandler which handles that part of the input(Do the picking, context sensitive cursor, etc.). But, I need to change it around to be less, messy.

Also, I've been thinking about adding a feature for hearing impaired. One of my current projectmates for a college project is deaf, and one of his biggest issue with most RTS games is that he never gets a message about that his base is being raped. (He usually notices that he's getting his ass kicked when it's too late...) Well, there is a warning, but without working hearing, he can't hear it. So I want to add an optional screen message, which blinks in the middle of the screen. Simple to add, and usefull for those who can't use sounds or can't hear. Having people in your projectgroup which have a minor disability widens your view a bit.

I am an idiot, srsly

2007-05-16T01:15:00.000-07:00

I'm an idiot. A huge idiot. Remember how I reported about rolling out 2 Draytek Vigor 2800G routers? Turns out I ordered the wrong routers. A 400 euro mistake.

The routers I ordered come with a built-in modem, and all snazzy features that the router has, are done on the WAN interface(The modem). But, Versatel doesn't allow their customers to replace the modem with one of their own and the new line that was in the new office was an SDSL line. So none of the routers can be used.

I'm trying to order the Vigor 2910 now, which is used to cable(And therefor, has a WAN interface where an RJ-45 plug fits in). I'll contact a reseller to see if it works on the SDSL line and Versatel, and if so, see if I can get a hold of them today and roll them on tomorrow(Which was supposed to be a day off)...

Idiot...

Problem solved, and the lack of updates

2007-05-14T14:57:00.000-07:00

I'll kick off with some good news: I solved the issues with the weird rendering of vertices. I got the advice to toggle some of the important and basic D3D feats off/on to make sure it all didn't get messed up.

I decided to walk the list of D3D renderstates and pick the ones I knew and change them to be off. This was lightning, Z-Buffer, CullMode and FillMode. Turns out, the z-buffer was the problem. So now i know where the problem lies, I can continue to work on the issues at hand.

However, there is a reason for the lack of updates: I'm very busy at the moment with school and my business. For school we have program a robot, and most of the hardware of the bot was dead. So we got new hardware, and need to update all the code to work with the new hardware, re-write all the PIC controllers(They burned out, and no source was avaliable) and implement new features too. And I got a few clients that demand my attention aswell.

Tomorrow I will be delivering 2 Draytek Vigor 2800G to a client. And these things are pretty sweet. They support up to 32 simultaneous VPN connections, protocol blocking, content filtering, url filtering and they're wireless too. It's pointless for home usage(As they're 200 euros a piece), but for a business, it's pretty sweet stuff.

Some minor issues...

2007-05-05T15:11:00.000-07:00

I'm currently having weird issues rendering linestrips... I noticed this week that the drag selection wasn't rendering anymore, so I went to search what the cause of this was.

I still have no idea what causes it, but the more I test, the stranger the results: After a a reboot or running another DX application, it now shows a filled triangle(As it should), which it is striped. However, when I move my self-rendered cursor over it, it disappears.

Restarting the application doesn't work, it just doesn't show up. Pretty weird... I asked on GDNet, hoping they can help me out....

Almost a game...

2007-04-23T14:39:00.000-07:00

Today I merged the UI code with the Gamestate code. And lo and behold: Something that looks like a game.

Almost a game, almost.

I discovered there is something severely messed up(I nearly wrote fucked up) with my Post-Build step. It doesn't update the revision in the bottom of the screen properly. It probably has to do with TortoiseSVN and it not going a proper update after the commit. Because if I do an update after the commit and recreate the file, it works like a charm. Pretty weird.

Also, I'm thinking about how I am going to handle building of stuff. First of all, I need something that manages buildings. We shall call this the BuildingManager. The BuildingManager contains a list of all buildings in possession of the player. When a building is destroyed, it will remove it, etc. Also, I need something to uniquely ID the buildings across the network(Yes, I'm also thinking about). So, each building will have an unique identifier, which is nothing more but a sequential integer.

When a building is being constructed, the BuildingManager will receive it's application and store it. It will then return the unique identifier to the building and inform the network about a newly constructed building. When it is the first building of it's kind, it will also contact the ConstructionManager. The construction manager will look in TechTree and see if there are any changes needed. If for instance the building just placed is a construction yard, it will see that after a construction yard has been built, the slab and windtrap will be unlocked. It will then add these to the construction sidebar.

For a networked game, there will be a RemoteBuildingManager(RBM) and a RemoteConstructionManager(RCM). The RCM will not schedule any construction, it will only pass the order to the correct building. The LocalConstructionManager(LCM) however, will find an idle building and post the build order there to be completed. This has the added pro of the game being able to check if a player is using hacks(Because, it can see how long it takes before the next build order arrives. If the remote player has an instant build hack, it can see that the player still has to wait for the construction to be completed).

So, still a lot of work to do, and I'll start out with the techtree loader tomorrow.

Hello Arrakis!!

2007-04-18T16:04:00.000-07:00

I added some more features to the Windowing system, and I think I'm done for now with the system. All that remains are the controls to be written, and I'll write those as soon as I need them.

Features I've added:
- Complete rendering of the borders and title bar
- Client rectangles(Client Rectangle = Window - borders)
- Dragging of windows
- Move event for when the window is being dragged around

The dragging of the window was quite some work, as I needed to change quite a lot of code. It wasn't very difficult, just required a lot of code changing, since I never wrote the code to be able to drag the windows around, nor intend to have borders around it them(Pretty stupid).

This initially ended up with the Control class drawing itself on the wrong position while being dragged, and the derived class draw on the correct position. Pretty weird, and I still have no idea why this happened. The image below shows this in action(I had to place my fingers in a really uncomfortable position to be able to get this pic. My left hand pink and ring finger held down the FN + ALT key, while my thumb help down the L-mouse on my touchpad, my index finger drew circles on the touchpad and my right hand was used to pressed Print Screen).

Dragging bug in action, nearly lost my fingers while obtaining this image

After I fixed the dragging bug, I'd figured I'd make a standard dialog window(Not yet written, but the code needed for it is ready, just need to be moved into another class). This is what it looks like:

Standard dialog with label and button

How does the dragging system work?
When the L mouse down event is catched, it checks if the mouse is over a window. If this is true, it will check if the mouse is within the ClientRectangle. If this isn't the case, it checks if the Y is within the bounds of the TitleBar. If this is true, it will record the state as Dragging for the LMouse button, and which control it is dragging.

On every mousemove, it checks if the LMouse is down, and when this is the case AND the state is dragging, it takes the Delta X and Y and substracts this from the position of the window. It then forces to update all the client rectangles and voila, done.

New control
I added a Label control. Not very special, it took like 2 minutes to create...

Todo for now:
- Create a MessageBox class.
- Add support for modal windows
- Incorporate UI into existing game class.
- Build CreditCounter control(Dune specific)
- Layout new todo list for building, techtree, etc.

Also, to answer a previously asked question about open-sourceness:
For now, I will keep the source closed. This is a personal project, and I don't take kindly to people changing my code while I'm still working on the game. However, after the game is completed, I might open-source it. However, I might, might release my UI system, in case people want to take a look at it, and perhaps improve it. It's not the best system out there, there are MUCH better UI systems out there, but it works for a small amount of controls.

Image strips are in... And update on dialogs

2007-04-15T14:24:00.000-07:00

Today I managed to add the images into the imagestrip. The image strip is the little strip that holds all the icons of the units/buildings you can make, and allows you to scroll through it.

It was rather simple to implement, except I ran into 2 little problems: The original images that were used in the original Dune for the imagestrip end up HUUUUGE when enlarged. So I scaled them up 2 and then reduced them to 66% of their size. That worked quite well(As you will see below).

After that it was a matter of painting the green bar between the 2 images and fit a few images in. Fitting the images in wasn't very difficult, except that was were the other problem was: The icons Stefan provided with his Dune 2 image set were too small. Increasing them in size turned out horrible. Really horrible. Loads of artifacts and they were pretty pixelated.

So I had to find a way to extract the images myself. This was rather problematic, as I had no idea which of the PAK files contained these images, and only 1 PAK file contained the palette files. I downloaded XCC Utilities and started messing around, but I was unable to load a palette after loading a new PAK file.

Eventually I extract the palette file, made copies of the MENTAT.PAK and FINALE.PAK. I then opened up XCC editor and placed the palette file into both these files and saved them. I then loaded up FINALE.PAK and MENTAT.PAK into XCC mixer and discovered that mentat had all the images, but that finale.pak also had a bunch. Duplicates that is, since all these images were also in mentat.pak. I have no idea why there were 15(!!) duplicates in the FINALE.PAK. These images(All just 1 frame) were the sardaukar, death hand, fremen, refinery, MCV, sand worm and a few others. When I looked in mentat.pak, I fould all the images, with their animations.

I extracted these files, and converted them into icons. The icons are 52x32 in size. If anyone wants these, for whatever reason, let me know, and I'll upload them. I also have to extract a few other files from the dune.pak file, since these are missing(I think I'm missing 1 missile impact animation and the burning/burned out tank).

Right now I need to update the image strip so that clicking is supported, it's possible to mask out all the images except 1(The building animation, not sure how I'm going to do that with multiple construction queues) and I need to fix the windows and their title-bar/border drawing.

The UI in action, showing the image strip(Scrolling works) and a window with title bar

I also need find a better way to render client areas of Windows. Right now they are textures. That's a a massive waste of VRAM, so I need to fix that. I'm probably going to use quads for the client area and just cram them into a VertexBuffer and render all the client areas at once. Not sure how that will work out, but I'll experiment with it. Alternatively, I could just create 1x1 textures with the correct background color, and rendered them stretched. Don't know which one is less work and/or cheaper to do in terms of performance.

More gooey goodness...

2007-04-12T16:27:00.000-07:00

Ok, f this. I just spent 30 minutes writing up an entry about my awesome progress with in-depth details of decisions, backgrouns and other information, and then Firefox decided to crash.

When I restarted it, it recovered the session, but the entire post was gone. And apparantly, clicking 'Recover post' does nothing, except show up a messagebox that it will replace the post with an older version. WHAT OLDER VERSION?

Here's an image of the UI in action: A button with the mouse over it and the left mouse button down. Hooray, BOOOOORING! And yes, I'm annoyed now. Really annoyed. Annoyed as in I want to break something. And yes, I have anger management issues. It's a miracle I never killed someone.

A really not very exciting image with a button responding to a mouse down event. Tee hee

It's my birthday...

2007-04-11T05:34:00.000-07:00

So yeah, I turned 24 today. Nothing special, just a funny cat. Also, I have no time to code today.

Still working on the UI....

2007-04-09T14:25:00.000-07:00

Yes, I am working on the UI stuff. I got the events sorted out, and I'm right now working on rendering the system controls and the window bar. Nothing special to see right now.

To keep you guys happy, here's a cat. DuneCat

User Interfaces are GO!

2007-04-07T15:40:00.000-07:00

So, yesterday I started working on the user interface code. I thought it over a bit, and came to the conclusion I would go with the "Everything is a window" approach. The reason for this was so that I could make the WindowManager class a Task, shove it into my engine, and forget about it.

However, it made me think later on: What if you're playing an FPS, and everything is a window? Then there might be a chance that you have your comm. window open while laying an ambush. You suddenly see an enemy walk around the corner. He hasn't seen you yet, so you jump up, aim at his head and hit left mouse. But instead of shooting him the head, you'll order a pizza from the comm. window, and end up dead yourself. Oops, comm. window stole the cursor focus.

So, before I managed to mess everything up, I changed it all to be "not-everything-is-a-window", and non-task. Basically, I have to keep track of the WindowManager now, and during each update cycle check if the mouse is over a window, and then ignore the input in the regular game handler. When it's not over a window, I do my normal mouse logic. In the case of the FPS, it would mean I have to press a special button before I'm able to interact with the UI.

Right now, basics are in, that is: I have the WindowManager, basic flat-style windows and response from the windows from the mouse. As seen in this exciting image(I merged to images together, because having 2 huge black images with 4 colored squares is boring).

Basically, I clicked on the blue window, and it came Top-Most. Exciting huh? Indeed, it's not...

Before I started to work on the gooey system, I also updated my mouse input code a bit. It no longer uses DirectInput but regular Mouse Events. This has the added advantage of that I have the mouse acceleration that Windows provides for me(Before, the Windows mouse would move faster than the in-game mouse. That's now fixed.). Also, the Windows mouse cursor is now hidden. I have no idea what kept me from doing Cursor.Hide() in the first place...

Tomorrow and monday it is easter(Yes, we have 2 easter days), so I doubt I'll manage to do any work on the gooey system. But, I'm currently writing the mouse-event cascading system. Meaning: When the mouse is over a certain window, this window will check for any updates(movement, etc.) and trigger the events, and then see if any of it's children need to know about the mouse update. I started out with this code to be in the WindowManager, but that ended up being a horrible mess. So I now leave this to the base Control class.

IT'S A TRAP!

2007-04-05T06:35:00.000-07:00

I finished coding up the windtraps.

The technique behind this is pretty easy. What I do is create a static texture for all windtraps in white. During rendering, I first render the white texture with an overlay color, and on top of that, I render the normal windtrap texture. And in the Update() function of the windtrap, I have a timer to increase/decrease the color every 1/10th of a second. Simple, and effective.

I will probably add this texture to the SpriteSheet, as it would reduce texture swapping. And texture swapping is bad, m'kay?

I also added a link to the development blog of an online friend of mine. He's developing a 3D engine and a bunch of games with it. Except it takes him a decade to produce it all. Yes, I'm serious. A decade.

Building basics are done

2007-04-03T17:52:00.000-07:00

I got the basics of the buildings in! And by basics I mean the image files, the classes(Each building has it's own class, as oppossed to units which mostly consists of 1 class and a few derived for special units).

Buildings in action

The reasons are simple: Most buildings have a bunch of animations which are non-standard(starport, refinery, radar), buildings also add 'things' to the game. For instance, building a light factory, enables you to construct new units. By spawning the building, it 'registers' itself with the game, exposing the features to the rest.

All the buildings also play their 'pre-deployment' sequence. This is a different sprite(See below), which is displayed when the building is deployed. It then 'blinks' between the normal and the deploy image a few times with decreasing interval and finally shows up normally. Nothing fancy, nothing difficult to make. However, I must say, I'm getting a quite a lot of timers... Thank god timers don't have a 68MB memory footprint(A la the clock in Vista).

Buildings before being fully deployement

I'm not sure how I'm going to proceed from now on. Probably the next thing to do is to get the powerplant operational, showing it's animation. EDIT: In before someone comments about it: Yes, the 3x3 and 3x2 buildings are off half a tile. This is because they render using their position, not by tile. since I used 64 as X position, it renders from 64 - (32 * 1.5) = 16. Would I use X - 80, they'd render normally.

However, this probably does bring up the problem I had before: Images are alphablended into 1 fugly soup of weird colors. I really should spend some time testing out with the various D3DXSprite render modes to figure out how to only replace specific colors. If the power plant works, I'm going to make buildings selectable, including a selection marker.

After that, I will probably start working on the UI parts. I'm not really looking forward to that, but after that, it will start piecing together.

Stefan: On a sidenote to what you said about rotating the turret and moving: Good point. I'll fix that aswell.

In other random news: I got a new archwire for my braces. I went for 012 to an 016. I know it means the thickness of the wire, but not really sure how. I'd assume it's 0.12cm, but not sure. Anyway, my teeth are sore now. But I know what I'm doing it for: sexy teef!

And, changed the layout of the blog a bit. I upgraded to the new layouts, which allow me to expand the layout myself. I'm probably going to add a ToDo list to the left navigation bar. Should be hot.

Little weapon update!

2007-04-02T13:32:00.000-07:00

I fixed a few things in the weapons. I made rockets leave smoke trails. It does look good, when you fire a single rocket. With 2 rockets, it looks a whole lot less pretty. Probably has to do with the fire rate of 0.5 and the trail spawning with the same rate. Here's how it looks:

Looking good. I did have a few bugs with it, which was good in the end, since I had a nasty little parse bug with the rules.ini. Apparantly, float.Parse() looks at the Locale settings for numbers, and on my Dutch settings, it excepts to see a ',' as decimal point, instead of a '.'. Therefor, it parsed my 0.5 to 5. I fixed that with with a NumberFormatInfo instance, setting the correct char and passing it to every float.Parse() call. Nothing serious.

Oh, this was a little timing info bug. I had the smoke trails randomly pick a number between 0.0 and 0.5 for releasing their puffs, but forgot to set it back to 0.5 after the initial puff(I wanted a gap of 0.5 between puffs, and a random first puff, so they're not all on the same spot).

This is the final result, including a demonstration of the enemy quad being on firing(Including debug output. I should remove these, otherwise I end up with a cluttered debug log, which I don't really want.

Now I'm going to add Buildings to the game, and after that, the User Interface :D.

Speaking of which... I have basically a week off... Not something I'm very happy with, because I'm missing 5 exams now. But my stupid college requires that I sign in for every course I follow(I'm automatically enrolled to the course, but I have to enroll for the exams). Since I forgot to enroll myself for the exams, I'm not allowed to make them. Kinda weird. You're enrolled for the course, but not for the exam by default. I'm pretty pissed off...

Weapons are done!

2007-03-31T15:57:00.000-07:00

I finished off the weapons. Well, most parts. There are a few minor things that I need to change. But most of the work is completed.

First of all: I changed how units keep track of their internal state. Initially, I had a unitState attribute in each unit class. Which worked reasonable, until I started adding attacking. I had to define several states, such as AttackGroundRotate, AttackGroundMove, AttackRotate, AttackMove, AttackGround and Attack. Yes, that's overkill...

What I did was implement the unit states as a stack. I then cut down the states to their basics: Move, Rotate, RotateTurret, Attack and AttackGround(There are a few more, but I'll safe you the hassle for those). When a unit is sitting idle, it's state contains just 1 state: Guarding. When moving the unit, it's a matter of pushing a bunch of states onto the stack and the unit manages after that. For moving, I just push Move and Rotate onto the stack. In the rotate state, it will determine the desired angle, rotate to it and pop the state. The next time the unit updates, it starts moving.

I also did the same with the gun, except I did make a different state for it, since some units have a seperate turret sprite. This will rotate the unit normally for units without a turret, and rotate the actual turret for those units who have one.

With the stack I also implement a CancelOrders function, which allows you to cancel whatever your unit is doing. However, it has a tiny bug(which I noticed after comitting my code, so I'll fix that after publishing this post): When moving, it stops the unit directly. The unit doesn't stop in the middle of a tile as it should.

The code for checking distance to the target, determining if the weapon is ready, etc. is very exciting to tell about. Only exciting thing I can think of is are the images below.

Only things left to do with weapons: Have the ornithopter fly attack patterns(Since it can't hover), have rockets leave smoke trails(Not in the original Dune 2 I believe) and have units spray smoke when their HP is below 50%.

As for now: Images!Medium Tank is being ordered to attack. Ornithopter is there for no reason

Medium Tank just fired it's weapon at the quad, which is doing nothing...

For those who are wondering why there isn't a healthbar showing in the first pic: I removed them, since I need to redo how healthbars work. The old way sucked donkey balls. Also, there is no image of the quad exploding, since I tried 4 times and still couldn't get to show the explosion.

Weapons are nearing completion

2007-03-28T15:38:00.000-07:00

So, I got most of the weaponry in. I got a Weapon class to fire projectiles(Perhaps I have to add some more classes, such as a BulletWeapon and MissileWeapon, but not right now). The projectiles are in aswell, and this includes bullets and missiles(Which happen to be the only projectiles in the game). Also, the death hand missile is in, including 3x3 explosions.

I took a different way for missile weapons that the original. In the original there were 16 images of the missiles, where each image was rotated 22.5 degrees. Since the original had to run on 8 to 16 Mhz machines, rotating the images in real-time was probably impossible, so they just had a bunch of pre-made images. In assume they used a Cos/Sin lookup table during the game to calculate the trajectory of the missiles, since Cos/Sin calls are pretty expensive.

However, I wanted to save myself the hassle of having to calculate which of the images I had to use, so I cut up the images, took the 0 degree image, enlarged it and use that myself.

I did run into some serious trouble with the rotation tho. At first, I couldn't figure out how to rotate the 2D image without upsetting the entire world view. Turns out I forgot to restore the original Transform. Oops. And, I didn't quite understand that I needed to take the negative value of atan2() when the adjacent side of the triangle is below 0. Took me all day long to debug. But it works now.

As promised: The image. It shows randomly launched Death Hand missiles flying to their destination and explode. Oh, and a lone tank which I used to test the bullet and missile weapons on.

The next step is for weapons to have some intelligence: They have to determine if their target is in range, and if not, don't fire. After that, I can actually implement inflicting some damage based on armor stats. If that's all working, I can do some testing, and implement unit squashing. Oh, and corpses.

Rotation works... Finally...

2007-03-26T01:46:00.000-07:00

Ok, so I finally managed to fix all the weird shit concerning rotation and movement. The large break from coding really helped on that.

Basically, what I did was this: I ditched all my previous movement and rotation code. I then re-build everything up from the ground using sheer logic. It was actually pretty easy.

I did make the same mistake I made the first time with my movement code. I rounded the location X and Y to an integer value(they're stored as floats). So, when a unit would move to x.86, it would round to x + 1, which obviously is somewhat correct. However, if I would start moving from this location, the angle wouldn't be correct anymore, and the unit would just move over a bunch of tiles it wasn't suppose to be on. I noticed this when I would start printing out the x,y locations after movement. Easily fixed.

After that, my rotation code was simple. The old code was overly complicated, while my current code(Including determination of which direction to turn in) is something like 20 lines.

Now I only need to re-work this code so that it also works for the turret, and the problem is solved. Then turretted buildings/units can share the same code.

So, later today I'll start adding weapons. I think I'll start out with the medium tank, since it's the coolest tank of all(coolest graphics, I have no idea why).

No images for now, perhaps after I got some weapons in.

Dual-Core ready!

2007-03-23T17:56:00.000-07:00

I did some coding in the past days when riding the train. However, when I moved my code from my desktop to my laptop(which has an AMD x2 in it), I noticed movement had crawled to a slow.

I tried to fix the problems with setting ProcessAffinity, ThreadAffinity and whatnot, which all failed horribly. Eventually Mithrandir pointed out that DateTime.Now has a Ticks property, which holds the number of 100 nanosecond thinks since 1 jan 0001. I re-write my FpsCounter class to use that, and since then, it worked like a charm again.

So, if I recall correct, I was working on the unit rotation code, so I'm back to checking out the status of it, and probably re-write it completely. I remember it was flaky last time I was working on it. After that, I'll add some weapons.

On other news: These Tower-Defense games are all hawt all the sudden. Perhaps I'll write a little one myself using the current dune 2 remake engine. Shouldn't take too long once the building construction stuff is in.

Update!

2007-03-21T03:15:00.000-07:00

I read some comments from people who wanted an update on the game and/or progress. So I figured, I'll do that now.

First on the game: I did some minor work on the game since the last update, but nothing major. The reason: I'm busy as hell with my own business and school. Especially school has the highest priority over anything else. Should be obvious why.

I intend to get the latest DirectX SDK on my laptop(Which I bought last december) and start doing some development for the game again. I need to fix the unit rotation a bit, since it's fucked up(The units sometime appear to wiggle, moving a pixel up and down while moving. Seems a bit odd, so I need to find out why.

After that, I intend to add weapons. Explosions are already in, so adding in the weaponry shouldn't be too much of a problem.

I want to spend some time today on coding, since I don't have an awful lot of to do(Except unpacking boxes. I moved again ;_;).

omg, LARGE!

2006-11-11T16:56:00.000-08:00

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.

About Spritesheets, explosions, infantry and enlargement...

2006-11-09T13:11:00.000-08:00

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.

Spritesheets partially working...

2006-10-26T07:15:00.000-07:00

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.

Work in progress

2006-10-23T12:09:00.000-07:00

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

I'm not death!

2006-10-20T12:39:00.000-07:00

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.

Aaah~~ Busyness!

2006-09-12T12:39:00.000-07:00

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.

ATTACK!

2006-09-07T12:19:00.000-07:00

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.

College is starting again...

2006-09-05T14:51:00.000-07:00

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.

New input handler

2006-09-03T13:07:00.000-07:00

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

Carry-alls are completed.

2006-08-29T07:42:00.000-07:00

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

2006-08-28T14:03:00.000-07:00

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)

2006-08-24T15:35:00.000-07:00

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

2006-08-21T15:00:00.000-07:00

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

2006-08-12T14:47:00.000-07:00

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

2006-08-10T00:34:00.000-07:00

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

2006-08-06T21:51:00.000-07:00

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

2006-08-01T14:02:00.000-07:00

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)

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

2006-07-26T11:59:00.000-07:00

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!

2006-07-26T11:57:00.000-07:00

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

2006-07-08T08:42:00.000-07:00

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!

2006-07-02T13:29:00.000-07:00

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

2006-05-02T04:04:00.000-07:00

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

2006-04-27T14:53:00.000-07:00

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

2006-04-25T14:10:00.000-07:00

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

2006-04-19T18:20:00.000-07:00

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

2006-04-18T00:22:00.000-07:00

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!

2006-04-14T16:48:00.000-07:00

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.

2006-04-12T01:18:00.000-07:00

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

2006-04-09T04:54:00.000-07:00

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.