Jump to content
  • Advertisement
lyth

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

  • Advertisement
  • Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By Gnollrunner
      Hi again,  After some looking around I have decided to base my game directly on Direct X rather than using an existing game engine.  Because of the nature of the stuff I'm doing it just didn't seem to fit very well and I kept running into road blocks.  At this point I have a big blob of code for doing fractal world generation and some collision code,  and I'm trying to put it into some form that resembles a game engine.  Since I've never used one before It's a bit alien to me ..... so can someone direct me to a book, website, article, whatever... that covers this?  I'm mainly looking for stuff that covers C++ library design. I'm not adverse to using 3rd party tools for stuff I can used them for.
    • By Atwo Studios
      Hello everyone this is Anthony from Atwo Studios, as small indie company we have published 2 indie games using Game maker, one being ROY - Color Matching and the other being Solar Switch. Both can be found on iOS and the Google play store.

      For our third indie game we are wanting to make a golf puzzle based game, this would be on mobile too.

      Our current team consists of a designer,programmer and artist. I would like to add a person who is interested in making sounds effects/ music for our game.

      If you are interested in creating a game for portfolio work or just as a hobby, 
      please send me an email at : anthony@atwostudios.com

      PLEASE do attach any audio work so that my team and I can review it and determine if you are qualified for what we are looking for.

      Please check out our website for more information about us and the types of games we have made so far.
      atwostudios.com
      DOWN BELOW CAN BE FOUND VERY EARLY SNIPPET OF THE GAME TO GIVE YOU AN IDEA OF WHAT WE ARE MAKING.
      p.s. I am not a website designer
      2018-05-01_04-58-04.mp4
    • By mapmip
      Hi, I am fresh to database design, recently trying building my mobile multiplayer game, it will be something like pokemonGo.
      I have experience on MySQL, and I know some NoSQL engines like redis.
      I saw some existing game projects which store their data on both SQL database and noSQL database.
      Could anyone give some advice that what kind of data should store in SQL and what kind of data is better to be in noSQL.
      It would be nice if giving some real scenario examples.
      My understanding is data like user profile, purchase transactions should be in SQL.
      Field map information, enemy status can be NoSQL.  
    • By Shtabbbe
      I've had a game idea for a while, and I wanted to finally try to create it.
      Its a 2D open-world tile-based MMO. The concept is it is one world and multiplayer only, so everyone shares one world no matter region, platform, etc.
      I am having problems finding out what to use to start development, I tried Unity but saw some of the negatives and refrained and now im stuck, could anyone recommend some intermediate friendly 2D engines that can support what I am looking for? Preferably in languages that are or are somewhat like Java, C#, Python, JavaScript, Lua.
      Thanks for your help, im very new at this if you cant tell
    • By chiffre
      Introduction:
      In general my questions pertain to the differences between floating- and fixed-point data. Additionally I would like to understand when it can be advantageous to prefer fixed-point representation over floating-point representation in the context of vertex data and how the hardware deals with the different data-types. I believe I should be able to reduce the amount of data (bytes) necessary per vertex by choosing the most opportune representations for my vertex attributes. Thanks ahead of time if you, the reader, are considering the effort of reading this and helping me.
      I found an old topic that shows this is possible in principal, but I am not sure I understand what the pitfalls are when using fixed-point representation and whether there are any hardware-based performance advantages/disadvantages.
      (TLDR at bottom)
      The Actual Post:
      To my understanding HLSL/D3D11 offers not just the traditional floating point model in half-,single-, and double-precision, but also the fixed-point model in form of signed/unsigned normalized integers in 8-,10-,16-,24-, and 32-bit variants. Both models offer a finite sequence of "grid-points". The obvious difference between the two models is that the fixed-point model offers a constant spacing between values in the normalized range of [0,1] or [-1,1], while the floating point model allows for smaller "deltas" as you get closer to 0, and larger "deltas" the further you are away from 0.
      To add some context, let me define a struct as an example:
      struct VertexData { float[3] position; //3x32-bits float[2] texCoord; //2x32-bits float[3] normals; //3x32-bits } //Total of 32 bytes Every vertex gets a position, a coordinate on my texture, and a normal to do some light calculations. In this case we have 8x32=256bits per vertex. Since the texture coordinates lie in the interval [0,1] and the normal vector components are in the interval [-1,1] it would seem useful to use normalized representation as suggested in the topic linked at the top of the post. The texture coordinates might as well be represented in a fixed-point model, because it seems most useful to be able to sample the texture in a uniform manner, as the pixels don't get any "denser" as we get closer to 0. In other words the "delta" does not need to become any smaller as the texture coordinates approach (0,0). A similar argument can be made for the normal-vector, as a normal vector should be normalized anyway, and we want as many points as possible on the sphere around (0,0,0) with a radius of 1, and we don't care about precision around the origin. Even if we have large textures such as 4k by 4k (or the maximum allowed by D3D11, 16k by 16k) we only need as many grid-points on one axis, as there are pixels on one axis. An unsigned normalized 14 bit integer would be ideal, but because it is both unsupported and impractical, we will stick to an unsigned normalized 16 bit integer. The same type should take care of the normal vector coordinates, and might even be a bit overkill.
      struct VertexData { float[3] position; //3x32-bits uint16_t[2] texCoord; //2x16bits uint16_t[3] normals; //3x16bits } //Total of 22 bytes Seems like a good start, and we might even be able to take it further, but before we pursue that path, here is my first question: can the GPU even work with the data in this format, or is all I have accomplished minimizing CPU-side RAM usage? Does the GPU have to convert the texture coordinates back to a floating-point model when I hand them over to the sampler in my pixel shader? I have looked up the data types for HLSL and I am not sure I even comprehend how to declare the vertex input type in HLSL. Would the following work?
      struct VertexInputType { float3 pos; //this one is obvious unorm half2 tex; //half corresponds to a 16-bit float, so I assume this is wrong, but this the only 16-bit type I found on the linked MSDN site snorm half3 normal; //same as above } I assume this is possible somehow, as I have found input element formats such as: DXGI_FORMAT_R16G16B16A16_SNORM and DXGI_FORMAT_R16G16B16A16_UNORM (also available with a different number of components, as well as different component lengths). I might have to avoid 3-component vectors because there is no 3-component 16-bit input element format, but that is the least of my worries. The next question would be: what happens with my normals if I try to do lighting calculations with them in such a normalized-fixed-point format? Is there no issue as long as I take care not to mix floating- and fixed-point data? Or would that work as well? In general this gives rise to the question: how does the GPU handle fixed-point arithmetic? Is it the same as integer-arithmetic, and/or is it faster/slower than floating-point arithmetic?
      Assuming that we still have a valid and useful VertexData format, how far could I take this while remaining on the sensible side of what could be called optimization? Theoretically I could use the an input element format such as DXGI_FORMAT_R10G10B10A2_UNORM to pack my normal coordinates into a 10-bit fixed-point format, and my verticies (in object space) might even be representable in a 16-bit unsigned normalized fixed-point format. That way I could end up with something like the following struct:
      struct VertexData { uint16_t[3] pos; //3x16bits uint16_t[2] texCoord; //2x16bits uint32_t packedNormals; //10+10+10+2bits } //Total of 14 bytes Could I use a vertex structure like this without too much performance-loss on the GPU-side? If the GPU has to execute some sort of unpacking algorithm in the background I might as well let it be. In the end I have a functioning deferred renderer, but I would like to reduce the memory footprint of the huge amount of vertecies involved in rendering my landscape. 
      TLDR: I have a lot of vertices that I need to render and I want to reduce the RAM-usage without introducing crazy compression/decompression algorithms to the CPU or GPU. I am hoping to find a solution by involving fixed-point data-types, but I am not exactly sure how how that would work.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!