Elite did have missions that you could succeed in, giving some sense of victory - just not in the Electron version, which is what I had. We had to make our own fun in those days

So the Electron really was the poor man's BBC - "The Electron version is exactly the same as the BBC version in every detail.....except the last two thirds of the game are missing, so you can't win!"


I never had Elite on my Electron.

Elite did have missions that you could succeed in, giving some sense of victory - just not in the Electron version, which is what I had. We had to make our own fun in those days

So the Electron really was the poor man's BBC - "The Electron version is exactly the same as the BBC version in every detail.....except the last two thirds of the game are missing, so you can't win!"

I never had Elite on my Electron.

As the BBC Cassette version didn't have the mission's either this is a totaly spurious point.
Also You don't have to complete the mission's to become Elite.

Cheers,
Rich.

All granted, James, but not really the point. The Electron version didn't have suns or Thargoids either, so it really was a poor man's version. Luckily, I'm also elite on the Arc version.

And this is one of the games I've played the most in my lifetime? Sheesh!

Someone tell me what game to write!

I'm thinking that you'd need supplies on route, so you could go quite far without having to interact with someone, but at some point you'd need to get hold of stuff.

So it's not so much never-ending waves of enemies, it's the constant tough choices as to what you're willing to do to get the supplies you need.

Perhaps you could even have combat and legal status type stuff as part of the setup. If you kill kids to take candy, you might get a rep that means villagers won't come near you, making trading harder (but maybe soldiers will like you more?); if you kill soldiers then perhaps you'll have problems passing check points, or entering larger towns; and if you're a stone-cold killer, apart from adding to your strength/stamina/perception stats, perhaps you'll be asked to do bounty hunting or assassination missions...?

Someone tell me what game to write!

Have you read the uplift books, by David Brin?

I suggest you write something like a cross between Elite, Exile and Ascendancy.

One ship per player. (Multi-player or networked as you choose, design accordingly but start with a working one-player game)

Most importantly: *diverse* means of travel. I want travel by hyperspace, infra-space, teleportal (gated, long-distance instant travel), warp-space, witch-space and more. All these have different challenges and benefits.

... and *diverse* real-space environments. These should include densely as well as sparsely-packed stuff of different sizes, including asteroids, Oort clouds, space-junk, meteor storms. Different places need different backgrounds: near the sun should be red. Interstellar dust clouds would of course be black.
All of this necessitates multiple viewing methods. Standard visible light, infra-red, gravity, magnetic, radar, plus more as gameplay dictates.

2d would be fine.

Just use whatever engine is to hand.

Challenge.

Have you read the uplift books, by David Brin?

Nope.

One ship per player. (Multi-player or networked as you choose, design accordingly but start with a working one-player game)

Multi-player/networked?

Most importantly: *diverse* means of travel. I want travel by hyperspace, infra-space, teleportal (gated, long-distance instant travel), warp-space, witch-space and more. All these have different challenges and benefits.

What are the different ranges/speeds/technologies/etc for each of these?

... and *diverse* real-space environments. These should include densely as well as sparsely-packed stuff of different sizes, including asteroids, Oort clouds, space-junk, meteor storms. Different places need different backgrounds: near the sun should be red. Interstellar dust clouds would of course be black.
All of this necessitates multiple viewing methods. Standard visible light, infra-red, gravity, magnetic, radar, plus more as gameplay dictates.

Easy enough

2d would be fine.

But that requires drawing lots of sprites!

Just use whatever engine is to hand.

Half-finished 3d engine which is being developed to support most of what you've described... nope, still needs more work.
Numerous platformer engines written in BASIC which use a crappy sprite plotter... nope
Vague skeleton of a roguelike engine written in C... nope
Wolfenstein 3D-style graphics engine... nope
Half-finished 2D racing game engine... nope
Crappy voxel landscape engine... nope
(Other, long forgotten engine, which may/may not exist)... nope

* Assume space has friction.

...
* Planetary flight is presumably impossible. Planets/stars you are near may be represented as a large sprite in the background (say one or two times the size of the screen).

* What about ships and ship fittings? You say that you have one ship per player - but does that discount being able to upgrade to a new ship or to buy new guns/etc. for your current one?

Presumably if there's a big war going on and you're fighting in it then you'll need to change to different ships for different battles.

* Each object will have several different sets of sprites, one for each visible spectrum. My rotated sprite plotter produces acceptable results (especially if there's a 1-pixel transparent boarder around the sprites), so only 1 rotation of each object will be needed.

...
* I do have some ideas for stuff, but the ships involved are far too big to be visualised in a 2D game. Should Dark Matter actually reach completion, you have been warned

[edit]* Also you mention Exile... now I know that Exile doesn't involve much flying around in space ships, so does this mean that there'll be out-of-ship platformery bits?[/edit]

Challenge.

Challenge? CHALLENGE?

Is this the kind of challenge where you'll just sit back and do nothing, or are you man enough to challenge me to a coding duel? I demand satisfaction! :slappingwithglovesmiley:

To actually have a chance of 'finishing', although you might plan it, don't rely on it until single-player is working.

Faster travel methods should 'feel' faster - so one could involve hurtling down a set of branching tunnels, another might be slingshoting round attracting objects to get to exit-points.
A 'slower' method might be based around the concept of floating round thin films like bubbles, and so on. These, and other concepts can be developed these further as necessary.
Each one of these would of course be necessary for different purposes, or just because they don't all cover the whole universe. All must be interesting.

Might not be. Gravitic view for example would involve tracking contours, or some form of scaling beta-ball-like plot.

Hey, space-ships are not all that hard.

Bigger ships can be generated from tiled stuff close-up, although I suppose that might make rotating more difficult.

I thought you had a set of routines for drawing sprites you were happy with now?

* Assume space has friction.

No! that is the sort of thing that should vary by area.

Perhaps. Doesn't matter too much.

Duelling with nukes or kinetic impact missiles might be more interesting.

For many of the plots, I was imagining that no extra sprites would be required. Instead, custom plotters. Heh, sorry.

Heh, in the game (name not disclosed, I think it is fantastic), most ships would tend to fit under a single pixel in many plots.

Heh, moral support?

But with someone enthusiastic, maybe that could change.

And still might have interfacing issues.

But if you want me to work with you on this, I want to have some creative input, and also... to use my special name for it.

Perhaps you could even have combat and legal status type stuff as part of the setup.

Maybe. I think there'll be too much anarchy for the corporations to bother tracking every criminal.

Cheers,
Rich.

If I was writing it I probably wouldn't involve multiplayer at all

So the different travel methods are interactive? e.g. if you're going through branching tunnels, the player has to select the right branch each time or run the risk of coming out somewhere completely different to where he wants? Now I see the motivation for having the different types. If you're a good pilot then you can take the fast and risky route, or stick with the slow & safe (i.e. flown by autopilot) route.

Might not be. Gravitic view for example would involve tracking contours, or some form of scaling beta-ball-like plot.

Well, that one might be tricky. But the others shouldn't be

Hey, space-ships are not all that hard.

True. But recolouring polygons or detonating a polygon mesh is a lot easier than recolouring sprites or drawing explosion graphics

Bigger ships can be generated from tiled stuff close-up, although I suppose that might make rotating more difficult.

I could probably write a tiled rotatey plotter thing if big tiled ships are needed.

Without friction, you'll be able to accelerate to crazy speeds. This will make 16x16km very small, so you'll need to use a bigger coordinate system - say 64bit math, 48.16 format. This is the same that Dark Matter uses, and is large enough to fit a solar system into. If space doesn't have friction then presumably we're going for the full newtonian pie, so planets and other objects will have gravitational fields. All major structures in a system (stars, planets, moons, stations, gates) will therefore have to have the correct orbital paths, and will be loaded into the game world when you enter the solar system. However when you're flying along at several thousand km per second, a small top-down 2D view will become restrictive, so you'll probably want to be able to zoom your view (Which is easy enough to do), or switch to 3D. A zooming view should let the player zoom out very far, far enough to theoretically see thousands or millions of space ships clustered round stations and planets - so you're either going to have to be able to process a lot of space ships, or make it so that the size of object your sensor can detect is inversely proportional to its distance. The fact that space is no longer grid-based means that generating encounters with ships or bits of scenery (Oort clouds, space junk, etc) will be a lot trickier.

Perhaps. Doesn't matter too much.

So you want a 2D space game with newtonian physics and planetary flight?

Duelling with nukes or kinetic impact missiles might be more interesting.

So large-scale, long-distance, tactical battles as opposed to the more usual arcadey close-range dog fights? That'll imply a fairly zoomed out view to start with (say, 1000km by 1000km), which means that the grid-based approach may still be workable (The grids will be a thousand or so times larger than before, so will still take several seconds to cross unless you spend all day with your foot on the accelerator)

For many of the plots, I was imagining that no extra sprites would be required. Instead, custom plotters. Heh, sorry.

What kind of custom plotter? Just colour translation, or some other fancy effect? E.g. would it be possible to put the sprites through a translation algorithm beforehand, and then use the standard plotters?

Heh, in the game (name not disclosed, I think it is fantastic), most ships would tend to fit under a single pixel in many plots.

Ah, so it is a large scale game. You could have said sooner

If it's such large scale then a tactical view might be best, rather than one showing each ship rotated & scaled accordingly. Just plot a nice display showing what the ship is and a line giving its trajectory.

If you truly are thinking big, then it will be interesting to see how your big ships compare to mine

And still might have interfacing issues.

Yup - I'd much rather write it all in C/ARM than BASIC/ARM. And usually the only ARM that would be needed would be the sprite plotters, which are mostly written already and are generated from an obtusely formatted run-time assembler written in C. So there's very little recognisable assembler there, either

But if you want me to work with you on this, I want to have some creative input, and also... to use my special name for it.

I was more envisaging us working against each other, and seeing who could complete the game first

But working with each other is OK as well

You can have all the creative input you want - you're the one who's come up with the idea, and know how it should all work. Depending on how ambitious the design is, you may be able to convince me to write it in BASIC. But if it needs a WIMP interface, fixed point math, extensive sprite plotters, 3D graphics, code profiling, transformation matricies/3D vector maths, or lots of speed, then I'd much rather write it in C and use my WOUM library

I think several scales should be necessary for different purposes. I'm a bit bored of space-based rotating dog-fights to be honest. But I've never seen a long-distance tactical duel done. (Even though this is arguably more realistic!) I think there is some real scope for different types of missile with multiple flight-path options.

If you truly are thinking big, then it will be interesting to see how your big ships compare to mine

Well, I don't have any concrete plans for *huge* ships, but space-stations can be almost arbritrarily large.

I was more envisaging us working against each other, and seeing who could complete the game first

So... You beg for ideas, and I tell you mine for the game I've spent years developing on and off. Then we both write it separately, but with me explaining all the reasons for why things are how they are?

Why?

fixed-point - as opposed to what? Ints?

code profiling - what?

So what interface does your WOUM have?
If you can make a system I can slap ARM routines into I'll be fine.

I guess if we were doing it we could start pretty small, then develop 'outwards' adding on new plots and travel methods, then add a story when appropriate. But a mission system would need to be there from close to the start.

The only problem with missiles and long range is that there's plenty of time for the enemy to shoot down the missile before it can hit them. You'd either need a lot of missiles, or some kind of projectile/energy weapon. Or a very big noise generator to confuse the enemy's sensors and stop them seeing the missiles

(Mine are bigger )

chal·lenge ( P ) Pronunciation Key (chlnj)
n.

1.
a. A call to engage in a contest, fight, or competition: a challenge to a duel.

So what interface does your WOUM have?
If you can make a system I can slap ARM routines into I'll be fine.

C. But if you're willing to put up with the APCS parameter passing method (Functions which take >4 arguments will have some of them placed on the stack) and the loss of a register or two then it should be easy to use from assembler. However if your code doesn't need to call any other C functions then you can do pretty much whatever you want. You'll even get to use an assembler that supports the full instruction set!

I guess if we were doing it we could start pretty small, then develop 'outwards' adding on new plots and travel methods, then add a story when appropriate. But a mission system would need to be there from close to the start.

Sounds good to me. It's quite easy to write assembler that's tolerant to changes in data structure layout, so that shouldn't cause any problems as the system grows.

What kind of mission system did you envisage? Will all the missions be hard-coded or will some simple scripting language come in to play?

(Mine are bigger )

Its what they can do that counts.

What you seem to have missed is the concept of "challenge and response". It is traditional for a series of small skillful repostes of gradually increasing difficulty to be alternately performed.

Sounds good to me. It's quite easy to write assembler that's tolerant to changes in data structure layout, so that shouldn't cause any problems as the system grows.

Is that sarcasm?

About structure, I suppose it is undecided.
The free-form/sandbox and trading models are I think probably a little lacking for this.
The grunt/soldier model (linear missions) would probably feel too rigid, would prevent exploration and would make a mockery of the core concept.
The GTA model (fairly free-form missions chosen by player) is OK; A variant of this might work quite well.
It would be interesting to be a semi-autonomous secret agent, you could receive requests on things to go and spy on (or blow up). And so on.

Yes, yes, yes, and yes

Someone tell me what game to write!

What happened to Dark Matter?