Skip to main content
Code Review

Timeline for BigInteger formatting for endless tower defense game

Current License: CC BY-SA 3.0

19 events
when toggle format what by license comment
May 23, 2017 at 12:40 history edited Community Bot
replaced http://stackoverflow.com/ with https://stackoverflow.com/
Jun 22, 2016 at 15:22 comment added corsiKa @ThijsRiezebeek A double is too LOW for you? You're going to go up to 2^1000 power? You need to lower your scaler values. There are other ways to have infinite progression and still have low scalers. Off the top of my head, you can have healing towers which will give you another variable. But even at 2^1000 even if you double your values every level (which, let's be honest, what's the point that isn't progression) that's still over 900 levels. If players do 900 levels, worry about fixing it then, not now.
Jun 22, 2016 at 15:20 comment added corsiKa @pipe that's fine. That's why it's called "significant" digits. If a tower has 100000000000000000000000000000000 hit points, and I do exactly 1 damage to it, it effectively hasn't changed. This is totally fine.
Jun 22, 2016 at 15:01 comment added pipe @ThijsRiezebeek Hm, that's pretty high. A double can store values up to about 10^308. Not saying it's impossible to exceed that, but just want to remind you that it's a lot. Nevertheless, a BigNum is of course more future-proof here.
Jun 22, 2016 at 14:51 answer added Risky Martin timeline score: 2
Jun 22, 2016 at 8:31 comment added Thijs Riezebeek @pipe what you say is true, but I don't think that would be a problem. When damage and or money hit such high levels, the amount of money that is received on a kill will also be extremely high and probably near it. However I double doesn't have a high enough maximum for me.
Jun 22, 2016 at 1:44 comment added pipe @corsiKa doubles are notoriously bad when accumulating over long timespans. Taking your comment as an example, adding 1 to 100000000000000000000000000000000 would still return the same value, causing for example score accumulation to break down.
Jun 22, 2016 at 1:03 history tweeted twitter.com/StackCodeReview/status/745422026941341696
Jun 22, 2016 at 0:47 comment added corsiKa Have you considered whether or not you need the precision of big integer? I mean, does the game care if you do 100000000000000000000000000000000 and 100000000000000000000000000000001? Chances are you could use double for simplicity and have just as compelling game play. Usually games round it to 123k or 456m. Occassionally you see 4 digits of precision but after that, not so much.
Jun 21, 2016 at 18:01 comment added Pharap Instead of pointing out specific naming issues, I'm going to say here is the set of naming guidelines recommended by Micosoft/MSDN, and the majority of C# programmers follow them or some minor variation of them. Read it and practise following the guidelines. It can be painful using an unfamiliar style, but it's a necessary evil. (My fingers still physically resist when I have to follow a style using underscores, and I'm only just becoming accepting of camel casing method names)
Jun 21, 2016 at 15:06 answer added Neil timeline score: 0
Jun 21, 2016 at 13:31 comment added BCdotWEB @RJFalconer I quoted the "incorrect" code, didn't give corrected versions.
Jun 21, 2016 at 13:30 comment added RJFalconer @BCdotWEB I think your example is camelCase rather than PascalCase.
Jun 21, 2016 at 12:32 comment added Thijs Riezebeek Thanks you for the advice and the link. I was unaware of the specific C# standards.
Jun 21, 2016 at 10:47 comment added BCdotWEB Not enough meat for a review, so i'll just post them here: No need for shouting: PRECOMPUTE_FOUR_CHARACTERS. Also, method names should be Pascalcase: private static List<string> preComputeBase27Values().
Jun 21, 2016 at 10:41 answer added Heslacher timeline score: 13
Jun 21, 2016 at 10:32 history edited Jamal CC BY-SA 3.0
deleted 4 characters in body; edited title
Jun 21, 2016 at 10:20 answer added forsvarir timeline score: 6
Jun 21, 2016 at 9:49 history asked Thijs Riezebeek CC BY-SA 3.0
toggle format

AltStyle によって変換されたページ (->オリジナル) /