I have a few at the moment:

1. A new version of Elite... would have to be multi-platform to work, features would be infinite size universe (128bit coordinates!), scalable 3D engine, persistent on-line world, and one life per person - once you're dead, you start off again with 0 kills. Other things would be a customisable array of weapons (have to have some kind of physics/programming aspect to let the user make their own), automatic planet generation for when people fly to uncharted areas, ability to fly round cities on the planet surface - what I'm talking about is starting off inside a building (e.g. a ship hangar), flying out into a street, going up through the atmosphere and out to another planet all in real time, without any pauses to load stuff off disk - pretty ambitious, but it could be done.

2. An RTS similar to Age of Empires, where you start off with a primitive race that gradually builds up technology, until (hopefully) they conquer the planet and take off for another one (e.g. and Exodus style galaxy). Maps would be huge, at least 1000x1000 tiles. Again, a persistent multiplayer world would be nice.

3. First there as Stunt Racer 2000, then Star Fighter 3000, but what happened to Death Racer 4000? I'm sure Fednet wouldn't mind too much if we did it. My ideas are for races in space ships on planets, similar to Star Fighter. Each ship could be given a launch buggy which it is docked with at the start, which can later be used for re-fueling and pit stops.

4. A voxel based game, with AI vehicles? The story line would be something along the lines of the military developing AI vehicles due to shortages of men, and you have to train them to kill the enemy. The only real problem is likely to be the low speed of voxel plotters and neural nets.

5. A GTA style game, where you are the head of/member of a gang. Most, if not all, of the missions would be computer-generated, so it would be a constant battle against the other gangs. A top-down semi-3D view like GTA would be best I think, and of course multiplayer would be fun

6. Erm... Ur... Erm... Anyway, you get the idea. Things that could work now, or in the near future.

1) Sounds a lot like Karma. Yes you're right it would be ambitious given that Karma has yet to see the light of day on any platform and must have been work in progress for nearly a decade now. Karma doesn't have the fly around in the atmosphere bit either.

I wouldn't go for automatic planet generation as such, I'd be tempted to look at a Karma style system where data is generated using astronomical rules / data as we know them today. If you fly out of the galaxy then expect a huge empty void - sounds realistic to me

The planets could probably be achieved using somekind of procedural synthesis (I believe there is a PSX2 project which uses something similar to map out the Earth) and cities could probably also be automatically generated. If you generate all this information procedurally then you won't necessarily be loading data off the disk. However for those times you do need disk access I dare say it could be done under interrupt at appropriate points (ie when there isn't much on screen). Then all you need to do is combine this little lot with a truly scalable engine - Elixirs Infinite Polygon engine for Revolution would probably do the trick quite nicely for the cities. The landscapes could probably use a system like ROAM, or quad or octrees for frustrum clipping and depth sorting.

2) RTS...well hopefully Tek is on the way, although it's scope is less ambitious. Talking in terms of tiles can be a bit meaningless though because the world will be much bigger if you use 32*32 tiles as opposed to 8*8.

3) Deathracer 4000? Well Fednet went to other platforms. You wouldn't have to call it Deathracer 4000 either, perhaps something like "A Tribute to Fednet" ;-)

I'm not quite sure what you really mean though. Are you saying you race spaceships or cars (Deathracer 4000 was due to be an updated version of Stunt Racer 2000)? If spaceships I guess you're looking at something similar to, but with more freedom, Wipeout.

4) Interesting, although I'd throw out the voxel landscape. With the Omega we're apparently getting 3D acceleration. Might as well use it. The AI stuff would be complex - artificial life programming anyone?

5) Probably the most realistic of the ideas here in terms of the resources that RISC OS developers have access to. I guess an enhanced version of the EMD engine might actually do it (judging from the screenshots), although all the graphics would either have to be reimplemented as polygons or some sprite scaling routines implemented. BTW, Owain, if you're reading this I'm not trying to drop you in it

6) Well theoretically all these are possible, and I've tried to outline some of the techniques that might be used. I wouldn't expect them appear anytime soon though (especially number 1). However, perhaps some of the ideas could be incorporated at a less ambitious level.

The main problem is that I have found noone who wants to write a new version of or update the present StuntRacer. I have Fednet's two computers full of code and if anyone wants to do definitely sit down and start rewriting or updating StuntRacer then speak to me.

There MUST be someone out there?

Perhaps (depending upon licensing issues, etc). The Hexen engine could be used for it?

SR2000, SF3000, and Chocks Away were (I think) all based upon the same game engine, written by AH using the BASIC assembler. This was fine for the early nineties; this is the early naughties.

They were great games. If you stick bits onto programs, however, they become 'spaghetti code' very quickly. 10 years is a long time (too long) for a game engine to be maintained over.

I cannot emphasise enough how much the RISC OS platform needs a new 3D API/implementation. If this were done, then bringing back these great classics would be the icing on the cake.

If the 'meat' of SR2000 is anything like the 'meat' of SF3000, then no ARM coder coming from the nice world of Acorn's C/C++/Assember and APCS would even look at it.

I am not saying that these things are impossible, and certainly not that SR2000/Chocks Away/SF3000 are unmaintainable, but simply that the renderer of these games is completely obsolete.


[Edited by 34 at 17:18, 21/12/2000]

I have always heard, "There is another one being written...." but that turns out to be a load of hogwash anyway.

Noone is dedicated enough to write one as it is a long and complicated procedure made worse by the fact that if more than one person is working on it then they usually have to do it by email slowing progress eve more.

Either we get the best coders left (I certainly wouldn't put myself forwards) to cooperate on implementing a 3D API, or there will be no new 3D games, and porting games from the PC will be nigh-on impossible.

Either it is worth it or it isn't.

In what manner is DFI dead? Isn't the source-code around? I imagine that DFI suffered from the same problem as dogged TAG and other 3D engines - it was an entirely proprietory system.

If a SWI interface was created for a 3D API, then instead of each being different and totally dependant on the person that wrote them, you could have had a DFI OpenGL module, a TBA OpenGL module, and anyone else that wanted to implement the API.

STANDARDS ARE VITAL!

We won't get many more/any more conversions because nearly all the software companies has shut their doors to us so I wouldn't worry as far as that's concerned because we can't do anything.

As regards getting the best coders together, this has always been an idea broadcast on the newsgroup but I doubt it would ever happen. Most RO coders do stuff themselves and there is always someone who falls out. All the decent coders are doing projects at the moment anyway.

I doubt we will get a 3D engine soon, well, not a decent one. So bye, bye 3D.

The DFI engine was quite advanced. We have the source but it is completely non understandable for anyone other than pT.

I doubt we will get a 3D engine soon, well, not a decent one. So bye, bye 3D.

I hope everyone has got that. No more silly suggestions about porting Half-Life OK?

I am looking into what would be needing to create a game using this method, as surely it must be possible, and would be a major hit in the acorn market if done well.
It think it can be done, and i have the ideas (im keep 'stum 'bout them at the mo) so what d'you VOTI????? (this is the part where you say "yes thats a brilliant idea, i would love to help you, & also get some dosh to pay for a happy retirement )

Firstly, if you want even the faintest idea of the complexity of writing a 3D engine, then read Paul Thomson's articles in Acorn User. Then implement what he suggests. Understanding all this and programming it, should take a few months. You willl then end up with a very primitive and slow game engine.

If you actually want to know about 3D graphics rendering, you'll need the book "Advanced Computer Graphics" that I borrowed from the university library. It weighs a few kilos, and it is full of Degree-level mathematics formulae.

It is all very well for people like you to think up these "simple" ideas. Who will you get to write the code? The mathematics behind a complex rendered 3D scene is completely beyond the comprehension of most people.

There is no shortage of "ideas" in the RISC OS market, but there is a shortage of skilled programmers.

The difference is, that im taking it a little further than "an idea", as im aware writing a 3D cant be easy, but once you have one 3D engine in the RiscOS market, that opens the scope for more 3D based-games - just look at the quake engine -> you can get pretty much any game you like for it (although it wont be that kind of scale)
The idea will be to set up a team to produce this game as a commercial venture, then after its release then release the engine & tools for other groups to build new games.
I understand your sceptism, and im fairly sceptical about it, but hey, if i can get the "idea" up and working then its going to be a major move for 3D apps for RiscOS.
Where you were saying about the speed, Im thinking of the engine being based around how doom is run (but modernised) which runs at a decent speed on a RPC anyway, so if this 3d engine was to follow this im sure that it should run well.

The mathematics behind a complex rendered 3D scene is completely beyond the comprehension of most people.

It's not too bad though, some complete s understand it...

yay some support
As andrew was saying, once you have 1 engine, even if only VOTI have access to it, then you can produce & develop alot of new software, which can only benefit the RiscOS market at the moment.
If I take Quake as an example (sorry for using too much ) but looking at the number of different mods avaliable almost all game genres are covered, from Action to R-T-S, all with one pretty old & dull engine, the difference being that it is soooooooo versatile

This is all getting a bit heated so hopefully I can calm things down a bit.

Firstly Quake isn't all that versatile. It's great for indoor games and not a lot of use for much else. This is fine if all you want to play is FPS but, frankly, they bore me rigid.

Secondly there's obviously a massive gulf here between the people who suggest 3D and those who "know" 3D. This isn't surprising - we're not all programming experts. I don't think people should flame Mark for putting his ideas forward, however Mark does need to appreciate just how tricky it is. To give an example, John Carmack has stated in Edge that they don't make games, they make engines because the 18month development cycle doesn't allow for both.

Now if Id can't do both in 18months of full time work it's going to prove a little difficult for a part time RISC OS coder.

Thirdly I think we all agree that what is needed is a proper API and perhaps the way to go is to cannabilise code where possible. Personally the resources I have at my disposal include my OS/G event driven 3D engine, my Warp API, Martin Pipers free 3D engine and TAG from the TBA Collections CD. All of them have large flaws but potentially provide a starting point. I thank Andrew for his confidence in my ability - I wouldn't be so sure and my time is limited. A more powerful machine would help as well (an A4000 really isn't up to it) .

Take a look at the old IconBar news section as there was something about cheap RPCs for programmers/developers.
but hey, the A4000 was a nice machine (provided me with many hours of chocks away fun )

About the idea of sticking with 1 3D API, what has/in development for RiscOS??
and what do you all think would be the best API to start with???

[Edited by 22 at 12:52, 16/12/2000]

yup,
i see what you mean about the time/skill needed for a project like that, and i understand that just putting up "ideas" isnt much help, and i wouldnt have if i didnt feel that i knew "enough" about it to start this idea, although im not saying that i couldnt learn a few more things -i have experience of working with 3d engines (so i know a bit about how they operate).

Again I don't want to sound like I'm putting you down but I could probably tell you how just about any of the najor engines out there operate. There's a world of difference between knowing that and coding it. The principles are usually quite simple.

I for one do appreciate hearing your ideas. I'm not a particularly imaginative person (well, not when it comes to games) so it's always nice to hear what people would like.

Take a look at the old IconBar news section as there was something about cheap RPCs for programmers/developers.

I know and I mailed Chris Evans at CJE about it. At the time I decided not to take it because Evolution was supposed to be a lot nearer. I also don't have room for a second desktop machine right now. I'd be quite prepared to cough up for a RiscStation laptop but again it's not ready.

but hey, the A4000 was a nice machine (provided me with many hours of chocks away fun )

I'm still using mine - I'm writing my thesis on it. My PC is faster but Word is a nightmare. However it's not up to 3D Engine development unless you're prepared to do a lot of extra work (supporting old and new versions of RISC OS - personally I'd only write for 3.5+ if I could) and compromise with 256 colour graphics.

About the idea of sticking with 1 3D API, what has/in development for RiscOS??
and what do you all think would be the best API to start with???

OpenGL is the only way to go if we want cross platform compatibility. Mesa is available but is huge. A MiniGL driver would be a good start (and, to be honest, not that difficult to create). THe trick is to find the source code to one.

[Edited by 9 at 17:39, 16/12/2000]