|
Beef posted:A good excuse for programmer art if I ever heard one. Programmers would still find a way to screw it up, give it a low resolution bump map or something. "What? 128x128 is plenty of pixels."
|
# ? Oct 30, 2012 17:08 |
|
|
# ? May 25, 2024 15:00 |
|
OneEightHundred posted:There is no air, lift, drag, or gravity, you have 6 DOF and can maintain a dead stop with no power, surely that means you can do more than strap a single thruster to the rear end-end and stick some useless fins out of the side!
|
# ? Oct 30, 2012 18:07 |
|
Doesn't excuse battleships that only have guns on the 'sides' and not the top or bottom.
|
# ? Oct 30, 2012 18:14 |
|
Shalinor posted:I kind of liked the Wing Commander explanation: "we designed the jets to mimic atmospheric flight, because the pilots couldn't handle it otherwise,"
|
# ? Oct 30, 2012 18:19 |
|
yaoi prophet posted:Doesn't excuse battleships that only have guns on the 'sides' and not the top or bottom. Ships in the Honor Harrington universe nicely explain this in by having some kind of impenetrable shields at the top and the bottom that acts as propulsion, forcing ships to broadside in engagements. In EVE Online, all shiels have a double the number of turrets for the amount of hardpoints. Each turret is placed on the ship model such that each 'gun' from a pair is certain to have line of sight to the target.
|
# ? Oct 30, 2012 18:29 |
|
I could park an x-wing off the bow of that thing and light you up for hours, and you'd never draw a bead on me EDIT: Wait, stern. The back part. Stupid nautical words. ... though I guess they probably explain that via shields, which prevent ships from closing to sufficient range as to make shots impossible. EDIT2: VV I think the gist of this conversation is that, yeah, I'd love a spaceship game that actually played with some of these questions, instead of cramming in story to explain why everything in space fights like battleships and propeller-driven aircraft. Though I'd also want the option to fly the big ships and focus more on trading, as per usual. Shalinor fucked around with this message at 19:03 on Oct 30, 2012 |
# ? Oct 30, 2012 18:32 |
|
Shalinor posted:I could park an x-wing off the bow of that thing and light you up for hours, and you'd never draw a bead on me a) I can see a turret at the stern. There's probably more than one. Edit: yep, look at tips of the "wings" b) Those side turrets look far enough apart that there isn't much of a blind spot. Anything that gets close enough to exploit it is asking for a face full of plasma from the engines. Blue Footed Booby fucked around with this message at 19:06 on Oct 30, 2012 |
# ? Oct 30, 2012 18:53 |
|
Shalinor posted:I could park an x-wing off the bow of that thing and light you up for hours, and you'd never draw a bead on me Although I also think that in EVE even the smallest craft is much much larger than an X-Wing, because small fighter-class aircraft make little sense in space.
|
# ? Oct 30, 2012 19:02 |
|
Above Our Own posted:Although I also think that in EVE even the smallest craft is much much larger than an X-Wing, because small fighter-class aircraft make little sense in space. If the big ships have gaping holes in their turret arcs, small craft make a lot of sense. Assuming you have an energy source and thrust that makes rapid course changes efficient. The Egosoft "X" games operate under this mechanic and it sure makes for a fun game. Light ships will get pasted if they get hit, but up until that point they own the vacuum because no one can touch them.
|
# ? Oct 30, 2012 19:07 |
|
xzzy posted:Programmers would still find a way to screw it up, give it a low resolution bump map or something.
|
# ? Oct 30, 2012 20:23 |
|
Shalinor posted:... instead, I would highly recommend building static singletons that bake out to PlayerPrefs on destruction, and reload from PlayerPrefs on load. All the convenience of a global always-there singleton, but they can actually respond to scene change events in a sane fashion via their usual Awake() method. If I combine your approach with something like this: code:
I can avoid even putting a manager object into every scene via the editor, but I still get to use Awake() and the like. Is there a reason this is a bad idea? I'm just making notes, I'm really not at a stage where I should be coding anything more elaborate than Pong clones. No idea what I'm doing here. Unity makes it so easy for people that have no business programming, like me, to get simple stuff up and running. Re: space. Thanks to spending too much time reading sites like Project Rho I think about realistic sci-fi games a disturbing amount. I still haven't come up with a way that'd make plausible space combat fun. In a general sense I'm imagining space Silent Hunter, which to the right kind of nerd (me) sounds really awesome. But when I get into imagining the details of such a game - or at least one that fits in with my conception of "plausible space combat" - it occurs to me that it probably wouldn't be much fun to play. I guess I'm going about this backward: I should come up with an idea for a game about orbiting crap and shooting lasers and then create a setting that fits the mechanics. I always thought the best design for an interplanetary spaceship was a blob on the end of big long stick, with your engine on the other end of said stick (think 2001). Since it's probably nuclear and pumping out fun radiation, you can minimise the size of the shielding by having it only partially cover the reactor and hide the important stuff in the 'shadow' (hence the big long stick). Bonus, it's something even a programmer could model! Plus when you add radiators into the equation it could look like a dragonfly
|
# ? Oct 30, 2012 20:46 |
|
Myopic posted:I always thought the best design for an interplanetary spaceship was a blob on the end of big long stick, with your engine on the other end of said stick (think 2001). Since it's probably nuclear and pumping out fun radiation, you can minimise the size of the shielding by having it only partially cover the reactor and hide the important stuff in the 'shadow' (hence the big long stick). Bonus, it's something even a programmer could model! Plus when you add radiators into the equation it could look like a dragonfly A dragonfly with a long body would probably be an annoying place to live and work, a long boring walk from the cockpit to the engine maintenance room.
|
# ? Oct 30, 2012 20:55 |
|
So no recommendations for 2D in Unity? 2D Toolkit and Futile are the ones I've found. Are there others worth investigating?
|
# ? Oct 30, 2012 20:59 |
|
roomforthetuna posted:From the point of view of "practical from the outside" that's good thinking, but for "practical from the inside" a ring is good, because you can just spin it to have artificial gravity for the people inside. A disc comprised of multiple rings is even better, because you can have variable artificial gravity - if you want a lot of gravity you go 'down' to the outer rings, if you want no gravity you go to the center. From the outside perspective this is horrible because steering a thing that's spinning would be a huge pain. It'd be a pain to do engine maintenance, for sure, but weight is everything. I imagine a hollow frame has a lot less mass than an engine sitting within the main body would (because of the aforementioned shielding issues). The crew better get used to EVA. When it comes to gravity, only the living quarters really need it (same goes for atmosphere). The rest of the time you'd just be strapped in wearing your space suit. The most interesting suggestion for providing artifical gravity that I've seen is to have set of arms with the quarters attached. When you're under acceleration, they're folded next to body, providing some gravity (and eliminating your steering problem). When you're cruising, they're unfolded and spinning, again providing gravity. Game Development Megathread: daydreaming about spaceship design
|
# ? Oct 30, 2012 21:10 |
|
And of course, for a space game context where the ships are almost certainly best designed around combat, both our ideas are stupid because a dragonfly has a huge profile to shoot at and a spinning disc is about as maneuverable as a falling turd. Which brings us back to the sphere!
|
# ? Oct 30, 2012 21:18 |
|
Pfhreak posted:So no recommendations for 2D in Unity? 2D Toolkit and Futile are the ones I've found. Are there others worth investigating? I've only been using Futile for a week or so -- I actually really like it, even if it's fairly lightweight and geared very much towards drawing 2D sprites onto the screen. I find it really familiar moving from an AS3 background because you do a lot of creating FSprites, adding FSprites to FContainers, etc. etc. It's completely code-based as far as I can tell. There's also not much support for collision detection outside of getting a sprite's bounding rectangle and comparing them, but if you're doing a 2D god game that might be less of a worry.
|
# ? Oct 30, 2012 21:41 |
|
roomforthetuna posted:And of course, for a space game context where the ships are almost certainly best designed around combat, both our ideas are stupid because a dragonfly has a huge profile to shoot at and a spinning disc is about as maneuverable as a falling turd. Which brings us back to the sphere! Only from the side of course. As far as radiators go, they'd be a massive liability in combat, but heat is going to be a limiting factor for any "realistic" design. Even the sphere will need them. I assume they'd be foldable and you'd keep them flush until you're in danger of cooking your crew alive (or another cool idea I read: they're thin pairs of booms that shoot droplets of liquid lithium/sodium from one side to the other). All of this ties into why I think a plausible space combat game would be more Silent Hunter, less Freespace. I have faith it could be made fun, but I'm at a loss as to how. There'd be a lot of waiting around. Certainly no dogfighting. Manoeuvres would be boring: just accelerate or decelerate, essentially. Repeat until you run out of fuel. Unless you go all super-duper future tech with ridiculous antimatter drives and poo poo, at which point you might as well just remake Freespace. Same poo poo with gunnery. Tell your targeting computer where to point the lasers, press button.
|
# ? Oct 30, 2012 21:43 |
|
Well it's not a space game, but since relativity as a game concept was being discussed earlier, here's one that's all about relativity. It's being developed as open source too, with a planned release of the source in Q1 2013. So that might be a very useful resource if you really want to play with the effects of relativity.
|
# ? Oct 30, 2012 21:46 |
|
Pfhreak posted:So no recommendations for 2D in Unity? 2D Toolkit and Futile are the ones I've found. Are there others worth investigating? I've been experimenting with the free version of Orthello and it works pretty well thus far, though it's been a bit wonky to use (mainly because I didn't really read the manual since I followed a guide and also probably because I'm still new to Unity) I wonder if Futile will work well for what I'm making in Unity, I might switch to that.
|
# ? Oct 30, 2012 21:58 |
|
Shalinor posted:Just be sure you prefab them out. What does this mean?
|
# ? Oct 30, 2012 22:21 |
|
Pfhreak posted:So no recommendations for 2D in Unity? 2D Toolkit and Futile are the ones I've found. Are there others worth investigating? I use ex2D, and I like it. It's very simple and easy to drive entirely with code, if that's what you're looking for. It's also open source, which makes it easy to figure out what it's doing when it's being dumb. https://github.com/jwu/ex2D_Runtime
|
# ? Oct 30, 2012 22:28 |
|
Myopic posted:If I combine your approach with something like this: What you want to do is use Awake() as a purely internal-to-component setup pass, and only call into other objects - even Singletons - within Start(). This guarantees that everything has the state you expect before you call into it. Given your above approach, you obviously couldn't do that.
|
# ? Oct 30, 2012 23:11 |
|
Alright I've always wanted to play around with 3d stuff and I've finally given it a shot using C# and OpenTK. I'm working on wrapping my head around the way a "camera" and the coordinate systems work in 3d.code:
1) The use of the sine and cosine functions means that the Vector3 class uses radians, correct? 2) So why don't I get a top down or bottom up view?
|
# ? Oct 31, 2012 01:02 |
|
Tres Burritos posted:1) The use of the sine and cosine functions means that the Vector3 class uses radians, correct? Radians are a measure of angle. The Vector doesn't really have any units attached. Usually, it's some form of spatial measure, like distance or location. The Math.Cos and Math.Sin functions take radians as their input, though, yes.
|
# ? Oct 31, 2012 01:15 |
|
The Cheshire Cat posted:Well it's not a space game, but since relativity as a game concept was being discussed earlier, here's one that's all about relativity. Holy poo poo. 6 minute acid flashback. I'm really glad I don't have photosensitive epilepsy right now. Awesome concept though. Not exactly the most exciting game in the world but hey. The way the MIT people were talking in the video, I figured they'd written their own engine, but it's actually Unity. I wonder how much is just crazy shaders. That makes perfect sense now that you say it, but it wouldn't have occurred to me in a million years. Thanks.
|
# ? Oct 31, 2012 01:35 |
|
Shalinor posted:If you do that, you're (in effect) encapsulating the singleton in question's Awake() method within whatever first calls to it. You have no idea what that will be (literally - Unity's execution order for Awake()'s on an object can shift each time you save a scene), and it could result in some pretty nasty situations. You can't have any global cross-scene gameobjects this way, but since gameobjects are generally supposed to be wiped between scenes anyway it would be kind of silly to do so! If I want a thing to have a quick reference to global-like gameobjects I generally have them do a 'find' of some sort during their 'start' function, and store their own reference, rather than using a global for it. I just don't see a lot of need to transfer between scenes the sort of data that isn't suited to being a static (such as references to objects that get deleted).
|
# ? Oct 31, 2012 01:54 |
|
Shalinor posted:I would argue that you do not want GameObjects to persist across scene loads. In practice, it is almost impossible to get such an object to respond to a scene load, which means if it was tracking ANYTHING in-scene, you've now got a lot of pointers in a very weird stare. They don't even invalidate immediately - there's seemingly a window before it realizes the GameObject pointer it had is now bad. So I'm not quite sure I understand how this works. I've seen multiple people suggest having a singleton class that is derived from MonoBehavior and attached to a gameobject, which doesn't make a lot of since since my understanding is that Unity will instantiate that class as part of constructing the game object, and that will be a different instance than the singleton instance constructed within getInstance(). Does Unity have some sort of special case handling for classes with a static getInstance() method, or are these suggestions just insane?
|
# ? Oct 31, 2012 03:24 |
|
Paniolo posted:So I'm not quite sure I understand how this works. I've seen multiple people suggest having a singleton class that is derived from MonoBehavior and attached to a gameobject, which doesn't make a lot of since since my understanding is that Unity will instantiate that class as part of constructing the game object, and that will be a different instance than the singleton instance constructed within getInstance(). Does Unity have some sort of special case handling for classes with a static getInstance() method, or are these suggestions just insane? void Awake() { singleton = this; } ... and if you want to idiot check yourself, check the value on singleton first, and pitch a fit if it's non-null. EDIT: VV No. By definition, a prefab must have existed in the scene first, which means it must have been a GameObject. You can create entities that exist outside of scenes and GameObjects (ScriptedObject? Something like that), but they very specifically don't scene, prefab, or any of that. Shalinor fucked around with this message at 15:01 on Oct 31, 2012 |
# ? Oct 31, 2012 05:13 |
|
Alright, that pattern makes much more sense than some of the other suggestions I've seen. So you attach that script to a prefab, allowing you to edit its data using the inspector, and then drop an instance of that prefab into every scene. Follow up question - does Unity have any sort of ability to make something like a prefab out of a set of components without it being a game object? The goal being that at runtime you can add pre-configured components to objects, without having to set up the property values in script. Or perhaps there's a "add all of the components from that prefab to this object" function?
|
# ? Oct 31, 2012 05:35 |
|
Pfhreak posted:So no recommendations for 2D in Unity? 2D Toolkit and Futile are the ones I've found. Are there others worth investigating? It costs a few bucks, and there are a handful of decent newer systems out there now, but I've been using http://www.anbsoft.com/middleware/sm2/ for awhile. It's a pretty solid and well put together library.
|
# ? Nov 1, 2012 08:05 |
|
Im going through the pyglet tutorial and I've been defeated by the simplest of tasks. Im trying to display a jpg I made in paint using the pyglet tutorial code:code:
|
# ? Nov 3, 2012 02:50 |
|
It should be the directory you're sitting in when you run the script. You can add search directories by setting the 'path' variable if that's not convenient for you: http://www.pyglet.org/doc/api/pyglet.resource-module.html
|
# ? Nov 3, 2012 02:57 |
|
Not really gamedev related but just got back from Wreck-It Ralph and it was really good. Can't beleive they got video game characters from real games in it. Didn't expect that.
|
# ? Nov 3, 2012 03:02 |
|
xzzy posted:It should be the directory you're sitting in when you run the script.
|
# ? Nov 3, 2012 03:03 |
|
That link I gave claims the default path is '.'. I haven't used it in ages though so I have no idea if that information is accurate.
|
# ? Nov 3, 2012 03:05 |
|
A quick google shows at least one old version had the default value broken, so that's probably what I was using.
|
# ? Nov 3, 2012 03:09 |
|
xzzy posted:It should be the directory you're sitting in when you run the script. I figured out that the error wasn't on my python code's end but somehow on paints end; the file it makes must not be compatible somehow because when I test my code using the kitten.jpg file that comes with pyglet renamed to trash.jpg the code works fine. Thanks for the help xzzy and The Gripper. Rob Filter fucked around with this message at 04:01 on Nov 3, 2012 |
# ? Nov 3, 2012 03:56 |
|
I'm sure this has been asked and answered a dozen times, but I skimmed the last ~20 or so pages I didn't see anything relevant. All my previous game development has been either Windows-only (plus Windows Mobile/Xbox, which are basically Windows at their core) so almost all of what I know is deeply rooted in Managed DirectX and related frameworks, and my code isn't particularly portable because of it. I'm looking to switch to OpenGL or at least dip my feet in the water, but can't find any resources modern enough to commit to reading. I know the fixed function pipeline is deprecated as of 3.3 or thereabouts, and is unavailable in OGL ES 2.0, yet most of the suggested reading material from people saying "OpenGL hasn't changed since 2.1, retard!!!!" (every stackoverflow thread) is strongly based on it, to the point where it's hard to pick out what is required as part of the fixed function pipeline and what is considered more general opengl use. Given all that, is there any particular resource for documentation that isn't just going to require going through each previous OGL version, or is that a necessity? Popular opinion seems to be "for every version of OpenGL after 2.1 you need to know the fundamentals of the previous version, so we're not going to bother explaining anything". Browsing through GLSL examples looks useful enough for filtering out ffp-based resources, but honestly I just need a push in the right direction to make sure I don't get too deep into obsoleted tech. I suppose just outright knowing what features/techniques to avoid because they're obsoleted/superseded would be enough to get me on track.
|
# ? Nov 3, 2012 09:43 |
|
The Gripper posted:I'm sure this has been asked and answered a dozen times, but I skimmed the last ~20 or so pages I didn't see anything relevant. I see this below guide recommended fairly often: http://www.arcsynthesis.org/gltut/
|
# ? Nov 3, 2012 14:12 |
|
|
# ? May 25, 2024 15:00 |
|
Thanks, I must have stumbled across that one a while ago and not bookmarked it, there's a few visited links there! Also noticed that there's a PDF of that guide to throw on my ipad as well, so it seems like a perfect fit.
|
# ? Nov 3, 2012 14:42 |