1. Help us improve the editor usability and artist workflows. Join our discussion to provide your feedback.
    Dismiss Notice
  2. Unity 5.6 is now released.
    Dismiss Notice
  3. Check out all the fixes for 5.5 in patch releases 1 & 2.
    Dismiss Notice
  4. Get further faster with the Unity Plus Accelerator Pack, free for new Unity Plus subscribers for a limited time. Click here for more details.
    Dismiss Notice
  5. Learn how you'll soon be able to publish your games to China in four simple steps with Xiaomi. Sign up now for early access.
    Dismiss Notice

annihilaTRON, a 3D light cycle game

Discussion in 'Works In Progress' started by Instability, Feb 2, 2017.

  1. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Hi,

    did you like the Light Cycle races in the TRON movie? There should be a game that takes the classic TRON formula and makes something fresh, lively and modern with it. That is what I am trying to create with this prototype. I have been inspired by Armagetron Advanced which is an excellent but stagnating light cycle game. I want to take it further by introducing new rules that explore the third dimension.

     
    Thrawn75 and Denisowator like this.
  2. Denisowator

    Denisowator

    Joined:
    Apr 22, 2014
    Posts:
    304
    This really reminds me of the snake game added to GTA V Online. I really like how the camera is really far away from the ball, so that the slow camera turning doesn't make the player disoriented in terms of where they're going.

    Although I can see some people still having some issues with how the camera works. Therefore an overhead camera mode could be something useful to consider.

    With the speed the balls are moving at, I don't think anyone is going to have time to even glance at the minimap (at least I wouldn't), because they would be too focused on avoiding the lines. Although it would be good to be able to see what the map looks like at the end of each round.

    The colors aren't too bright, but vibrant enough for you to be able to tell the difference between everything, which is really important in fast paced games like this.

    I also really like the kill streak system. It definitely adds an edge to the competitive side of things.

    Best of luck on your project, I can't wait to see what this evolves into. ;)
     
  3. imaginaryhuman

    imaginaryhuman

    Joined:
    Mar 21, 2010
    Posts:
    5,260
    Looks neat. I would maybe like an even further-away and higher-up camera so that I can see a bit better what's coming up ahead?
     
  4. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Thanks for your replies guys! I will work on the camera distance and angles, will also perhaps add it to the options menu for everyone to tweak.

    Do you think this game is suitable for putting on Steam after some polish? What would be the most essential features it needs? (I am thinking AI opponents, curved grid, online play, original music... which of these is essential, not just nice to have?) Should this be a free game, or would it be appropriate to charge a small fee on Steam? Please let me know your thoughts.
     
  5. Denisowator

    Denisowator

    Joined:
    Apr 22, 2014
    Posts:
    304
    It should either be free, or $3 max, your choice.
    Out of all the stuff you listed, online play, and original music are essential. It would be hard to make a game of this type, fun without original music. Especially one that really fits with the surroundings. And while I'm on the subject of surroundings, 3D environments would be nice, like simple 3D levels, instead of a flat plane in the middle of space.

    In a game with little gameplay, everything you mentioned is pretty much essential, or else the player(s) will get bored pretty quickly.

    You should also add a points system, or a points mode, where you get points continuously, and bonus points for jumping over lines, turning very close to the lines, and stuff like that, to make people do risky stuff a lot more often.

    And most of all, spawning and dying animations and sound effects.
     
  6. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Thank you Denis! Very sensible advice on what would make the game a more well-rounded complete experience.

    I would really be curious how people feel about TRON and lightcycle games in general? What kind of expansions of the classic TRON formula would you like to see? I have expanded the classic formula with jumping, an open arena, acceleration and slowing down.

    What would you be excited to see? Is TRON too basic to be exciting? What about TRON on curved surfaces, like spheres and donuts, as done in Cycleblob or Milksnake?

    Here are some screenshots from Cycleblob:
    [​IMG]

    [​IMG]

    ...and from Milksnake:
    [​IMG]
     
    Last edited: Feb 19, 2017
    toto2003 likes this.
  7. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    A particle effect from a previous game I made. Working on making the TRON trails look like this.

    [​IMG]
    [​IMG]
     
    toto2003 and Denisowator like this.
  8. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Tile based AI work in progress:

    [​IMG]
     
    toto2003 and Denisowator like this.
  9. Denisowator

    Denisowator

    Joined:
    Apr 22, 2014
    Posts:
    304
    I think the combination of those particles, inside an unusual shape like in the two games you mentioned, would be amazing. Because it would really add the edge to make the players pay more attention.

    You could also make the trails have different levels of brightness on different levels, so that on some levels it just serves as an eye candy, while on others, it actually helps light up the level and show thew players, what the level looks like, as they play more and more.

    Tron in itself is an extremely fascinating and very fun concept, the whole idea of light which can be used to destroy others, whether it's attached to a Frisbee-like disk, or to a motorbike.

    It's definitely one of those concepts, that are so simple, yet so addicting. Much like flappy bird.
    The way flappy bird kept people addicted, wasn't for the fact that everyone wanted to get to the end. It was the random placement of the pipes, which forced the players to be focused non-stop.

    You could do that in this. Add things which make the players put more attention to the level as a whole, maybe moving obstacles, like pillars moving from one surface, and into another.

    I'm not saying make a Tron-Flappy Bird baby, I'm just saying add things that would cause the players to have to keep their focus up, more often.

    Also, explore how music works on the brain (just in a general sense). Because although you might find a piece of music to be a cool addition to the game, it might make the players really stressed. For example, really fast paced music would be something that I personally would find quite stressful in a game like this. Mainly because it would slowly act up my ADHD, and listen to intense music and keeping up dodging things, would be too much for me. But I really think it will also apply to regular people.

    Try combining different types of music and sound, with different levels, to create different feeling. For example, some levels might take place in complex shapes, and have very slow and soft sounding music, while others might be on simpler and bigger levels, but will have fast paced music, to act up the brain once there is little space to move for the players.
     
    Instability likes this.
  10. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Thank you Denis, this is really helpful! It's great to brainstorm these things. I agree that randomly placed pillars and holes (which are not the same thing in my game) could prove hugely exciting. Also thank you for your hint about music - I always had fairly fast retro-futuristic synthwave in mind, but slower music might actually calm people down. Thank you for mentioning these ideas.
     
    Denisowator likes this.
  11. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    I am gradually coding my way towards procedural generated level geometries. But for now, I am testing this new hand made level:

    [​IMG]
     
    Denisowator likes this.
  12. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Laid the foundation for procedurally generated TRON grids. Here is a Sierpinski carpet:

    [​IMG]
     
    Denisowator likes this.
  13. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    A record high! Never had that many games in one session before. This was almost 350 games in about 1.5h playtime against my flatmate!

    [​IMG]
     
    RavenOfCode likes this.
  14. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Here is a little test ride through the maze from the previous screenshot:

    ezgif-3-947b620f07.gif

    And here is some gameplay on a plain grid:

    ezgif-3-68a2b3dc71.gif
     
    Last edited: Mar 5, 2017
    Denisowator likes this.
  15. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Here are some upcoming grid designs:

    [​IMG]
     
    Last edited: Mar 14, 2017
    Denisowator likes this.
  16. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Playing the new grids is possible now. Here are two new grids in game form and matrix form:

    [​IMG]
     
    Denisowator and RavenOfCode like this.
  17. Denisowator

    Denisowator

    Joined:
    Apr 22, 2014
    Posts:
    304
    Looking great so far!

    Question, how did you make the matrix form images? From what I can see it looks like a really clever way of using MS Spreadsheet and graphs, but I'm 99% confident that I'm wrong.
     
  18. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Thanks Denis :)

    I am using Wolfram Mathematica, which is a massively powerful software for scientific computation of all sorts. The specific command is MatrixPlot.
     
    Denisowator likes this.
  19. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Thanks to those for expressing interest and replying to this thread, it is good to know that there are a few more TRON fans out there!

    An idea that I have been intrigued by recently are surface shaders. The tutorial video below was quite eye opening. The idea I expressed in a previous post - to run TRON on curved surfaces - seems to be best tackled with vertex shaders, just like in the tutorial video. It will take me quite some time to learn how to code vertex shaders, but in the long run I want to make my TRON run on a torus. I am not sure what that does to the gameplay but my inner nerd needs to see this. If anyone has insights on vertex shaders, knows great tutorials, or would like to warn me about rabbit holes please I would very much like to hear that.

     
    Denisowator likes this.
  20. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Finally compiled a new build! It's the first time that my game is ready to test on procedural placed tiles. Collision detection, jumping etc. all seem to work properly now. Will give it a good test with friends and hopefully record a short gameplay video in the upcoming weeks. Here is what it looks like for now:

    [​IMG]

    A nice advantage of this tile based approach is that more things can be controlled by scripts instead of manual object placement. For instance, the confines box (which ends the game if any player leaves it) is now procedural controlled and its margin can be set in units of tile length. In this example, the margin on the XZ plane (which you can see) as well as the hidden Y plane is 2 tiles:

    [​IMG]
     
    Denisowator likes this.
  21. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    After optimisation of the trail algorithm, the physics computation scales much slower, resulting in a great performance boost. Please find below the striking profiler comparison of the old and new collision systems. This optimisation has allowed me to play this game on WebGL for the first without any serious lag or problem.

    [​IMG]
     
    SiliconDroid and Denisowator like this.
  22. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    In the previous posts, I modified the level geometry significantly. But after a test with a friend I noticed it does not change the feeling of the game too much.

    I was wondering if you have any ideas or wishes about what gameplay elements you would like to see. I have my own ideas and list of priorities/difficulty of implementation, but I would really love to hear from you first.
     
  23. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    A post-mortem for SUPERCOIL and its legacy for TRON

    Here are some musings about my journey in game design and what I am trying to learn with this project. I made a game prototype called SUPERCOIL (see here, or click link in signature). It was a passion project in which I tackled a very challenging high level concept (making a scientific simulation playable - I am a professional scientist and this really excites me). I chose a scientific subject which was relatively basic for me, but having had no previous game design experience, I completely underestimated how hard game design is and overreached. I conflated several things that are in themselves very challenging:
    • the extremely challenging problem of creating original and fun game mechanics based on my electrostatics concept
    • making beautiful minimalist graphics that look unique, which I think I succeeded at
    • creating a platformer-like "experience" and mood, by using lighting, camera movement and original music made by a friend, which I think is a partial success.
    The partial success of graphics and atmosphere was uplifting, and got me a certain small amount of attention at a few festivals and an initially lively TigSource thread, a press article, and a reasonably successful trailer. But in the long run, the game never materialised. The reason is that I never managed to make solid game mechanics. I attempted to reinvent the concept through a 2D prototype and a puzzle spin-off prototype, but none of them really clicked. At this point I still like the idea, but can see no clear path to a great game.

    The lesson learned here is, as I have found, the same that I learned from science, where I applied it better: Solid fundamentals are the most important thing, without them, a concept will crumble sooner or later. This is what I am trying to teach myself with TRON: I am prioritising making a solid game that works and is fundamentally fun. In my opinion, the most important fundamentals for this game are:
    • Solid and clear game mechanics with a good control scheme - this is basically done
    • Very good AI. This is what will make other people play the game (or not). This is in early stages, but given my background as a scientist, I think I will be able to pull this of well and this will most likely be the most fun part of the project. But so far, early stages.
    • Beautiful presentation. Given my previous game and and its TRON-like beautiful graphics, you can imagine that my hands are itching to make this game look gorgeous. But I restrain myself here - as learned from my previous experience, good graphics before a solid game is a bad idea.
    • Expansions of the classic formula - power ups, curved geometry. If by this stage, the rest of the game is great, then these things will be the icing on a cake and will produce the most gorgeous trailers. This will add a bit of novelty and eye-candy. But this only works if it is built on great fundamentals.
    Anyway, these are my thoughts. Hope you find this interesting, and now we have a bit of a mission statement for this project. In my slow hobbyist pace, I will keep making this game boring and solid until it feels absolutely great, and once I have achieved that, I will have the basis to make it fly.
     
    Last edited: Apr 21, 2017 at 9:50 PM
    PhilippG likes this.
  24. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Some efficiency improvements. Greatly reduced the amount of raycasts to check for collisions against trails. While on the ground, the minimal amount of segments is laid down, whereas in the air more raycasts are performed. This should keep performance lean.

    [​IMG]
     
  25. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    18,672
    Another consideration could be using line segement - line segment c# functions (many online) instead of raycast and of course a quadtree or grid to minimise checks further. Ideally you should be doing around 1-3 checks per frame per player.

    I think it could become necessary with lots of players, larger levels or busy levels.
     
    Instability likes this.
  26. Instability

    Instability

    Joined:
    Apr 16, 2012
    Posts:
    258
    Thank you hippocoder, this is interesting. line segment functions and quadtrees are concepts I am not familiar with. Will do some research. You are completely correct, while my method works for now, it will definitely be a problem in the long run.
     
  27. SiliconDroid

    SiliconDroid

    Joined:
    Feb 20, 2017
    Posts:
    72
    Oh yeah, looking really nice so far!

    another optimization idea:

    Instantiate a 3D look up table (LUT) with byte[][][] array.

    Each trail color represents one of the eight available bits in that byte.

    Array resolution will need to be tweaked to be some fraction of your trail width. To make collisions always precise you would also quantize your players trails to conform to that resolution, at say quarter trail width the players would never notice or complain, in fact they would be thrilled to more often hit an edge case where their trail was running right next to another.

    As your trails grow out into the available volume they are logically oring their bit volumes into the LUT and also checking for existence of any existing bits in the LUT (collision) before they do that, use same addressing code for both.

    Basically you'd be making a painting canvas which you checked for existing pixels and painted in its trail if it was clear, but in 3D.

    It's a fast game: your trails are growing faster than (trailWidth/frame) so you will need to interpolate through the array per frame, C++ would be much faster here with raw pointer operations in that array but C# I think is fast enough.

    Ideally you would stick it in a separate thread but for proof of concept can just do it in render thread.

    With this scheme you would have a fixed per frame computation cost regardless of how many trails you've laid down or how large your playing volume is, you would also not cause much if any GC. Nowadays RAM is cheap so allocating a few hundred MB for the job is totally doable.

    It's certainly doable on a large scale if you stick to mainly 2D plane with just a little height for jumps, which are cool BTW! But of course if you constrained to just 2D plane it'd be super cheap and 'easy' with just a 2D array.

    EDIT: As it's game over for colliding trail when two trails collide you would not need logical operator to or in your bits, you could just read/write your color indices directly, a little faster and up to 255 trails per game, not that you need that many lol.
     
    Last edited: Apr 24, 2017 at 9:32 PM