Jump to content
  • Advertisement

Glasshalfpool

Member
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

9 Neutral

2 Followers

About Glasshalfpool

  • Rank
    Member

Personal Information

  • Role
    Game Designer
  • Interests
    Art
    Design
    Programming

Social

  • Twitter
    glasshalfpool

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Glasshalfpool

    First Demo in early 2019 ...didn't happen

    The post below I wrote at the start of the year and promptly fell off development entirely and did some other stuff until last week where I picked the game up again and found new enthusiasm for it. I do really want people to play it as I did when I wrote the below, but I'm someone who doesn't let go of things easily for fear of negative feedback on something I suspected wasn't ready. Anyway, still hoping to deliver something playable before the end of 2019. Over the Christmas break I had a friend play TLC and it was one of the most satisfying experiences I've had on this entire project. It felt like a mini pay off to months of work. It was a fleeting feeling, but for a couple of minutes I felt like I'd just released a finished product to universal acclaim. 😋 It was the first time someone has played it and kind of just got it. With a few seconds of explanation ('this button is go', 'that button is stop' kind of thing) he was able to play, which doesn't sound like a big deal but when you're the only person who's played it for any length of time you've always got it in the back of your head that maybe it's a complete mess that no-one who touches it will understand, so it was so heartening to know that for at least one other person, that's not the case. It's spurred me on to want to release a playable demo as soon as possible. I'm desperate for feedback, good or bad. I came up with the following list of things it could contain along with the current status: Core game play - functional UI - functional Camera behaviour - functional Visuals - functional Audio - To Do Player Instruction - To Do Player Feedback - basic functional Bugs - To Do So while I continue to work on this, I know I need to decide how far each piece of the game needs to be developed in order to work for the demo. But what does a demo need to contain? To what extent should a feature be complete? What level of polish? Where do you stop? How do you decide what's necessary and what's not? Find out more about Tokyo Light Cycle at the project page.
  2. Glasshalfpool

    Tokyo Light Cycle

    Album for Tokyo Light Cycle
  3. It's always been my goal to have as little UI as possible, one that tells you everything you need to know and not a single item more. Like any game, Tokyo Light Cycle needs to convey certain information to its player. There are things the player can do in certain situations and not in others and they need feedback to tell them what they can currently do. Currently, the UI for Tokyo Light Cycle looks like this: The UI can be broken down into three section. Lap times, Health and Speedometer. Lap timer and health are self-explanatory but due to the nature of the gameplay the Speedo conveys (for a racing game) quite a lot of information. Start of game Current speed: Red line shows selected speed (in the below example 0). Available speed: White area shows available speed. Grey area shows speed yet to be earned. Charge status: The word "empty" denotes the current status of the charge bar Charge bar: The charge bar itself is visible (and also empty) Gameplay begins: Current speed: Red line moves to current max as accelerator is held Charge status and bar: Bar fills and status changes to "charging" as players drifts Charge bar full: Available speed: In this case the player has unlocked level 3 speed. Charge status: When the bar is full the words "Cell Full" with a button prompt tell the player the charge is ready to cash in I designed this and for a while I was pretty happy with it... ...then I realised that a racing game, by its nature, demands your attention is fixed on the road ahead at all times and that relying on the UI at all to make the game playable is probably a really bad idea. The world is the UI The answer of course is obvious. The UI isn't the only thing that tells the player what's happening. Visual and audio cues of different kinds convey this information much more effectively than even the most elegent UI can manage. Whether its the whoosh and boom that accompany a filled boost bar in Burnout, or the way a powerup appears next to your racer in Mario Kart (an upgrade from the original where it just appeared in a box) the information needs to be conveyed in the most effective way, and for a racing game this means a way that doesn't force the players eyes away from the road. So, this created a whole new goal: to have the entire game playable without any UI at all. Could the UI be something you can toggle off in the menu? Can all the necessary information be conveyed in-world? I recollect how Dead Space handled showing player health on the player's back: Or the addition of ammo count to the actual gun in Halo: Both conveying important, gameplay-relevant information right where the player was already looking. So the ideas begin to flow and like many other aspects of Tokyo Light Cycle, I find myself taking inspiration from Akira: The crackle of electricity on a wheel. The afterglow of tail lights: Thanks for reading. J.
  4. Glasshalfpool

    Tokyo Light Cycle

    Story It looked like an easy score, but turned out to belong to people who don't like being stolen from. Now your sister has a gun to her head and they hand you a package and tell you to deliver it in less than an hour or she dies. Your only option is to speed across the city in the dead of night to make the rendezvous in time. Ride as fast as you dare across the unforgiving landscape of Tokyo, from wide sweeping highways to deadly narrow alleys, discovering risky shortcuts and surreal alternate paths. Gameplay Tokyo Light Cycle is an arcade racing game. Steer left or right and the bike will bank in a (fairly) realistic way, but tap the brake while steering and your bike will drift around corners like it's sliding on ice. Drifting and pulling wheelies build energy which once full can be released to boost to a new, faster top speed and you can do this over and over again. The world is full of shortcuts and alternate paths, many of which require you to be going fast enough to break through barriers, jump gaps or squeeze through tight spaces. It's all about balancing speed and survival: Every collision robs you of your top speed and you and your bike are pretty fragile. You can only only take a few hits before you're done. Goals I'm trying to create a game that's about riding that ultra fine line between zen-like control and complete disaster. A game that encourages you to go as fast as you can while punishing you for every mistake. I'm also interested in the idea of creating a racing game that tells a story, both through it's environment and dialogue, about the main character and her relationship to those who have her sister hostage. The aim is to create a mesmerizing soundtrack that drives the player forward and is its own reason to play, blending traditional Japanese drums and modern electronic beats. About me I'm a solo developer and Tokyo Light Cycle is my first game, though I have a background in web development and software/UI design. I'd love to work on TLC every waking hour but unfortunately (or fortunately?) I have a full time job so progress is sometimes slow. Status (January 2019) At the moment I have a working prototype with basic visuals and the core game play in place (you can see some footage below). I expect to release this as a playable demo in the first few months of 2019. If you like the sound of the game and are looking for a project, do DM me. A word on audio: I created a video to explain the audio goals of TLC to help any composers interested in collaborating.
  5. I have put a lot of time into developing Tokyo Light Cycle's gameplay over the last year... possibly too much. 😉 I spent ages deciding how the controls should work, a tonne more tweaking specific values, and I'm still working on making sure its fun to play, while also serving the larger design goals of the game. I thought I'd write a little about what this process was like and how starting from a baseline of "typical" arcade racing gameplay has evolved into what I have today. What is typical arcade racing gameplay? I would define the gameplay mechanics of a basic arcade racing game as follows: Accelerate: One input to go Brake: One input to stop Steering: Two inputs (or a single axis) to steer left and right Almost every arcade racing game will have these basic gameplay elements and most will build on or tweak them in various ways depending on their own unique mechanics: Forza adds a handbrake, Wipeout has a separate brake for each direction, Mario Kart has a jump button which turns into a drift, etc. etc. Case Study: Burnout Series Burnout is probably my favourite ever racing series. I haven't spent as much time with any other racing game and I took some inspiration from it when I started thinking about how I wanted TLC to play. Burnout expands upon those three core elements of an arcade racing game: Accelerate: One input to go Brake: One input to stop Steering: Two inputs (or a single axis) to steer left and right Steering + Brake: Tapping brake and steering changes the physics on the car's wheels, reducing traction to make the car drift. Boost Meter: Performing certain actions fills a meter which can be spent to temporarily boost the player's top speed. Burnout evolved into a very specific type of racing game, focusing more on car on car combat as the series went along. While I didn't mind this, it wasn't actually what I enjoyed most. I loved the super simple "tap to drift" gameplay. I enjoyed getting to the front of the pack and then it was just me vs the road, weaving in and out of obstacles and drifting at insane speeds was a very zen experience for me. It was that element of Burnout that I wanted to distil to something pure and simple with TLC and so I started with Burnout's "tap brake to drift" mechanics as a reference point. Game Design Overview: What is Gameplay in service of At it's core, TLC is just a linear racing game taking you from A to B through a series of levels, but along the way the player can access shorter and more difficult routes off the main path with the goal of getting a better completion time. These shortcuts are either gated behind a barrier that requires the player to be going at a certain speed to break through, or are time sensitive, so the player has to arrive at that point in the course before access expires. Like a rail crossing which becomes blocked by a train for example. From that base "tap brake to drift" idea, the gameplay in TLC has evolved in small ways to help enable the above design and along the way created a slightly more nuanced and involved control scheme. How Game Design Influenced Gameplay To serve this design, the gameplay has essentially becoming about earning and losing and re-earning speed while of course staying alert to the twists and turns of the track. This lead to me thinking of speed as the game's currency. Earning Speed The player starts the game with only speed level 1 available. Speed is earned by drifting around corners and performing a wheelie, which fills a meter that when full is "cashed in", unlocking speed level 2. They repeat this process twice more up to speed level 4. Losing Speed Mistakes remove the player's top speed level, slowing them down and making it so that they cannot access shortcuts until they have re-earned the necessary speed level. They also lose a chunk of health proportionate to the severity of impact. Speed is lost through colliding with the environment. Collisions happen because of mistakes or accessing a blocked off shortcut. Spending Speed Speed is automatically "spent" when the player bashes through a barrier to access a shortcut in the same way as it is through a collision, except that they lose speed but do not lose health. Because the player's health is also lost very quickly (3 - 4 collisions will kill you), speed can also be spent to recover it. Sacrificing a speed level recovers roughly one collision's worth of health. Moment to moment gameplay The resulting moment to moment experience is pretty fun. It's not revolutionary or anything but the earn/lose/spend mechanic adds an extra layer of interest to the core racing. The player has to be alert to the shape of the course like any racing game, reacting to the corners and learning how to take them without hitting a wall or losing too much speed. They also naturally want to keep their eyes open for shortcuts and hidden paths. The player will always be managing their speed as they earn it, spend it, lose it and re-earn it. Once earned, the player can switch up and down through the four speed levels at will, using these to quickly reduce or increase speed in addition to their brakes or set their top speed to be lower if they're going through a tight section. Dropping a speed level and then jumping up one again can be turned into a wheelie at any time, meaning if the player goes through a tricky section and comes onto a straight section having lost some or all of their speed, they can start to re-earn it immediately. But the gameplay is also quite flexible and the player can play the game without necessarily knowing all the quirks or mechanics. A new player can enjoy the game just knowing how to accelerate, brake and cash in their meter once it's full without worrying about much else. Quick Note: Advice for beginners who want to make a racing game Designing and building this game has been a long and often difficult process (mostly because of my lack of experience), but while there are a lot of get you started tutorials out there for other genres like platformers or first person shooters, I didn't find much dedicated resources to help make a racing game. For that reason I thought I would share a couple of things I found useful early on: Quill18 ran a livestream a couple of years ago where he created a simple top-down arcade racer which I found a really nice start point to get used to a few of the concepts that are useful to know for racing games. https://www.youtube.com/watch?v=0Quv9U9_a8c Unity's manual (which I don't think normally contains much tutorial) has a good article on the build-in wheel collider. I didn't use this but if you're looking to make a more realistic racing game, you can get a vehicle controller up and running very quickly with this. https://docs.unity3d.com/Manual/WheelColliderTutorial.html Hope this has been interesting.
  6. Glasshalfpool

    I need tips for breaking into Game Industry

    Nothing necessarily wrong with wanting to do everything, but it does split your focus and your time. I find this a problem when I do it myself. It's helpful to me to have quite specific, defined goals.
  7. Glasshalfpool

    I need tips for breaking into Game Industry

    What do you want to do? Do you want to develop your own games? Do you want to make tools for developers? Or is your plan to produce and sell your own engine? Kinda seems like you are trying to do everything.
  8. Glasshalfpool

    Designing Difficulty

    I see a lot of talk these days about difficulty in games. Specifically there is a lot of discussion about whether games that are designed to be difficult can or should provide ways to make them easier for players who might be frustrated by the difficulty. Mark Brown's video on Celeste's Assist Mode sums up the subject very nicely. I find it hard to nail down my own opinion on this subject because I don't think my enjoyment of a game is effected JUST by its difficulty. There are games I have bounced off of (I've never made it more than a few hours into a Dark Souls game) and other games that have really sucked me in (I must have nearly 100 hours in Spelunky) and I don't think I can honestly say the difficulty alone accounts for my love or dislike of either. This has got me thinking about how difficulty could be adjusted in a racing game. My current project (Tokyo Light Cycle) is racing game, but has some particular quirks that make it a little different from typical racers where the goal is to beat opponents, sharing mechanics with games like Race the Sun or Thumper that are about avoiding obstacles and mastering timings. TLC is a simple game, but there are still a number of elements that could be changed to alter difficulty: Player health Death mechanics Movement Speed Level Design Time Limit Other random thoughts Player health Current Default: Player loses health when they collide with obstacles. Player can survive approximately 4-5 collisions depending on severity. Making things easier: Give the player more health so they survive more mistakes. Allow health to regenerate under certain conditions (such as at a check point or via pick up). Since TLC is all about earning and then maintaining speed, could allow player to "cash in" their top speed for a chunk of health. Turn off health entirely so player cannot fail by dying. Making things harder: No health. One hit kill. Death Mechanics Current Default: Once health reaches zero, player is dead and must start again from the beginning. Making things easier: Dying sends the player back to the last checkpoint instead of the start. Old fashioned "lives" mechanic where player gets multiple chances. As with health, dying could be disabled completely. Movement Speed / Level Design Current Default: Speed and level design are intrinsically linked with speed values currently set so that it is possible to make it around the main course more or less always at top speed, but with shortcuts presenting more challenge (narrower road width, more severe corners). All "main" route roads are navigable at top speed just by managing use of brakes. Shortcuts and alternative routes require more nuanced management of speed (for example setting the speed lower than the max available) Making things easier: Reduce speed values. Make roads wider. Make corners less sharp. Making things harder: Increase speed values. Make roads narrower. Unlike other elements, level design and speed feel like they cannot easily be changed in an options menu. You can imagine the player being able to toggle between some of the other difficulties listed but adjusting difficulty through the level design feels like it would be very challenging. Time Limit Current Default: One hour time limit on completing the whole game. I've made the decision that the game should be fairly easy to finish in the time limit, with the challenge being more about surviving all the way to the end. Still, I can see that a timer could be stressful for some players and that being able to disable it could make it feel easier for some. Making things easier: No time limit. Making things harder: Current plan is to give players a different ending depending on their completion time so in a way there is already build in difficulty to the time limit. Other random thoughts I've had a couple of thoughts about features that could make things easier that don't relate directly to game play but are more helpful information. World map: I've always planned to have a large map available in the menus to show the player the city and especially where they have been and where they haven't to assist in discovery of shortcuts. Demo mode: Watch the game play itself perfectly. So there are my thoughts on how the difficultly of Tokyo Light Cycle could be tweaked by the player to suit them.
  9. Glasshalfpool

    Help with 3d collision question

    I’ve done something similar recently creating a race track which was also just a giant snaking plane. I’d suggest you select the entire outer edge all the way around your plane and extrude it up so you have a wall around the whole thing. I would then use this wall as an invisible collider stopping the boat from leaving your lake.
  10. Glasshalfpool

    Time to Vote!

    Only comment is about your black outlines. You have the standing stones with strong black outlines around them and other scenery without any black outline. Depending on your goals for the art style I would suggest you pick one or the other and use it consistently. So attached is a version of your tent with a black outline to match the rocks. Agree that the middle one looks the best.
  11. Hi guys I'm working on a racing game and want a variety of buildings that make for interesting silhouettes and scenery. At the moment I'm mostly using Unity primitives and very rough building shapes and I'm stuggling to find an efficient approach to working out what placements make best use of the buildings and create the most interested silhouettes for the player. I've a master scene file in Blender where the track and complex beings are slowing being created and I'm placing cubes in Unity to block out a skyline but its a painfully slow process: Place block > Press play > drive a bit > no looks weird > Press stop > re-position block > Press play > drive a bit > Think it's too small > Press stop > Re-size block > press play... ...you get the idea Times that my 1,000+ and I think the sea will have swallowed us all long before I get all the buildings just in my demo level placed. Any suggestions for improving the efficiency of this process? Here's some gameplay for context:
  12. Hi there I'm working on a simple racing game at the moment that I like to pitch as Thumper vs. Burnout vs. Journey. In a nutshell it's a single player experience where the player races across a city in the dead of night with a time limit of one hour. The main mechanic being that driving well earns the ability to go faster, making things more challenging and opening up shortcuts and alternative routes, while mistakes (colliding with walls for example) make the player loses their highest speed and have to re-earn it. I have a grand vision for an a pounding, dynamic sound track with elements being added to the music as the player goes faster and I'm looking for someone to collaborate with on the audio effects. Here is a video of the early direction and feel of the project (it's moved on since, but this still gives a sense of the style): Contact me if you're interested in the opportunity to work on an interesting unique soundscape with me. Kind regards, Jamie
  13. Thank you so much to everyone who got in touch. I'm going to proceed with someone who contacted me from this forum.
  14. Hi there I'm working on a game where music is a key part of the experience and am looking for a collaborator. It's a driving game where the player must journey across a city at night to deliver a package in under an hour. It's essentially a time limited adventure taking place in a single night with short cuts, alternate paths and a story told through dialogue over the phone while the player is playing. It has elements that are most comparable to rhythm action games like Amplitude. The player begins at the slowest of four speeds and as they drive well they build a meter which once full, allows them to jump to the next speed. Doing so increases the colour and movement of the city and adds new layers and instruments to the soundtrack. I've struggled to find music that is along the lines of what I'm hoping to create. This track comes the closest to what is in my head: I'd be open to ideas you might have though. If you're interested in collaborating on the music and/or audio for a really unique title in progress I'd love to hear from you. Thanks, GHP
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!