If you know C++ I would not dismiss Construct so easily, as it's power increases exponentially if you can make your own plugins for it.

Using Construct, in my experience anyway, is kind of like driving my car. My car is falling apart, and regularly has some weird hitches in it, like the speedometer stops working, or I have to go into neutral along the highway to keep it from overheating, or whatever. The car works great, and it's actually pretty fast, but it's a death trap.

Construct is extremely powerful, but quite unstable. It's like sending yourself to the moon by strapping a few million bottle rockets to your back. With that said, the stability has improved over the last few years, so take that as you will.

I'm practicing "agile development", I guess. These aren't grandiose long term plans, they are what I am actively working on/completing. After internals (air, power, data) are done, sometime shortly after, I'm going to make another build available. Power is done, air is almost done, planning data.

Also we've been working on this game for three years already, so abandonment is unlikely. Perhaps pauses, but it's kind of a dream project.

I will summarize the future of this thread for you:

• There is no multiplayer plugin.
• There is a Python solution to multiplayer, but it's shaky. Learn Python before trying it.
• An MMO is too ambitious for your first project. Make prototypes and smaller games first.

Yeah we had a bump in progress due to some personal stuff going on, and our progress was so intense that we didn't want to burn out. We're back.

I've found a simple way to model atmospherics in enclosed spaces, to model decompression and stuff. I'm going to be implementing the atmospherics system over the next few days to get back into the groove of things.

We are also trying to flesh out the data system of the ships, which is turning out to sound like an extremely simplified version of visual scripting systems, like you'd find in Garry's Mod Wiremod, Minecraft's redstone, Engine of War (look it up), or UDK Kismet.

Right now I'm working with this system conceptually - bear with me for a moment. Every object in the ship has a data module under it. Modules come in three forms. Data sources, data processes, and data yields. Sources are where data is "harvested" for lack of a better word. A microphone would be a data source. A data yield would be where data is utilized practically, like a speaker. A data process is where data is modified in some way.

Modules have a series of I/O nodes around the outside of them that you hook the wires to. Data comes in many different types: Audio, Video, Binary (on/off, for switches and stuff), Sensory (further splits off into sensor types), and Diagnostic (further splits off into ship components). The I/O nodes around a module are colored and shaped differently to show the player what data type they require.

That's it. That's the system. Here are some examples of it in use. A microphone has one node: an audio output. A speaker has one node: an audio input. Hook those together, and you have an intercom. An audio detector is a process module, it has an audio input, and a BINARY output. If it detects noise, it will output a true. An alarm has a binary input and a audio ouput. When true, it makes a lot of noise. Using these four objects, you hook a microphone to an audio detector to an alarm to a speaker...and you have an alarm that will sound when noise is detected by the microphone.

Gravimetric sensor has a gravimetric sensor data output node, which you connect to a gravimetric sensor input node on a gravimetric analyzer. The analyzer has a video output, which you connect to a video input on a terminal. Now you have a terminal that displays a map of planets and stars.

We're still ironing it out, but that is where we're at.

Effort produces results.

Alee had to make that procedural galaxy in several engines over more than a year to get it where it is now. I definitely saw Eden over a year ago on another engine, I forget which one. I've been working on Void Runner for well over three years in Construct, in Game Maker, in OGRE, in Unity, and I DO know how to program in C++ already. I use C++ plugins developed alongside Construct to work on my game, because I know the effort is worth it. I've been learning how to program since I was thirteen, over ten years ago, and I still move slow. Game development isn't a quick fix, it's a long journey.

If you don't think the effort is worth it, then don't do it.

I chose The Bespectacled One's because it's actually appealing for programmers. We aren't advertising Construct to end users here, we're appealing for coders to make us cool plugins to use!

You are missing two things that the AI needs to function properly. Also, it would really help if the ghost was the same size as the tiles.

First of all, you need to keep track of the angle of the ghost, so you know which direction it's moving in. Second of all, you need to check in the direction you're about to move with an overlap at offset check, before you move in that direction. Right now you change directions at random without making sure there's a wall in that direction first.

I will tunnel until I reach HELL!

Be careful - that is actually possible in this game.

How would I set an angle to a random option of 90 or 270?

90+(Random(2)*180)

I believe Random(2) will give you 0 or 1, unless they changed the indexing on me, so that will either give you 90 + 0 or 90 + 180. 90 or 270 respectively.

Bullet always moves forward, and forward is dependent on the sprite's angle. By default, sprites face 90 degrees, or right. 0 is up, 180 is down, and 270 is left.

You can keep bullet on the ghost, and manually do this with events. On collision with wall:

If current angle is 90 or 270, randomly change angle to 0 or 180.

Else if current angle is 0 or 180, randomly change angle to 90 or 270.

That's all. Please keep that else in mind, it is important. If you start at 90 degrees and go through this block without the else, the first event would change you to 0, and the second would change you back to 90, the else makes sure only one of them fires, instead of the possibility of them both firing in sequence like that.

Hey Luomo I think it would be awesome if you could pass parameters to this. The structure of the files themselves allows you to use three different parameters when firing the bullet, allowing for semi randomization at runtime. Would be very cool if the plugin allowed this.