I spent most of this week working on my IRC program, it took a lot longer than I thought. But I did do some work on the Level Design and Structure Modelling for the first release of this project.
Since this release of the game will not have randomly generated levels (future versions certainly will) and each team has three different spawn points, I need to carefully place cover obejcts (such as bunkers, etc) and visual obstructions (such as walls, debris, etc) to provide a challenging playing field, which is fair for both teams.
I intend to finish all texturing and modelling next week.
I hadn’t intended to start this project, but I just got the idea for it and thought it would be a simple one-day project. It actually took most of the week, but I did learn a lot, and hopefully I can reuse this knowledge in other aspects of my work. The program is a simple IRC client. It can connect to any server on any port. Commands are sent through the standard “/” prefix, so /join #garagegames, for example. Members in a channel are automatically displayed in the users menu, and updated as they join or leave. Since the program is text only, there is no multiple tab functionality, but users can manually specify a target, and change this target, to control where the default messages go. In this way, a user could join a channel and have one on one chats, etc, at the same time.
There are no real advanced features in the program, but the IRC protocol is quite powerful, and I can see a lot of potential in this type of technology.
The only problem that I can see is that the IRC protocol seems to be non-standardised, or at least the standards are not strictly enforced, so it is very difficult to write a client that can correctly parse incoming message from an IRC server. In the images below, you can see that the initial text downloaded from the IRC server after joining is not formatted correctly. The reason for this is due to this non-standard message formate, developing code to correctly parse all IRC messages would be a project in itself.
I spent much of this week debugging and stabilising the code base. I am nearing a releasable state with this project. It will be an early Alpha state, but still playable.
I also implemented a mySQL database in Torque3D. This is actually very easy to do, however care must be taken to avoid breaching the terms of the mySQL licence. According to the licence, a fee must be paid if the code is to be released to the end user. This basically precludes it’s use in most indie or amateur projects, however, this licence fee does not apply if the code is not released.
Since this project is a multiplayer game, I can put all of the SQL functions on the server, and just send the data back and forth from the client using custom commands. This satisfies the terms of the licence without having to pay a fee.
I have implemented a system of promotion points and ranks in the game, where players will win experience points for completing a mission, keeping their squad members alive, killing enemies, etc, and lose experience points for dropping out of a mission before it is over, killing friendly players, etc. These promotion points will be used to determine the players rank, which will be displayed before their name in the game.
There is also an additional rank of “Marshall” which is actually not a rank per se, but a position. It will be held only be moderators and development staff, and it willl be appended to the players name in addition to the rank, so, for example “Marshall Admiral <Player Name>”.
These ranks server only a cosmetic function at the moment, but eventually they will determine the weapons and items that each player can bring into the game. Higher ranks will have access to more equipment. It will also determine which special abilites the player will have access to.
The ranks follow an exponential growth pattern, which is set up to allow the difficulty of progression to be changed easily, this should make game balancing much easier. The image below shows a simple graph from gnuplot proving that the growth rate of the rank system algorithm is in fact exponential.
I created several animations for the main player model this week, including crouch, prone and death animations, and transition animations between those. I also slightly modified the textures of the player models to make the team colour more obvious. The image below shows the curve editor of the main player model in the game.
I have made some progress here. In additon to adding some support for colour coded heat images (although not full RGB colour) I have managed to stitch together several images to form one single image.
The images below show my early attempts at this. The image quality and resolution are low, but you should be able to make out my hand in the image fairly clearly. The next step is to further increase the resolution and quality of the combined image using averaging and blurring algorithms.
I’m still not sure how to do this yet, but I have some ideas.
This week was mostly about bug fixes. I spent a lot of time working on the targeting, aiming, and firing code. Users now have the ability to fire on objects and terrain as well as on enemies. This could be important tactically, because a user may guess that an enemy is in a certain location even though they cannot actually see them. By firing on the location itself, they can hit the enemy even without the enemy being displayed.
I also made extensive modifications and improvements to the game rules that govern weapon accuracy. The accuracy of firearms and grenades is now much more realistic, and varies with distance, and with the type of fire mode that the user has selected (Single, Burst, or Auto).
I have designed these variables in such a way that they can be changed easily, which will make game balancing much easier later on.
There were a few bugs in the client/server code which only became apparent when I tested the game in a multiplayer environment. These were all down to the client not having access to certain pieces of information from the server. I fixed these mostly by moving the calculation itself to the server.
I also made improvements to the detection and client/server rendering code, to ensure that targets are detected at a reasonable distance, and can hide behind obstacles, while being visible through certain types of cover.
Finally, I did some work on the level design and level art.
This week, I made significant progress on the level design for Star Commander. The terrain file was already done (although not textured), but I made extensive modifications to it to accommodate the layout of the level.
The map features six spawn points, three of which will begin in the control of each team. The map size is relatively small, since the time limits are quite short, and I wanted to go for a more casual approach at this stage of the development process.
The six spawn points are:
Command Center, Trenches, Rail Launcher, Power Generator, ComSat Station, Mine.
These Spawn locations will be the focus of much of the action, and vary from small buildings with a dense network of corridors and turns, great for close quarters fighting, to larger areass that provide both cover and a means to outflank and surprise enemies.
I spent some time debugging the game this week, and discovered some issues with the firing code that need to be looked at more closely. I have also decided to add a feature to the games cover system preventing bullets fired by players who are behind cover from hitting the cover they are hiding behind. This should prevent irritating problems with aiming at an enemy while taking cover.
I have received the MLX 90620 thermopile and my Pan and Tilt servo system for this project, and I have come up with a simple concept test of the idea.
It was relatively easy to wire up the thermopile, and connect it to the arduino. It took a little more work to communicate with it over I2C. It turns out there is an array of 64 bit float values that needs to be calculated in order to calibrate this kind of thermopile. This array is different for each one, and I had to use a sketch to calculate the correct calibration values before I could use obtain temperate values from the thermopile.
I then used processing and a simple sketch I found to test the connection between the arduino and PC, and to visualise the 16×4 temperature values that I was getting from the thermopile array. This again, worked quite well.
I assembled the pan and tilt system using the manufacturers assembly instructions, this was easy, and then tested the servo code. I was surprised at how easy it is to control these servos, I was expecting it to be a lot more complex. I then soldering the thermopile and glued it to the pan/tilt system with a hot glue gun (A very useful tool, I don’t know how I did without one for so long!).
Since 16×4 is obviously far too low to be useful for any thermal imaging system, I intend to use use the pan/tilt kit to move the thermopile in a grid pattern, taking readings in 16×4 chunks, and assembling them together.
I ran into some issues while trying to program the servo motors to move the way I wanted. Interacting with the motors is easy, but I wanted the servos to move in the most efficient way possible, to pan from, say, left to right, tilting up and down, and then reversing direction. This turned out to be difficult, but I got it working.
I also got a basic concept test of the combined image working, although it will take some tweaking to get the individual chunks to line up properly.
The next step is to generate a properly aligned high-res image from the low-res chunks, and then run some smoothing algorithms on it. I will probably increase the size of the raw image by, say, three or four times, then interpolate the pixels inbetween to produce a smoothing effect. I will also implement colour coding as opposed to just grayscale.
While working on my latest multiplayer game, I started thinking about dedicated server options. Up to now, I have set up dedicated server in windows using small form factor computers. This has worked fine, however, I have been considering ways to improve the efficiency of this setup.
Even a small form factor PC that is on constantly will use a reasonable amount of power, produce noise, etc.
Dedicated servers require little resources, and no graphics support, so it is a waste of a conventional PC to use it for this purpose.
I have been doing a lot of work with Arduino development boards in the recent past, and I got the idea some time ago to use one of the newer boards as a game server.
All of these boards use linux in one form or another, but thankfully, the latest releases of T3D MIT version have support for linux dedicated server builds (although not client builds).
The Arduino Yun is the first such product from the Arduino family that would be suitable for use as a server. However, it runs a stripped-down version of linux, and only has 64 MB’s of DDr2 RAM, and a 400MHZ processor. This is quite powerful for what it is, and would likely be able to run an SQL server or a Master Server, but I have my doubts as to whether it could run a dedicated server.
However, the upcoming (not yet released) Arduino Tre may address these doubts. The Tre features a complete install of linux, a very impressive 512 MB’s DDR3 RAM, and a 1GHZ processor. I see no reason at all why this couldn’t run a T3D dedicated server.
It would have the advantage of consuming significantly less power, producing less noise, and taking up less space than any small form factor PC. This could be a new direction for small game servers and home servers, and, with the Tre’s ability to interact directly with homemade electronics (like all development boards) it could open up fantastic new options!
I have now implemented almost all of the basic gameplay features of Star Commander, and the game is more or less completely playable. There is still a lot of work to do, but this is huge progress, especially given the fact that I have only been working on this for a matter of weeks.
This week I spent a lot of time debugging the game, and tracking down various long-standing issues and minor glitches. There is still some more work to do on this, but the game is a lot more stable now.
I also added game rules to determine a winner. The game ends in one of three ways: All players one one side are killed, All of a teams control points are captured, or the time runs out. I have added a 15 minute timer to the game, which isn’t a lot, but I think it will be easier to build up a user base if I try to encourage short, casual gameplay as opposed to long tactical games. In the future, I intend to expand this project and add more features, including the option to play longer games.
I created some gui’s to make navigating through the game’s menu’s easier, and a post-game summary gui. I will add a point system to the game in the future to allocated points to players based on various factors. These points can then be used to purchase better equipment, weapons, etc. The end game summary will display the points allocated for that mission. In addition, I implemented a timer in the lobby. Once more than one player has joined each team, the timer will start. Originally, the game would start once all players clicked the “ready” button, but this was problematic, since the server didn’t know how many players would be joining the game, and a malicious player, or a player with a poor internet connection, could avoid pressing the ready button and hold up the game. Having a timer prevents this, while still allowing players time to join the game, and select spawn points, etc.
The weapons in Star Commander inflict damage in a slightly different way than in most games. Most games have fixed damage amounts for each weapon, so a weapon might do, say 20 points of damage with each hit. Each weapon in Star Commander has the same fixed “Max Damage” variable, but when a character is hit, their armor will absorb a certain random amount of damage, within the range of that armours capabilities. So for example the weapon might do 20 points of damage, and the players armour may absorb between 5 and 10 points of that damage, so the actual damage dealt by that weapon will be between 10 and 15. This make the game less predicatable, and hopefully, more fun.
I had time at the end of the week to do some work on the level design. I created a fairly good looking skybox, using the program SpaceScape. I then added a picture of Jupiter, rising above the Europan horizon. I think the effect looks quite good.
Most of my time this week was spent modifying the guishapenamehud in T3D. I was trying to make a client-specific colour coding system where the name tags above the heads of aiplayers change colour based on the team the player is on, or whether or not they are the players own units. This took a lot of time, particularly sorting out the network side of things. I had a lot of issues resolving ghosts, using ghost id’s, etc, but it seems to be working ok for now.
I also added line of sight calculations to the game rules. Star Commander uses a free camera, so it was possible for players to view enemies that are actually obscured from sight.Players that are behind buildings will not be rendered, regardless or what position the camera is in. Players that are behind cover or out in the open may be hidden or displayed, depending on distance, cover status, and a variety of other factors which I have not yet implemented. In future, some enemies may be rendered even while hidden from view. If they make a noise, for example.
I have also decided on the setting for the first “Map” of the game, and completed the terrain file for it. I am thinking of a futuristic fortress on Jupiter’s Moon Europa as a setting. This will provide ample opportunity to test the games mechanics. I have created a simple building model as well. It hasn’t been textured yet, but I am using it to implement and test structures for the game. I intend to implement multi-story structures, and ladders, lifts, etc in the future.
In addition, I have implemented game rules governing the accuracy of grenades, meaning they will not always hit their targets. Grenades are, like all other aspects of gameplay, governed by a complex set of rules, and some random chance, to provide realism and fun to the gameplay.
There is one annoying bug in the network code of the game which I am attempting to track down. Occasionally, when a client joins the server and spawns a team of AI players, the game will crash. The callstack reports the crash occurs in unpackupdate. I am guessing this has something to do with datablocks not being available on the client, but it may take some time to track down.
