Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In nearly every tutorial for beginner SpriteKit game making I've seen, people delete the GameScene.sks with no real explination.
The reason why building simple non-game apps is so beginner friendly is because of the Storyboard.
Ray uses the GameScene here:
http://www.raywenderlich.com/84341/create-breakout-game-sprite-kit-swift
Is there any reason why NOT to use this tool? Writing out EVERYTHING in code is a little more daunting when you have this tool sitting right here that seems to simplify it a bit.. but I'd rather avoid it if it's better to do so.
Thanks in advance.
It's all personal preference really. I think the reason why people delete it though (at least in my opinion) is due to the following reasons:
You have to specify an initial scene size in the file. Whereas if you create the scene programmatically you can set the size to the view size.
The editor is very limiting. Xcode 7 however greatly expands the editor to include much more such as custom classes.
There were some pretty big bugs/crashes in the initial release of Xcode 6.
When learning Sprite Kit it's good to know how to programmatically do things instead of doing it visually. This is because games often have dynamic gameplay so you will certainly have to do things programmatically (especially when you consider the limitations of the Xcode 6 editor).
Some people (including myself) may use their own custom editor for designing levels etc. Whereas interface builder is standard because it has become very powerful over the years and works perfectly with UIKit.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am planning to create a cross-platform (Windows,Android and iOS in future) application just like Plotagon, where we can add/modify 3d model characters in some background scene, apply some animations & sound effects to those characters and finally produce rendered video of it.
When it comes to CrossPlatform, right now I can think of two technologies.
Xamarin
As far as I have researched, currently Xamarin has excellent support for Android and iOS. But, handling 3d Models and rendering becomes nightmare.
Unity3d
Since Unity can be used to develop Apps apart from games, Handling 3d Models and animating it becomes easier task. And I think its the way to go.
But, I have no clue of how to deal with rendering stuff.
Questions:
Am I going in the wrong direction? If yes, can someone suggest better technology for accomplishing all the requirements.
How can we render a video inside the app?
Little background:
I have 3+ Years of experience in developing enterprise applications(Web based) and few desktop applications using Java and .Net platform. Now started learning Unity3d.
Note: I am trying to avoid C/C++ languages.
I had a similar question when I was making my first game. I would strongly suggest going with Unity3D. I did and was very happy with it. Unity3D has a rich set of tools to help you develop your app and it is great for cross-platform distribution. And, in the case that it does not have what you need built-in, there is a store (the AssetStore) that has an enormous amount of helpful tools and assets.
Take a look around https://assetstore.unity.com to see what it has. You can search for "movie" and get multitude of hits (everything from video capture to movie theater models). As a note, not everything in the AssetStore is free.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm currently making my first game in unity. I came through all the tutorials on their site and i have one doubt. There are many situations when I can use either animation or just add force(or do something else). For example, if in my game player hits something it should fall and i can make it fall by animation or by just adding force. Both of these solutions are good for me. Can somebody more experienced in making unity games tell me are there any good rules for deciding what should I use? Are any of these for example more performance-friendly?
It depends a lot on what your game is, and what kind of scale.
Falling objects that interact with other dynamic options? Physics is usually the best answer.
Just want something to move off screen then go away? Animation can make sense, but there are other options too without using physics.
Using lots of objects? Physics is a good way to handle it.
Using thousands of objects? Physics may be too much, will need to think of other ways.
Your question is really vague so can't give anything but a vague answer back.
However, for your first game, I will say don't worry too much about optimizing and make it simple at first. As you learn, you will understand what can be trimmed/changed later on.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
The question is above...im newbie with unreal engine and just want to start a hobby...so i'd like to spend my time with gameccreation. How can i do sports game like tennis with unreal? what can i do or could someone write links or just explain how it works? Or i just try with different engine? I tried download ffrom the webpage and istalled it...but i dont know. And i have to write c++ or i can use other program language? Blueprint what is it in this engine? And if i want like a tennis game what can i choose? SSo all in all it would be useful if someone explain how it works the whole thing. Thank u very much!!!
Yes.
You can make any game in the Unreal Engine. I highly recommend you check out https://wiki.unrealengine.com/Videos for some video tutorials on UE4 to get started. You do not have to touch any C++ when you use Blueprint, but it is highly recommended to learn some C++ eventually so that you can add your own functionality to make the engine do more than it was originally intended.
That said, designing a game even with a game engine is an incredibly difficult endeavor. Especially for people who are new to the whole scene. Just make sure to watch a lot of video tutorials if you are a visual learner or read lots of documentation on how to do different things. Don't expect to make any huge projects, such as large open world MMOs. Try to make really small, simple projects. You can use those to learn different aspects of game development and eventually be able to work your way up to larger and larger projects.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I wish to make an iOS application that includes a document library, log/journal, forums, possible randomized quotes ?and coaching tools?, and have built applications of that size in other contexts but this is my first iOS application.
Right now I'm working through http://www.raywenderlich.com/1797/how-to-create-a-simple-iphone-app-tutorial-part-1 , and I'd welcome comments on other tutorials, but I wanted to ask: does it work to work out the logical gears of an application before developing the graphic design? I would like to have somewhere between a Dirtylicious and Nature look, but my natural bent (no pun intended) is to get most the gears working and then defer most of the design work until after the gears. I expect they should not be completely separated, and there are cases where you apply the design and then realized that what the gears are doing only looked good on paper, but I wanted to do a sanity check on whether it makes to look up tutorials appropriate to a document library, a log/journal, forums, etc. and get them to work together first, and then skin it.
TIA,
It is recommended that you follow the MVC pattern, which strives for separation between layers.
http://developer.apple.com/library/ios/#documentation/general/conceptual/devpedia-cocoacore/MVC.html
Xcode helps you implementing that pattern.
I think you should try to put in "paper" everything you want to do, before doing any actual coding, check how many views you are gonna have, what you need, the flow between views, try to diagram everything, that will save you a lot of pain later. You don't have to be so specific about the GUI at this stage, you only need to know what kind of visuals you need in the views, (buttons, labels, etc...)
And yes, I think you're safe doing the Model first.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I maintain an app for my business and am pretty much self-taught on code. I understand all of the structural code, and everything is perfectly usable. My problems is with the overall boringness of the looks. Everything is stock iOS from buttons to backgrounds to pinstripes on the list view. Does anyone have any guides or tutorials they used to take a stock iOS app's look to something like the Piictu app? (I'm not looking for something that impressive but in between that and stock iOS; and I'm open to a full app re-start.)
Almost all of controls can be customized with the view properties. and also there are lots of fully customized controls published with its source code.
With iOS5 there is a lot more scope now for customisation of UIKit elements. However, where this is not custom enough for your design then you would need to write your own controls rather than only using Apple'. There are a few good ADC videos on this.