Aurora Game

Hi there, gotta new PC which kinda slowed me down. So, what’s new?

First I (kind of) finished the Converter. As I said in a previous post, it supports normals now and even  diagonal walls will be possible, which sounds totally weird - however it wasn’t possible in all the other versions of Aurora.

In addition I completely changed  the setting. Since I haven’t started with the design of the levels yet, it’s no big deal. I had some major issues with the SciFi setting, for example the game would turn out to be exactly like Portal. I don’t want to bash on the game, I love it, but almost all of the ideas and conception of game-play elements aren’t that creative. They just logically fit in the game-flow. For example the auras: Theres an aura for  jumping -> repulsion gel. The aura for teleporting -> Portals. I even planned (years ago) to add a drone, just like Weathley, which helps the player at the beginning and gets evil after time.

That’s why I think, there’s no space for Aurora in the SciFi setting. The new setting will be […]

Took me about five days to port the project to the new GameMaker version.

That’s pretty much for actually two bugs. The first one was an outdated script, that messed up parsing the maps. The second one caused the whole geometry to not load. That’s pretty troublesome.

Up until now I was manipulating existing models that hold the geometry. But now the  models are static, so I had to load the geometry directly when initializing the model.

That really made me grow some white hair. 

I just updated my version of Game Maker, well it’s GameMaker now (tremendously innovative, isn’t it?).

This might raise the performance  quite a bit.

By the way, I’m working on the geometry converter again. Using Nautilus instead of Modul8 give’s me some nice possibilities but it’s an obstacle too.

 Adding normal support to the script I can now use lighting. The geometry is now stored in models, one for each material / texture, instead of creating an object for every damn wall and floor. Imagine that for a second.

That’s the reason I’ve got a shit load of coordinates and variables. It’s quite the problem to store and manipulate them in the converter, but nevertheless I hope to finish it within the next days.

There were a few major changes in concept, too, but I’ll mention ‘em later.

See ya ;)

Today’s the last day I’ll spend playing around with the collision DLL.

So I made a timetable which is obviously totally unrealistic:

16.: Creating the basics of FPS-movement, implementing collisions

17.: Creating the developer console

18.: modul7 and modul8 are history. The new version is the Nautilus system, it’s pretty much the same but will include new functions. On this day I’ll start with loading geometry for the levels, including collisions (thats kind of what modul7 was for back then).

19.: Importing resources. Implementing scopes for the script, to localize code much easier.

20.: Implement variables to the Nautilus script. The “call” function can also call external code.

21.: Creating and modifying objects.

22.: Automatically import the hitboxes when loading models.

23.: Some free space

After this, I’ll have to spend some time on studying again, however it’s not that much.

I think I’ve made a decision: I’m gonna rewrite Aurora completely.

“But Moolt! after all these years of hard work, why the hell ar-“ 

» Well, it’s super simple. I’ve never worked concentrated on this project. This project is about fucking 4 years old and, let’s face it, I didn’t knew a damn about programming back then. The whole project is a mess. And even when I’ve rewrote and fixed big parts over and over: Every component is in a way incompatible to another, I won’t fix this in a thousand years. The whole Engine, the only thing I’ve notably worked on, does not work as it should.

The main reason to rewrite Aurora is: The gameplay is tremendously influenced by bugs. And if even the gameplay isn’t working, the game would be crap - seriously.

“You’ve been working on this project for many years! Do we have to wait for eternity?”

»Nope, I guess not. Until now, I totally rejected the usage of DLL’s. That was really idiotic and I don’t even know what’s the reason behind this stupidity.

However, I’ve found a nice DLL on collision. For a few days I’ve been testing it, and it’s awesome. It even allows me to continue using modul8 - that’s totally fantastic.

To make it clear: I won’t start programming the next days - no go. I’ve got plenty of time, so I’ll do, again and again, some conception. Nothing is more important, than a well structured project, else I’d totally lose interest in it. That’s at least one thing I’ve learned of that FAIL.

Later guys~

… since I last posted something here.

At the end of December I stopped working on Aurora - temporarily. Now, four moth later, I finally have some time again to continue my work.

The changes to the last post are so freakin’ small, It’s not even worth mentioning. Nonetheless, I’m back. On Saturday the latest I’ll start with some further conception. Because, you might’ve guessed, I never stopped thinking about this project, I have an enormous amount of new ideas and motivation.

Further information on.. well, later on - bye~

Important: Right click the images to view them in full scale.

I feel so emo. Well, school kept me a whole damn moth away from this project - I’m not that amused but back again and ready for at least a month of total freetime.

3 days ago I sort of continued where I’ve stopped: Gameplay elements. Back then, when I talked about the ideas, it was already late. One reader asked to explain Modul8 a bit further, too. Second that, let’s go:

Realizing some of the ideas, I started with the switches. The biggest problem was to find a fitting design but I somehow did a passable job. Remember, there were three kinds of switches:

1. A switch that can be activated by the users and stays activated until the user changes it’s state again. This switch controls mostly one single object, e.g. a door.

2. A switch that stays activated for a  period of time. After it expired, it changes to a default state. Objects controlled by these switches could be e.g. doors that close 10 seconds after the switch was triggered. I’ll use it to build up pressure on the player.

3. This switch controls up to 4 Objects. The objects are processed within a queue, so only one will be activated the same time. Further information when I work on this one.

I started with the first one as a basic of the others. The inner block is flexible. If the switch is deactivated, it will have the height of the border/ floor. The black part is not/ barely visible in the game because it’ll be beneath the floor.

Stop - don’t get it wrong. The position of the basic block just indicates, whether the switch itself is activated or not. You can only manipulate it’s on/ off state, when its activated.

Then on/ off state is visualized by the four crystals. WHAT?! Yeah, you don’t see any crystals:

Yea, these little fellows. In this untextured and temporary model, you can’t identify it for sure. However, these crystals can move in (off) and out (on). If they’re activated, they change saturation and color. In the 1st switch all crystals pop out on activation - this differs for the other ones. (Thats exactly the reason for there to be more than one crystal)

Ingame functionality:

It took quite some time to get this switches dancing to my pipe. I even noticed, that the immense complicated trigger/ target system I made for modul7 (the older version of the level storage language) is superfluous in modul8, because I can directly manipulate variables now - more of that later, a few pictures fist:

On the right you see the switch, on the top/ left is a temporary object I made for testing it. It contains a variable called “action”, like all trigger and targets.

Assume we have an door object. When the action variable is zero, the door is closed. If it’s 1 it opens up. All objects differ in their reactions. This test-block is white when the action variable is zero. The rest is like

1 = red

2 = green

3 = blue

Like you might have noticed, this block is a target object, because it has to be triggered. But our switch has also an “action” variable. It’s the value, that will be transmitted to the target object, when its activated. Else it has the value of the “def” variable (default).

Back to the pictures: On the left picture, you see the switch turned off. It’s default value is zero, thats why the block is white.  On the right one the switch is activated. The action value is 2, so it’s color is green.

On the left you see the switch deactivated. Before it can be “shut down”, it turns itself off, so the crystals pop in, then the main block sinks in the ground.

On the right you see my little developer console. To be honest, I made it primarily out of fun and to look cool (lol). But it’s unexpected useful, I kind of understand now why developers use ‘em. By clicking on objects, I get their ID’s (these weird numbers). With these ID’s I can read/ write variables of the objects. As you can see, I asked for the “action” value of the switch, and as expected, it is 2.

Then I change it to 1, so the block should be red on activation.

A red block it is!

Behind the scenes:

For programmers I show you the *.m8 Code I used for these two objects:

This is tremendously easy to read, however I’ll  explain it’s functionality.

 On line 73 the object with the index 2725 will be created (test object). The variable $q will contain it’s ID, so you can read/ write variable values.

This happens in the next three lines: The coordinates of the object are set.

On line 78 the switch will be created, then the coordinates are changed as before.

On line 82 it’s target is set to $q, in other words the test-block. Now the switch knows which “action” variable it will refer to later on. Then the action variable is set to 2, so the block will change it’s color to green on activation, same for the def value.

The last to variables will make the switch either activated itself and it’s target object, too.

If you’ve read until here, I have to confess my love to you. *Here’s a cookie for ya*

See you guys the next days, with some other switches. :D

No real time for conception, and this wont’s change within the next weeks. But well, I promised you some gameplay information.

There are a few gameplay elements I thought of, but they’re not final. On the one side, there are three different types of switches. They can (de-) activate  e.g. Doors and Lasers.

The default switch (de-) activates objects by pressing. The state will not change till the user interacts again.

The alternative to the default switch is the time limited switch. It will change it’s state back to normal, after some time.

The third variety is a switch, that controls up to 4 Objects.  It will activate one of the 4 objects while working like a queue. After a short interval the triggered object changes.

The other elements are:

• Aura annihilator: It’s a kind of machine that sprays particles into a given direction. At those places you can’t create Auras, only if it’s deactivated by switches
• Poisonous water: You will die getting in contact with it.
• Laser wall: It’s a laser wall you can’t walk, but shoot through
• Laser: Will create lasers in short intervals, which will kill the player

That’s it, I’m pretty certain you haven’t understood a thing I talked about. Well it’s late and I wanted to keep my promise so my English-skills are slightly influenced. ;-)

Good night, I’ll do some conception when I have some rare freetime.

It’s been a while, and I have been chilling too much. However, vacation ended and now I have a lack of time.

Anyway, this project goes on, and I did some minor bugfixes and conception, but that’s nothing I could show to you.

So, here’s my deal: I’ll introduce you to some gameplay related elements by Tuesday by the latest. If not, I’d be pleased to invite you to some pizza.

That’s it for now, gotta study.

A week ago, I showed you my Wavefront to modul8 converter.

modul8 is the language aurora reads, to create it’s levels. To show you what it’s like, I wrote down the syntax. Here you can view the html, or this big-ass image:

This may be very boring if you’re not into programming, but I wanted to show it anyway.

By the way: I enabled commenting for this Blog. If you have to say or ask anything about this game, feel free to do so.