next »

[nihilocrat]

Had time to try 0.0.4 and it all works for me (except possibly music?) I was able to maneuver and destroy one of the enemies.

Things I like:

* I was playing in a darkened environment, and when I turned toward the lightsource the darkened cockpit made the whole room feel darker. Spooky!

* The voice is a great idea.

Bugs:

* No music?

* If you fire lots of missiles the target list overflows the top left display.

* I couldn't use the mouse (laptop trackpad) to look around or to rotate the ship, although the buttons worked. I'm reasonably sure this was OK in an earlier version though.

Looking forward to updates,

Will

Hey, thanks for playing and giving feedback. The voice is much less active now, as I've replaced stuff like targetting / weapon selection feedback with actual sound effects. I was getting a little annoyed, but it's still there, it just generally only comments on events outside the cockpit (missile launches, detonations, ships destroyed, laser fire, etc.)

1) Yeah, there's music, I've noticed that occasionally, with some builds, it won't work. Never happens during development. Not sure why, try 0.0.6.
2) I fixed that a build or two ago
3) I don't think I had mouse movement working in 0.0.4 either

Update: For the sake of seeing if everything works for everyone, I'll make a 0.0.7 build tonight, and that will be it. Otherwise, I'm holding out for another release until final so that it's still sort of a surprise for those following the techdemos. I'm sufficiently not embarassed enough that I'll release the source under a lenient open source license. I'll post screenshots in the interim.

[nihilocrat]

New demo. I am not calling it a 'tech'demo anymore because the gameplay is technically there and there's even a main menu.

Known issues:
-Only your first missile will actually destroy anything. Any others will never hit their targets. I don't know why, it's really annoying me.
-If you quit to the main menu and then try and start a new mission, it will crash. This is a side-effect of the scene objects in the engine never actually getting deleted. I blame Python and its reference-counting garbage collector... this is just as bad if not worse than tracking down memory leaks in C++. I'm in the process of trying to find a workaround.
-Not really an issue... the Gauntlet isn't really a Gauntlet, your first enemy is the only one. I will throw in some goal-checking code to properly spawn new enemies as you destroy each wave.

[Pishtaco]

Doesn't run for me. I get "hardaether.exe - Entry point not found / The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll". I tried installing the vc08 thing (although I suspect I had it somewhere already), but I still got the same error.

Reading about your problems with destroying objects in python, I've decided just not to do that in my game. I'll just have a fixed number of things instead.

[nihilocrat]

Doesn't run for me. I get "hardaether.exe - Entry point not found / The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll". I tried installing the vc08 thing (although I suspect I had it somewhere already), but I still got the same error.

Reading about your problems with destroying objects in python, I've decided just not to do that in my game. I'll just have a fixed number of things instead.

I had issues with Python's typing system early on, which I started calling "surprise typing" instead of duck / dynamic typing. The latter two names suggest that the language is "typeless" or something, which isn't true at all. I learned that, to get around this, you basically need to just keep the scope of your variables relatively tight... the Python axiom in effect here is "flat is better than nested". I was having problems when I was passing around the same variable across 8 or so functions, and somewhere along the way a function needed it to have "Foo.bar()", which was a method of the "Baz" class, but it was really a "Qux" object all! Surprise! Of course, you only figure this out during runtime.

Now, I'm having issues with the memory management. Up until Python 2.5, Python never freed memory. You could delete objects, but the memory allocator never gave that memory back to the OS. At least we can free memory now, but as I say above, the garbage collector uses reference counting, which means that it just keeps a count of the number of references made to an object rather than the references themselves. Again, it's very easy to shoot yourself in the foot because you never before really thought of a new reference to an object as being expensive.... pointers in C are very cheap to pass around, just a long int.... and you need multiple references to objects all over the place. You're even encouraged to make local copies of references, because every dot in "self.model.ships[0].target.weapon.ammo" costs a string lookup, so if you're using that more than once in a function you're encouraged to write "target_ammo = self.model.ships[0].target.weapon.ammo" and use that instead. However, this creates an intricate web of references-made-by-such-and-such-referrer of the object you want to delete.

Things are complicated more because when I try to delete my GameScene object (which doesn't inherit anything from OGRE, and which I carefully create and delete) it mysteriously holds onto references from "frame" objects that I've never ever actually used, and have no idea where they are coming from (Maybe from FrameListeners... but... why would the FrameListener care about my custom GameScene object enough to make a reference to it?), so I can never delete my GameScene objects because I can't figure out where these "frame" objects are and why /they/ aren't getting deleted!

On top of that, whenever you make an object that contains another object, and the child object holds a reference to the parent, you create a circular reference. On the Python console, it's easy to fix these; you basically need to explicitly delete one of the references. In reality, there always seems to be something else holding onto a reference. I could use weakref and proxy objects, maybe I just need to man up and start using them, but it seems like it would just complicate my code as I don't have a clear idea of where I should use weak references and where I should use real ones. (edit: reading this is helping me out a little... it might help to use weak references only in in strategic places like the Bullet class)

I should probably post this to a Python forum and have people point out what I'm doing wrong. I'm not concerned about the Ship objects not really being deleted right now, I'm more concerned about the GameScene objects and all the things it contains... Model, View, Controller instances along with a bunch of scene-related stuff, a bunch of things that need to be cleaned up every time you go from title screen to game or back.

As for the error, I figure you just might need to resort to DLL bombardment. I sort of wish they didn't compile the Python-Ogre binaries with Visual C++ and instead with GCC...

[muku]

I'm pretty shocked that Python still uses reference counting as a GC mechanism... that's not exactly state of the art... According to http://www.python.org/doc/2.5.2/ext/refcounts.html, though, it does at least have an algorithm for detecting cycles, so you shouldn't have to use weakrefs for that particular purpose. See also this: http://docs.python.org/library/gc.html#module-gc.

[Mikademus]

Nihil, thanks for writing about your issues. That made me think twice about using Python as as a development language or for scripting. I hope you sort the issues out, and you already know I look forward to the game!

[György Straub]

I tried it (and hard), but wouldn't start. Says something like: the entry point of the application (_except_handler4_common) could not be found in the DLL (msvcrt.dll).

It's a Boot Camp XP SP2, had the runtime already installed. any ideas?

[nihilocrat]

Nihil, thanks for writing about your issues. That made me think twice about using Python as as a development language or for scripting. I hope you sort the issues out, and you already know I look forward to the game!

Heh, I don't mean to demean the language, there are just some hard lessons involved in using it properly. I think it's great to embed if you want to import lots of things from its extensive standard and third-party libraries, or if you otherwise want to have "heavy lifting" occuring in your scripts. However, if you don't think you'll ever need to use any functionality you don't already expose, Lua might be a better option.

It's quite possible I just haven't made the proper quantum leap in knowledge to properly use weak references. In most applications, you never need to worry about it, because the application never really needs to get rid of anything.

Poo, looks like I didn't include the DLLs I thought I didn't need to distribute anymore:

msvcrt.dll
msvcp80.dll
msvcr80.dll
msvcp90.dll
msvcr90.dll

I'll include them in future builds again. 0.0.6 should have them: http://willhostforfood.com/?Action=download&fileid=60232 . In fact, you shouldn't need msvcrt.dll, 0.0.6 doesn't have it an I'm pretty sure the issues arise from the "msvcr*" that py2exe packs being the incorrect version for Python-Ogre.

I'm pretty shocked that Python still uses reference counting as a GC mechanism... that's not exactly state of the art... According to http://www.python.org/doc/2.5.2/ext/refcounts.html, though, it does at least have an algorithm for detecting cycles, so you shouldn't have to use weakrefs for that particular purpose. See also this: http://docs.python.org/library/gc.html#module-gc.

I've actually already read those, but thanks for showing them me again. I guess I should contemplate being down and dirty and looking in my gc.garbage for stuff that is successfully getting marked but not actually getting deleted. I'm making use of __del__ methods in several places so perhaps I should comment those out.

In other news, I vote for this as "coolest cockpit ever":

[Will Vale]

Space Ship One?

[nihilocrat]

Yep!

Programming tidbit of the day: For some bizarre reason, OGRE3D doesn't let you "setEmissive" on a material. Sure, you can modify that in a material script. The emissive properties are contained, you can even see an "mEmissive" member.

You can, however, "setSelfIllumination"

[Will Vale]

2) I fixed that a build or two ago

Sorry, I realised too late that I played an earlier version not the most recent one I'd downloaded. Must try to do better next time.

[nihilocrat]

No worry, beef curry!

Now that time compression is in place (it was amazingly easy to implement...) you can skip the boring slogs through space if you feel so inclined. I much prefer tweaking simulation time rather than going into "autopilot" cutscenes like in Wing Commander games. It just makes me feel like I'm not flying in space, but instead flying in little spheres of space in between autopilot sequences. I think I will proceed to increase enemy spawn distances now.

Yes, enemies will spawn. How else can I provide the player with a managable number of enemies for the player to fight, but not have the mission end immediately after a short skirmish?

Yeah, got a better idea? (no, really, if you've got a better idea, please mention it)

[nihilocrat]

Observation for the day: it's really hard to keep track of your orientation in relation to other ships without a proper radar image and/or an attitude indicator. I want the game to be sort of difficult due to an artificially high learning curve (like flight sims... why call it an AMRAAM when you could say "mid-range missile"?) but when I was flying around willy-nilly it became extremely hard to point myself towards the enemy after a bunch of random rotations. I'll also need to tweak the mouse controls, because they are a lot more frustrating (like accidentally maneuvering in a direction you don't want, like your yaw suddenly has a pitch element) than using the keyboard. The keyboard maneuvering/thrust controls will be in the final game because of this; I'm curious what people will end up preferring.

Good news: pretty much everything else is done, sans a few bugs (like the controls mentioned above), so I should have the time to try and implement such things.

My, how the times have changed

If you are to at least get off the ground, the manual comes in very handy. I recommend at least printing out the keyboard map so you'll know what each button does.

[Pishtaco]

I still get this with 0.7, even if I copy the ms*.dll files from 0.6.

Doesn't run for me. I get "hardaether.exe - Entry point not found / The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll". I tried installing the vc08 thing (although I suspect I had it somewhere already), but I still got the same error.

With 0.6 I get some loading text and then "hard aether has encountered a problem and needs to close."

[nihilocrat]

I'm honestly pretty tired of working on this. In a brash design decision, largely due to laziness, I'm going old-school and forcing you to read the manual or figure out the controls yourself. I'm seriously curious whether people have the patience for that anymore. Wrapping up a few things, calling it done, and posting the compo-final version.

It's quite a bit buggier than I would like it to be. One part gigantic distances and things traveling many kilometers a second, one part floating point inprecision, one part disinterest in math classes.

Known Bugs:
* When ships start traveling very quickly in different directions, missiles will fail to reach their targets. You can always go in laser range and blow up enemies with guns.
* Occasionally, missiles will repeatedly flip, and create a sort of cool looking pinwheel effect. If they don't move at all, they tend to wise up after a few seconds and start heading towards the target.
* If you fly several hundred km from 0,0,0, you will notice the cockpit shaking. This is probably due to floating point imprecision because the cockpit is actually treated as a part of the scene, and the vertices, stored as floats, are being rendered... imprecisely.

update: Posted the final, postmortem should follow in a day or two. It will sound either educational or somewhat emo, depending on your perspective.

[Mikademus]

That's what you get when you try to represent the entire solar system with micrometer precision! <--also gives me the shakes

[Fuzz]

I'm honestly pretty tired of working on this. In a brash design decision, largely due to laziness, I'm going old-school and forcing you to read the manual or figure out the controls yourself. I'm seriously curious whether people have the patience for that anymore. Wrapping up a few things, calling it done, and posting the compo-final version.

I really don't care whether the instructions are in-game or in the manual. Sometimes the game flows better if the instructions are just in the manual.

[nihilocrat]

Sweet, good to know everyone isn't going to be clicking around asking "WHERE'S THE TUTORIAL?"

Forgot about publishing the source. I'll have it on the frontpage shortly. For those who want to run it from source, here are the required libraries:

Python 2.5 (feel free to try 2.6)
Python-Ogre 1.6.0+
py2exe (for building, of course you don't need it to run)

You need to put the source directory inside of the PythonOgre directory for it to work as-is. If you want to run it someplace else, I think you can just copy the 'plugins' directory into the source directory and modify plugins.cfg.nt so that it points to './plugins' and not '../plugins'. This is what I do to build .exe versions, so I'm pretty confident that's all that's needed.

[nihilocrat]

Did some minor adjustments, I will post a new build as soon as it finishes uploading. I have replaced the missile tracking algorithm with a much stupider one (go straight towards the target, do not attempt an intercept path) and it seems to actually work better in tests where I let the enemies gain some speed while I flanked them (moving at heading 90 while they were at about 180).

In the targetting screen, BEARING is your bearing towards the target, HEADING is the actual heading that target is taking. This adjustment made me realize that the "steering" (if you look in the source you know I'm not actually steering) mechanism the ships and missiles share cause them to spin. I've replaced it with an alternative, and missiles have since been flying straight and true at all times.

[Bob le Moche]

I hope I'll be able to run the next version (I get the missing DLL error as well), because this really sounds like a game I'd like to try out.