Love this idea!
Jason Doucette
Recent community posts
I think you're using C#. Look into System.Globalization. Try using CultureInfo.InvariantCulture. Then try using TryParse on the data type you are reading into. I believe it should parse any global / culture format.
However, if you just changed all of your floats into integers (x100) then that also works, but you should then read them into integers -- this is so it fails when someone later adds a float to that text file by accident.
In other words, your code should fail at the location of the bug. Not in the middle of gameplay where anything may have caused the error. Fail fast. Then my report to you would be "here's the exception", which can be solved in seconds.
Nonetheless, good debugging!
I forgot to mention - the browser game worked exactly like the one I downloaded/recorded - it goes super fast, except it appears the car was mostly visible this time around, likely due to your camera changes.
Unity should be frame-rate independent if you are using the correct delta time. However, it does not explain the 100x speed up. I doubt my machine is 100x faster than yours.
> I guess as long as I have no 240 hz monitor, I have no clue what's the problem.
That's not correct. You can play your game on your machine at any frame rate. You don't have to v-sync to your monitor refresh rate. I mentioned earlier that you can shrink the screen to make it go 1000 fps probably.
While I know you don't have the data for which part of your code has the problem - that doesn't stop you from looking at all of your code. It's possible the delta time bug exists in all parts of your code anyway. So you should be able to debug from the code alone. Give it a shot! Debugging is what makes a great programmer! :)
It's not trivial to record and upload. If I play in the browser, my recording software doesn't work. So I have to download to do so.
I can tell you that the numbers on the screen that appear are all very large, some are negative. It's what you would expect them to be if the game made you travel 100x too fast through the level. So I don't think this will tell you anything more.
If you want accurate info, log out data to a log file. Can you grab logs from a Unity run game inside of the browser?
You should make your best effort to fix things before asking people to play. Try running the game at a higher framerate yourself. Run it in a tiny window so it runs super fast. You will have to get good at debugging, since it takes a lot of time for other people to help - which is something you should only rely on as an extreme last resort. For example, I already played through and sent feedback. Now, I'll play the game a 2nd time, not to enjoy it, but just to send more info on the exact same buggy code. My 3rd time playthrough may be bug free - but probably not, because your dev system cannot see the bugs, and you cannot find them yourself. You can see where this leads. Once you have feedback, do everything in your power to fix every issue -- your fans will be happy about this. Sorry that I cannot help more than this, but I hope this advice helps.
Wow... so I got my TI-99/4A when I was 7. Your analysis of SuperChase on the TI was almost identical to my own thoughts -- C.Regena produced such awesomely unique mazes that were perfect for this game... sometimes large connected areas joined only by a few threads, and just enough dead ends to keep things challenging. And while I had no idea the original used a in-memory queue, C.Regena's method for monster AI was phenomenal -- not only smelling your scent when you can use to trick it, but also that the monster leaves its own invisible scent to help avoid it from repeating the same paths it already travelling. So funny you mention spaghetti code, since if I recall correctly (I literally have a BASIC file of this stripped apart with analysis), the flag for when the monster is "mad" (FL) and leaving is own trails behind is so messed up that I couldn't determine the precise meaning of the variables (FL can be incremented from 0 to 1, but no further - thus there is code that is never run). This FL flag leaves a trail to avoid the monster from rerouting through parts it already visited, blocking its only exit from a dead-end. To fix, you need to acquire what was the original intent, and essentially re-write the code to fit the intent. I figured the intent was the monster leaves its own scent to avoid travelling a path it was already at, but not to be 100% restrictive, and also disallow repeated 180 degree turns. In any case, such cool, simple AI -- producing amazingly emergent behaviour -- which is how most complex systems arrive (complexity from simple rules). Love it!! p.s. I also noticed the LV level variable never increases!
Wow, just found out about this. I knew of the original from the TI-99/4A (note the punctuation!) version, which is the computer I grew up with. I always loved the game, but the code had a bug that caused the monster to get stuck. I analyzed it a few years ago, and re-wrote a SuperChase II in TI Extended BASIC -- though I don't have it released. It adds to the original clever monster AI that tracks you and its own paths (which is where the bug was), and adds more monsters. I've been thinking of doing a re-write in XNA/MonoGame, kind of like what you did here - pretending to be on the old original 8-bit machine! Though the TI-99/4A was actually 16-bit, crazy, huh? (EDIT: Oh wait - you actually did code it for the C-64? I can't believe any form of interpreted BASIC goes this fast - wow. Oh it's a compiled BASIC. Very cool!) Anyways, neat method to the madness of having the monster go faster then calm down (EDIT: I see this is a design from the original Atari version!), and having an exit you must reach rather than ending the level after an arbitrary number of pick ups. I'll have to check out the other 2 original versions to see what helped drive your inspiration.