|
So I got a question that I hope will set me off on the path to discovery. I've tried googling this a bit, but landing on the right keywords is proving to be a bit difficult. Short version: how do game developers typically store their world data in memory? Longer: I'm mostly interested in generating outdoor game worlds. From what I've been able to gather, terrain is typically stored as a heightmap, because games that let you import/export data typically do it with greyscale images. Are these games holding this data in memory as enormous 2d arrays, or do they actually load an image file and write methods for accessing (and manipulating) the data? Or some other more complex format? Do they bother with two copies of the data? Say, a high resolution one used for rendering, and a lower resolution one for managing player boundaries or other "game logic" tests? Probably my two favorite examples of what I'm trying to pull off might be Sim City 4, or Dwarf Fortress.
|
# ¿ Mar 15, 2012 20:39 |
|
|
# ¿ Apr 28, 2024 07:57 |
|
If you ever want to put cities or roads into those provinces, lsystems are a lot of fun. They're pretty good at making believable street grids.
|
# ¿ Apr 26, 2012 22:58 |
|
Pfhreak posted:I kind of have to this a little. The circumference of the globe is about 40K km, and the speed of light is about 300K km/s. So assuming a worst case distance (which is unlikely) of halfway around the world, a player with a game connection at the speed of light would only be experiencing input lag of ~120ms. Assuming a player is within 2000km of a server, a speed of light line would have 6ms lag time. Unfortunately the internet runs slightly slower than the speed of light. The bits may move at the speed of light, but there's a delay created when computers route those packets. It's been a long time since I've worked for a large network, but back in 1998 the best case (that is, an otherwise unused chunk 'o fiber that we were adding to the network) delay between our data center in NYC and one in San Francisco was 12ms. Straight line between the endpoints was ~2500 miles. I imagine in the intervening 14 years they've shaved some time off that but I would have doubts they've reached actual light speed.
|
# ¿ May 10, 2012 03:24 |
|
The past week or so I've found myself toying with game ideas in my head as I'm falling asleep at night, trying to come up with ones that I could reasonably implement in less than a month. And I don't even know the theme yet! vvv That game's been done already sorry. xzzy fucked around with this message at 16:25 on May 29, 2012 |
# ¿ May 29, 2012 16:08 |
|
xgalaxy posted:You have to be careful with this though. I like to champion Bungie in conversations like this. They've long stated that they primarily make games they want to play, and have risen to pretty great heights because of it. But if you pay attention to the changes between Halo games, you can also see they listen to feedback (as well as a ridiculous amount of stats recorded from online matches). Generally they get it right, they've had a few missteps but for the most part they seem to have maintained a good balance of listening and identifying. It wasn't like that with just Halo either. Myth played out fairly similarly, as did Marathon.
|
# ¿ May 30, 2012 19:41 |
|
Well The Doctor is an rear end in a top hat and I want a second opinion. I can wait until tomorrow.. barely
|
# ¿ May 31, 2012 22:18 |
|
WoW eventually eliminated percentage effects because it got so hard to balance. Their biggest issue was with people not discarding old gear because the percentage values scaled so dramatically when the level cap increased. But they also stated that percentage interactions were confusing players and they wanted to make it easier to understand. I'm sure they still design item stats on percentages, but when the stuff gets put into game it gets translated into a fixed value that add up with bonuses of similar type. It works well (or did once upon a time, I haven't played it in years) and I think is a valuable lesson: don't use percent based bonuses.
|
# ¿ Jun 28, 2012 17:12 |
|
Pfft, interpreted languages. By the time I'm 90 years old I suspect kids will program with voice commands. Except it won't be programming, it'll be "computer, make a program that illustrates the knight's tour" and the AI will run a google search, find whatever libraries or code is necessary, and execute it on the fly. It'll be like that chick on Bones who somehow manages to come up with elaborate mystery-solving algorithms during commercial breaks, but without the commercial breaks.
|
# ¿ Jul 4, 2012 22:56 |
|
Only optimize when you find performance problems. Programmers loooove to get hung up on writing perfect code, but it's pretty rare that they actually need to. Note that this doesn't justify writing terrible code. Your basic flow still needs to be well thought out or else you'll make refactoring a lot more difficult.
|
# ¿ Jul 9, 2012 20:51 |
|
As something else to consider, go look at TF2 threads whenever Valve puts out an update that breaks dx8 features. High-fps addicts go ballistic because to them dx8 is the promised land of efficiency. So I guess my point would be to either use the newest directx you can get your hands on, or pick a library that a 486 can run.
|
# ¿ Jul 19, 2012 15:58 |
|
This one.
|
# ¿ Aug 28, 2012 15:53 |
|
The linux "motion" software is capable of tracking a target, and I've seen it used to make an auto-aiming turret. That's going to get you into arduino and soldering iron territory however. I'm not sure it lets you identify individual subjects, much less identify them by their face. But it might be worth looking into if you're seeking options.
|
# ¿ Sep 12, 2012 17:44 |
|
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 |
|
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 |
|
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 |
|
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 |
|
Vinchenz posted:Anybody got any links to articles or examples of 2D terrain generation? I have some ideas on mind but my biggest problem that I can't get over is generating new terrain without making it seem like two different sections slapped together (say, walking in grassy fields and then it suddenly snowy tundras... which then suddenly become desert as you continue on). Pretty sure this was linked earlier in this thread: http://pcg.wikidot.com/pcg-algorithm:world-building It's at least a one place to start reading and figure out the terminology, which will help with google searches. I don't think I've ever seen a game that handled climate transitions smoothly, but mostly because game worlds are so tiny. Rapid transitions are a side effect of keeping the player interested in the world. But if you wanted to do it anyways, biomes and rain maps would be the hard way to do it, and low frequency perlin noise would be the easy way.
|
# ¿ Dec 5, 2012 16:51 |
|
crm posted:Are there any tutorials for Unity 4 yet? Those ones are close enough to be useful. They also have some here, but they're pretty light fare: http://video.unity3d.com/channel/1649856/tutorials
|
# ¿ Dec 13, 2012 23:12 |
|
I usually see stuff like that implemented as layers. Well really it's just tagging objects that you want to collide with the same id number, but it's usually described conceptually as layers. Objects in the same layer collide, and objects can be in multiple layers. Easy to implement because it only requires assigning an integer (or an array of integers) to your objects. The example you give only requires two: walls and braziers. Fireballs are only on the wall layer, the player is on the walls and brazier layer.
|
# ¿ Dec 19, 2012 16:48 |
|
I guess it depends on what you intend to do with your game. If you think you're going to need complex collision filters it makes more sense to use properties. But if all you need is for fireballs to not collide with braziers, a couple integers might be good enough. In my experience, "extensible" is a word that gets developers stuck in a sand trap. It's super tempting to make an awesome subsystem that can handle all possible permutations, but it generates the risk of you spending all your time making code rather than games. If you think you need properties don't let me stop you. I'm just babbling.
|
# ¿ Dec 19, 2012 17:05 |
|
"Tiled" is pretty popular because it outputs xml and there are libraries to load the files for basically every language on the planet.
|
# ¿ Dec 20, 2012 00:06 |
|
Isn't most of the really hardcore graphics stuff linear algebra and calculus anyways? That's the stuff that always made my eyes gloss over.
|
# ¿ Dec 21, 2012 04:49 |
|
I'd say just google game related topics that interest you.. there's no special magic to game structure, if you can handle an event loop and render sprites, you can make a game. If you pick a game engine to work with it's even easier because you can skip the event loop. The hard part comes from the other stuff a game needs.. play mechanics, AI, physics, polygons if you go 3D. I've never seen a book that tried to address all of that, which is why I think google is the best bet.
|
# ¿ Dec 26, 2012 18:12 |
|
Conversation caused some dark corner of my brain to conjure up memories of this book: http://www.amazon.com/Black-Art-Game-Programming-High-Speed/dp/1571690042 It's funny because it actually does try to be that one book that tells you everything you need to know to make a game.. and in general, fails at adequately describing much of anything. I got almost nothing out of it except a paperweight.. I bought on one of those "hey a book about games! I can do that!" whims and tried to read it, but really got nothing out of it. The interesting bit is that (as I remember it) it tries to build everything from scratch and covers DOS era design methods, which could be interesting from an archaeological perspective.. give some background on what life was like before we could download engines by the dozen and hardware accelerated graphics were a rarity.
|
# ¿ Dec 26, 2012 20:23 |
|
Source has the capacity to write mods too, but you're going to be stuck a fairly old code base.
|
# ¿ Jan 16, 2013 00:02 |
|
On the other hand, there's nothing wrong with aiming high. Just be aware that's what you're doing and that it's going to be a long, long climb. If you still want to keep that lofty goal, break it down into bite sized pieces. Like if you want your MMO to have real time combat, make a small single player game that implements the combat only. A procedural terrain system? Make a sandbox world generator. Then down the road you can repurpose that code into your grand design (or more likely, you'll rewrite it from scratch because you got smarter and found a better way to do things, but at least you'll know whether the idea works).
|
# ¿ Jan 17, 2013 17:44 |
|
Monochrome posted:Does anyone have experience with Pygame? I'm trying to build an Asteroids/Ikaruga prototype and learn Python at the same time and I'm wondering if this is a beginner-comprehensible library. Right now I'm having a go at something playable with Stencyl and try to translate that over to code. I made an SA GDC game with it a couple years ago.. it works well if you like python. Clean API, it's quite easy to get a game up and running and there's an enormous set of libraries you can drag in to make coding easier. The biggest problem is distribution, no user is going to want to install python to run a game, which means you have to look into the various py2exe type solutions, which works, but is a little cumbersome. Browser based games are not going to be an option.
|
# ¿ Jan 28, 2013 19:33 |
|
Every time I need to solve a math problem, it's off to a google search and hope I can find a code sample. I was convinced math was a stupid waste of time in high school, so put almost no effort into it. I think the number one use for a time machine would be going back and kicking some sense into my own rear end. Since I'm still a math idiot, obviously time machines will not be invented in my lifetime.
|
# ¿ Jan 31, 2013 17:11 |
|
Megadrive posted:That is really cool, I backed it. I remember wondering why someone hadn't done this already when I was watching animators animate 3D models a couple years ago. Synfig sort of falls into this category and has been around for a while: http://www.synfig.org/cms/ I tinkered with it for a bit, and found it to be absurdly slow even on decent hardware. Just based on the promo video Spine appears to blow it out of the water for game developers (Synfig is intended more for movie style animation, but you could easily export sprites for use in games). On the other hand, Synfig is free.
|
# ¿ Feb 6, 2013 02:50 |
|
Scaevolus posted:Most 2D games could be written in Python, but 3D usually requires better performance. Panda3D is surprisingly good though. The biggest failing of python is mobile or web distribution.. basically, it ain't happening.
|
# ¿ Feb 25, 2013 03:43 |
|
Unormal posted:Is there like a list of SA game-dev'ers twitter handles somewhere? There's a list in the making games megathread: http://forums.somethingawful.com/showthread.php?threadid=3506853
|
# ¿ Mar 29, 2013 02:39 |
|
I just wish 90% of Unity's documentation wasn't in a forum somewhere. answers.unity3d.com is one of my top visited sites lately.
|
# ¿ Apr 1, 2013 19:31 |
|
vim.
|
# ¿ Apr 4, 2013 22:48 |
|
SlightlyMadman posted:Ok, it seems like using Unity's built-in terrain will definitely work better for me than a grid of planes. I've even found a few blog posts and things by people that have done it, but most of it's old and I'm having trouble locating actual code snippets. It seems like I should be able to basically apply heights to individual points in the terrain map in code though? Yep, I just did this a couple days ago. The terrain class has a terrainData subclass with methods to accept a 2D array of floats to set heights for everything. You can set individual points as well. Only downside is it's a heightmap, so you can't do any overhangs or caves or anything.
|
# ¿ Apr 6, 2013 21:44 |
|
SlightlyMadman posted:Yeah, that sounds like exactly what I want to do! I'll start messing with a terrain generation script, but if you have any snippets you could share it would be a big help. code:
My terrain generation is basically a C# conversion of this: http://xzzy.org/sc/ (click the generate word) Which is a javascript implementation of the map generation code from the original simcity.
|
# ¿ Apr 6, 2013 22:08 |
|
SlightlyMadman posted:Now the hard part, I'm going to start with drawing roads. I've googled around a bit, and it sounds like I need to create a road mesh, and then break it into triangles and tile those triangles across the board? I get the feeling this is going to be tricky. I'm pretty sure we're working on the exact same game because guess what I've been researching the past few days? I haven't had time to dig in and check if it's actually usable, but my current plan is to look into the Unity 3 plugin "Road/Path Tool": http://www.sixtimesnothing.com/road-path-tool/ Mostly because it's proven to work in Unity, and they let you download source. It relies on what basically everyone else relies on for making roads, that being bezier curves. It also has some code for smoothing terrain around the roads which is also interesting.
|
# ¿ Apr 11, 2013 22:31 |
|
SuicideSnowman posted:What is everybody trying to make the next SimCity since EA failed at the latest attempt? Looks like! (my target is a little lower: I just want to re-implement the original SimCity in Unity, minus the tile based requirements)
|
# ¿ Apr 11, 2013 22:37 |
|
SlightlyMadman posted:Haha yeah I'm working on a cross between SC2000 and the Anno games. I actually came across that same tool yesterday, but it's only available for Unity 3, and I've been building everything so far in 4. Yeah but the code is really close, I suspect a lot of it can be C&P'd. The value to me is more that it's a working implementation, which makes it easy to learn from.
|
# ¿ Apr 11, 2013 23:43 |
|
SupSuper posted:I'm surprised nobody's taken advantage of the original SimCity code yet. I actually am.. though I've only gotten as far as implementing the random map generation code in Unity. The java port has very readable code.
|
# ¿ Apr 12, 2013 05:48 |
|
|
# ¿ Apr 28, 2024 07:57 |
|
If you google around, most people seem to suggest putting an empty in your game world and attaching a script to it, putting all your logic in the Update() function. This seems like bad design to me, but what do I know.
|
# ¿ Apr 12, 2013 16:27 |