PhoenixGames

About PhoenixGames

http://www.phoenixgamedevelopment.com

Posts by :

February 16 2014

Thermal Imager: Progress Update 1

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.

February 10 2014

Arduino as T3D Dedicated Server, Sql Server, Master Server

PhoenixGames On Game Development, Software and Games 0

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!

February 10 2014

Project 137: Star Commander: Debugging, Victory/Defeat Conditions, Control Points,Gui’s, Weapon Damage Rules,

PhoenixGames News, Software and Games 0

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.

February 3 2014

Project 137: Star Commander: Colour-Coded Player Tags, Line-Of-Sight Calculations, Level Design, More Game Rules, Bug Fixes

PhoenixGames Software and Games 0

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.

February 3 2014

Project 137: Star Commander: Context Sensitive Selection, Game Rules, Cover System, Gui’s

PhoenixGames Software and Games 0

This week, most of my time was again spent on this project.

I concentrated mostly on the game rules, with some time also spend on some important graphical and GUI features.

I implemented a context-sensitive cursor which will display the chances of hitting whatever target is currently underneath the mouse. This gui is affected by the distance, fire mode, cover status, etc of the ai firing the weapon and the target being aimed at.

I created a complex cover system which I am quite happy with. Instead of just keeping track of whether a player or enemy is in cover or not, this system actually keeps track of the direction of the cover, meaning a soldier could be protected from the front, but vulnerable from the sides and from the rear. This allows for flanking and diversionary attacks to be used to great effect.

I spent a few days this week working on some modifications to the guiShapeName hud used in the T3D engine. I have added the ability to display multiple lines of text, and to display different text on different clients. This means that I can display custom stats and attributes for the players own squad, visible only to the player controlling that squad.

January 25 2014

Weekly Update: 19/1/2014: Star Commander, Icarus 2

PhoenixGames News 0

I spent most of this week working on Star Commander, as I posted previously. I completed a great deal of work on client-specific rendering, and on the game rules. I did some work on gui’s, creating a lobby gui, and doing more work on the main game menu. I also did some animating of the main player model in the game.

I spent quite a lot of time getting the main game interface working the way I wanted. There are still some bugs in the solution that need to be fixed, but it is working quite well.

I also started the main Game rules, which will control the gameplay. Star Commander is intended to be a realistic squad-based game, and so most of the game play will governed by rules, which will influence weapon accuracy, sight range, move speed, etc etc. These rules will be built into every aspect of the game

In addition to the work on Star Commander, I did some basic sketches and design work on Icarus 2. I intend for Icarus 2 to be both a modification and improvement on the Icarus Rocket Simulator program, as well as a detailed design of a rocket using real-world materials and physics. The idea would be to make it as simple as possible to build, and yet still be powerful enough to reach Earth escape speed.

January 20 2014

P-108 Icarus: Phase 2: Part 1

PhoenixGames Art and Designs, Musings, Software and Games 0

I have had some further ideas regarding this project. Icarus turned out to be a very large rocket, much larger than I anticipated. It is also very complex, due to the fact that is uses liquid-fueled motors with cryogenic (LOX and LH2) propellant.

I want to know how small, and how simple, a rocket could be made to send a tiny payload (say, a USB memory stick) into space. I want to know if it is at all feasible to build a rocket powerful enough to reach escape speed with basic materials.

To simplify the Icarus project, in addition to reducing the payload capacity, I would use solid-fuel motors. This would eliminate the need for complex fuel and oxidiser feedlines, turbines, turbopumps, etc. Solid fuel rockets are much simpler to build, and homemade rocket fuel can be made relatively easily. The simplest type of homemade rocket fuel is “Rocket Candy“, Potassium Nitrate and Sugar (Sucrose).

The problem here is that solid fuel rockets in general, and solid fuel rockets using homemade fuels in particular, are less powerful than liquid fueled rockets. For this reason, medium to large rockets almost always use a liquid fueled main engine, possibly with solid fueled engines as boosters. Small rockets however, have been known to use solid-rocket engines exclusively.

The specific impulse of Rocket Candy is between 115 and 130 seconds, compared to 150 – 180 seconds for APCP (Ammonium Perchlorate composite propellant, used by the Space Shuttle Solid Rocket Boosters). This is surprisingly good, although, possibly not good enough for a ground launch to escape speed.

The next problem with building a simple rocket would be controlling it. Commercial space rockets use thrust vectoring, usually some kind of rotating gimbal mechanism. This kind of system would be much too difficult to build for an amateur. There are several other thrust vectoring options, (useful graphic here) such as Liquid Injection Thrust Vectoring, Hot Gas Injection, Jet Tabs, and Axial Plates. Axial plates and Jet Tabs are probably the easiest to build, since they don’t require modification of the engine nozzle itself, or any kind of extra fuel or related equipment.

January 20 2014

Project 137: Star Commander: Point and Click Interface, Unit Selection, Frag Grenades, Game Lobby, Client-Specific Rendering, Game Rules.

PhoenixGames Software and Games 1

I have made huge progress in Star Commander over the past week.

In addition to creating animations for grenade throwing (which still need some work!), I added code to allow for “Client-Specific Rendering”. This is basically where an object shows up on one client, but not on another. Since Star Commander is a tactical wargame, I will be modelling real-world variables, such as cover, concealment, etc. This means that some players will be able to detect an enemy before that enemy detects them, or vice versa. For this to work, I need to be able to control the visibility of each player object over the network. I have implemented this by simply hiding the mesh, as opposed to deleting it. The advantage to this is that the mesh is still in the game world, so it could still be hit by stray bullets or grenades, or detected by the footprints it leaves behind, etc etc, which is a desireable feature. I could have achieved this effect on the server of course, and hiding a mesh as opposed to deleting it does allow for the potential for cheating, if a player were to hack the client, so this is something I may look into and improve later.

I create a game lobby, and implemented most of it’s features. There is a fully colour coded (Red Team, Blue Team, and Observer) player list and chat system, the ability to choose teams, choose spawnpoints, and enter the game, and the ability to send chat messages to everyone or only to your team. A different set of spawn points are loaded for each Team, ensuring members of opposing teams dont spawn beside each other, and a map wil be shown behind the spawn select buttons, providing a visual indication of where it is.

I implemented the beginnings to the games rules. Star Commander will have a complex system of rules for governing things like accuracy, detection ability, chance to be detected, etc etc. These rules wil be based on variables such as morale, stamina, health, whether the AI is in cover or not, how many casualties have been taken by the players team, or the enemies team, etc. I have come up with al algorithm to convert all of this into a percentage chance of hitting a target, and an offset vector determing how much a player misses by if they do miss.

I spent quite a bit of time implementing a point-and-click object selection system. I had to make several changes to the C++ source for this to work, as well as do a lot of GUI work. Players can now click on the screen with the mouse and the 2D screen coordinates will be translated to 3d coordinates, and used to select items in the game world. This means I can combine an on-screen gui with object selection, I don’t have to hide the gui menu while the player is controlling the camera, and then show it again, which is what I was doing before. Players use the left mouse button to select squad members, select orders, and issue orders. Holding the right mouse button allows the player to rotate the camera in full 3d. The videos below show this in action.

Finally, I added some simple Decals to indicate which player was currently selected, and I implemented frag grenades. (Both of these should be in the video below too) as well as creating and setting up a dedicated server for the game. For the initial release of Star Commander, I will have about four or five dedicated servers, running different missions. I will eventually add the ability for players to host their own missions.

I have tested the network play on a LAN, and everything seems fine. I can’t test the network play on the internet from my machine, because due to the way Torques networking works, I can’t connect over the internet to a game while I am on the same network as the game server. I intend to upload a simple playable test version of Star Commander soon, to be used for internet testing.

January 13 2014

Project 137: Star Commander: Grenades

PhoenixGames Software and Games 0

I have managed to get the trajectory for my smoke grenades working, thanks t o some help from the Garage Games forums. I now just need to add the animations for the grenade throwing, and I am basically done. Adding animation support may be quite tricky, since I have to move the player from a normal pose to throw the grenade, take the grenade from a belt or pouch, and then throw it, creating a projectile just at the right moment.

Grenades will be a major part of combat in the early release of Star Commander, since the choice of weapons and equipment will be quite limited at this stage.I think that, without grenades, combat would become monotonous “trench warfare”, where players stay in cover and simply fire at each other until they score a lucky hit. With smoke grenades, however, players can deploy smoke to cover an advance or retreat, covering ground that would normally be impassible. With frag grenades, they can clear enemies out from cover, or from building, forcing them to change positions or retreat. This should make the game dynamic and fun.
It may not be possible to see the grenades being thrown in the video below, but they are in fact there.

January 13 2014

Weekly Update: 12/1/2014 Star Commander

PhoenixGames News 0

With the exception of some research and planning on the Thermal Imaging Camera, I spent all of my time this week working on the Star Commander game project.

I created a simple user interface, which I intend to replace soon with something more robust. To do this I need to dig deeper into T3D’s gui functions.

I also created, textured, animated, and mounted the primary weapon on the player, and added the fire commands. Weaponss are capable of single shot and burst fire modes. Single shot mode is more accurate, and more effective over longer ranges, while burst mode has the potential do do more damage, and is more effective over short ranges. There will also be fully automatic weapons in the game. I wanted this game to be real time, as opposed to turn based, and so I decided to continue executing the fire order at a given rate until it is either cancelled, or the target is killed or lost. This allows for reduced micromanagement on behalf of the AI.

I may post a tutorial on how I did the muzzleflashe for the weapon model, it’s a useful thing that a lot of people may not know, and it looks great ingame.

Smoke grenades have been added to the game, and will be joined by Fragmentation grenades soon. I do not have animations for them yet, or a smooth parabolic curve for throwing them, but the smoke effect is looking quite good. I am still working on a few things, but I hope that they will be done fairly soon.

«‹ 203 204 205 206 ›»