I have finished creating and setting up an online store, using openCart. The store link is HERE. I have not customised the look and feel yet, or added many products, but the store is functional. I will be listing a number of products on here in the future.
I have also signed up with a number of online marketplaces, including Payloadz, Cnet Download, TrialPay, and Softpedia.
Selling desktop software have a more difficult route to market than Android or Iphone apps, since there is no single store to sell your products. You have to divide your attention amongst many of them. I am confident however that I can build up a library of desktop software on various sites, including my own, over time.
I prefer writing desktop software and games, since there is so much more scope with regards to what is possible. Mobile devices are becoming more powerful and more fully-featured all the time, and are constantly being updated with more and more hardware and peripherals, but a desktop app will always be capable of a lot more.
For example, the arduino projects, (such as the random number generator) that I have been working on are only compatible with desktop computers, and anything featuring graphic or CPU intensive processing would need the additonal power of a desktop machine as well.
I have completed the MS1 Alpha Release for this project, however, it has not been properly tested. This is due to the fact that it is a multiplayer game, and I can only properly test it by connecting to it from a client located outside my local network.
If anyone would like to download this and help me test it, I would appreciate it. I do not have a dedicated server set up yet, so I will probably need to schedule times with people to ensure that the server is running when they are ready to play. I only need a handful of Beta testers at this stage, the purpose is mainly to look for major bugs in the networking hardware, or things like crashes, etc.
The link is to a .rar archive which is 445 MB’s in size. The game is PC only, (with possible linux and mac support being added later) and is built with the Torque 3D engine.
Any questions, or interested parties, etc, can email me at: [email protected].
I was involved with a lot of different projects this week. I have two more new projects that are currently in the research phase, I will announce these shortly.
In addition to those, I have had to rethink my Thermal Imager project. I intend make a more detailed post on this soon, but in short, the idea I had to pan and tilt the thermopile will likely not work. It has to do with the Field of View of the thermopile sensor being too wide, and overlapping each scan with the previous one. I have some ideas for modifications, which I intend to work on.
I am starting an online store for software. I sometimes sell software on ebay, but it’s not really optimal, with fees, and the hassle of listing and relisting items. Starting an online store here will allow me to direct people to it to handle sales of products I develop, and can be expanded on in future to possibly include other items and products.
I already made a post about long-term data storage, and “Data Vaults”. This is something that I have been thinking about, and I may produce a prototype of this concept.
While researching the DataVault idea, I realised that I would need some kind of battery capable of lasting much longer than a regular battery. I came across a battery design called a “Nickel-Iron Battery” or an “Edison” battery, after its inventor, Thomas Edison. This type of battery can last up to 100 years without failing, and can be discharged to 95% of it’s capacity without damage! I intend to produce a prototype of this battery, and evaluate it for use in the DataVault and other projects.
Another project that I began working on this week is an electronic log book. I will be posting in more detail about this too as the project progressess, but, it is, as it’s name suggests, a program designed to store and organise data for engineering, science, or any kind of project type work that would require frequent recording of information.
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.
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.
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.
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.
I spent the vast majority of this week working on my new game project, Star Commander. I modelled, rigged, textured, and began the animations of the main character model in the game. For the initial release, I will probably just have one of these, with different skins for each team. The character will need a full set of animations in order to perform complex tasks, such as throwing grenades, leaning, shooting from cover, crawling, crouching, etc, as well as running and walking.
Rigging is one of my least favourite modelling activities, however, after I finished rigging my curretn character, I discovered THIS site. It claims to offer an “auto rigging” service for bipedal models, which is available on a pay per use basis. I haven’t used it yet, but they offer a free trial, and I will definitely try it out the next time I am rigging a humanoid model.
I also did some work on the context sensitive menu for the game, as well as the spawn location selection, squad movement and orders menus. This project is off to a pretty good start.
I already posted about the Thermal Imager idea. I spent some time this week researching and sourcing parts for that. It shouldn’t be as difficult as I initially suspected.
This week I mostly finished Artillery, the simple game I am working on. I created a new projectile type (a homing projectile) and created some new levels, in addition to fixing some bugs and doing some texturing. I started the project principally to force myself to improve my knowledge of vectors, 3D Mathematics, and physics which I certainly did do. I am not sure if I will upload the finished game, the graphics are quite basic, and the multiplayer functionality is untested, I don’t know if it’s quite ready for upload. I may release it as “beta” software.
I build a simple 300 mW Infrared laser illuminator as well. It’s nothing complicated, I just wanted to boost the effectiveness of the Generation 1 night vision equipment that I have, and this is an excellent way of doing it. I found that in order to produce a properly collimated and circularised beam I need to do some “Beam forming” or “Beam shaping” using various different kinds of optics, mostly involving cylinder lenses.
I did a writeup of the Emergent AI project that I created the concept test for, and decided to postpone it. It is an exciting area of research, but I just feel that there is not enough material in the idea that I had to justify devoting an entire project to. I would basically be creating a system that searches for the optimum set of variables to solve a given problem, and while this would be interesting, I want to wait until I have fleshed out the idea more before I spend time on it.
I have come up with several excellent ideas for the new year, which I am very excited about. I have started research on them already, and even started development on one, but I won’t mention them until I officially start the projects in a few days.
This week I finished the Fast Fourier Transform and data recorder program (Project 115). There are a few improvements and GUI additions I would need to make before I would consider releasing it, but it does what I designed it to do.
I also bought the parts for an IR laser illuminator, in the 300mW range. I own a basic night vision monocular, and having an IR laser illuminator greatly boosts it’s range. I built a small low-power laser some time ago, and it worked well, so I thought I would build a more powerful model.
I finally released my Fluid Dynamics resource on GarageGames, which I talked about here.
With regards to the Resonat Inductive Coupler project, the concept I have is working, but is nowhere near powerful enough to move ahead in the project yet. I will need to get some new circuit diagrams and do some more research in order to come up with something that will work well enough.
With the success of my genetic algorithm concept I have also begun planning and researching the next stage of this project. I am mostly working on defining the variables involved, and the scope of the project. I am trying not to be too ambitious, but at the same time I want to try to push the envelope as much as I can with this project, since AI has always held a special interest for me.
I am finishing up the Demo for Artillery as well, working on some final projectile types and about to work on on basic Art and Gui’s for the game.
