early version of Cube-Space

WIP games, tools & toy projects Archived Projects
#21

The only disappointment I have with this game is how walking can kill you, I had like 8 energy, walked away and then died.

#22

Maybe a solution could be to change things in such a way that you won’t be able to move when you don’t have the energy for it. The result would be that you would move very slowly when you run out of enery, but it won’t kill you.

#23

that sounds good, but also implement that as well as rivens idea of having fuel.

#24

I’ve made a small update to the play mechanics:

  1. There’s now also a battery (‘BAT’ in the hud)
  2. Moving now costs battery power instead of main power
  3. If battery power is 0, you can’t move
  4. If you power up worth more than 100%, the remaining power will go to the battery
  5. You can transfer battery power to main power with the ‘TAB’ key
  6. The battery now regenerates instead of the main power

Other updates:

  • it should now work on mac (I made a mistake signing the jar)
  • the reflection is a bit more subtle (it now varies between 0 - 30%)

I tried mipmapping (as suggested by Riven), but I didn’t think it looked very good as things just got blurry. I think I should probably try MSAA instead to sort the flickering in the distance, or change the textures to make it less noticeable.

#25

Noooooooooooooo!

Now, to regain health, I first have to wait for 100% BAT, and then for 100% POW.

You just doubled the waiting game :-\

#26

No, just push TAB to quickly gain health :slight_smile:

#27

Well, even then: when you transfer BAT to POW, it makes the waiting game seriously long.

The net-effect of your update, was that you doubled the POW, and you die if it reaches ‘somewhere’ between 0-50%.

As long as you don’t gain ‘points’ (whether it is BAT or POW) faster, you have long delays in gameplay.

#28

I think that’s mainly a problem with balancing as it’s probably all just gets a bit too difficult too early.

As I see it, the battery has a few advantages:

  • it functions as a buffer for your health and your movability
  • it opens up possibilities to use battery power for other kinds of stuff (ranged attacks etc), which could introduce some interesting strategic dilemmas. (well, that’s the theory)

To prevent long waits, I could add an option to make time go faster (similar to sleeping in Dungeon Master).

#29

Acceleration of regain would be way nicer, IMHO.

#30

you mean instead of the battery or in general?

#31

Yay, it runs on my Mac. It’s a nice game and graphics are nice too.

The Window runs at full resolution here 1680 x 1050 but it’s not switched to fullscreen. I can’t see the whole screen and hud is only partial visible (behind my dock).

Anyway, great idea. Keep it up :slight_smile:

#32

Thanks for testing :slight_smile:
The last build is not switching to full-screen, but the next one will be full-screen again.

#33

I’ve put up a new build where I’ve implemented Riven’s idea to increase regeneration speed over time. It’s also full-screen again. Working now on weapons…

#34

Much better. However, the regain is now so fast that it makes the healthpacks worthless, and the ‘regain health update’ a waste of orbs :slight_smile:

Again, please use mipmaps. You said it went blurry, but that probably means you did something wrong in the init-code. The textures are flickering all over the place. The border-texels (bright colored) are 100% visible one frame, and 0% visible the next.

Oh, and nice bloom :slight_smile:

#35

So I am in “Reality #9” with STR 266, pestering robots with STR 18… it usually takes 1 blow and, I don’t even have to stop to beat them to oblivion. Sometimes the robots are blocking my way, but it usually takes less than a few seconds to punch through :slight_smile:

Also, the only hard part of the game is trying to kill all robots, and finding your way back to the exit. Everything looks alike :persecutioncomplex:

#36

[quote]Much better. However, the regain is now so fast that it makes the healthpacks worthless, and the ‘regain health update’ a waste of orbs Smiley
[/quote]
Yeah, exactly my thoughts :slight_smile:
You’re right it quickly becomes way too easy (and boring) now. Probably time to add a new robot type, and perhaps add some new map generation algorithm

Anyway, I just enabled mipmapping, see what you think. In my opinion it looks weirdly blurry in the distance, even though the aliasing is now largely gone.

#37

Could you try this?

#38

Ah yes, good catch, that might help.
In the meantime, I’ve added randomly coloured fog. A cheap effect but I thought it looked kind of cool (when it doesn’t choose some ugly colour that is :))

#39

I used to have bloom in my game (say, in 2006), and it was setup like this:

  1. a texture that holds the last bloom, multiplied by some factor between 0 and 1.
  2. a texture that holds the current bloom, this was actually mipmapped bloom, so that it didn’t suffer from popping
  3. merge the ‘current bloom’ with additive blending onto the ‘last bloom’ texture
  4. add it to the framebuffer

You get really nice blinding saturation when you look at a bright object for too long / too many frames.

Maybe something you could use :slight_smile: Very simple to implement, eats fillrate!

#40

Sounds good!
My current bloom implementation is really just a poor-man’s attempt at it :slight_smile: It just first renders to a low-res texture which is added to the framebuffer.

Any code to share? :slight_smile: