Still in the pretty early days, not even "playable" yet, really, though I expect to approach "playable" tomorrow or in the next few days (though no where near polished enough to be considered done.)

So this game (when it becomes a game) is very much inspired by Artemis Spaceship Bridge SimulatorSee: http://www.artemis.eochu.com/ The idea is you have a game which is played much as the actors in the Star Trek TV series played their roles on the bridge of the Starship Enterprise. There are a number of "stations": Navigation, Weapons, Science, Communications, etc. and each player assumes that role. Each station has it's own laptop or other computer which communicates via network to a central server which simulates the game universe. So it's kind of a cooperative multiplayer network game... No reason not to have multiple teams in multiple starships inhabiting the same server/universe either cooperating or doing battle.

Mine is different than Artemis Spaceship Bridge Simulator in that it is:

GPL'ed.Linux/gtkProbably uglier (lol).Probably more scalable (yay vector graphics.)Not even close to finished.

Skorpio {l Wrote}:I'd love to see this game finished. Are you leaning more towards a simulation or an action game?

Well, I'm not sure what you're asking...

It's going to be real time, but the action is probably somewhat slow, not frenzied. In some ways it's a simulation, but, also an action game?

In any case, I've gotten pretty far in the last day.

You can now drive and shoot, which as everyone knows, are the two most important activities of a starship captain.

Individual players can join the game at any time, and specify which starship to join, and multiple starships per game are possible. (this is all working now.)

That being said, you can pretty much *only* drive and shoot -- and the torpedoes don't ever hit anything, or die -- the torpedoes are immortal, just like everything else in the game so far (deleting objects from all the clients is not straightforward, but should be do-able, just haven't done it...)

Got a lot done over the last week, as I was on vacation for Thanksgiving. Too lazy to do a video today, so just some screen shots:

Above is all the client modes (screens) Weapons, Navigation, Science, Comms, Engineering, and Debug. They are small because, like Word War vi, the graphics scale to match the window size, and I have shrunk them all down to fit on the screen. They are all separate processes communicating via network with a server process. The large screen partially shown on the right is the "main" screen. Any client process can "project" his screen onto the "main" screen by pressing "ctrl-O" -- O for "on screen!", as Capt. Picard so frequently says.

Above is the navigation screen. Left/right arrow keys rotate the ship, up/down arrow keys move the ship fore and aft. The Warp drive slider and "engage" button "warp" the ship instantly through space (the warp drive needs some work to make it a little more intuitave and, uh, dramatic as well.)

Above is the Weapons screen. Torpedoes may be loaded into the torpedo tubes (2) and fired at passing ships. This needs work (sound effects) and also, right now, a single hit invariable annihilates whatever it hits, so that needs fixing. Phasers don't work yet.

Above is the "science" screen (scanning). You have a scanning beam that you can swing around using left/right arrow keys. up/down arrow keys control the width of the beam. When the beam is wide, it's range is short, and the further away things are, they "fuzzier" they are. As you narrow the beam, the objects become less fuzzy. At a certain point, when things are un-fuzzed enough, you get some information about the ship, like it's name, position, bearing, range, heading, shield strength and wavelength characteristics. You can also zoom the science scope in and out using the mouse scroll wheel.

The "dotted" lines in the above still picture are kind of moving around and a bit more lively than they look in this picture, but you can't see it in a still shot.

Above is the engineering screen. There are 4 gauges: RPM, Fuel, Power, and Temperature. The idea is you have some sort of "engine" consuming "fuel" and producing "power" which can be distributed to the various systems. The power is a function of rpm and temperature. The sliders are used to distribute the power around the ship. The power distribution part doesn't really do anything yet (but the sliders work.)

Last, is the debug screen, which shows a map of the universe. The white dots (or, X's, if you look really closely) represent computer controlled ships. They are clustered around the "starbases" because the AI for these ships at the moment consists of "go sit near the nearest starbase."

Also, difficult to show, when you start up each client you can specify which "roles" it will fulfill -- science, weapons, navigation, etc. ("all" is an option.) Additionally there is a "soundserver" role, so that sounds which are global to the ship -- e.g. being hit by a photon torpedo -- can be directed to the system that is connected to the big stereo. Sounds also may be directed to individual stations -- so you could get distinctive science-y beeping noises from the science station laptop, and weapons-y noises from the weapons stations etc. Not that any of those sounds are in there yet, but the infrastructure to do it is there in the code.

No 3d "thru the window" view yet --- if I do it, it will be a totally software z-buffered flat-shaded triangle renderer that looks like it's from a 1982 silicon graphics workstation. You'd probably rather someone besides me programs that bit, lol. As would I, as would I.

-- steve

p.s. Not getting a lot of feedback... wonder if I'm wasting my time creating a game that requires you get together 4-6 of your linux/startrek nerd friends on a LAN to play, lol. Well, it's a fun waste of time programming the thing, and, I am learning a bit doing it, so... I'll keep at it. I do worry that the various stations won't actually be *fun enough* though -- trying to program in some "fun", but, also keeping to the spirit of the thing -- the "fun" may depend more on the personality of the participants than on the game content for this sort of game, not sure.

Well... probably if I switched from basic gtk/gdk line drawing and so on to cairo, compositing a backdrop image -- even scalable -- would be possible, similar to Dueling Masters of Space Time. http://smcameron.github.com/dueling-mas ... pace-time/ Performance might be iffy on low end machines, but, eh, it'd probably be ok. To some extent, I think the "looks" of the thing aren't necessarily all that important, what's important is that is should be "fun", and fun and looks are not necessarily correlated, and maybe a lot of the "fun" of this particular game may come from the people playing it, we'll see, I guess.

The one place I think that the looks probably do matter quite a bit would be in the as-yet-unimplemented 3d "out the window" viewscreen.

I need to hurry up and get things far enough along that I can get some people together to play it and see what it's like.

I've been working on some new top-down spaceships (and mechs), just for fun, and wondered if you have a use for them. Or are you going for a more abstract look and 3D graphics for the screen? If you want 3D ships, then you could probably utilize the shipyard on OGA.

Btw, I think the term phaser is protected and you should better replace it.

I'm probably going for a more abstract thing than those top-down views. The shpyard may come in handy when I get to the 3d stuff. (I have vague notions of metaprogramming OpenSCAD to procedurally generate spaceship models, but haven't thought very hard about it.)

This game looks really nice. Its impressive to see the fast progress and all the new things. Keep up your interesting work, I`ll follow your posts.Do you have any idears of goals for the players, beside flying around in space?

Do you have any idears of goals for the players, beside flying around in space?

Well, as a start, various ships will attack various starbases, as well as your ship, so you try to intervene, etc. and stay alive.

Additionally, multiple player-controlled starships may inhabit a server, so either cooperative or combative play is possible. "Space" being kind of wide open (and in my implemenation) kind of two dimensional, there's not much opportunity to hide-n-seek, or have elaborate strategies that I can think of for multi-ship combat. Will have to think about some ways to liven that up and make things more interesting.

Farther than that, I haven't really given it much thought, just trying to get the game to a playable state for now.

If you have some particular ideas, feel free to share, but of course I can't guarantee I'll ever get around to implementing any of them.

Ideas that allow simple things to be combined in interesting ways that lead to some interesting emergent behavior are probably the best, but that is kind of a tall order.

Nice! What is the classical music playing in the background by the way?

BTW, you may wanna try actually, err, using a screen recorder (FDesktopRecorder is the one I find the best for Linux). Also, if you find OpenSCAD slowing you down, try BRL-CAD. It's much more powerful, and in many ways, the granddaddy of the CAD programs today, made by the American army.I'll just quote Wikipedia on it:

The BRL-CAD source code repository is believed to be the oldest public version-controlled codebase in the world that's still under active development, dating back to 1983-12-16 00:10:31 UTC.

You know your program is mature when it is still in use and development today and its original author is dead (another example: the C programming language)

Evropi {l Wrote}:Nice! What is the classical music playing in the background by the way?

I believe it's Bach, the Brandenburg Concerto.

BTW, you may wanna try actually, err, using a screen recorder (FDesktopRecorder is the one I find the best for Linux).

Bit of a hassle with the audio then... pointing the camera at the screen is trivially easy, and I'm lazy, though it does give sub-par results.

Also, if you find OpenSCAD slowing you down, try BRL-CAD. It's much more powerful, and in many ways, the granddaddy of the CAD programs today, made by the American army.I'll just quote Wikipedia on it:

The BRL-CAD source code repository is believed to be the oldest public version-controlled codebase in the world that's still under active development, dating back to 1983-12-16 00:10:31 UTC.

You know your program is mature when it is still in use and development today and its original author is dead (another example: the C programming language)

Interesting. I'll have to take a look at that. It appears to be a bit of a monster compared to openSCAD.

+1 for openscad. I'm aware of brlcad and it's history for a some time btw. But for programmers openscad seems like an awesome tool - again because I'm a fan of parametric and procedural design.On the other hand maybe I've missed similar features in brlcad?Can it do CSG operations like intersection, subtraction and addition on 3D geometry and that parametrically scripted with macro/modules

I'm a big fan of openSCAD as well. I'm not actually sure whether it's turing complete or not. It does have some pretty severe limitations (e.g. the "variables" you get in openSCAD act more like constants than like variables.) For this reason, I came up with openCSCAD, which is a tiny little C library for outputting openSCAD code. (It's kind of a neat little hack at best, and a useless piece of crap at worst, lol.) It does technically get you nice things like real variables, recursion etc. but at the cost of massive openscad file output which may or may not really be processable by openscad. (e.g. the tree picture on that page was done by screen shotting after pressing F5, not F6. F6 in openscad actually does all the reall CSG stuff, and doing all the intersections of all those branches, etc... well, you may or may not live long enough to see that computation run to completion.)

Haven't yet looked at BRLCAD, as I have no pressing need, and it looks a bit daunting.

Hm, assumed that recursion in OpenSCAD would work - which would still make it a more or less complete functional programming language for solids even without variables - but it didn't work. It gave no errors for module-recursion but didn't work as expected, duplicating and renaming the duplicate method code did of course. Yes, seems pretty static compile time and incomplete but for technical/mechanical models it should be enough.As for BRL-CAD: Can't imagine a tank having fractal structures ... unless for stealth someday

Yeah, generating code from code is of course an option - besides openSCAD's code-editor isn't the best.OpenSCAD's loops should suffice most of the time, I think I'll try when in need of recursive structures.

Wouldn't mind if Admins would move this discussion about tools somewhere else - don't want to divert from the interesting work in progres topic.

Yes. I'm pretty sure the openSCAD developers know this, because they provided a "hide editor" option, and the F3 key reloads the source file. What I do is have vim going in another window, and switch between the two with alt-tab. Save from vim, alt-tab to openscad, F3, then F6, then alt-tab back to vim -- that is essentially the "edit compile debug edit" cycle for me with openscad.