Hal Spacejock The PC Game
(Please see the FAQ before emailing me about the game)
May 9, 2012
And the updates are slowing down ;-) I took three days off to write an accounting program from scratch (done!), and I'm also working on code for clients. My 3D Math Primer book just arrived in the mail, so that'll be useful, and I spent a few hours designing an interior level. My plan is to allow players to walk around inside buildings, and there may be some combat involved too.
May 3, 2012
Ahh, the joys of programming. In my code I have building objects (based on the same class as planets and stars) and vehicle objects (which share the same class as robots and scenery items.) Despite the vehicles moving around and buildings remaining static, a persistant bug has had me tearing my hair out trying to get buildings to display on the correct terrain tile - and then stay there. Vehicles are well-behaved, doing exactly what you'd expect.
Today I decided to base the buildings on the vehicle class, only with a variable 'CanMove' set to false. (One benefit is that it really simplifies the autopilot, factory production and trading code.) I spent all day moving across building-related variables and changing the entire codebase to handle this alteration, and I finally got it done. When I finished, the damn vehicles were acting up just like the buildings used to. Jumping all over the map, not showing their models ... argghh.
May 1, 2012
Not much programming - it's all math and calculations and future plans for the game at the moment. I'm also working on the issue of wrapping, where a vehicle has to find the shortest path to a destination even if that means crossing a map boundary to get there.
Just started work on the space travel aspect of the game. Now, as someone famously said, 'Space is Big'. Many gamers (few of them famous) have also declared that 'Space is Boring'. The point about Space is that you can fly for hours (days) at mind-bending speeds while not getting anywhere or seeing anything remotely interesting. You can see why most space games force you to jump into and out of star systems. The other problem is that you want to fly between planets within the same system in a reasonable time (10-20 seconds would be good) but you also want to approach other ships. These two are incompatible unless you use an Elite-style booster which drops you back to normal speed when you're in range of something interesting.
(All the calcs below are back-of-the-envelope, and some may be out by an order of magnitude or two. I'm just theorising at this stage, not writing code!)
I figure a structure containing 10k x 10k x 10k cubes will be sufficient for a star and the orbiting planets, assuming each cube is 1 million miles across. Obviously it's not going to be possible to create a data structure that size (1 trillion vectors would require 12 trillion bytes or approx 1 terabyte of ram), but I can get around that by giving each object a location (e.g. 5000,5000,5000 for the star in the middle) and then calculating their relative locations on the fly.
Our own sun would would fit neatly into one of those trillion cubes, but Rigel would swallow 50x50x50 while Antares would eat up 700x700x700. The Earth and moon together would take up a cube (actually, half if you calculate the radius of the moon's orbit), but bigger planets with moons orbiting further out would spread across several.
If it takes 20 seconds to fly between two planets (never mind their relative positions just yet), then how long would it take to cross the system from one side of the outermost planet's orbit to the other? Hours of game time. So, we need another boost level for that, where planets and moons flash past in the blink of an eye. And what about flying between stars?
This is where it gets interesting. I'm going to allow about 5 light years between stars on average. One light year is around 6 trillion miles, or 600 of my structures above laid end to end (each of those containing 1 trillion cubes.) No wonder most games have jump gates. Still, forging on... Let's say it should take 5 minutes to travel 5 light years, which isn't too bad. Moving at one light year per minute means crossing 600 cube structures in that time, which is 100,000 cubes or the equivalent of ten solar systems every second. That means it would take one hundredth of a second to fly from the Sun to the Earth, and five one-hundredths to reach Jupiter. Good luck shooting at passing ships.
Obviously you'd want to lock this super-boost drive until the player has left the immediate area around the star, where the planets and moons are. I imagine a light tree where red means you can fly at local speed (approach other ships, dock with things, etc), yellow means you can zip around between planets and green means you can hit the triple-decker boosters and head for the stars. There's a missing step in there somewhere, because if moving from the Earth to Jupiter took ten seconds, flying from the Earth to the Moon would be impossibly fast. The other problem is, if the player is sitting next to the Earth but wants to fly to a star ten light years away, first they have to use slow speed to get away from the Earth, then they have to use Medium to reach the edge of the Solar System, and at last they can engage top speed.
Instead, top speed really needs to be scaled depending on the distance to target. (Finally, something practical I can use in my code!) If the player selects a star ten light years away they should be able to travel at super-speed right away, bypassing the slower steps. If they select a ship on the other side of the Solar System, they should be able to travel at a speed which enables them to reach it in 10-20 seconds as well. And if they select the Moon while orbiting Earth, another speed is selected.
It's beginning to sound a lot like a Jump drive, although I want to avoid that particular artifact and give the player more control over their movements.
So, that's the current thinking. I'm not introducing any of this before the first alpha release, but I need to know where the game is heading.
April 29, 2012
I've been flat out improving the AI these past couple of days. I have to say, this game is turning into more of an ecomony simulator than a shoot-em-up: I can spend ages watching ships and trucks picking the best trades and heading off to buy/sell goods, and it's rewarding when a factory has enough raw materials to fire up production.
The only down-side is that the AI is getting so smart there's not much of a need for a human player ;-) I'll balance this by making different grades of AI available (for a price), so the starting AI needs more assistance.
Anyway, thanks to the production tree it's important to get the basics like energy and raw materials under way first, so that more advanced factories (fibre optics, electronics, etc) can build the parts which the high-end manufacturers need to make flyers, trucks and robots.
I have a few more bugs to sort out before I get to the alpha release, but it's getting closer.
Factories firing up!
April 26, 2012
Just saw a game on Steam which seems to have a similar philosophy to mine. It's called Evochron Mercenary, and apparently a lone developer has spent ten years coding and tweaking the game. Judging by the screenshots I'm nine years, eleven months and one week behind. (Fear not - it's just like the time I decided to write a novel, and I realised there were lots of other novels out there all finished and polished and published and on sale in the shops with flashy covers and blurbs from famous people. There's room for everyone, and you should never compare your work in progress with someone else's completed masterpiece.)
Speaking of philosophies ... when it comes to computer games, I agree with the Comte de Frou Frou (Nob and Nobility, Blackadder the Third). To whit, I want others to do the work and give me all the money. Or to put it another way, one does not buy a computer and then add binary numbers by hand.
April 25, 2012
I've been working on the autopilot in the game, and I'm happy to say it's now a lot better. You can pick a factory and tell your ship to fly there, and it'll do so. Very satisfying. I've also been working my way through four pages of bugs/tweaks in my exercise book, crossing them off one by one, and I've put the LOD framework in place. (LOD is Level Of Detail. There's no point drawing complex terrain in the far distance, so you cheat by simplifying it the further it is from the camera.)
I also experimented with buying a truck and giving it orders, sending it off to various factories. Then I took off and flew overhead, watching its progress. Quite cool, really. Next I'm working on the orders screen so you can tell these trucks to buy and sell various products on their own. (A basic truck can handle simple tasks on its own, but there will be a way to complicate things.)
I'll tell you something else which is quite cool - factories have masts with a light on top. The light is green if they're producing, orange if they need raw materials and red if production is halted. (The latter for player factories.) Finding enough products to switch a factory over to 'green' is actually quite fun, especially some of the more advanced factories with longer lists of demands.
Once I have the orders system in place I'll be going over everything with a couple of bug-hunters (my daughters), and when they can play it without breaking anything I might release a first Alpha-test version.
Nice smooth terrain, despite building it from 25 tiles
April 23, 2012
Today: tackling a bug in the height map. There's a bug where what you see on the screen is not where the computer thinks it is, which allows ships to fly through some hills and hit others where there's supposed to be a valley.
One of the problems with programming is trying to turn streams of figures into something tangible. So, I wrote a quick routine which prints a '.' on the screen for all nearby vertices on the heightmap. As you can see, the red debugging overlay is nothing like the rolling hills. The red dots represent the unseen terrain which the game uses to work out whether you've hit the ground or not. My job is to get them both to line up.
Debugging the heightmap
April 22, 2012
Fixed the unsightly seams between landscape tiles, and stomped a bug in the tile wrapping code. Added basic collision detection for buildings and vehicles.
Still filling my 320-page exercise book with cool ideas for this game, and I have another five blank books waiting. Fortunately, unlike a novel, you can release games early and improve them as you go along.
I really want to get gunfire working properly, but the math makes my head hurt. (You can fly the ship in one direction and use the mouse to aim a reticule all over the screen. Shots need to leave the ship in the mouse direction, heading towards the cursor. Easy in 2D, but in 3D it's a real brain-ache.)
Update: Figured the gunfire out! Now to add collision detection for shots, so you can blow stuff up.
April 20-21, 2012
Spent a couple of days on freelance programming work.
April 19, 2012
Today was a bug fix day. When you write software you introduce new errors and glitches at every turn, and eventually you have to stop adding new features and spend time time fixing up what you already have. (Unless you're a big company, of course, in which case these fixes become 'features' for version 2.0).
After stomping a ton of bugs I improved the interface screen where you can interact with vehicles. You can now pick any vehicle and issue 'follow' or 'go to' orders, selecting the relevant vehicle or building from a list. I also had to write a combo box control (drop-down list), which I'm going to need for more complicated orders, such as 'buy this product here and sell it over there'.
The improved orders screen
April 18, 2012
Spent most of the day writing a tool which configures the economy in the game. E.g. I can add factories, assign each to a 3d model file, and specify which products they make (and how quickly). Under the products tab I can define new products and specify the raw materials which go into each one.
It's been a challenge putting it all together, but it's now a breeze for me to edit the Spacejock economy. Instead of hand-editing spreadsheet files with lists of obscure ID codes and rows of hard-to-decipher numbers, I can select values from dropdowns and enter numbers into the relevant cells.
Last night I played an early Alpha and managed to amass 3 million credits in about five minutes, which is enough to make X-universe addicts weep. I also managed to buy and load 64 T-7 Trucks, which is quite an accomplishment since each one weighs half as much as my flyer. This new tool will allow me to fine-tune such minor inconsistencies.
April 17, 2012
Last night I ripped into the coordinates system (again), and this morning I think I finally fixed it. Buildings still aren't displaying in the right place (again), but that's just an offset problem.
I spent the rest of the day working on the user interface - I wrote a listbox class which will be very useful in a game like this, and I also added a few more industries and played around with the economy code.
This evening I put together a basic 'garage' screen where players will be able to manage all their vehicles. Ordering your minions around is going to be a big part of the game, and it's something which is very hard to get right. You want to be flexible, but you don't want excessive micro-management either.
The new garage screen
After a couple of days working on the factory production and economy code I tossed aside my calculator and spreadsheet and took up surveying. I knocked up a quick map screen with an overhead view of the planet - you can scroll around and zoom in and out with the mouse. The idea is that players will be able to select buildings and fire up the autopilot, leaving all that flying and driving nonsense to the computer.
Assuming your vehicle has an autopilot, that is.
On the economy side of things, players can now buy and sell products. When you land at a factory the range of products and the prices depend on what the factory makes and how much raw material is available. Unlike some space-trading games you can buy raw materials from factories, but they're priced much higher than usual.
A bare-looking map screen
I've been messing around with terrain tiling again, trying to make sure you can fly all the way around planets to arrive at the same point. This involves resetting the world coordinates and using offsets to draw everything, which can get a bit hairy. (Otherwise you could continue lapping the planet, your coordinates increasing constantly, while buildings and ships which should be in the same spot are plotted in some alternate universe.)
Did some preliminary work on the galaxy save/load routine - stores everything nicely, although I haven't written the reloading code yet. Also worked on the economy code. (Each planet will have its own economy with prices based on supply and demand. An unscrupulous operator might find ways to restrict supply or increase demand. E.g. cornering the market then waiting for prices to rise.)
On the subject of gameplay, I want to make the game playable as a hands-on 3d experience OR a management sim ... or both.
Also did some quick texture work so that flying around on moons and asteroids doesn't look like an English country garden:
Not many veggie patches here
Continued work on the AI. It's amazing to start the game up with randomly generated traffic, allocate DockAt, FlyTo and Follow commands automatically, and watch them scurry around like ants.
Tried running the game with 300 vehicles on the screen - no problem. Tried 3000 ships and trucks - just for a laugh - and got a slideshow.
Screenshot with AI debugging labels
I've added a radar with target stalks, which updates as you fly around the landscape. When you're in range of a building the Land icon flashes - press L to land automatically (just warps there at the moment), and then the trading screen opens.
Still nutting out several math problems:
• Deriving the ship's pitch and heading from the position matrix
• Redoing the terrain tiling so it's more efficient (can wait for new terrain code)
• Calculate offsets for buildings outside the starting terrain tile DONE
• Rewrite the flight model
Other items on my todo list:
• Replace the heighmap terrain with a deformable mesh
• Merge in the truck-driving code
• Work out the hit point for blaster shots
• Implement the player object (belongings, etc) DONE
• Implement other permanent variables - e.g. traders' stocks, galactic prices, etc
• Add some dynamic traffic
The trading screen
April 2, 2012
The Hal Spacejock PC game is under development! Like the books, the game will be set in a populated galaxy with plenty of star systems, worlds and settlements. Features will include exploration both in space and on the surface of any planets or moons you might find, buying and piloting assorted vehicles, trading in resources, setting up factories, hiring robots to do the hard work and gaining reputation and cash by helping people out.
All that empire-building, and not a crafting table to be seen!
Of course, you're not the only person trying to make a buck, and you can be sure the road to the top will be paved with caltrops.
The plan is to release early and often. Alpha versions will be free to all (Windows XP or later, shader 3.0 capable video card, Microsoft Dotnet 4.0 and XNA 4.0 libraries required.)
Important note: I'm far more interested in gameplay than eye-candy and soundtracks. If you like cutting edge graphics, this is not the game for you. (Every game company under the sun thought graphics were a priority until Minecraft came along and proved them all wrong.)
Early days ... a screenshot from the flyer
Tau Ceti and Academy (ZX Spectrum)
Combat Lynx (ZX Spectrum)
Carrier Command (Atari ST)
Transport Tycoon Deluxe/OpenTTD (PC)
X2 and X3 (Egosoft, PC)
Elite (ZX Spectrum)
Interstate '76 (PC)