|
Pollyanna posted:I'm looking to do something new for my next app, and I want to try learning web game development. Is there a recommended beginner framework, or a well-liked tutorial website? what are your language preferences?
|
# ? Mar 9, 2014 18:04 |
|
|
# ? May 25, 2024 15:08 |
|
https://www.youtube.com/watch?v=_Vr9hRgWeNI. Does that pass for lightning, on the right? Trying to work on the first boss like fight. The robot dude will have a handful of balls that rotate around him, and will toss them above the level in various patterns, shooting down lightning bolts that you have to stand between to not get hit. Then he gets tired, and will drop them, and you can bust them up. It's literally like a 4x4 white box sprite that alternates from it's base position randomly slightly. Is there a better way to do that programmatically? Edit: Shalinor posted:Sure, that reads perfectly. If you want it to read better as a danger, you might just change it to a blue (common "energy" color) or red (common "threat" color). Edit: Woo-hoo. Progress. More or less the first attack mode done. Planning on having maybe 3 patterns for this boss. I think this is gonna work. https://www.youtube.com/watch?v=GjhRkBUvv0Y I'll try switching the color to red instead of blue, you're probably right on that. And I'll need to ray cast down and not spawn the lightning past ground. I might try the physics joints idea, haven't thought of that, but this seems to look OK now that it's a bit more put together. SSH IT ZOMBIE fucked around with this message at 06:44 on Mar 10, 2014 |
# ? Mar 9, 2014 21:15 |
|
duck monster posted:what are your language preferences? Well, I doubt I have much experience with the languages that are typically used...I'm most familiar with Python (which I doubt is used much in HTML5 games), but I can get around in Java and Javascript well enough. TypeScript looks interesting too. Are there other languages that are used?
|
# ? Mar 9, 2014 23:01 |
|
I'm still having the damnedest time working out class communication for an RPG type game. I can code each piece individually, but can't figure out an elegant way to tie it all together, unless a complicated web of bubbling events and references is just how it's done. For example, I have the COMBAT, INVENTORY, and PLAYER classes. The COMBAT object has a reference to the main PLAYER object where the player's attributes are held so it can work out the damage formulas. The COMBAT object also has a reference to the INVENTORY object so it can add loot. Then I think, "Well why doesn't everything have a reference to everything else to make it easy?" but that's like the opposite of encapsulation and bad right? Should I instead have some kind of master GAME class that calls the other classes, so the other classes don't need to communicate with each other directly? I can't wrap my head around how to distribute my code among classes and how they should work together. Any pointers in the right direction would be greatly appreciated. Sorry for the noob programming vocabulary.
|
# ? Mar 9, 2014 23:02 |
|
You might consider making a global game data class that other classes can interact with to fetch and store the data they need. Added bonuses is that only one class will need to be able to interact with whatever your storage mechanism is.. a database, a file on disk, whatever. This makes saving and restoring easier and means if you change storage systems you don't have to chase down code in your combat class to allow it to handle the new situation.
|
# ? Mar 9, 2014 23:07 |
|
Baldbeard posted:I'm still having the damnedest time working out class communication for an RPG type game. I can code each piece individually, but can't figure out an elegant way to tie it all together, unless a complicated web of bubbling events and references is just how it's done. For example, I have the COMBAT, INVENTORY, and PLAYER classes. The COMBAT object has a reference to the main PLAYER object where the player's attributes are held so it can work out the damage formulas. The COMBAT object also has a reference to the INVENTORY object so it can add loot. Then I think, "Well why doesn't everything have a reference to everything else to make it easy?" but that's like the opposite of encapsulation and bad right? I think one of the first lessons you learn as a programmer in the real world is that what's pretty doesn't always work, and what works isn't already pretty. Passing references to everything is annoying (maybe you could get away with some singletons in some places), but it's more what you do with those references that matters. If the classes are only using their references to ask the reference about stuff (ex, COMBAT asks PLAYER, what's your strength) or ask them to do things (ex PLAYER asks INVENTORY, add this item please?), then you're okay. What you don't want is stuff like PLAYER adding items to the INVENTORY directly. That's the essence of encapsulation: one thing needs another thing to do something, but doesn't care how that other thing does it as long as it respects the interface.
|
# ? Mar 9, 2014 23:11 |
|
Baldbeard posted:I'm still having the damnedest time working out class communication for an RPG type game. I can code each piece individually, but can't figure out an elegant way to tie it all together, unless a complicated web of bubbling events and references is just how it's done. For example, I have the COMBAT, INVENTORY, and PLAYER classes. The COMBAT object has a reference to the main PLAYER object where the player's attributes are held so it can work out the damage formulas. The COMBAT object also has a reference to the INVENTORY object so it can add loot. Then I think, "Well why doesn't everything have a reference to everything else to make it easy?" but that's like the opposite of encapsulation and bad right? Ultimately, you are going to be dealing with entities and events that relate those entities to one-another. Whether you want to do a very generic components & event handlers sort of setup, or keep your game objects very hard-coded in inheritance hierarchies with functions like "TakeDamage( DamageType )", or something in between, when it comes down to it you're ultimately going to have entities, and those entities are going to be relating to each other via events, and you're going to have some manager/controller pulling the strings that generates and propagate those events; how you end up abstracting and implementing your specific system depends very much on your requirements. Unormal fucked around with this message at 23:19 on Mar 9, 2014 |
# ? Mar 9, 2014 23:16 |
|
dupersaurus posted:I think one of the first lessons you learn as a programmer in the real world is that what's pretty doesn't always work, and what works isn't already pretty. Passing references to everything is annoying (maybe you could get away with some singletons in some places), but it's more what you do with those references that matters. If the classes are only using their references to ask the reference about stuff (ex, COMBAT asks PLAYER, what's your strength) or ask them to do things (ex PLAYER asks INVENTORY, add this item please?), then you're okay. What you don't want is stuff like PLAYER adding items to the INVENTORY directly. That's the essence of encapsulation: one thing needs another thing to do something, but doesn't care how that other thing does it as long as it respects the interface. That's a good example. Let's say I want to have loot added when the player defeats a monster. So ideally in BATTLE I could have a line like Inventory.addItem(feather);. But then BATTLE would need to know about my Item class to pass a reference of the feather object to INVENTORY. Or should I just have BATTLE send a string, like Inventory.addItem("feather");, and let INVENTORY figure out what to do with "feather"? I probably explained that poorly, but do you see where I'm at? Baldbeard fucked around with this message at 23:28 on Mar 9, 2014 |
# ? Mar 9, 2014 23:26 |
|
Your player has an inventory. Store the inventory as a field in the player object, then just pass the player object to your battle object (preferably via a Battleable interface or something) Also COMBAT doesn't sound like an object, it sounds like a behaviour. Either turn it into a static class and shift all the state into the participating objects, or rename it to something object-y like ENCOUNTER. coffeetable fucked around with this message at 23:33 on Mar 9, 2014 |
# ? Mar 9, 2014 23:29 |
|
Baldbeard posted:That's a good example. Let's say I want to have loot added when the player defeats a monster. So ideally in BATTLE I could have a line like Inventory.addItem(feather);. Presumably the feather has a unique id that the BATTLE can send to INVENTORY (and it should). So BATTLE and INVENTORY
|
# ? Mar 9, 2014 23:32 |
|
dupersaurus posted:Presumably the feather has a unique id that the BATTLE can send to INVENTORY (and it should). So BATTLE and INVENTORY And this unique id could be anything right? Preferably something simple like a string or number?
|
# ? Mar 9, 2014 23:34 |
|
Pollyanna posted:Well, I doubt I have much experience with the languages that are typically used...I'm most familiar with Python (which I doubt is used much in HTML5 games), but I can get around in Java and Javascript well enough. TypeScript looks interesting too. Are there other languages that are used? Cocos2dx-html is really neat , in my book, because the javascript binding is apparently 100% compatible with the js bindings for the cocos2dx C++ engine. Which gives you IOS, Android, Mac, PC and lunix as a freebie ontop of web. Its a more complicated engine than some ,but its used in plenty of commercial 2d games and has Zynga behind it, if that means anything. edit: Probably best not to use 3.0 versions yet, as its got a *completely* refactored API and as yet theres no real documentation or tutorials for it. The 2.x branch however is very well documented and loads of tutorials. duck monster fucked around with this message at 23:38 on Mar 9, 2014 |
# ? Mar 9, 2014 23:34 |
|
Baldbeard posted:And this unique id could be anything right? Preferably something simple like a string or number? Yup. All it is is some reference in your handy item database for INVENTORY to check out. If you're doing everything by hand then user-generated strings are more accessible, although you have to be careful about duplication. If you've got a tool doing it then you can let the database generate unique numbers and such.
|
# ? Mar 9, 2014 23:36 |
|
dupersaurus posted:Yup. All it is is some reference in your handy item database for INVENTORY to check out. If you're doing everything by hand then user-generated strings are more accessible, although you have to be careful about duplication. If you've got a tool doing it then you can let the database generate unique numbers and such. Thanks, that makes sense. I think a mistake I'm making is storing data in the same classes that are part of the UI -- because it is so easy to do in Flash/Actionscript. For example, the class that displays the player's inventory to the user, also holds the actual data for items. So if another class needs access to item data, it needs a reference to the whole drat inventory management system or do some inventoryManager.inventory.item.etc..... bullshit to access something. I guess keeping classes that hold data, classes that do stuff with data, and classes that display results to the user separate is way smarter.
|
# ? Mar 9, 2014 23:45 |
|
Baldbeard posted:Thanks, that makes sense. I think a mistake I'm making is storing data in the same classes that are part of the UI -- because it is so easy to do in Flash/Actionscript. For example, the class that displays the player's inventory to the user, also holds the actual data for items. So if another class needs access to item data, it needs a reference to the whole drat inventory management system or do some inventoryManager.inventory.item.etc..... bullshit to access something. Yeah. Speaking as a professional UI programmer, interfaces should be as dumb as possible. Making the interface control things beyond the UI beyond "user clicked a button" is asking for trouble. Your inventory flow should probably work something like this: * File in whatever format that stores item properties. * Inventory reads file to populate item object instances (Whether you read and cache it on launch, or as-needed depends on how big the file is, how often you need to reference it, and how much of it you need at once). * UI asks inventory about items, and inventory gives UI the list
|
# ? Mar 9, 2014 23:56 |
|
xzzy posted:You might consider making a global game data class that other classes can interact with to fetch and store the data they need. I just like using a singleton that has a dictionary\hashtable\map\whatever depending on what language you're using. That singleton has a setFlag(String,String) function and an addFlagListener(GameFlagListener listener). I use the Observable\Observer pattern and a GameFlagListener interface. So, if a game object cares about stuff going on, any game object can set a flag, and any game object can register itself as a listener if it implements the interface.
|
# ? Mar 10, 2014 00:09 |
|
SSH IT ZOMBIE posted:https://www.youtube.com/watch?v=_Vr9hRgWeNI. The "right" way is to have a string of line segments jointed by points, and randomly jerk each of the points back and forth (continuously, not like popping from one side to the other, but still making them move pretty fast). But I think your way probably fits your aesthetic better.
|
# ? Mar 10, 2014 00:51 |
|
poemdexter posted:Commit always and often. Also, I always tap CTRL-S between hitting play for just this reason. On my mac i always have a finger hovering over command so I can just regularly mash command-s. Like every couple of lines unconsciously and habitually. At work I also had a little script that committed to a secondary repository on a network drive every 15 minutes juuuust in case I managed to do something dramatic.
|
# ? Mar 10, 2014 04:53 |
|
The s-key on my work computer first wore away the letter and now there's a little divot forming in the plastic. Gotta save that poo poo.
|
# ? Mar 10, 2014 04:57 |
|
I'm only focusing on making my racing game local-player for the moment, but are there any architectural approaches I might want to keep in mind and adopt that might make my life easier if/when I do try networking?
|
# ? Mar 11, 2014 03:46 |
|
I've only done network programming for basically 2d zelda-like clone that I never finished. No physics or anything funky. I'd say it's something kinda hard to add after the fact. Like, I don't know. Take a control mechanism. You might have a game controller input class to manage keyboard or game input. Well, for a 2d game, ultimately you might do something like if (right) x = x + (deltaTime * objectSpeed) Are you controlling your computer controlled opponents in a similar fashion and actually basing the car object around that logic? That might completely break down when you go to add networking capability to the game. You'd be limited to dead reckoning for net code, which may or may not work well with your game. What about obstacles on a racetrack? You'll have to have some way to have the server control weather or not an obstacle was hit. You might be able to continue processing it locally for the local client, but you don't want to apply obstacle effects on opponents, you can't guarantee that your positioning on your client will be accurate. Does that even make sense? I guess, IMO, control as much of your game state as you can in a central manner, so it's easier to plug net code in later on. Just be prepared you'll probably have to refractor the hell out of your code when you go to add net play. Hopefully this isn't bullshit advice. I have an easier question Unity, if I want to "flip" a sprite, is it best to set transform.scale = new Vector3(-1,1,1), or transform.rotation = new Vector3(-180,0,0) ? The latter will make transform.right actually be correct. Are there downsides? I did something kind of dumb, learning unity tutorials showed transform.scale on the X axis used to flip a sprite. Later on, as my project grew, I wanted to use .rotation for the Y axis. So I need to pick one way to flip a sprite and be consistent with it, it's important because in my game you can be upside down and be able to jump and jump through platforms, etc, so I need to change my ray casting code appropriately. Is there a "right" or "best" way to do it?
|
# ? Mar 11, 2014 06:44 |
|
I've made a load of progress on my current project that implements Theseus and Minotaur by Robert Abbot. (Warning: Website has an old Java applet that implements the game/logic maze.) I wrote it from the ground up in C++. It uses OpenGL 2.0 (limitation of my laptop) for graphics and GLFW for window management and input handling. My first question maybe silly, but what constitutes "feature complete?" Tomorrow I should have a full implementation of the minotaur class, followed by implementations that require the minotaur (handling the minotaur's turns, it's victory conditions, etc.). If the game can do all it needs to and my focus will shift to polishing and implementing more UI, can I call it feature complete? My second question links back with the encapsulation discussion, is it bad design for my minotaur to both know where it is in game space and be able to draw itself to unit space (i.e. a 1.0f grid)? I have a GameRules class that checks for legal moves and a Display class that sets up a simple transformation matrix. This is my first rodeo with model-control-view, and I feel like I've missed the mark on some small aspects of it.
|
# ? Mar 11, 2014 07:37 |
|
dupersaurus posted:I'm only focusing on making my racing game local-player for the moment, but are there any architectural approaches I might want to keep in mind and adopt that might make my life easier if/when I do try networking? Personally, I think the main architectural thing that makes things drastically easier is use state as much as possible and avoid using events for things that affect the world in any persistent way. Relay the way things are rather than the way they've changed and make it as easy as possible to put things in a particular state, because the relative timing between events can get really messed up in multiplayer, but if a client can always easily show the world in a target state, then it's easy to make things sane again. The hardest thing to network are the things being controlled by the player, because if you want things to be responsive, you have to show them doing things that the server might not allow, and fix them when the client is wrong, even though the client has already sent more commands to the server between the time it made a mistake and got corrected. There are two main ways of doing this: Either let the two disagree and try to smooth out the disagreement on the server, or store a backlog of commands that you're sending to the server and replay the unconfirmed ones when the server sends a confirmation with your actual state at the time of confirmation. I tend to prefer the second way because it is much more predictable and stable, but it's not always viable (i.e. it depends on being able to replay commands for just you, and if you're doing a 3D racer with a physics middleware that only supports advancing the entire world, then it probably won't work).
|
# ? Mar 11, 2014 08:44 |
|
Reading over the terraria network protocol is a pretty good read to see if it makes networking "click" for you. You can see that they have a server and a client, and the server sends messages to the client when important things happen that the client has to know about, and vice versa. For example $1A, the Damage Player message. It sends the info for the hit direction and damage so it knows what way to knock the player. If the client sends that message to the server, the server simulates the damage and knockback, and sends the message to anyone in view. If the server sends a client that message, they can see that player getting knocked back. So a client sends the "hit a player" message, server simulates it, and server propagates that message to everyone to simulate the event locally. You just make your game run with a bunch of special messages like this, and sync things every few seconds by sending messages containing exact positions and stuff like that. The biggest benefit to keeping with a server<->client model is that you can just run the server locally to run singleplayer, and if you change something you don't need to update multiplayer and singleplayer code, it automatically works online too.
|
# ? Mar 11, 2014 08:52 |
|
BirdOfPlay posted:what constitutes "feature complete?" It probably depends on whether you consider UI a feature or content/polish. The main benefit of calling "feature complete" is that you shift your coding priorities from adding features to finishing them (polish and bugfixing). BirdOfPlay posted:is it bad design for my minotaur to both know where it is in game space and be able to draw itself to unit space (i.e. a 1.0f grid)? I would guess most game programmers would say it's overengineering to not allow a game object to draw itself. Most of the "drawing" code will end up being high-level graphics calls anyway (load this sprite/model, play this animation and put it at this po.sition). I'd normally only separate out the view when it becomes too unwieldy not to. Flownerous fucked around with this message at 09:08 on Mar 11, 2014 |
# ? Mar 11, 2014 08:58 |
|
OneEightHundred posted:Networking is something that's hard to add later. Real-time games with responsive controls usually use a client-server model because peer-to-peer has mandatory input latency, and the main idea behind that is that the server controls the world state and everyone else is looking at what is at best an approximation of that. The critical thing when doing that is to avoid doing things on a client that are distractingly different from the server's version of reality, especially things that can't be undone. If you have a racing game where cars can crash and explode, for example, clients should never be showing cars exploding unless the server says they blew up. Clients shouldn't be deciding who won the race either. Well, peer-to-peer also has the trust problem where a peer could be cheating and every client has to triple-check with every other client with Byzantine fault tolerance and now you've become MongoDB and IT'S NOT FUN. Don't do that. Real-world games often cheat. A lot. For unimportant physics entities, like cones on the racetrack that will get knocked around but won't slow you down, they can be simulated on the client, because they aren't doing anything that would change the server. Even a game like TF2 doesn't sync physics entities across the server, because the bandwidth is better spent on players and their interactions — they just don't put many physics entities in the maps, really.
|
# ? Mar 11, 2014 14:55 |
|
Yeah I was wondering if I should implement the a client/server setup right off the bat. And I was assuming I'd do my own collision calculations, rather than trying to stream built-in physics. How's Unity's networking system? Are there any 3rd party systems (I see the NGUI guys have one) that work better?
|
# ? Mar 11, 2014 15:48 |
|
Pollyanna posted:I'm looking to do something new for my next app, and I want to try learning web game development. Is there a recommended beginner framework, or a well-liked tutorial website? Try ActionScript3/Flixel, it's pretty simple to get up and running, and you can do a lot with it. There's a nice tutorial here.
|
# ? Mar 11, 2014 16:06 |
|
dupersaurus posted:Yeah I was wondering if I should implement the a client/server setup right off the bat. And I was assuming I'd do my own collision calculations, rather than trying to stream built-in physics. If you understand unity's entity/component model and basic networking, you're fine. I did kids bop in 11 days last summer with base networking. Photon sits on top of unity's networking and is much faster to get implemented in my opinion. I did horse wizard online as a proof of concept in a weekend.
|
# ? Mar 11, 2014 21:31 |
|
dupersaurus posted:Yeah I was wondering if I should implement the a client/server setup right off the bat. And I was assuming I'd do my own collision calculations, rather than trying to stream built-in physics. I looked at photon and unity park suite (uLink) and ended up deciding on the latter. I was able to set up an authoritative server with the server handling all the physics on objects in an afternoon pretty easily. You can 'trial' it forever as far as I can tell, so no paywall to unlock content (until you decide to go live, of course). http://developer.muchdifferent.com/unitypark/uLink/ConnectingClientAndServer
|
# ? Mar 12, 2014 00:29 |
|
Kaedric posted:I looked at photon and unity park suite (uLink) and ended up deciding on the latter. I was able to set up an authoritative server with the server handling all the physics on objects in an afternoon pretty easily. You can 'trial' it forever as far as I can tell, so no paywall to unlock content (until you decide to go live, of course). That looks interesting, I think I'll give it a try. If anything simulating physics might be nice. I guess all these 3rd party plugins are pretty much just wrappers around the built-in stuff, but do some of the grunt work for you? This question might be answered once I get a chance to look over example projects, but how's player input handled with authoritative servers? Are the clients just sending RPC calls each tick the input changes?
|
# ? Mar 12, 2014 16:17 |
|
dupersaurus posted:That looks interesting, I think I'll give it a try. If anything simulating physics might be nice. I guess all these 3rd party plugins are pretty much just wrappers around the built-in stuff, but do some of the grunt work for you? I hope I didn't give the wrong impression. The ulink network stuff isn't simulating physics, Unity is (in my Server executable). The network is just updating all clients with whatever changes I want to be shared (in this case, object transforms, such that objects crashing into each other is played out exactly the same on every client). The way I have it set up currently is that player input is indeed sent in an RPC to the server. Since it's physics we're talking about, I am asking the server to add a force to my rolling ball object, and the server receives the call and does so. Since the ball object I am adding force to is observed over the network, changes in its transform are sent back to the client (and all other clients witnessing the event).
|
# ? Mar 12, 2014 23:17 |
|
Kaedric posted:I hope I didn't give the wrong impression. The ulink network stuff isn't simulating physics, Unity is (in my Server executable). The network is just updating all clients with whatever changes I want to be shared (in this case, object transforms, such that objects crashing into each other is played out exactly the same on every client). Oh yeah, that's what I meant. I went into this presuming physics simulation over the network (replicating in Unreal parlance) wouldn't be reliable, so I was just surprised to find that it is done. Not that I plan on using it much, but having it is nice.
|
# ? Mar 12, 2014 23:22 |
|
I'm just getting started with making a game with C++/SDL2 and I'm struggling with getting my build system set up. I'm using Clang on OS X and I want to eventually deploy to both Windows and OS X, maybe Linux too I guess. I've written a good amount of C-related code, but it's always been in a context where the build system was already handled for me, so I've kind of skated by with a bare minimum of knowledge on how compiling, linking, and properly using third-party code in general work. Following tutorials, it seems like the standard procedure for including SDL and other frameworks into your project is to install them into some global location like /Library/Frameworks, then tell the compiler to find it at that location. I can get things up and running fine if I do that, but I'd prefer not to do it that way for a few reasons. First, any time the project is loaded onto a new machine, all of the frameworks that are used will have to be installed separately, making sure to use the correct version, which seems like a huge hassle and potentially error-prone. Second, if there are any other projects using the same frameworks on the same machine, I guess they'll have to all use the same version? And if project 1 uses version A but then project 2 updates to version B, it could inadvertently break something in project 1. Or even within the same project, if you want to revert back to a previous revision that used an earlier version of a framework, the framework won't stay in sync with it... Anyways, as far as I can tell, it just seems like a bad idea with no real benefits. What I'd rather do is just keep the frameworks bundled with the project so that in theory, you could pull down the repository and run make and you're up and running. Maybe this is a crazy idea since it doesn't seem like anyone does this, but it makes sense to me. So I've got the frameworks I want to use (for now, SDL, SDL_image and SDL_mixer) in my project directory, and the first problem I'm running into with this is that SDL_image and SDL_mixer are dependent on SDL, and they both include headers from it via #include <SDL2/SDL.h>, which Clang can't find. Only #include <SDL.h> will work. I can modify the headers manually I guess, but that's kind of lame. How can I get Clang to find headers with the SDL2 prefix? The other problem I'm having is figuring out how to statically-link the frameworks. Even though my locally-included headers being used when compiling, the frameworks are dynamically linked, and when running the executable, it searches for the frameworks in the standard global locations: code:
Here's the Makefile I'm working with so far, which is a modified version of one I found online: code:
|
# ? Mar 15, 2014 05:10 |
|
You're making an awful lot of problems for yourself by trying to look too far into the future. If you aren't even at the point of compiling a program, worrying about porting to other platforms and eventual distribution of libraries is kind of ridiculous. You should just focus on following tutorials and getting something up and running.
|
# ? Mar 15, 2014 06:33 |
|
The question about distribution of libraries is a good question, however. How is it usually done? I don't often compile the source of other projects so I haven't run into it myself yet.
|
# ? Mar 15, 2014 06:45 |
|
Paniolo posted:You're making an awful lot of problems for yourself by trying to look too far into the future. If you aren't even at the point of compiling a program, worrying about porting to other platforms and eventual distribution of libraries is kind of ridiculous. You should just focus on following tutorials and getting something up and running. That's generally good advice, and I appreciate it, but it's not really what I'm looking for. I can get things up and running fine locally, but I'm going to need to distribute this very soon to the artist and sound designer I'm working with, who both use Windows, so I need to get this figured out sooner rather than later. Plus I'm just the kind of person who hates having to deal with all this mundane stuff at the end of a project.
|
# ? Mar 15, 2014 07:01 |
|
Jewel posted:The question about distribution of libraries is a good question, however. How is it usually done? I don't often compile the source of other projects so I haven't run into it myself yet. These are the strategies I've seen: A) Just write down which versions of the libraries to install and where. Works pretty well in small teams. B) Include it statically in your project. Most of the libraries I've used are designed with this as an option, it just takes more work with some than others. C) Write an "environment setup" script/wizard that installs the right versions of the libraries or configures the build to wherever they are on the user's system. Going with B, what dizzywhip wants to do, usually the main tasks are: 1) set header search paths so that the libraries compile. 2) add the static libraries (.a or .o I can't remember I've been in C# too long) as arguments to the linker. I'm not sure exactly how to do that in Clang but hopefully it gives you something to search for.
|
# ? Mar 15, 2014 07:13 |
|
On *nix platforms you have a few options... * Tell users what they need and leave it up to them to install it. * Use a package format such as rpm or deb to automatically manage installation of dependencies * On Mac your dmg could invoke a packaged installer for your dependencies if available. * Build and distribute your own binaries, this requires setting up your executable binaries to use custom library search paths (otherwise they default to system paths) and requires providing tons and tons of different builds if you're supporting lots of Linux distros/kernel versions (I was on a project that did this and oh god its giving me PTSD to think about) Regarding the include file problem you might just be hosed because OS X loves to be a special snowflake and install headers in non-standard paths. You should probably just ln -s /usr/include/SDL2 to the Headers directory in the framework to get around this. And all of this is totally moot for distributing to your Windows partners because no matter what you do you are going to need to set up a completely separate build process for Windows. Fortunately, it's a hell of a lot more straightforward. Also if you aren't using Xcode you should ignore frameworks where possible and just build your own SDL from source, if you aren't going to use Xcode then your far better off just treating it like Linux where possible. Mixing and matching the two is hell. I also haven't done Mac dev in two years so this might all be out of date. Paniolo fucked around with this message at 07:37 on Mar 15, 2014 |
# ? Mar 15, 2014 07:31 |
|
|
# ? May 25, 2024 15:08 |
|
When I was still working on my own engine, I made a Dependencies folder that held all the libraries I was including inside the project folder. Each library got it's on folder inside that and then added the dependencies folder to the include and linker paths. If you happen to put your SDL stuff in a folder named SDL2 (I'm assuming it's all just loose in your project folder at the moment?), then SDL_Image and SDL_mixer should be able to find it using the dependencies include path. It seemed to work reasonably well. I already had a sizable project when I tried to organize everything into the project folder and it was a nightmare to move it all and make sure it was linking to the proper files again, so I wouldn't really say it's too early to worry about it. It isn't super complicated now, but it can be later. I did a little googling and apparently if you add the full path to the .a file it will use the static version instead of the shared one? Or make sure you have the -static flag after anything you don't want statically linked, but before anything you do? I've done a little programming in linux, but mostly work in windows, so I'm not very helpful on this point. If you search for static linking hopefully you'll find something useful or someone more knowledgeable might chime in. Edit: I took too long! Anyway, yeah, if your artists are on windows, I don't think they can use the .o/.a's you've got, so you'll either have to set up your build pipeline to build everything (including dependencies) from source or have different pipelines for windows/*nix/mac. You might need different pipelines even building from source. ZombieApostate fucked around with this message at 07:45 on Mar 15, 2014 |
# ? Mar 15, 2014 07:40 |