Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1059162 Posts in 43053 Topics- by 34996 Members - Latest Member: kshankin

October 30, 2014, 08:02:23 PM
TIGSource ForumsFeedbackDevLogsTriverse
Pages: 1 [2] 3
Print
Author Topic: Triverse  (Read 7676 times)
Netsu
Level 10
*****



View Profile WWW
« Reply #20 on: March 11, 2013, 03:23:30 AM »

I too consider the neon-like graphics far sexier actually.
Either way, this looks awesome, can't wait to see it in motion Smiley
Logged

sublinimal
Level 8
***



View Profile
« Reply #21 on: March 23, 2013, 09:09:06 AM »

I find the neon style to be more memorable too. Sounds like the sort of game I'd like a lot.
Logged
gears
Level 0
***


View Profile WWW
« Reply #22 on: March 23, 2013, 01:53:32 PM »

This has all been great feedback!

While I like aspects of both styles, I'm revisiting the neon style and looking at ways of visually differentiating enemies (which was the problem the other style attempted to overcome). That's been the sticking point, and I haven't come up with anything I really like yet.

Sandbox/test feature: copy/paste ships
In the meantime, I added a copy/paste feature for testing that was long overdue. Copying a ship puts its text representation on the clipboard, and pasting text attempts to parse the text on the clipboard. The text form has been very helpful for a long time now. The format is my own, but I got the idea of using text visually from Captain Forever.

So copying this:



Puts this on the clipboard:

      /.\p/.\p/.\
    /u\./.\o/.\./u\
  /i\./.\u/ \u/.\./i\
/.\./o\./i\u/i\./o\./.\
\i/.\u/         \u/.\i/


And vice-versa. Any of the rotated variations below paste in the same orientation as the first version, as it's based on the calculated forward direction of the ship:

/i\./u\         /u\./i\
\./.\o/.\i/u\i/.\o/.\./
  \i/.\./u\ /u\./.\i/
    \u/.\./o\./.\u/
      \./p\./p\./
 
        /.\i/.\
        \u/o\./i\
        /i\./.\./u\
      /i\u/ \u/.\./.\
/.\u/o\./.\u/.\o/.\p/
\i/.\./i\./u\./.\p/
 
/i\./.\i/.\u/.\./p\
\./u\o/.\./u\./o\./p\
      \i/u\ /u\./.\./
        \i/.\./.\u/
        /u\o/.\i/
        \./i\./
 
      /.\p/.\p/.\
    /u\./.\o/.\./u\
  /i\./.\u/ \u/.\./i\
/.\./o\./i\u/i\./o\./.\
\i/.\u/         \u/.\i/
Logged

PythonBlue
Level 2
**



View Profile WWW
« Reply #23 on: March 23, 2013, 02:53:25 PM »

Looks very interesting, indeed! Smiley
Logged

gears
Level 0
***


View Profile WWW
« Reply #24 on: March 25, 2013, 03:42:33 PM »

Experimenting with a darker color theme for enemies (yes, neon style is the way forward):



My intent is to show the team/alignment through the core glow and overall theme, but I still want to indicate power levels using hues in the same way as the player's ships.. without making it a giant mess of random/clashing colors that no one can understand.
Logged

eigenbom
Level 10
*****



View Profile WWW
« Reply #25 on: March 25, 2013, 05:04:33 PM »

bewdiful!
Logged

gears
Level 0
***


View Profile WWW
« Reply #26 on: March 25, 2013, 05:31:08 PM »

bewdiful!
Glad to regain your approval!
Logged

eigenbom
Level 10
*****



View Profile WWW
« Reply #27 on: March 25, 2013, 05:46:52 PM »

bewdiful!
Glad to regain your approval!

Be careful, I may turn again at any moment..  Evil
Logged

lithander
Level 0
***



View Profile WWW Email
« Reply #28 on: April 28, 2013, 02:06:17 AM »

I liked the new graphics. They just were a little hard to read... maybe a combination of the two?

The approach of having an Ascii representation of ships that you can copy&paste is so cool! You found a neat way to map a hex-grid to text that preserves the look & feel.
« Last Edit: April 28, 2013, 02:12:23 AM by lithander » Logged

psyguy
Level 0
***



View Profile WWW Email
« Reply #29 on: April 28, 2013, 07:05:54 AM »

I really like the lighting work in this, the neon glow and everything.  It looks really cool.  Smiley
Logged
gears
Level 0
***


View Profile WWW
« Reply #30 on: April 28, 2013, 12:28:39 PM »

I liked the new graphics. They just were a little hard to read... maybe a combination of the two?
The approach of having an Ascii representation of ships that you can copy&paste is so cool! You found a neat way to map a hex-grid to text that preserves the look & feel.

The ship graphics will continue evolving, and I may try some form of directional lighting effects again at some point. Cells are actually stored in a triangle grid rather than as hexes, but both hex- and tri-grids are really just different ways to look at the same underlying structure. The Voronoi diagram formed by connecting the triangle cell centroids is a hex-grid, so I guess that makes them complements.

I really like the lighting work in this, the neon glow and everything.  It looks really cool.  Smiley

Good to hear! Hopefully the lighting effects I'm working on now are continuing that effect in the right direction.


Progress

Recently, I haven't had much time to work on this, but I've still gotten a few things done:

  • Proximity hash marks: They indicate nearby ships and work like you'd expect. I'm wondering if I can get away with avoiding a minimap in favor of hash marks + zoom.
  • Procedural terrain + chunking: This minimizes load time because chunks can be streamed in, and it also means the world can be 'infinite', or at least 'very large' (but not yet as large as you'd think because I haven't tackled the FP precision problem).
  • Expanded tiling system: The old terrain tiles were a hack because they weren't seamless and didn't support transitions well. The new method allows me to generate seamless tiles/transitions and hand-tweak them if needed. It's also subtly styled as trixels, not pixels!
  • Point lights: Just started testing point lights emitting onto terrain. I might look at doing a bit of occlusion to hide the terrain interior.
  • Performance: Getting around 90 FPS (20 Hz physics updates) with 100 ships in fairly close proximity on a single thread, so I'm conservatively aiming for gameplay that limits battles to half that scale.



Lots of hash marks indicate we're probably in a bit of trouble. Also note the random bits of 'ore', or whatever the lighter-shaded rock is.
Logged

gears
Level 0
***


View Profile WWW
« Reply #31 on: June 22, 2013, 10:04:59 AM »

I've been a bit preoccupied lately, but here's some visibility/occlusion shading from awhile back. It's static and recalculated when tiles change.


Lots of progress in these areas:
  • Chunk system: Supports massive/infinite worlds generated on the fly.
  • Unity abstraction: Over time, I've gradually abstracted away Unity3D functionality, and I'm at the point where I can run much of the game outside Unity but still get many of the benefits within it. This is great for testing and needed if I want a separate server app.
  • Threading: I recently took a few days to write a threaded job system. This allows me to run jobs like map chunk generation in background threads to avoid affecting framerate. For fun, it's mostly lockless.
  • Networking: In progress. The immediate use is actually to help with content generation, which is sorely needed if I want more than rocks floating around. I'm a big fan of feedback, and I plan to include C# compilation with the server so I can edit a PCG script, save, and the server will reload the script and push down updated chunks/tiles in real-time. As far as libraries, I've chosen Lidgren over Photon because it offers more control.

Hopefully I can get back to the important stuff, gameplay and content, after a bit more of this.
Logged

Ankmannen
Level 1
*



View Profile WWW Email
« Reply #32 on: June 23, 2013, 09:58:42 PM »

Looking great! We're kinda in the same genre but your games sure does look amazing compared to my programmer art blockiness! Smiley

I'll be following this project for sure and check it out in more detail when I'm not at work. Smiley
Logged

Check out WordRoom for Windows 8, WP7/8, iOS and Android. Soon on Facebook. Also working on my concept game called Spacealot (www.spacealot.net).
josh_s
Level 0
***



View Profile WWW
« Reply #33 on: June 24, 2013, 05:26:01 AM »

This is looking great. I loved Captain Jameson, this seems like the logical next step. The game idea will appeal to a wide audience.

You were definitely right to go back to the neon. So much easier to read, also arguably more stylish than the solid-effect.

The real-time networking could be quite hard to get right due to latency. I would imagine you will need a similar model to that used by FPS games. I used such a design on a previous project.

Logged

website  |  devlog  |  twitter  |  indieDB  |  facebook  |  steam
jonbro
Level 3
***



View Profile
« Reply #34 on: June 24, 2013, 06:06:14 AM »

this is looking super slick! I also like that eval2d thing that you mentioned earlier is super slick looking, are you planning on releasing it at some point? I would really like something like that now that I have moved to unity, it is one of the things I miss about working in lua.
Logged

gears
Level 0
***


View Profile WWW
« Reply #35 on: June 24, 2013, 02:17:38 PM »

Thanks guys. Progress is slow but steady!

Looking great! We're kinda in the same genre but your games sure does look amazing compared to my programmer art blockiness! Smiley
I'll be following this project for sure and check it out in more detail when I'm not at work. Smiley

I guarantee I've got plenty of terrible programmer art! Only through spending inordinate amounts of effort in Inkscape and on procedural generation have I gotten something ok, although it remains to be seen how much further PCG can carry my terrain tiling.

this is looking super slick! I also like that eval2d thing that you mentioned earlier is super slick looking, are you planning on releasing it at some point? I would really like something like that now that I have moved to unity, it is one of the things I miss about working in lua.

Here's a non-recent build. At this point, it only loads the DLLs for my own math/noise library, but I'd like to go to more of a plugin model using MEF to pick up arbitrary DLLs in the folder. A bit dangerous if those DLLs come from an untrusted source, but fine for personal projects.

The real-time networking could be quite hard to get right due to latency. I would imagine you will need a similar model to that used by FPS games. I used such a design on a previous project.

Yeah, it'll be tricky. I'm most concerned about the networked physics part, but I do have the benefit of doing 2D and having relatively simple interactions at limited velocities.
Logged

josh_s
Level 0
***



View Profile WWW
« Reply #36 on: July 01, 2013, 06:48:49 AM »

Quote
Yeah, it'll be tricky. I'm most concerned about the networked physics part, but I do have the benefit of doing 2D and having relatively simple interactions at limited velocities.

Getting a realtime multiplayer game which works at LAN latency levels is quite easy. If you want it to work over the internet it's a lot trickier. This was my approach in the realtime multiplayer game that I worked on.

  • The server is master of the state of the game at any time, and simulates how the game world changes over time.
  • Each client is capable of simulating the game world. To prevent cheating, the client only simulates those local changes to the game world which the local player can see.
  • Each client maintains a TCP session with the server. The TCP session is used to send players' actions to the server. The server can also use it to send player chat messages etc.
  • The server also sends regular UDP updates to the clients. These UDP updates tell the client "the state of the world local to you is now this. Overwrite your local state". Clients react to these by discarding their local state and replacing it with the update. If the update timestamp is older than the timestep which was in use before the update arrived, the simulation is run forward to that timestep.
  • Each player action is timestamped with the timestep of the game which was current when the player executed that action.
  • When the server receives a player action, it rewinds the game state to the timestep referenced by the timestamp of that action. It applies the action at that time, resimulates the world back to the present time, then sends out UDP updates to all players with the new state.
  • Avoid if possible doing any floating point calculations using native CPU floating point hardware. Otherwise players with different hardware will simulate the world updates differently.
  • Design the UDP update encoding so that it is smaller than a packet size.

In the end I was happy with realtime play over the internet but it took a long time to get right. You might want to start working on this part as soon as time allows as addressing it at a later stage may be difficult.

Logged

website  |  devlog  |  twitter  |  indieDB  |  facebook  |  steam
gears
Level 0
***


View Profile WWW
« Reply #37 on: July 02, 2013, 04:08:40 PM »

Thanks for sharing those details doctor!

I'm glad you brought up fixed point, because it's been a concern of mine. I don't have the time to spend getting floating point deterministic across multiple builds/processors even if there were compiler flags for C# to enforce some level of strictness in FP calculations, so I'm assuming that's off the table. That means I'd have to go with fixed point for determinism, but I don't know of any mature physics libraries supporting it. So I see two general directions:

  • Larger scale RTS with very simple fixed point motion/physics with lockstep clients, supporting many entities because of the reduced need for communication due to all simulations remaining synchronized. Mostly reliable/ordered messaging?
  • Smaller scale action-oriented game with high-frequency UDP updates, with nondeterministic physics requiring synchronization. I'm leaning toward this option, but hate to lose determism!

The net library I'm using supports optionally reliable/ordered UDP at the application layer. I'm curious how that compares with use of a TCP connection as far as performance over WAN.

One thing I need to do is see what's needed to support rewinding the world to apply updates. That could get complicated...

And like you say, it'll be a lot of measuring to see what's feasible, and tweaking until it works.
Logged

josh_s
Level 0
***



View Profile WWW
« Reply #38 on: July 03, 2013, 01:53:00 AM »

I think your game lends itself to real-time, which implies UDP for updates. An RTS would be a very different game.

Reliable / ordered UDP could be faster than TCP, but I'd only use that for sending actions from client to server and other messages which must get through. I would still recommend plain old unreliable UDP for server -> client updates.

On the fixed point determinism point, I have heard of a very simple solution (this was from the author of Scorched3D). The solution was to multiply the fixed point numbers up to very large integers (e.g. longs), and do the calculations in integer land, since integer arithmetic is predictable across processors. This is fine if you do the physics stuff yourself. I think doing the physics yourself should be possible in your game. However this option may not be possible if you are using a 3rd party physics library.

My networked game which I mentioned was Java so I didn't have the determinism issue, I believe the Java VM layer is always deterministic for floating point.
Logged

website  |  devlog  |  twitter  |  indieDB  |  facebook  |  steam
Belimoth
Level 10
*****


high-heeled cyberbully


View Profile
« Reply #39 on: July 03, 2013, 02:24:54 AM »

Quality work here. I'm glad you went with triangular components instead of the usual rectilinear thing.
Logged

Pages: 1 [2] 3
Print
Jump to:  

Theme orange-lt created by panic