Forgotten Space (Working title)

Hello all,

Now the time is about right to start giving my game some much needed publicity.

Forgotten Space is a top-down space game. Currently, it is intended as a single player game. First let me start with a short introduction of the story behind the game.

When the game starts you, the player, is in a hibernation pod. Suddely, you are fully awake, and your viewpoint is the top-down viewpoint. At that moment, the computer starts talking to you. The ship has been attacked by pirates, the crew is dead, and you are the only one on which the brain implant was successfull. This brain implant is what lets you work with the ship on the level needed to pilot it properly.

At this point, you can go in any direction you would like, but the main storyline behind the game will be one off revenge. Who caused this, and why. Since, after being hooked up to the ship, you can’t leave the ship ever again, your former life is over and you want to make them pay for that.

Currently, a lot of the basics are in there already:

  • Movement

  • Targetting

  • Shooting

  • Basic AI

  • Ticker tape (interactive)

There's still a lot to be done though. Which brings me to the other reason for posting here.
I need help. Plain and simple. Currently, I'm spending all my time working on the actual game stuff. While that is coming along, there is also the need for the whole modeling and texturing part. And lets not forget the SceneBuilder. While the game works with the basic scenebuilder from the SDK, there are some additional proprty editors etc. that need to be added onto that basic scenebuilder to make it play nice with the game's entity system and ai system.

Both the graphical and the scenebuilder are areas I could definately use some help with. The graphical stuff I just don't have the skills for, and the scenebuilder stuff I just don't have the time for.

Please drop me a line if you think you can / want to help.


Oh yeah, almost forgot, test version of the game:
Movement is: qweasd.
shooting is: space.
targetting is: mouse.

If you close in on the red cube, it spawns another ship.

Looks great :slight_smile: I’m looking forward to the progress on this Mark.

You might be able to find some artist help on IndieDB. Create a page for FogottenSpace, add some screenshots, and post an introduction news article. There are lots of artists there and many are quite helpful.

Nice work.

The game closed by itself a few times due to a NPE (something about the render thread). Maybe you need to have the game generate a log file that can be sent back to you for debugging and/or stats.

On my machine, it was running as around 1400 fps. I have an i5 processor with a Radeon 5650 series video card.

I liked your shading. You have no reflected light in space … which is quite realistic.

I found the mouse targeting with keyboard movement controls kinda hard to get used to. I think an all keyboard approach might be easier to get used to … but that is just an opinion. Or maybe just mouse, with an extra control key for added commands … probably best to experiment.

All in all, you seem to be on the right track … keep going and you’ll have a nice little game there.

thanx for the kind words guys.

And yeah, I’m thinking about doing it all through the keyboard. Still thinking of way to do the targetting and the interactive ticker though…

Oh ad there should be a log file somewhere. I don’t really set a folder atm. So it gets created in the run location of the game. This changes from OS to OS though, so it might take a bit of a look around.

Ok, I changed the folder for the log, it first placed it in the users home folder, which is kinda weird. So now it puts the log file in the same folder as the game itself. Should be easier to find. The new build is on the test page if you would like to test again so I can find the reason for the NPE.

Oh, and if you do run into defects, I’ve got a mantis page:

OK. Found the log. It was fs_0.log in my user root dir. But I ran the game from a folder on my desktop. Here is the log:


<?xml version="1.0" encoding="windows-1252" standalone="no"?>

<!DOCTYPE log SYSTEM "logger.dtd">











<message>Cannot find loader com.jme3.scene.plugins.blender.BlenderModelLoader</message>




This may tell you why the thing crashed. BlenderModelLoader?

Hope this helps.

You need to convert the models to j3o before distributing your game.

What? No video? :_(

ok, that’s a weird error…

Never seen that one before. And I’ve had the game tested on all three OS before posting it on here.

I’ll have to see what I can figure out here, especially since I don’t see the same problem on my system.

Oh, and I did do the whole blender to j3o conversion, and a clip will be up here shortly.

Yay for upcoming clip. :smiley:


Goddamn parser removed one of my arm! gasp

Ok, here’s the Vid. I created my own youtube channel to hold it. And I promis to put up more vids there as I get more stuff in the game.


Pretty nice! :smiley:

Was that parallax I see with the stars?

Yeah, stars work with parallax. There’s currently three layers of stars. This means three randomly generated textures. The textures are scaled to the resolution selected. Also, the number of stars is scaled to the resolution selected as well as the layer number. the further down, the smaller the stars, but also the more stars.

Per layer, a certain number of stars have a random color and a certain (other) number of stars have a variable size. This all makes a very dynamic starfield. Since this is all setup a seperate AppState, I can easily plug it into any scene / level.

Oh, and I did a fix for the ticker, it is now slightly bigger (25px) and has a background. Both things make it way more readable.

No idea how you’re actually doing that star field, but wouldn’t it be better to make it one big procedural texture for each layer that you could wrap-around?

Just a thought.

That’s what I’m doing, I have a single texture, which is generate from code, for each layer. This is then moved around as you fly the ship. Since it’s a texture, I just set it to autowrap. Works like a charm. The scaling is done to make it so the textures further back have more stars, while the texture itself isn’t a whole lot bigger then the viewport. Making the textures fit nicely in the viewport makes them smaller, and thus perform better.

I did the textures partly in Java, partly in Shader. The textures are generated in Java, this is done only once, so Java is more then adequate. The movement of the stars is done in the shader, making is fast.