next »

[Arne]

(Edit: Sorry if my server is down, been like that the last few days, due to... server things.)

Having played Fiona's Scavenger (LudumDare16) and enjoyed it, I thought I'd do a remake.

Since there will be thousands of debris chunks to collide with and possibly draw on screen, I decided that using buckets would be a good idea. There is also an 'active' list for drifting debris (the player can set things in motion), but friction will eventually slow debris down to the point where they are removed from the active list. Rotation can probably be global in some cases (just an on screen effect). I don't know if friction will slow that down.

Here I'm drawing 10x10 buckets and their contents (which is the whole game world at this point). The Radar is drawing a selection of buckets surrounding the player.



I copy-pasted the radar routine and used it for drawing the cropped player centered playfield (which draws the debris from the neighboring buckets). Several rings with debris surround the worm hole. The rings farther out are more dangerous, but offer better loot. The player can upgrade his ship with the money made from selling debris.



There will be a central worm hole which the player returns to with the loot. A worm hole makes sense because if it had been a space station, then it's reasonable that NPCs would be here looting as well, or that the entire region had been looted already. With a worm hole, the player can be perhaps alone in finding this treasure stove.

The debris will have short description strings. There will be ship wrecks which suggest that a space battle took place. There can be black-boxes and escape pods containing brief logs.


I have some immediate mode GUI routines I can adapt to this project. The cargo bay probably needs a scroll bar and buttons. Then there's the shop of course.



I tried to come up with some more resources besides those already in scavenger (Solar panels, Space kitty food, Mines, etc). I have an idea about 'Compactors' which can compress or extract stuff so it doesn't take up as much cargo space. Currently my space debris has mass and volume (and density), so it's not economical to haul home stuff with a lot of volume.

That's it for now. I'll see if I get any further. My code so far is pretty clean.

[Core Xii]

I like your sketches.

[Arne]

Nothing to show, just reporting progress.


A new TShipData Class ('Type' in BMX) keeps track of the stats of ships. I've made a few sample ships which are loaded from BASIC style Data lines (I'm not sure if I should make it load an external file). My stats are similar to those listed in my rough sketch.

The beginnings of a TPlayerShip class references a TShipData instance, but also stores unique variables like position, velocity, cargo list (debris), equipment, etc.

I have the base of an Immediate Mode GUI class up and working. Still need to do graphics and layout.

Before I can begin working on the store (layouting the GUI), I'm thinking of drawing some graphics so I know what size and resolution stuff should be. I don't know if I will have separate store screens for selling cargo, buing ships, inspecting cargo (each cargo piece (e.g. a black box) might have a little story attached to it.)

Yesterday I did some things too:

A TDebris class is an extension of a simple TEntity class. The TDebris instances (floating asteroids, hull pieces, etc) references a TDebrisData instance (what they are), so they don't have to store a bunch of stuff which they don't need to store. The player ships cargo list will reference a TDebrisData instance too, I think. Something aboard a ship doesn't need to know position or rotation.

[MaloEspada]

MY GOD
ARNE IS MAKING A GAME

HOLY CRAP

[Arne]

We'll see how it goes. I'm not known for finishing stuff.

Seems the server is still going down and up. You may or may not see any images here. It's surprise magic of the internet.

I'll try to polish this sheet up tomorrow. The asteroids and broken hull bits needs to have variants so they don't look repetitive. I'll scale the rotating stuff to 50%, because i think it improves the sampling, reducing jittery jaggies for the rounded forms. I think the boxes, which are drawn in perspective, needs to rotate real slow, or it might feel like... they should be rotating in perspective too. I'm not sure what to do about the light source problem which comes with rotation.

Arne: I like this. I think I’m going to write a clone, if that’s ok.
Fiona: Uh, that’s a bizarre comment. Okay, I guess.

A probable OK stamp on the butt of this little toy project

Yeah, I'm still working on my communication skills.

[Arne]

After some experimentation, I figured out a way to kill as many birds with one stone as possible. Once the player goes into the warp, he'll arrive at an outpost where things can be sold and bought. By making this outpost a hangar ship, I can show many types of ships, suggesting an active market, and then the player ship doesn't have to be drawn explicitly.

Also, I can show the action of unloading cargo, and I can show some warps in the background.

Aside from showing this as an intermission screen, I can also use it as a GUI background (faded to low contrast gray) (a bit like the X-Com GUI BGs).



As for the ship in the warp tunnel, I might not use other than as manual art. I want to suggest (with the shield taking hits) that the tunnel has deadly thunder stuff going on, and that's why stuff has to be put inside ships and can't be bumped in or towed.

Since no one else is supposed to have found the warp in the player area for a long time, I imagine that ships that enter a warp have to connect to an existing exit warp, and not all of these are known.

[Arne]

Finally made a TMain class which dictates program flow, measures time, etc. Actually I just copy pasted most of it from another project. TMain has a function pointer which I can direct to the gameplay screen class, the shipyard screen, the title screen, etc. Most of my classes have functions for booting, loading assets, setting default state, loading and saving state, drawing and updating. I try to be consistent so a class does the things it's good at (encapsulation, and such).

I now have 13 source files, but estimate I will have over 20 soon. I suspect, once I have the art done, it'll be pretty easy to get the actual game part up and running (buying ships, flying around, moving between screens).

Tomorrow, art, I hope.

[Saker]

This definitely is going to be awesome with your super dupper art .
can't wait to see the art .

[Mr.Flibble]

Keeping my eye on this.

Played Scavenger and really enjoyed it, although the constant back and forth became a drag, it also became a bit boring after a while.  But for a game in 48hrs it was great.

How will you handle the constant back & forth that was in Scavenger?

Any enemies?

[gnat]

MY GOD
ARNE IS MAKING A GAME

HOLY CRAP

I can't believe more people haven't picked up on this. Arne's game concepts = ALWAYS AWESOME.

[Arne]

To be honest, I haven't though this project through much. If I do, I start to feature creep, and won't be able to finish. It will have to be improvisational.

Since my map is radial, with rings, backtracking will be less of an issue - if you are bored of a direction, you can go in another next time.

Enemies... mines and turrets, sure. AI ships is more tricky, since I might need to write AI for dodging obstacles and other AI ships. However, I plan to put regenerating Elite-style ships on the ships, and a repulsor/plow device. Maybe that will partly solve the problem.

I've thought a bit about the goal of the game: A fleet carrying a device which was the last hope of a now dead faction was lost/destroyed. The device, once assembled, would do some 'Omega' thing, like destroying an evil empire. The player finds the warp coordinates to the fleet. Since everyone can be a mind controlled spy of the empire, the player keeps the information to himself. Maybe the Omega device will negate a mind control field, drug, parasite, Dnyarri, or something to that effect.

Practically, this means that X number of parts have to be found, maybe a boss space monster has to be defeated in order to finally assemble. Some parts can be hidden in minefields, turret fields, etc. Leveling up the ship for the boss fight is also on the agenda.

Yesterday: No art, failed with some physics code.

Today: Art, I hope.

[jwk5]

Practically, this means that X number of parts have to be found, maybe a boss space monster has to be defeated in order to finally assemble. Some parts can be hidden in minefields, turret fields, etc. Leveling up the ship for the boss fight is also on the agenda.

Or perhaps you could have it so you are assembling devices designed to fight each specific boss. Anyways, this project looks really cool thus far, keep up the good work!

[Loren Schmidt]

Hi Arne, I'm just popping my head in to say I really like the idea of this project. It seems like a good, clean idea, and I can imagine myself getting really into the gameplay already. I wish you all the best!

If I may offer a suggestion, I'd like to say that the wonderful marketplace ideas you posted seem great, but rather asset intensive. I wonder if it might be wise to start with a simple one screen market GUI, and plan on expanding it later (so as not to get lost in details too early). I hope that suggestion isn't at all intrusive- I have all kinds of trouble with feature creep and completing projects too, so I wish you all the best on that front.

[Arne]

I like the idea of bosses/guardians which can be more easily defeated with certain items installed. Maybe the bosses can be things like mine and turret fields which can be disabled with a signal. Perhaps there's a shield which offer good protection against the rays of a space monster. Stuff like that is in the future though.

Here are some medium scale playfield entities. I might also do some small pebble stuff, and large landmark things like ship wrecks, derelict space stations, large asteroids.


I'm not sure if I need to do that many assets. The store is just the GUI buttons, background screen, the debris graphics, and some ship images. I might bake in the color of the ships into the graphics, rather than letting the engine color them. Then I can do zebra stripes and stuff too.

[Arne]

  Added a player controlled thing. Sloppy code though.

  Physics fail again. I have friction in space because of the emergent velocity cap it introduces. Also, dogfights are be more fun if ships don't just fwoosh by at light speed. Also, no need to write anti-tunneling code. Since my ships can be loaded with heavy cargo, I figure it would be fun if it affect how they handle. It seems reasonably that air (space aether) friction would have less of a breaking effect of a heavily loaded ship, carrying say Neutronium. I already divide Engine Thrust by Ship Mass, but that has nothing to do with friction, just acceleration.

I figured that the counter force would have to do with how many cubic meters of air that is pushed aside, but Mass lessen this resistance. I end up with a resistance value between 0 to infinity depending on speed, and I need to make that inverted into a 0 - 1.0 current velocity multiplier. Not sure how though...

Code:

			Local Slowdown:Double
		Local AirDensityFeelGood:Double = 0.00000001 
		Local Speed:Double 
		Local MassInTon:Double = 21
		Local CrossSectionInM:Double = 10
		Local AirDisplaced:Double
		Local TonsBehindCuM:Double 
		
		Speed = YVel ' In the range of tens of thousands
		TonsBehindCuM = MassInTon / CrossSectionInM
		AirDisplaced = CrossSectionInM * Abs(Speed) * AirDensityFeelGood
		Slowdown = AirDisplaced / TonsBehindCuM 
		YVel:*1.0-Slowdown
		
		' ... and same for XVel

In this case, I risk getting a >1.0 number, and I don't know if my formula is even sound in some way. It does seem to make heavier objects slow down slower though.

Edit: Still no real news on the graphical front. I doubled the size of space, and luckily my population algorithm scales things automatically.

[Arne]

Successfully implemented a system where I can have 2 cross section values for a ship, front/rear and sides. I use sinus with the difference between the aim angle and drift angle of the ship (adjusted to loop around 90 degrees) to determine the in between cross section which I then feed into my friction algorithm. Practically (I just tested), this means that a long ship will be fast (not slowed down much by aether) when going straight, and when in a sharp turn it will 'aether break'.

[mokesmoe]

Æther break sounds like a generic rpg attack.
Technically there is friction in space, with small air and dust particles, there's just very little of it.

[Arne]

One hydrogen molecule per CuM or so, IIRC.

Drew some Elite ships. With my aether friction system now, these will handle differently depending on their shape. I have thought about moving my bucket code into a separate class and make it handle my basic entity. I'll see if I can solve the encapsulation problems that may or may not come with that. Might also prepare the code to handle 'mother buckets' which can contain bucket arrays, or not. *is already having feature creep fantasies about multiple star systems*

[Arne]

Uh, I don't know if I should be doing this. I now create the entire universe, and I had to restrain myself from going multiverse.

Code:

Commencing pie creation...
---
Creating GALACTIC partition: 0, 0
  Creating STAR BLOCK partition: 0, 0
    Creating SECTOR partition: 0, 0
    Creating SECTOR partition: 1, 0
    Creating SECTOR partition: 2, 0
    Creating SECTOR partition: 3, 0
...

Still, it's fun to code and watch things go.

[Loren Schmidt]

I know you share some of my vulnerability for feature creep, and I'm really looking forward to playing this one, so I thought I might gently suggest scoping this back a bit for the sake of completing it. I'm inclined to say it'd be better to pick a scope based on your gameplay goals, and use the multiple solar system, multiple galaxy idea for a larger game later.

I love the space junk sheet you posted earlier. There's a lot of fun stuff on it.