# omnomnom

Members

2

118 Neutral

• Rank
Newbie

2. ## So I created a universe with 10,000,000 stars today...

that's a lot of stars! Even if the player can see a different 1/100,000th of the objects each second it would take them about 28 solid hours to see them all, so generating on the fly is probably a good move if only to prevent the generation of stuff some players will never see/visit. Have you thought about a brightness limit for rendering rather than a depth limit? Nearby planets and dim stars might be too small to be seen, but a really bright supernova you might be able to see from the other-side of the galaxy? If you use any kind of depth limit you end up drawing a lot of invisible objects, and not drawing a lot of very bright ones that should be visible. "That's a good idea, the only struggle will be correctly applying gravity to the offloaded chunks so they don't whizz off in weird directions." Could you get away with not simulating gravity between stars? I am not certain but I suspect the movement of distant stars relative to one another through gravity, given the sheer distance between them typically, is so slow that no-one will notice if they were fixed. I guess you'll have to test it once you increase the distances to see if having it on/off makes any noticable difference. Also here's an issue you might be aware of already but it's probably critical for what you are doing given the severely large distances you might work with: [url="http://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/"]http://randomascii.w...hat-in-a-float/[/url] If you scroll down there's a table that shows the precision drop-off when using a float to store distances in meters. It mentions that at 1 billion meters, 1.4x sun radius, you only have precision of 64 meters. So you can't increase the value of a float holding 1,000,000,000 by less than 64 meters, preventing you from perhaps accurately moving ships or slow objects. Could be catastrophic if you try to move something 20 meters in a frame and it doesn't move at all because it cannot be represented in floating point. Using double floating point would help, but it would only delay the problem to larger distances. If you plan to represent a real scale galaxy at something like meter precision for ship movement, then storing ship/planet positions in meters relative to an origin point could result in very strange bugs later. A solution would be to store positions relative to local points (eg relative to the nearest star), or relative to the nearest "gridpoint" or something to prevent storing coordinates so big they cause precision to drop too low.
3. ## And a video

" [left]when their centres are essentially 0 from each other the gravity pulls them at a ridiculous speed so they fling off in mad directions"[/left] [left]Yea I had that happening as well, I tried various hacks to fix it like bouncing colliding objects off each other,[/left] [left]capping max velocity and even adding a short-distance repulsion force, but none of it looked right. Finally I settled on a clumping behaviour where two colliding masses combined into a single larger mass, with momentum conserved.[/left] I guess the question is what would happen if a moon sized object slammed into a planet in real life? I guess a lot of it would "stick" together but there would be a lot of debris flying off in various directions. The problem I had was my low limit for particles I couldn't support lots of minor debris. In the "universe" I made I found [left]everything eventually either collapsed in on itself or expanded away to infinity. A bit like the universe I guess, except I never saw any cool structures like orbiting planets/stars/moon heirarchies emerge, let alone galaxies. I assumed that was because I was doing it in 2D, plus I didn't have enough particles. Either that or I disproved modern cosmology![/left]
4. ## And a video

nice, ive done something like this before but I didn't think of the critical step of subdividing the world like you've done, so I had every "star" gravity testing against all others with predictable performance results...oh and I was doing it in 2D - amazing how an extra dimension cuts down on all the pesky collisions.

7. ## Destructing spaceships

yes that's a lot more intuitive as it's like a skeletal structure and could probably be understood without displaying it. Perhaps there's a middle ground where instead of white arrows that are obviously an overlay there could be tubing on top of the ships hull that matches the skeleton but is part of the ship.
8. ## Destructing spaceships

[left]It looks good. I doubt I could make anything like that, so my criticism next is from a player point of view rather than a development one. [/left] [left]The ships [i]look [/i]like all neighbouring elements are connected to each other. The player cannot see how the connections are actually winding paths. This means from the player's point of view the breaking reactions to shots appear unintuitive. If I felt this was just my personal opinion I wouldn't say anything, but I suspect a lot of players will have the same opinion about it. [color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]I[/font][/color][font="helvetica, arial, verdana, tahoma, sans-serif"][color="#282828"]t isn't obvious why a single shot in one place will split the ship in half but a shot elsewhere has no effect. Perhaps you are planning something to alleviate that, although I doubt anything could.[/color][/font][/left] [left]You say you want the ships fragile which I understand, but cant you achieve the same effect by connecting all elements to their neighbours and allowing attacks to "chew through" the body until they cut through? The interior elements of a ship could be slightly or very explosive so once you've chewed through the hull layer you could "split" a ship in half really quick.[/left] Anyway that is supposed to be constructive criticism although I realize it is annoying in suggesting a system you've worked on for days is redone.

10. ## Learning something about game development

Thanks for all the help everyone, I will do things in an Agile fashion then. I have roughly designed the game plot, etc now, but you are all right I shouldn't go so far as some kind of waterfall model but implement pieces of the game at a time. I guess if I end up implementing a feature I end up removing later that's just part of the testing/learning. Also thanks about the 1024x768 recommendation. 800x600 people are probably the kind of people who can tolerate cramped screens anyway.
11. ## SimpleRTS Update #1

I'm going to make a game...<INSERTS CODE> but seriously an RTS is a nice idea. Now I wish I was making an RTS too. Maybe my next project (ie 2014). You going to make it singleplayer or multiplayer?
12. ## Spaceship pixel art, bullets & ship design

That's really cool, for some reason it reminds me of that youtube video of two cats fighting and then a dog runs in and breaks it up it also makes me wish I wasn't making a turn-based game...
13. ## It's been a while...

"I also discovered how addictive Minecraft can be." It can be dangerous stuff trying new games. I probably spent 1000 hours on minecraft in the last 2 years. No exaggeration (possibly an under-exageration). Multiplayer of course, singleplayer is only addictive for a week or two. Have stopped now though, not because I got bored, but because I wanted to work on more productive stuff (learning guitar, writing a game) Some people say they get bored in their spare time. Seriously? I wish I could have 100 lives lasting 1000s of years and run them all in parallel. In one I would be playing quake2 all day, in another I would be playing minecraft all day, in another guitar all day, in another I would do something "social", etc...the list goes on.
14. ## Minor update

"I've had a tough couple of days coding... It's just been one of those times were you run into a wall and get discouraged. Partly because of difficulties in keeping the code within their well-defined boundries and keeping them from becoming inter-dependant on one another when I don't have a clear plan for how things will be written. Class and function-level code design is easy, but overall arcitecture level is harder for me. I guess that's the important difference between a software arcitect and a code monkey. =D" Tell me about it. That's my exact problem too. I can waste hours, days, even weeks on architectural problems. The trick IMO is to not do that. So I allow the odd boundary violation rather than spend ages thinking on a possibly unobtainable architecture (not all problems have solutions). I am fine with an 80% perfect architecture. I might improve it later, I probably won't. I just find a way to live with it. In terms of justifications I tell myself it's good to be more relaxed if you are working on an internal project anyway, otherwise you are missing out on a very big advantage of not working in a team! In my opinion half the by-the-book stuff on code design is a waste of time for internal projects anyway. For example Notch recently said: "I still stubbornly believe the whole “private members accessed via accessors” thing in java is bullcrap for internal projects. It adds piles of useless boilerplate code for absolutely no gain when you can just right click a field and chose “add setter/getter” if you NEED an accessor in the future." [url="http://notch.tumblr.com/post/15782716917/coding-skill-and-the-decline-of-stagnation"]http://notch.tumblr.com/post/15782716917/coding-skill-and-the-decline-of-stagnation[/url] And he's right. So why am I still writing accessors? Ah....I dunno. I like them I guess. An exception to the exception to the rule. One rule I violate, although not architectural, is putting an underscore before every private member variable name. A year ago I was venomously opposed to doing that. Why? Because the C# guidelines said don't do it. But since then I've changed my mind (due to being forced to use underscore prefixes at work) because I find it very useful to be able to distinguish local variables in function bodies from private member variables.
15. ## Learning something about game development

Very unproductive week for the game but I think I have learned something about game development. I wasted it thinking about the UI. Why? The current UI is a mess. At 800x600 resolution with all the various windows open you can't see the dungeon: So I was trying to figure out how to reorder it all. What windows do I need? How do I divide it into different screens with shortcuts? Do I need a hotbar? If the user is in a shop does the floor need to be visible? Should the message log be minimal but expandable? etc. I kept hitting the same brick wall - I can't answer a lot of those questions until I know what game I am making. For example I was wondering how the user would put spells a hotbar, but that depends on, among other things, how many spells there will be. I haven't even worked out the spell system yet (or even decided if I will have spells!) So I have reached this conclusion: Design the game before making it Until now I have been trying to make an enginey kind of sandbox and worry about what game I am making later. I know I am making a rogue-like but what is the setting? (medieval? sci-fi? fantasy?). Does it have magic? What is the skill system? What is the XP system? What items will there be? What monsters will there be, etc. How does it all fit together? That's the key part: fitting it together. If I just implement things separately. they won't tie together. I mean that's how minecraft was done and while it's one of the best games ever I think a general weakness of singleplayer is that there was no focused game, just cool bits and pieces being added on in each update. Eg wolves, how do they really fit into the game? I don't expect to be able to design the game completely up front. There will be discovered problems and new ideas that will modify things, but even with a rough design it will be much easier to prioritize things, faster to develop and the game should be better at the end. I can also bounce the rough design off people who might turn round and say "no way that sounds boring!" and then I can go ahead and do it anyway in defiance. So next post will outline exactly what the game is, the setting, the ending, all of it. How do other people do all this? Do you already have a 90% complete game design written down?