Progress

Re: Progress

Postby charlie » 08 May 2012, 00:55

Slow progress is the most important progress of all. It's what differentiates the dead projects from the projects that survive the test of time.
Free Gamer - it's the dogz
Vexi - web UI platform
User avatar
charlie
Global Moderator
 
Posts: 2131
Joined: 02 Dec 2009, 11:56
Location: Manchester, UK

Re: Progress

Postby hc » 08 May 2012, 17:54

> Is the git archive in download page updated yet?

Yes, there is a new git archive.
The changes are still work in progress, so you may find code that is not fully adjusted to the subsystem scheme.
But the Subsystem interface isn't likely to change a lot (which is interesting for mission extensions).
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby charlie » 18 May 2012, 19:11

Does that mean there's a binary for Windows? I was hoping to try it out this weekend or soon thereafter. :)
Free Gamer - it's the dogz
Vexi - web UI platform
User avatar
charlie
Global Moderator
 
Posts: 2131
Joined: 02 Dec 2009, 11:56
Location: Manchester, UK

Re: Progress

Postby hc » 19 May 2012, 14:16

Sorry no new windows binary.

Problem is, the cross-compiler version doesn't support c++0x to the extend necessary yet - but that should change sometime.
There may still be the chance to get it to compile on my legacy windows netbook with a new mingw version.
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby hc » 05 Jul 2012, 21:00

Added some yet simple logger classes to the linwarrior framework.

It's just the beginning and is lacking:
- thread safety (not that it would be necessary for linwarrior at the moment anyway).
- disabling of log levels.
- logger hierarchy.
- file appender or in game console appender
- testing

But it's just the beginning and that means that those may come (en-/disabling of log levels for sure) and moreover it means there already are:
+ Log levels.
+ Named loggers.
+ Appender interface for custom appenders.
+ Message or event based - ie. stream in until a newline which triggers a log message.
+ Plus (+) operator and stream operator (<<), too

All in all I'm unpleased with how C++ loggers usually have to work with streams as there is no proper string support (" "+" ", split) in C++.
Which btw makes thread safety a headache because sending a concatenated string isn't atomic (here: a single method call) but several calls to the overloaded stream operator method - to solve this will at least cost performance (looking up and building message fragments by thread id in a syncronized map...).
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby hc » 11 Sep 2012, 19:36

Just a small keepalive:
In the past weeks I've been working on some of the last changes to clean up the guts inside the mech class by moving everything to components and systems.
That includes a component for sounds that should eventually enable foot steps.
Of course some special cases still remain for later cleanup (like the jump jet light).

Some possible experiment-branch directions I see now are these:
- Persistence (savegames dude) using sqlite
- Reworking the Input to have events consumed by systems/components (or passing abstractions of SDL events).
- Some relaxing modeling work and integration of some more models
- Extending Physics to support tracked and wheeled vehicles - just talking about slanting on sloped ground by having 4 particles for wheels.

Multithreading would be possible, and easy with the system/component approach now but it isn't a top priority I think.
Easy because the execution model is working in phases, one sub-system at a time with no immediate communication between subsystems.
No need for any locks - values are only copied once between subsystems at a single moment which would run single threaded after joining threads.
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby charlie » 29 Sep 2012, 11:02

Looking good hc, looking very good.

What I would really like to see is features that makes it feel more like you're in a giant robot:
- stomping sounds
- cockpit moving up/down when walking, affecting accuracy

At the moment it is a bit like a slow paced FPS, but if you have to decide when to fire, when to be stationary, or when to deploy your jets for stability, it would make the game much more tactical.
Free Gamer - it's the dogz
Vexi - web UI platform
User avatar
charlie
Global Moderator
 
Posts: 2131
Joined: 02 Dec 2009, 11:56
Location: Manchester, UK

Re: Progress

Postby hc » 29 Sep 2012, 20:18

Good news, I'm just at implementing stomping/footsteps sound and it's technically working.
Tweaking the sound to be believeable and not annoying is what I'll have to put more time into.

Charlie, I like the idea of accuracy, I could imagine rolling some dice for weapon damage based on movement.
Having weapons and aiming jitter physically would be a tougher goal.
Besides I like the idea to have some pen&paper stats+modificators+dice which leads to character advances at some time.
And varying sized reticles come to mind.

I think having some camera jittering when walking (like when jetting) shouldn't be too hard.
In general a "smarter" camera would be nice.

A different thing I'm thinking about is how the throttling works - with a keyboard (vs analouge gamepad) you push forward and you are almost instantly on top speed.
Speed control (for strafing) with keyboard is impossible that way.
Other mech games (originally based on battleship simulators) use number keys to set the desired top speed.
But I could imagine using gear-shifting like in arcade racing games:
You basically set a top speed limit by shifting to a certain gear and you de/accellerate to that limit using your gas pedal.
Somehow I like that if I think about it that way: They imagined walking battleships, I imagine walking cars and tanks.
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby NaN » 29 Sep 2012, 23:38

hc {l Wrote}:Having weapons and aiming jitter physically would be a tougher goal.

You could add center of mass up and down motion(inverted pendulum) on movement. This should make the mech movement look more realistic, make it harder to aim when moving.
Image

A more crazy idea would be to use a bipedal controller. But this is maybe a bit too much robotics, out of the scope of the game.
http://www.youtube.com/watch?v=Jy_CeRcNfM4
NaN
 
Posts: 151
Joined: 18 Jan 2010, 10:32

Re: Progress

Postby hc » 03 Oct 2012, 19:37

Maybe physical was the wrong word, meant was actual movement and rotation vs fictional accuracy and damage calculations.

Anyway an interesting diagram, how about some words about it?
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby NaN » 05 Oct 2012, 16:26

The pic is just one that came up using google image search. I've added it to make more clear what I mean with up and down motion. The idea is to add some vertical center of mass motion(pendulum) to the mechs maybe proportional to their velocity/stride length so they don't look like they would be hovering.

To the pic above:
A: Inverted pendulum model (the interesting one).
B: Inverted pendulum potential energy (the height change is the interesting bit here).
C: Center of mass times natural frequency of the pendulum against center of mass velocity phase diagram (irrelevant).

OT: The pic is from a paper investigating the critical condition to avoid backward falling when walking (the thick trajectory in the phase diagram)
NaN
 
Posts: 151
Joined: 18 Jan 2010, 10:32

Re: Progress

Postby Skorpio » 05 Oct 2012, 18:40

Btw, will you add skeletal animation in the future? Also, image based textures would be cool. Let the artists do the work for you! :) Or do you want to keep everything procedurally generated?
User avatar
Skorpio
OD Moderator
 
Posts: 775
Joined: 05 Dec 2009, 18:28

Re: Progress

Postby hc » 07 Oct 2012, 12:16

You mean artist generated animations? (There are procedural skeletal animations at the moment).
Well, probably not, especially because this is a chicken-and-egg problem and I can use any static model available the way it is now after adding a rig.
I know the generated animation has to become better - eg. add that up and down movement to remove that floating moonwalk impression.

As for the textures: Using procedural 3d solid texturing (material) will stay (but eventually GPU based with higher detail).
But I'm unterested in having optional/additional 2d decals and detail textures like these: http://opengameart.org/content/free-decals-01-sci-fi .
Think of having the model milled from raw steel with paint/camoflage and with additional artistic overlaid details.
Basically that would allow totally customized texturing but mind the conformity that can be reached when at least the basic texturing/material comes from the same source.

And as for now there are a lot more models without animation and unwrapping available
http://opengameart.org/forumtopic/idea-for-new-challenge-the-mech-workshop
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby hc » 07 Oct 2012, 14:35

A thing that has to do with adding artist art and what hinders this at the moment:

Content and source is in the same (git-)repository and I think this has to be split before adding "mass-content" like custom model textures.
So, at the moment I am trying to keep the amount of bytes delivered within the repository small.
This has to be split into a source and a content repository.

However, a goal is to keep a minum-resource-pack within the source repository to keep the source runnable without the (additional) high quality/volume content repository.
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby hc » 29 Oct 2012, 21:17

Without comment: Experimental Stereo-Barrel-Warping in post processing.
Screenshot_at_2012-10-29.png
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby hc » 31 Oct 2012, 23:17

I've changed the copying conditions for the source in the public repository:

The LinWarrior source code is from now on available under Apache License 2.0

Happy Halloween!
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby cdxbow » 01 Nov 2012, 01:20

Hi hc,

I was reading down this progress post and I saw the bit about your physics system, how far along is it and how well is it working?

We have base Cube2 physics, which is servicable for most things but the collision model is a simple stick, resulting in the outer parts of the meks can pass through each other, not a very convincing look for a 50 ton war machine! So at some stage in the future we have do something about it. There may be a simple fix perhaps the Mek game, but in the longer term we may look at how we can support different player types better.

How is the damage system working? (I read about it in the damage post )

My memory of MW type games were that they supported a damage model with where different parts of the Mek could be damaged with different effects and it looks, including specifically disabling the legs, and your zones look similar. I worry a bit about implementing a complex damage model in a MP online game, with all the player state data presumably having to be kept and updated on the server, and the effects this might have on performance. Any thoughts?

MechAssault on the otherhand, implemented a simple global damage model, which consisted of 2 elements, the first were visual changes to the damaged mek at as health fell (smoke, sparkies, yellow 'jacket' then kaboom!). The only functional loss was at about 10% health you became crippled ('gimped') and your speed fell to about a third normal. We haven't made any efforts yet to implement this yet, and I am trying to get get my head around how the model/code work might split. Walter did provide us with a limping animation so at least for the chicken walkers we have them already.
User avatar
cdxbow
 
Posts: 317
Joined: 21 Mar 2011, 23:36
Location: Melbourne, Oz

Re: Progress

Postby hc » 01 Nov 2012, 09:25

About the physics:
I use a particle, springs/sticks/rods and constraints based system along with verlet integration.
Actually I only use the particles and constraints at this point but the math is there.
That's soft body dynamics - sounds complex but is comparativly simple.
Those are the keywords for googling (I'm not going into details now).

What's more interesting is:
Models have a cylinder that descripes the space which another model's particle may not enter.
Actually particles have a radius, too, which basically just increases the size of the cylinder when checking against a point.
The point will be constrained to that enlarged cylinder's hull and verlet integration takes care of the rest.
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby hc » 01 Nov 2012, 09:45

About the weapon and damage system:
Given an impact point with the model (which happens to be on a cylinder) the relative position is used to determine a damage zone. Upper half: About left third, right third, center third. And lower half.
Each zone has hp.
You are destroyed when center hp reaches zero.
When other zones are destroyed then damage to that zone is counted as damage to the center zone.
With other words other zones shield your center unless they are destroyed.

There aren't any other implications of damaged or destroyed damage zones but having a damage hinder walking would be the obvious first.
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby hc » 01 Nov 2012, 10:12

Linwarrior isn't an MO and I'm not a cube expert, so here my guesses for adding damage zones to cube:
It would add 4 hp variables per player to the existing 1 hp zone.
A question would be if every player can see each others zone damage, which would mean 50 variables to transmit instead of 10 for 10 players in the worst case.
If those are only send when changed then I think it wouldn't mater too much.
Or if zone damage is only visible to oneself then you only need to send the implications of damage ('gimping' or not).

Does cube send the full state of objects, or just differences or interpreted commands?

As for performance on the server itself, if you use abstract zones like in linwarrior (not model exact) then the processing isn't expensive.
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby cdxbow » 02 Nov 2012, 07:53

Thanks for that hc,

Wow, you do a lot!! Code the engine, the game! Model, run the project. Can you sing?.

I think for MekArcade keeping it simple and as close to the RE code base is a good principle. For the collision model issues I need to discuss with Quin and work it up and ticket it. I think we will stay away from trying to get a more general fix suitable for a variety of vehicle/player types. The damage model probably will remain discussion only, and if implemented would be simple like MekArcade. If it only depended on player health which is already looked after by the server then perhaps any code changes could be restricted to the client. One area where people have struck trouble with the cube engine is mucking things up on the the server side. I think the engine largely sends difference data where possible.

I might have a few modelling question for you. Animating Tank tracks comes to mind. I can't for the life of me find a way with m3 or md5 to do them. Any ideas?
User avatar
cdxbow
 
Posts: 317
Joined: 21 Mar 2011, 23:36
Location: Melbourne, Oz

Re: Progress

Postby hc » 03 Nov 2012, 23:51

I'm not into blender modeling, I only made the simpler base models with misfit model 3d.

Tracks, well animated, are hand work I think but the formats would support the animation itself.

Well, I think client side damage zones would be easiest if impacts and damage are handled there too.
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Re: Progress

Postby Skorpio » 04 Nov 2012, 20:56

You can animate tank tracks with a curve modifier in Blender, but I don't know if this method is suited for a game. http://www.youtube.com/watch?v=68Quz2yVIz4
In older games they just animated the texture, but I don't think that's appropriate for more modern games.
User avatar
Skorpio
OD Moderator
 
Posts: 775
Joined: 05 Dec 2009, 18:28

Re: Progress

Postby cdxbow » 05 Nov 2012, 04:32

Skorpio, you should try the curve modifier and see what comes out.

We have tried exporting working tank tracks as md5 or md3 and failed. We have 2 Max tank models, alledged 'game ready' and neither can we export a working track, the wheels are Ok but the tracks never export moving. In one case max uses alternating texures to mimic movement, and the other I can't remember, in neither case could we export a working md3 or 5. I have tried other formats, too. The result is the same, moving wheels, fixed tracks. I went and looked at games built with IdTech4, and none seemed to have working tracks and I also checked various doom/quake collections. No moving tracks. I decided it must be difficult.

My first thoughts with using an md3 were that it may be possible to animate the track by hand as a loop, much as Nieb did with his md3 waterfall. I would have to do this in misfit, by hand, but I don't need a tank that badly at the moment.

Md5 I thought might be easy, until I tried! The only way I have thought of is for each plate on the tank track to have an associated bone, but this would result in a a far too high number of bones (minimum about 30 per track) In max it might be possible to set up a controller to pull your bones around like a conveyor belt, otherwise I would have to do it in misfit by hand. It then might be possible to convert it to a vertex animation, avoiding the 'too many' bones issue.

The only other approach I thought of was to somehow use a shader effect, where you would set up some shader effect that looked like moving tracks. Shaders are very powerful and barely exploited with models in the Cube world, so unfortunately it would be real trial and error.

So that is where I have left tank tracks. It would make a nice challenge....
User avatar
cdxbow
 
Posts: 317
Joined: 21 Mar 2011, 23:36
Location: Melbourne, Oz

Re: Progress

Postby hc » 17 Nov 2012, 13:59

Progress at parallel frontiers:
I've recently upgraded my home workstation.

Instead of having a complete compile of LinWarrior in a bit more than 130 seconds on on my old pc (AMD Athlon 64 2.1Ghz) I'm now compiling in about 11 seconds!
That is using the -j option of make to fork many compilation threads on my new Hexacore - for comparison:
Not using the -j option and only one thread the compilation would still require about 45 seconds.

It is very pleasing to see all cores work at 100% while compiling. :)
And having a ssd for the operating system makes the os start farster than the bios counts memory and lists hardware - at least it feels like that's the bottleneck now.
Having little spare time this will help in developing more and waiting less.

Another thing I'd like to delve into a little more is virtualization - another reason why I went for more cores vs less faster cores.
Virtualization helps in test driving different operating systems, configurations and testing.
Amazingly LinWarrior can run in a virtualbox with hardware accelleration (1 dedicated core + gfx access) quite good.

Well, to be a little bit more on topic: Virtualization can help in setting up and testing build environments for (open source) projects.
Or, with a player's-blank-operating-system what's the setup procedure to make it a code builder's or content creator's system?
github.com/hackcraft-de
hackcraft.de
User avatar
hc
LW3D Moderator
 
Posts: 213
Joined: 07 Feb 2011, 10:00
Location: far away

Who is online

Users browsing this forum: No registered users and 1 guest