|
Yodzilla posted:Yeah the Unreal Engine is really resource intense. The twin stick shooter Waves was made in UDK and even though it's not super graphically intense that game drains my laptop battery almost immediately. I was honestly shocked. I was having issues until I reinstalled Visual Studio 2013 and made sure to close the editor while playing and now I can get pretty good performance on a Macbook Pro Retina 15 (2.4 I7 + Nvidea 650m). The shooter example runs at 40-60 full screen low res (1025x768) on high detail and 60fps on low detail. It's not great but not that much worse than Bioshock Infinite. Also the mobile games (flappy bird/runner game) run great on a Moto X. Unity can really scale down (my last game demo thing runs around 400 fps) but I think UE4 can also. One of the big issues is the freaking editor continually animates and processes graphics (taking about 25% of my CPU + unknown GPU), so if you launch a standalone build without closing the editor you get like 15fps.
|
#
¿
Mar 21, 2014 14:52
|
|
|
|
| # ¿ Apr 28, 2024 16:06 |
|
|
taqueso posted:I've been programming for something like 25 years and I've played around with making some games, but all of it was more than 10 years ago. I got an itch and installed Unity last night. I've been going through some of the tutorials and playing around with them afterwards. Holy poo poo does Unity make things easy. I'm blown away by how smooth and integrated the whole system is. So many batteries are included. If you like Javascript or C# go ahead and just jump all the way into Unity. It's totally free to use for Mac, PC, Linux, Webplayer, Android, iOS, Windows 8 Metro, and Windows Phone 8. You'll be required to buy the Pro versions once you make 100k. If you're a C++ dev, then pay the $19 for one month and grab Unreal Engine 4 and cancel the plan.
|
|
#
¿
Mar 28, 2014 19:55
|
|
|
TwoQuestions posted:Does this sound like a good idea to you people, or does it sound like a giant pain in the rear end? TDD always sounds like a pain in the rear end, but would be amazing for some of the more basic development early in the life cycle. It's almost always better to have unit tests then not but like everything else moderation is the key. Make sure to only unit tests things that matter and that you can keep your unit tests up to date. Also don't try for more than about 50-70% code coverage as it becomes massively diminishing returns.
|
|
#
¿
Apr 2, 2014 15:25
|
|
|
AntiPseudonym posted:I feel embarrassed to admit it, but I honestly have no idea how to go about doing TDD Don't be, true TDD is almost never appropriate for game development. The short version of TDD is when you decide you want a new feature (like say, space will cause you to jump) you first go build positive and negative tests. TDD means you first determine and code the unit tests before attempting to code the implementation. Ex. you would make a test that when space is pressed you users should be 2 units higher 1/10th of a second later, and if any other key was pressed then you should be the same high 1/10th of a second later. The problem with TDD for game development is you often have no idea how you are going to solve the problem before you attempt to solve it, and even if you did your intended implementation might not have good game feel and immediately be changed. In short TDD is NOT recommended for game development for these exact reasons. Instead when you have an issue you want to implement, go implement it and afterwards consider if a covering unit test might be worthwhile. In some cases it will but in many it won't, unit tests can be great for code logic, but be very careful to not use too many as it can kill your ability to adapt (which is the essence of early game development). Again, don't do pure TDD, but this seems like a pretty good resource: http://www.agiledata.org/essays/tdd.html Also once you have done TDD make sure to bring it up in every technical interview you ever do and explain exactly why it is and is not appropriate for the application your interview for. Hiring managers love hearing that stuff. Stick100 fucked around with this message at 08:01 on Apr 3, 2014 |
|
#
¿
Apr 3, 2014 07:59
|
|
|
dizzywhip posted:I agree, I spent a few hours with the project tutorials and that was plenty for me to become comfortable in Unity. I did roll-a-ball and then about half of space shooter and didn't bother with the stealth one. Since you're coming from a programming background that should be plenty to get you started. One Note: The stealth tutorial is pretty useful but it requires many features that are present in Pro only. I got about 1/2 of the way through and then they go into light probes and other neat things and then BAM! no warning it just doesn't work unless you're using Pro. So the tutorial just falls flat without Pro. Because of this I wouldn't suggest the Stealth tutorial.
|
|
#
¿
Apr 12, 2014 06:08
|
|
|
Alexander DeLarge posted:After Garry Newman came out speaking against the uLink networking API and their attempt to silence his outspokenness about the lack of support, I'm kind of reluctant to be using Unity at this point because I was really relying on uLink. Are there any alternatives? I really don't want to use the cloud solution, I want functioning netcode so I can build off of it and create dedicated server tools and all that good stuff. Take a look at TNet. http://forum.unity3d.com/threads/163681-Released-TNet-Tasharen-Networking-Framework It's from the creator of NGUI and it's a full networking solution. People seem pretty happy with it.
|
|
#
¿
Apr 22, 2014 18:44
|
|
|
The Grumbles posted:Steam's just been down for maintenence, which seems an apt time to ask about something I've always wondered - when big game servers go down for 'routine maintenance' - services like Steam or World of Warcraft going down at a scheduled time each week, what actually happens during that time? Is everything just 'reset'? What constitutes 'maintenance' of this sort?, why is it required so regularly, etc? Well in every other software solution I've seen you often want a little bit of time to do database maintenance/batch operations. Most systems do batch jobs every night that wouldn't run under load when you're customer base isn't using them. No one talks about it because it doesn't get noticed. Once you become 24/7 you learn you have to schedule outages just for basic things. It's a good idea to schedule these at least once a week so that you can deploy and respond without taking down the system when people are using them. If you make your outages spaced out further than a week you end up taking it down just to make a simple change that could wait a couple days but couldn't wait a month. In short they are doing it so that they can be up the other times.
|
|
#
¿
Apr 23, 2014 01:17
|
|
|
The King of Swag posted:For you Unity users out there, this may be old news, but I just ran across this tool that allows you to seamlessly use VS Express with Unity. I wish I had found it a couple of weeks ago when I started learning how to use Unity. MonoDevelop is actually a pretty nice IDE, but it has a few quirks that really throw me off, such as an autocomplete that sometimes won't let me escape from it, requiring me to accept the autocomplete, delete back and retype what I wanted. There also is http://unityvs.com/ they have a short trial (2 weeks) but it's $100 a year that lets you hook up to any Visual Studio and even lets you debug in visual studio.
|
|
#
¿
Apr 24, 2014 18:02
|
|
|
Hughlander posted:The problem with zero disruption is the cognitive overhead on the engineer. Also all of this is ignoring the nice things you can only do if everything is down like reorganize a database, update database statistics, change a column type. Or even swap out massive parts of the game client. Zero disruptions is nearly impossible for the massive amount of changes and service a game like WOW provides. Minimal scheduled downtime is by far the best solution.
|
|
#
¿
Apr 24, 2014 18:10
|
|
|
Dodgeball posted:Does anyone have any experience with Construct 2? I've got a 2D pixel-art platformer I'm making and I'm in the air about whether to go that route or Unity. If you've used both, is there one you prefered over the other and if so, why? There is all game maker studio and Stencyl. Minecraft was written in Java. There are a billion and one game engines use the one that you are able to finish a game in. It doesn't matter what it is. Personally I've ended up settling on Unity3d, but I'm a professional C# developer by trade so it was pretty natural choice. I did a little bit of XNA/Monogame in the past but Unity's asset store really sealed the deal for me personally. The big deal new engine that became available cheaply is Unreal Engine 4. But it's C++ if and when you have to deal with code.
|
|
#
¿
May 1, 2014 15:43
|
|
|
Look Around You posted:I've been trying to start writing a game on and off for the past... ever it feels like, and I always get frozen on which langauge/library to use. I'm thinking of a 2d top-down adventure game in the style of the older Zelda games (A Link to the Past, etc.). I know you said you wanted C or C++ and didn't like unity or Unreal 4. But still I'd really suggest either Unreal 4 (only $19) or Unity. For Unreal 4 you just pay $19 once get the source code access and build. When the month runs out they don't remove the source code access so you can keep getting the newer versions (as long as you build them yourself). It's in C#/JS but if you want full control over every step you might consider the Futile framework for Unity from Matt Rix of Trainyard fame. https://github.com/MattRix/Futile You get on every platform with no effort, you get the unity asset pipeline, you get the asset store. It's running in Unity but it's just a pure sprite framework, you have to implement everything yourself. Some things you might not have thought about are sound, input management. Honestly you're not going to finish a game if you start from scratch. If you want C++ just find an engine/framework that does what you want. There are several (including unreal 4) that have the full source code available.
|
|
#
¿
May 8, 2014 23:36
|
|
|
Cirrial posted:What about AIR? AIR is also dead as a good development platform because Adobe is no long supporting the technology underneath it. AIR will work but won't be nearly as efficient as most anything else. It's like using Silverlight at this point. It will still work, but there is no major effort to support it anymore. Adobe and Microsoft are pushing HTML5 as future of Web/Desktop applications.
|
|
#
¿
May 8, 2014 23:39
|
|
|
xgalaxy posted:The way it's supposed to work is if your sub lapses you lose access to updates via GitHub and via the Launcher. You do lose access to the newer version via launcher but the github still works. You do still have access to the older version via launcher too.
|
|
#
¿
May 9, 2014 09:06
|
|
|
xgalaxy posted:If you do fork it, and your sub lapses, you should (if everything works correctly) lose access to the EpicGames company repos, but you will still have access to your private fork. This means you still have code access, but no more new changes since you no longer have access to EpicGames parent repo. That's what I had expected. But after my sub lapsed I still have access to the company repo. The launcher still works too, but will only let you get the 4.0.1 instead of 4.1. I built 4.1 from source (downloaded from Github) after my sub had lapsed. I did lose access to the new marketplace content (like the elements demo). I don't know if this is what they intend but it might be. They talked about wanting to keep pumping content into the marketplace as a way to keep interest going, they might be willing to let you have the source including updates without a subscription. TL:DR: I had a sub, it lapsed I still have access to the EpicGames repo.
|
|
#
¿
May 9, 2014 18:46
|
|
|
Tenacious J posted:The problem with unity (free) is that it doesn't support VR. UE4 does, but there are very few tutorials. There are going to be very few tutorials for any system and VR because it's so new/niche right now. Unity has some support for Oculus Rift, I know some companies are currently using Unity for VR projects. I don't know if they are using Pro or Free however. A big question is also what are you professional interests/aspirations separate of game development. I've worked in about 7 languages over the past couple years, but since I spend most of my time in C# Unity works much better for me. Also keep in mind with Unreal and a pretty good blueprint system you don't really even need to learn to code for many simple games. If you want to do C# If you want to do C# also Monogame is a pretty good option. EDIT: Removed Unity JS as apparently it's horrible. Stick100 fucked around with this message at 10:15 on May 11, 2014 |
|
#
¿
May 10, 2014 19:35
|
|
|
Tenacious J posted:Your reply was reassuring and gave me a ton of hope and motivation. Now two days later, hope has been dashed due to several barriers to C# (money and having a Mac). Go get Unity for Mac. As stated it's got Monodevelop built-in when you install it. Also Unity was first built for Mac and still runs slightly better on Macs then Windows machine. If you want C# on mac -> go get Unity 3d.
|
|
#
¿
May 12, 2014 16:59
|
|
|
Wozbo posted:So I know probably none of you devs use the kinect, but what are your guys' thoughts on the removal of the kinect from the xbone as a separate sku (this news just came out)? I think its a dumb idea (never gently caress with your baseline). EDIT: Oh crap it's already done. http://www.indystar.com/story/entertainment/2014/05/13/xbox-one-without-kinect/9034753/ FYI: Available June 9th. Now if they could just get the use your xbone as a dev kit thing! Also: "In the same announcement, Microsoft also confirmed that beginning in June it will no longer require owners of the Xbox One or Xbox 360 to be Xbox Live Gold users in order to access entertainment apps such as Netflix and Hulu." Probably a dumb idea as they are loving with the baseline, but MS might have some analytics on the % of Kinects that are not plugged in. If there is a decent % (like 30%+) that are not plugged into the systems, it's probably time to ditch it. Of course once they do that the % of Kinectless XBones will massively increase, but some people just want a game machine. Personally I think they should do everything they can to make the current Kinect smaller, cheaper, more usable. Maybe downgrade the camera slightly as I think most people just use the voice part of the Kinect anyway. Getting rid of the voice stuff would hurt MS/Xbone usage much more than a worse/no camera. Maybe a XBone mini, with mic built in and no camera? Stick100 fucked around with this message at 16:58 on May 13, 2014 |
|
#
¿
May 13, 2014 16:48
|
|
|
Cryohazard posted:I just finished up a match-3 (bejeweled-style) base for a procedural RPG thingy I'm going to be working on. It's basically the first thing I've ever really put together (it's done in Construct 2, that's how inexperienced I am.) I know GameMaker-likes aren't particularly great for bigger projects, but for what I'm doing it seems more than adequate, if a little fiddly. As a side-question, is it teaching me any bad habits that I'm going to have to wean myself off? Use the tool you are using. Finishing games is by far the most important skill to finishing games. Construct is fine for one man projects. The main problem with game maker likes is they are hard for larger teams to work simultaneously. Besides that game maker makes some great games. Splunkeys first version was game maker. Nuclear throne is game maker. Hell game maker can publish to the ps4 now.
|
|
#
¿
May 14, 2014 02:07
|
|
|
Forer posted:This is also part of the 2d 4.3 inclusion thing, before then if you wanted to do 2d unity you had to use futile, which is VERY VERY codebased (bad example of incomplete lovely code here) and it SEEMS Like this is more how you would code a c# game without unity, and the futile stuff is just there to simplify "this is just here to draw pretty boxes on screens for you to fill in with sprites" If you wanted to do 2d development in unity before Unity 4 the suggested path was 2d toolkit + ngui. Futile was created for a specific development method (all code). The creator was using it for his successful game and decided to open source it. But he suggested no one use it as it's so specific to his method and completely opposite of the normal highly GUI method of development that Unity uses. The futility of working against the programs standard workflow and having to reimplement ever thing unity had implemented is why it's named futile. All that said it's a good alternative to monogame if you want to control every aspect of your 2d game.
|
|
#
¿
May 16, 2014 16:28
|
|
|
Evil Sagan posted:This is a little general, but since my ultimate goal is related to game development I'm hoping this is the right place. Go get the unityvs trial. It lets you use Visual studio to develop Unity. The trial is for 14 days and you can get more than one if you use more than one email. It costs $100 per year. If your going to spend money on Unity buy this before asset store packages. I didn't do this and regret it every time Monodevelop opens.
|
|
#
¿
May 16, 2014 16:32
|
|
|
xgalaxy posted:Do this only if you can afford $600 (cost of baseline Visual Studio) + $100 (cost of UnityVS). The specific user said he had Visual Studio at work so I assumed he could coast of that for home. In addition Bizspark gives you every piece of MS software for free (including all Windows and Visual Studios) for three years, all you have to do is apply. At the end you can keep everything you've downloaded for a one time buy out of $100. It is limited to companies creating software (not consulting). I already had some WP7 games at the time, made a submission saying I make WP7 games, apps and windows apps and it was approved a couple days later. There are plenty of MS advocates that can give you a preapproval codes. Visual Studio is miles ahead of MonoDevelop. While you're at it I'd suggest getting Re sharper too. If your a professional C# developer you'll almost certainly be working in Visual Studio for your day job, so I'd suggest using it in your free time.
|
|
#
¿
May 16, 2014 20:11
|
|
|
Tann posted:Make a game every week! Also use source control for everything (bitbucket _ Git works well) and put your stuff out there no matter how good or bad. I'd suggest Kongregate for web stuff. Once you get a bit into it add some Analytics. That way you can find out that 99% of plays of your web game are being unreported by Kongregate because some one made a copy of you game and is hosting it somewhere else.
|
|
#
¿
May 25, 2014 19:40
|
|
|
Note: Unreal announced a policy of not counting the first $3000 per quarter in your royalty report. This means if you make less than 12,000 per year you owe nothing to Unreal. If you happen to make $3001 in a quarter then you owe them 5 cents. This is equivalent to a $600 yearly discount. Also in 4.2 Direct support in blueprint for iAds, Admob, Game Center, and Google Plays game center. Also an iAdprovider interface for adding ad providers at will. Most of these things (iAds/Google Play integrate) are difficult in unity. Most people end up paying for a plug-in (like $50) to fix these isues. Unreal is working on a better 2D system shortly. They showed with thier new Tappy Chicken that they can achieve a decent frame rate back to the iPhone 4 and very old Android devices. https://wiki.unrealengine.com/Tappy_Chicken I subscribed was added to the GitHub, canceled my subscription and still had access to the most recent builds in GitHub. Unreal Engine 4 is rapidly surpassing Unity3D for me. The one thing I wish I had access to in Unity3D was a performance profiler, and in Unreal Engine 4 you can just press cntrl-shift-comma and they will explain everything.
|
|
#
¿
May 25, 2014 19:49
|
|
|
The King of Swag posted:I want C#. As do I and it's the only reason I haven't jumped 100% to Unreal yet. I'm a professional C# developer and I've learned in the last couple years it's really hard to program in multiple languages at the same time. Since games are the hobby they should mirror my professional not the other way around. If it makes any difference: https://forums.unrealengine.com/showthread.php?110-Mono-C-Bindings-for-Unreal-4/page3 quote:Mono binding and licensing TL:DR Unreal might get a C# projection/bindings but probably not. Good god I hope so. If/when will it happen, who knows.
|
|
#
¿
May 26, 2014 19:54
|
|
|
Shalinor posted:This is the big reason their plans terrify me. Their brilliant plant is to not only generate their own C#->C++ compiler, but to maintain that IN PARALLEL with the still limping along, old as hell Mono. Oh.... that's no good at all. Xamarin is the only C#->C++ organization I'd be willing to trust. Microsoft is doing everything they can short of buying Xamarin to prop it up, no one else is going to come close. Ditching mono over terms with Xamarin is horribly bad.
|
|
#
¿
May 26, 2014 21:33
|
|
|
Ephphatha posted:How many of us are planning on entering the 2014 indie game maker contest? I'm gonna try get something made since the longer timeframe gives me more weekends to work on something, but I know it won't be competitive. I think I'm going to try. My plan is to attempt a Unity 4 blueprint only vehicle game.
|
|
#
¿
May 30, 2014 15:19
|
|
|
Che Delilas posted:Premature optimization is death, DEATH, for a project that you actually want to get out the door at some point. It's also quite frankly a waste in most circumstances. Most early code either get's completely rewritten, unused, or never needs to be optimized. It's very difficult to optimize the code until the projects finished. As one of my bosses would say the key to optimizing is speeding up the slow parts. You can't know which parts are the slow parts until you're near the end. This is also why most game dev machines and game demo's are hardware 5-10x more powerful than game consoles. Notable example Forza E3 vs shipping. http://www.examiner.com/slideshow/forza-motorsport-5-e3-build-and-final-version-compared Data driven code can save your tons of headache and in and of itself is not necessarily optimization.
|
|
#
¿
Jun 1, 2014 21:29
|
|
|
The King of Swag posted:The purpose of this post was originally to ask a simple question, but after having asked it, this post devolved into a detailed analysis of my project; the decisions I've made so far, the ones I'm still deciding on, how and why I've made them and how I felt they would affect the commercial sales of the finished product. That further devolved into an analysis of my insecurities with devoting so much time and effort into a project, that like most indie projects, needs to realistically be looked at as an inevitable and abysmal commercial failure, and that any money made from such a venture is simply to be taken as gravy on top of having the pride of having released a game. I know 2D toolkit is well regarded for 2.5d development using a perspective camera although I've never tried it for that purpose.
|
|
#
¿
Jun 4, 2014 07:15
|
|
|
Yodzilla posted:I used SourceTree with BitBucket because it's super easy for me to work on three different computers at once which I kinda need. Sourcetree + bitbucket.com = Good! Git can be a little difficult to learn when working with multiple people, but if your yourself it's a no brainer. Everyone please use source control, sourcetree + bitbucket (Either Git or Mercurial) is free and very easy. Github is free for open projects, but charges if you want to protect your code.
|
|
#
¿
Jun 13, 2014 15:10
|
|
|
Fano posted:I was trying to create a loading screen for a mobile game I'm working on since there was a bit of jitter going from the menu scene to the game scene, I was advised to use Application.LoadLevelAsync to achieve this, but it's a Pro only feature :/ There are some things in Pro that seem important for most people but as I'll describe why most of these limitations are actually better kept from most developers. The nice for everyone include loading screens (your forced with a "Made with Unity" screen, and profiling. After really examining Pro/Free I've realized with the exception of profiling evertyhing is either marketing (loading screen), window dressing (the dark theme) or legitimately a good idea to keep away from beginners. Baked lighting (deferred rendering paths) async calls and web sockets are possibly useful to an advanced developer but can trip up many developers. But these things that cut down on iteration time (there is no 40 minutes of baking if there is no baking possible) and prone to cause incredibly difficult problems. Any async logic breaks standard debugging and is an incredibly difficult problem when it goes wrong. Unity Free is a full engine and capable of nearly everything that the pro version is. At this point I'd suggest people use Unity Free, and if you make some money or get ready to publish to a serious platform (XBONE/PS4) get Pro and learn real lighting. Everything about this is going to change in under a year when Unity 5 gets finalized anyway. Unity Free is perfectly capable for any one man games up to full release. If you get a deal or ID@Xbox you'll get full paid for anyway. Stick100 fucked around with this message at 04:33 on Jul 14, 2014 |
|
#
¿
Jul 14, 2014 04:30
|
|
|
Fano posted:Could you (or anyone here, really) recommend what the best practices are with regards to reducing scene loading times? What are the biggest culprits? We have randomly generated levels whose chunks all get instantiated at the beginning of the scene and thrown into an object pool for the purposes of lag free gameplay, which works great, but there is quite a bit of jitter at the very beginning that we're trying to get rid of. Could you hold off on letting the user act (example a 3,2,1 count down with time stopped) while you load everything? Not necessarily a best practice but you could maybe use something like the dark souls fog wall to slow/take control back from the user while loading. As an example of a count down with time factor set to 0 here is one of my horrible games: http://www.kongregate.com/games/beep2bleep/dark-wisper This technique might work to load your assets. In this case it wasn't used to hide anything it was a game jam game and at one point we didn't have a menu screen and it was jarring to just jump into a game immediately. Mobile is always tough because of extremly weak CPU/GPU(well at least until the Snapdragon 800/A7 chip they had very slow CPU and you had to be very careful of things that are simple on even an i3). Thankfully with the K1 we are very close to having a full convergence between low level desktops and mobile hardware. Without the ASYNC calls you might be stuck with some hitching unfortunately. This is even mentioned by the highly regarded (although not used it myself) sectr dynamic loading/unloading framework. http://www.sectr.co/stream.html
|
|
#
¿
Jul 14, 2014 15:12
|
|
|
HaB posted:It took about two weeks for mine, iirc. Both my original signup and the renewal. Mine was exactly 2 weeks as well.
|
|
#
¿
Jul 21, 2014 15:49
|
|
|
The King of Swag posted:Just in case anyone else signs up for Bizspark; Microsoft says you'll be approved or declined within 5 business days, but I wouldn't believe that. I signed up right after Unormal posted this (on July 2nd), and I still haven't heard a peep out of them. Last I checked it said 10 business days. Must have some people out for summer or something.
|
|
#
¿
Jul 21, 2014 15:50
|
|
|
Shalinor posted:Transition points still suck rear end, though. We're still going back and forth on our next project. "A decade of institutional knowledge and experience with C# and Unity workflow and caveats" VS "switching to the hip on-the-rise engine, away from the one that very clearly peaked and is starting its downward spiral." I'm not sure Unity has clearly peaked. In Unity 5 they are introducing most of the advantages that UE4 has (reflections, real time lighting). The real question is how good is it, how buggy and if they are going to stick with closed source + $1500 as the only price point. All indications are that it will stay janky with closed source at that pretty expensive price point. I'm really hoping they either annouce a pivot or get enough of an earful at Unite to start talking about it. UE4 is just crushing currently (every single week they have a new integration). FYI now twitch streaming is just built it to both any game you build and into the actual IDE/Editor. Yup didn't even bother talking about it because hey, that's not big news. Unity won't have that for years. Oh and speed tree will just be built in + extremely affordable in a couple weeks. I think unity might have that in a couple of months/ then not be buggy in a year. I didn't catch the live stream but apparently they also made a deal with Miximo to get a bunch of Miximo stuff built-in/free but I didn't watch the livestream. ARGH com'on Unity open the source and give us a 5-10% option please!
|
|
#
¿
Aug 4, 2014 21:08
|
|
|
nite time dinosaur posted:My concern wasn't so much that the computer would get damaged. It was more that when I tried running the editor, it was making my fans run at maximum speed and the computer, a retina macbook pro, was so hot it was painful to touch. I wasn't even doing anything in the editor. Can't imagine what would happen if I tried to do anything. I had the same in Windows (rMBP). In 4.3 they are introducing settings let you cut back actions in the editor. Most critically for when on battery and not in game. You said you were doing "nothing" but the editor just keeps running the game constantly it like the game never stops just the perspective changes to the editor camera. Unity does the same thing in the editor just your scene is probably much simplier so Unity isn't running your GPU/CPU full out like UE4.
|
|
#
¿
Aug 5, 2014 16:51
|
|
|
xzzy posted:Unfortunately that's SOP for Macbooks. You can't make computers that small without some compromises. I still think the rMBP/Air are the best hardware but if you use a rMBP + discrete at full throttle for long it will get extremely hot and throttle down the CPU.
|
|
#
¿
Aug 5, 2014 18:10
|
|
|
exotarih posted:Heya everyone! Do you maybe have any special approaches for a somewhat burned-out programmer of how to get into game development? My day-to-day job (text processing, mostly in Haskell and R) is, I take it, pretty far away from anything gaming-related. However, I've been meaning to get into game development as a hobby for quite some time now. I don't want to create the next big hit or anything, just something that I can play around with. Maybe reading recommendations for a (somewhat) experienced programmer? Language/engine recommendations? Keeping the 'burned-out' aspect in mind maybe something that helps me see the fun in programming again. Unity, UE4 are the first but anything that makes games makes games. Some people really enjoy gamemaker and some of the other things like Stencyl. What kind of games do you want to make? Make sure to join Ludum Dare 30 — August 22nd-25th 2014. It's a lot of fun. This weekend people will be doing a "warm-up" weekend so there are tons of people you can discuss with about engine choices. Literally this is one of the best weeks all year to discuss and explore game engines. To join the discussion join an IRC client at #ludumdare on irc.afternet.org http://www.ludumdare.com/compo/ Big list of game engines: http://en.wikipedia.org/wiki/List_of_game_engines FYI: There is a Haskell game engine. The current big three engines are Gamemaker, Unity and UE4. All are cheap (or free to start) and have good tutorials. Some people like HAXE and have had good luck making pretty games very quickly, see http://deepnight.net/. Stick100 fucked around with this message at 18:42 on Aug 11, 2014 |
|
#
¿
Aug 11, 2014 18:26
|
|
|
Unperson_47 posted:What are some good primer resources for learning to code AI? Something with examples using C# or Python would help as these are what I'm most familiar with. I'd suggest you consider using state machines. If you're in a Unity you might want to consider a third party plugin like Playmaker or a different plugin. AI starts pretty easy but often gives you really wierd results so something like an FSM really helps debug what the AI is doing and why. It's very helpful to be able to answer the question of why an AI did something. I know unreal has a built in AI tool also I believe it works with FSMs also.
|
|
#
¿
Aug 13, 2014 00:11
|
|
|
Subjunctive posted:If you're looking to Google more information about this, it's more commonly known as a "vertical slice". You might also think of it as "enough game to launch a Kickstarter", I guess. It's generally what was required for developer milestones (to my understanding). It's enough to decide if the game is any fun before heavily building out the content required. There's a great discussion of it for X-Com Enemy unknown. http://www.polygon.com/features/2013/1/31/3928710/making-of-xcoms-jake-solomon-firaxis-sid-meier They found out the game was no fun for anyone but X-Com fans once they finished the vertical slice.
|
|
#
¿
Aug 13, 2014 22:33
|
|
|
|
| # ¿ Apr 28, 2024 16:06 |
|
|
Hughlander posted:And by f-ed I meant at least one person has to redo all of their work. Yes. Everyone needs to get latest often, and be careful when editing binary files. If it becomes an issue you'll have to either institute policies or procedures to fix it. MS Source safe atomic checkouts (that's the name for the system) was far more of pain than dealing with merging. In short binary assets and source controls never mix which is part of why Shalinor above was talking out having to "airlock" scenes (binary file) and deal with these issues through policies.
|
|
#
¿
Aug 17, 2014 22:12
|
|