• Advertisement

New questions?

Recommended Posts

Hi i am a c++ programmer,

Want to make games for mobile with c++ and compile it to android and ios.


1- Is c++ with ((game library) or (game engine)) enough to make(compile, deploy ) games for mobile?
or i have to  use c++ with (game library or game engine) with android studio ,ndk
and , c++ with (game library or game engine) and Xcode , iOS SDK?
2- What is next after learning c++ to be a gamer developer?
3- And Some advices please.

Share this post


Link to post
Share on other sites
Advertisement

Don't learn C++ to make games. Learn programming if you enjoy programming. Use game-making software if you enjoy making games.

C++ is a very difficult language to start with. All the programming languages you learn after your first are much easier to understand. Professionals use it because you can speed things up, but that is only nessecary for professional games. You won't be able to make those on your own.

The best languages for a beginner to learn are probably C#, Python, and Javascript. Choose one and stick to it.

Some good game-making software are Unity and GameMaker studio. I believe both allow a great deal of portability between different types of operating systems.

To answer your second question, whatever you want. Note that learning a language by itself generally isn't enough to make a game. There are many, many more aspects.

It's hard to give advice until we know more about your situation. Your post makes it sound like you are just beginning to write code. I would suggest not worrying about "portability", making your code run on other operating systems, until you are fairly experienced.

Share this post


Link to post
Share on other sites

You could start with learning C++, especially the strict memory modell will help you understanding other languages. It is more easy for some people to go from C++ to C# and for others the other way round, depends on the person. If you want quick success just learn C# first because getting started here is way more comfortable than it is in C++.

You basically dont need any game engine to develop for Android as you dont need any game engine to make a game. It is harder to solve and you waiver for a lot of convinience, but it is possible. Developing for Android is much harder. This platform has a wired architecture where any of your apps is running inside a Java VM and is potentially written in Java, at least to startup anything else. There is the NDK you could use for making C++ code run in the Java VM by either call your C++ functions directly or use the Unity 3D way and have a simple startup routine in Java that calls into your C++ startup code.

You dont need Android Studio for this per se while Visual Studio C++ 2015 (dont know about 2017) provides an Android project template that creates all the necessary files you need to build an APK file from your source code and run it on Android. They also provide some emulation software you could test and debug your app in first. But I have never worked really with that, just played a little arround so at the end you need to get started on yourself.

I would recommend to first learn how to code and later go to such a diffcult platform as Android is. This will help getting a better knowledge of how you debug your code and how you have to write it :)

Share this post


Link to post
Share on other sites

Hi, if you are already a good c++ programmer then there is nothing wrong with that for writing games on mobiles. I’ve done this myself.  Now using visual studio 2017 community (if you download the mobile API stuff as part of installing). The VS project templates has Android and IOS cross platform projects which are ‘hello world’ style opengles apps.  In VS 2015 they had a spinning cube project but this has now gone in 2017 (but you don’t really need this). From here you can use the NDK, OpenGLES and OpenSLES (for audio) APIs etc. Obviously this doesn’t come with any game engine, so all this is not really a beginners choice here. I'm sure there must be good enough c++ engines that you can use here, but haven't used any myself.

 

Using unity for mobile games with C# is a good option to learn anyway.

I know C# as well, but learnt C++ first.  C++ is one of those languages that once you’ve mastered you can pretty much learn any other language with no problem.

Share this post


Link to post
Share on other sites
9 hours ago, RidiculousName said:

Don't learn C++ to make games. Learn programming if you enjoy programming. Use game-making software if you enjoy making games.

C++ is a very difficult language to start with. All the programming languages you learn after your first are much easier to understand. Professionals use it because you can speed things up, but that is only nessecary for professional games. You won't be able to make those on your own.

I'm a bit confused by the statement "Don't learn C++ to make games. Learn programming if you enjoy programming. Use game-making software if you enjoy making games." I enjoy making games but refuse to use "game-making software". Even back in the early 2000's I hated it and went full scale into C++ for game development, 15+ years later I'm still using C++, JAVA, C#, and more to make games because I enjoy programming, and making games.

C++ is indeed difficult to start, to be honest I started on BASIC, and jumped from that to C++ because I hated the limitation of "Game Makers" back in the day. It's also not just C++, but once you learn any language within reason moving to the next is a lot simpler. C++ made my learning experience easy because I had to program many functions and classes from the ground up, handle memory, and deal with the many features C++ comes with.

In the modern day, C++ isn't "necessary" anymore because we're not dealing with such a limitation in memory and CPU processing anymore. C++ was a big thing when you had to develop on some platform which required squeezing every possible usage of your program within a tight memory restriction, and that was a long time ago. This is why you should pick the language you want to learn and just make games, not because everyone thinks you need C++ because you "must" have manual memory management.

Unity is a cross-platform game engine which requires C# programming, and GameMaker Studio 2 is a 2D development environment that provides drag and drop functions, as well as access to their scripting language GML. Unity is not a game maker in the sense of how GameMaker Studio 2 is a game maker, it's an engine.

To the OP, the other replies already provide good recommendations, so I cannot add anything more.

Edited by Rutin

Share this post


Link to post
Share on other sites
12 hours ago, Rutin said:

Unity is not a game maker in the sense of how GameMaker Studio 2 is a game maker, it's an engine.

I have to disagree with this somewhat.  Don't let the name fool you, Gamemaker is as much of an "engine" as Unity is, just that the scripting language isn't a "standard" language like C# is, and the focus is on 2d, not 3d.  I'd say the argument is more about properly defining the word "engine" but the way you put it feels like you are making GameMaker seem less useful to the point you can't even call it an engine, rather something like a "toy."

Share this post


Link to post
Share on other sites
1 hour ago, kburkhart84 said:

I have to disagree with this somewhat.  Don't let the name fool you, Gamemaker is as much of an "engine" as Unity is, just that the scripting language isn't a "standard" language like C# is, and the focus is on 2d, not 3d.  I'd say the argument is more about properly defining the word "engine" but the way you put it feels like you are making GameMaker seem less useful to the point you can't even call it an engine, rather something like a "toy."

I haven't used GameMaker since before YoYo Games got involved, and did use it from version 2 to 5 off and on when Mark Overmars was the main man. I've never considered it an engine as I would consider something like Irrlicht, or Orge3D, nor has anyone else I've ever known. I've looked at it like a good starting tool that allows people to create 2D games within a limited environment that has added scripting for those wanting to get into GML as an entry level language (You may define it as an engine simply because it has GML, which is fine). My comment still stands, it's not at the same level as Unity, and I never said GameMaker was some useless toy. In fact, you can view my post history, I recommend it to a lot of new game developers as it has a lot of potential for people starting out. I've also seen some very good games created using the application.

I understand where you're coming from about GameMaker. It wasn't a tool for me back then, and simply isn't a tool for me today considering I went all out into developing programming skills because I wanted more control and custom options, not to mention I really wanted to 'program'. I honestly cannot think of one friend back in 2000 that is currently using any GameMaker tool to date. Most of us are either using our own in house engines, or 3rd party commercial engines.

"

Hi i am a c++ programmer,

Want to make games for mobile with c++ and compile it to android and ios.

"

Considering the original poster was referencing C++, for me to even suggest GameMaker would not be relevant as an option, and if you know C++ and intend on making games with it, why use GameMaker Studio? It would be better to start off with SDL, Allegro, or SFML if Unreal, or another engine if it's not an option.

GameMaker Studio 2 is great for what it provides, and who it caters to, and is simply an entry level solution for non advanced programmers, or those who never intend on learning to program.

Also, my "opinion" of what an engine is may also be wrong in this case under the 'true' definition of a game engine. GameMaker Studio 2 can very well be 'defined' as a game engine. I just don't look at it that way because I come from a different perspective and have always viewed GameMaker as a tool to create games. I just don't put it in the same category as Unity however. :) 

Edited by Rutin

Share this post


Link to post
Share on other sites

@Rutin It seems we agree then.  I've used more recent versions of Gamemaker.  My first game programming was actually hacked into Microsoft Access(using VBA back with Office97).  I've also used C++ and vanilla OpenGL to make a few things, and tinkered with Irrlicht as well(brings back fond memories actually).  But I'm more of the thinking that just because I know C++ doesn't mean I need to make games from scratch.  If I want a 2d game, I'll like use the current version of Gamemaker, as for that specific job it makes things much easier than anything else, and also development speed is much quicker(in my experience and many others too).  That being said, my current project is a top-down space shooter that plays similar to Asteroids, but I want 3d graphics(despite 2d gameplay)...so, I'm using Unity for it, which is what I consider the best tool for the job for the majority of smaller(as in non-AAA) 3d projects.  I also recognize UE4 as valid, especially if someone knows C++.

 

My point is basically that with C++, even with some pre-canned code like Irrlicht, or whatever 2d library you want...I don't see how development can be as fast or as easy as it can be with Gamemaker or Unity.  This assumes of course that you don't need something exotic that the engine doesn't directly do(like massive amounts of units in an RTS, or destructible voxel terrain).  In those cases, depending on how good you are with the engine, you may be better off rolling your own.

Share this post


Link to post
Share on other sites

For sure, it really comes down to personal preference, and using GameMaker isn't a wrong choice if you're looking at making 2D games quickly. I've been programming tool-kits and game engines in house for so long that I enjoy the process which is why I don't use GameMaker or similar tools. This is what got me started in C++ to begin with, I wanted to essentially make my own engine from the ground up, and tool-kits so I could make a variety of games.

At the end of the day if you're just into making your game as fast as possible, there is nothing wrong in using the many tools available to streamline the process.

I don't fall into the above category because I love programming so much, and I also enjoy making games equally (believe it or not, I really enjoy programming game engine features). In the 15+ years I've been at this I have tons of re-usable code and can fairly easily setup a 2D game in record time, which doesn't really hinder my development time. This is the beauty of game development, there are so many ways you can create games. The most important thing of all is to complete a functional game, how you get there doesn't matter. I'm just very hardcore, and enjoy re-inventing the wheel to make it my own at times. :)

There is no doubt a new game developer is going to create their project much faster using something like GameMaker as opposed to programming an engine from the ground up. We all enjoy different aspects of game development, some people enjoy the creative process of making an engine with their game, others are more into just getting their game on screen as fast as possible.

I understand where you're coming from and agree that just because you know (x) language or how to do everything from scratch, doesn't mean you have to. There is more than one way to paint a picture. :D

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By francoisdiy
      So I wrote a programming language called C-Lesh to program games for my game maker Platformisis. It is a scripting language which tiles into the JavaScript game engine via a memory mapper using memory mapped I/O. Currently, I am porting the language as a standalone interpreter to be able to run on the PC and possibly other devices excluding the phone. The interpreter is being written in C++ so for those of you who are C++ fans you can see the different components implemented. Some background of the language and how to program in C-Lesh can be found here:

      http://www.codeloader.net/readme.html
      As I program this thing I will post code from different components and explain.
    • By isu diss
      I'm trying to duplicate vertices using std::map to be used in a vertex buffer. I don't get the correct index buffer(myInds) or vertex buffer(myVerts). I can get the index array from FBX but it differs from what I get in the following std::map code. Any help is much appreciated.
      struct FBXVTX { XMFLOAT3 Position; XMFLOAT2 TextureCoord; XMFLOAT3 Normal; }; std::map< FBXVTX, int > myVertsMap; std::vector<FBXVTX> myVerts; std::vector<int> myInds; HRESULT FBXLoader::Open(HWND hWnd, char* Filename, bool UsePositionOnly) { HRESULT hr = S_OK; if (FBXM) { FBXIOS = FbxIOSettings::Create(FBXM, IOSROOT); FBXM->SetIOSettings(FBXIOS); FBXI = FbxImporter::Create(FBXM, ""); if (!(FBXI->Initialize(Filename, -1, FBXIOS))) { hr = E_FAIL; MessageBox(hWnd, (wchar_t*)FBXI->GetStatus().GetErrorString(), TEXT("ALM"), MB_OK); } FBXS = FbxScene::Create(FBXM, "REALMS"); if (!FBXS) { hr = E_FAIL; MessageBox(hWnd, TEXT("Failed to create the scene"), TEXT("ALM"), MB_OK); } if (!(FBXI->Import(FBXS))) { hr = E_FAIL; MessageBox(hWnd, TEXT("Failed to import fbx file content into the scene"), TEXT("ALM"), MB_OK); } FbxAxisSystem OurAxisSystem = FbxAxisSystem::DirectX; FbxAxisSystem SceneAxisSystem = FBXS->GetGlobalSettings().GetAxisSystem(); if(SceneAxisSystem != OurAxisSystem) { FbxAxisSystem::DirectX.ConvertScene(FBXS); } FbxSystemUnit SceneSystemUnit = FBXS->GetGlobalSettings().GetSystemUnit(); if( SceneSystemUnit.GetScaleFactor() != 1.0 ) { FbxSystemUnit::cm.ConvertScene( FBXS ); } if (FBXI) FBXI->Destroy(); FbxNode* MainNode = FBXS->GetRootNode(); int NumKids = MainNode->GetChildCount(); FbxNode* ChildNode = NULL; for (int i=0; i<NumKids; i++) { ChildNode = MainNode->GetChild(i); FbxNodeAttribute* NodeAttribute = ChildNode->GetNodeAttribute(); if (NodeAttribute->GetAttributeType() == FbxNodeAttribute::eMesh) { FbxMesh* Mesh = ChildNode->GetMesh(); if (UsePositionOnly) { NumVertices = Mesh->GetControlPointsCount();//number of vertices MyV = new XMFLOAT3[NumVertices]; for (DWORD j = 0; j < NumVertices; j++) { FbxVector4 Vertex = Mesh->GetControlPointAt(j);//Gets the control point at the specified index. MyV[j] = XMFLOAT3((float)Vertex.mData[0], (float)Vertex.mData[1], (float)Vertex.mData[2]); } NumIndices = Mesh->GetPolygonVertexCount();//number of indices MyI = (DWORD*)Mesh->GetPolygonVertices();//index array } else { FbxLayerElementArrayTemplate<FbxVector2>* uvVertices = NULL; Mesh->GetTextureUV(&uvVertices); int idx = 0; for (int i = 0; i < Mesh->GetPolygonCount(); i++)//polygon(=mostly triangle) count { for (int j = 0; j < Mesh->GetPolygonSize(i); j++)//retrieves number of vertices in a polygon { FBXVTX myVert; int p_index = 3*i+j; int t_index = Mesh->GetTextureUVIndex(i, j); FbxVector4 Vertex = Mesh->GetControlPointAt(p_index);//Gets the control point at the specified index. myVert.Position = XMFLOAT3((float)Vertex.mData[0], (float)Vertex.mData[1], (float)Vertex.mData[2]); FbxVector4 Normal; Mesh->GetPolygonVertexNormal(i, j, Normal); myVert.Normal = XMFLOAT3((float)Normal.mData[0], (float)Normal.mData[1], (float)Normal.mData[2]); FbxVector2 uv = uvVertices->GetAt(t_index); myVert.TextureCoord = XMFLOAT2((float)uv.mData[0], (float)uv.mData[1]); if ( myVertsMap.find( myVert ) != myVertsMap.end() ) myInds.push_back( myVertsMap[ myVert ]); else { myVertsMap.insert( std::pair<FBXVTX, int> (myVert, idx ) ); myVerts.push_back(myVert); myInds.push_back(idx); idx++; } } } } } } } else { hr = E_FAIL; MessageBox(hWnd, TEXT("Failed to create the FBX Manager"), TEXT("ALM"), MB_OK); } return hr; } bool operator < ( const FBXVTX &lValue, const FBXVTX &rValue) { if (lValue.Position.x != rValue.Position.x) return(lValue.Position.x < rValue.Position.x); if (lValue.Position.y != rValue.Position.y) return(lValue.Position.y < rValue.Position.y); if (lValue.Position.z != rValue.Position.z) return(lValue.Position.z < rValue.Position.z); if (lValue.TextureCoord.x != rValue.TextureCoord.x) return(lValue.TextureCoord.x < rValue.TextureCoord.x); if (lValue.TextureCoord.y != rValue.TextureCoord.y) return(lValue.TextureCoord.y < rValue.TextureCoord.y); if (lValue.Normal.x != rValue.Normal.x) return(lValue.Normal.x < rValue.Normal.x); if (lValue.Normal.y != rValue.Normal.y) return(lValue.Normal.y < rValue.Normal.y); return(lValue.Normal.z < rValue.Normal.z); }  
    • By nick1
      Hello,

      I have limited programming experience in C++, but have always had a passion for games.  Where do I start?  I have a rough idea of the type of game I want to develop and am ready to commit the time necessary to learn new languages.  Are mobile games too difficult to begin with? Should I begin learning the basics of keyboard controls before attempting touch screens?  I would appreciate any input or advice!
      Thanks!
      Nick1
    • By khawk
      Dene Carter, Managing Directory @ Fluttermind LLC (@fluttermind)
      From Indie to Fable and Back. 30 Years of Wisdom.
      Started writing games in 1984 when he was 14 years old. What has he done in 33 years?
      Druid - Commodore 64 Original Dungeon Keeper core team Fable franchise and more Indie through AAA.
      "I am an idiot" - first learned in 1984, and every year after.
      Rockman - made $7500 for 2 weeks of work. Figured he could make 26 games a year, or $438k in today's money.
      Takeaway: Really stupid at 14.
      Even in 1980's, developer only got 12-14% royalties.
      (Side note: Dene is fun to listen to. Recommend this on the Vault when it goes online.)

      You are not your players.
      Made a black and white game on a Spectrum, which was color. Did it because he was poor. Problem is his audience were not poor, and had color TV's. Reviews were not nice. Players see things completely different to you. Do not forget that your players have not seen the game as much as you. Avoid difficulty/complexity-creep. The real world has distractions and beer - they don't care about your game as much as you do. Test your mobile game on the toilet - that's what your real players do. Fundamentally, players live inside their own brains, not yours. Those you ignore will ignore you in return. Design for your players' minds, not for you. Generalizing is Really useful
      "An expert who is too narrow has difficulty colaborationg" - Valve Employee Manual Did a lot of things over the course of his career. Everyone did everything in the 1980's and 1990's. Most developers generalized. Developing a broad skill-set aids communication. Large teams require collaboration and clear communication. Knowledge breeds respect (never say 'JUST'). 'Just' suggests a task is easy. It might not be. Ignorance is an energy. Don't forget you are human. You are designed to adapt and can do anything if you put your mind to it. Be a human. Learn a skill outside your area. Programmer learn how to 3D model. Artist learn how to code. Learn music, theater. Think of yourself as an artist. Rapid Team Growth is Dangerous
      "If your team can eat more than two pizzas, it's too large." Werner Vogels, Amazon VP/CTO Early Fable - 3 developers. Communication very easy. Later Fable, team grew bigger. At 12 people rumor mill started to develop. Can't have everyone in every meeting at same time. Pockets and cliques develop. Fred Brooks. Communication paths don't grow linearly. Team communication grows exponentially. [n * (n-1)] / 2 8 people on team, 28 connections. Ringelmann Effect - "Larger groups lead to less motivation & coordination & productivity." Decreased motivation - larger group, start to feel like a cog in the machine. Decreased coordination - communication pathways explode. Suggestion: Increase identifiability. Make sure everyone knows everyone's contribution. Most of all: think before growing your team. Blandness Has Its Uses
      Pursuit of excellence can be wasteful. Sounds counterintuitive. Blandness helps disguise repetition. Think reusing assets. Players notice the patterns. When asking for something to be made, communicate the context of assets - how will they be seen or heard? Often find they need to be bland. Prototypes Can Be Misleading
      Experiential games are difficult to prototype. More useful for mechanical games. Fable only came together at the very end - threw away at least one entire combat system. Looking back, it wasn't polished not necessarily bad. Bland prototypes are better than ugly ones for experiential. Keep prototype completely separate. Define prototypes success criteria. Art Style is More Important Than You Think
      Curate rather than create Style can hide the fact you can't draw. Restrict complexity. Style is marketing. Unique style tells players there may be something unique about your game. Streamline Your Process
      What is your iteration cost? Recognize your cost to try something and learn from it. Making your life easier is real work. Resist self-sabotage. (context of making tools) Closing Thoughts
      Don't let technology dictate your game's core promise. Static screenshots have to look good, too. No 1 pixel lines. Don't worry about the things people don't ever get to see. Don't panic if your game sucks - fix it. Editor thought: Really enjoyed this talk. Dene is a fun speaker, and his advice was raw, real world advice for anyone aspiring to make it in game development.
  • Advertisement