Monday, December 17, 2007

I hate coursework...

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.

Wednesday, December 12, 2007

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

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

Friday, December 07, 2007

Background loading of assets

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.

Tuesday, December 04, 2007

A peak into Dune's protocol

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.

Monday, December 03, 2007

We get signal!

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!

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.

Thursday, October 25, 2007

Updates!

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.

Wednesday, October 24, 2007

More info tomorrow!

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.

Tuesday, October 23, 2007

Not dead yet!

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

Friday, July 20, 2007

Networking

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.

Saturday, July 14, 2007

Bugtracker update #2

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.

Tuesday, July 10, 2007

Bugtracker update #1

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

Saturday, July 07, 2007

Counting the credits

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.

Thursday, July 05, 2007

Carry-alls and harvesters... An excellent combination

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.

Monday, July 02, 2007

Spice must flow!

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

Friday, June 22, 2007

Epic debug sessions

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.

Monday, June 11, 2007

Let the vehicle construction begin!

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.

Thursday, June 07, 2007

Bug fixes, loads of them!

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

Wednesday, June 06, 2007

Building placement is in

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.

Friday, June 01, 2007

Construction is in... Now building placement

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.

Wednesday, May 16, 2007

I am an idiot, srsly

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

Monday, May 14, 2007

Problem solved, and the lack of updates

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.

Saturday, May 05, 2007

Some minor issues...

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

Monday, April 23, 2007

Almost a game...

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.

Wednesday, April 18, 2007

Hello Arrakis!!

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.

Sunday, April 15, 2007

Image strips are in... And update on dialogs

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.

Thursday, April 12, 2007

More gooey goodness...

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

Wednesday, April 11, 2007

It's my birthday...

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

Monday, April 09, 2007

Still working on the UI....

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

Saturday, April 07, 2007

User Interfaces are GO!

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.

Thursday, April 05, 2007

IT'S A TRAP!

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.

Tuesday, April 03, 2007

Building basics are done

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.

Monday, April 02, 2007

Little weapon update!

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

Saturday, March 31, 2007

Weapons are done!

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.

Wednesday, March 28, 2007

Weapons are nearing completion

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.

Monday, March 26, 2007

Rotation works... Finally...

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.

Friday, March 23, 2007

Dual-Core ready!

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.

Wednesday, March 21, 2007

Update!

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