• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
GraySnakeGenocide

Anyone else run into the "idk what programs to make" issue?

34 posts in this topic

Someone told me the order I should work on things is as follows:

 

1. c++ basics (types, functions, classes, pointers, includes <iostream> <fstream> <sstream> <stdio.h>)
2. sdl with the posted tutorial and/or sfml
3. opengl

 

thing is, i have no idea how to use those libraries. Letalone what programs to make using them.

0

Share this post


Link to post
Share on other sites

I can honestly say I've never had that problem.

 

I got into this to make games like the games I love to play. I never worried about doing things or learning things in the right order, following some kind of schedule, or asking to be told what to do. Back when I was learning how to make games, everyone else was, too. There wasn't an internet to go to if I ran into a little bit of trouble. There were a few books I could buy, some of which helped me a good deal, but the vast majority of my learning came from trying to make games. If you worry too much about doing things in the proper order, let yourself dwell too much on how big the job is, etc... you stand the very real risk of total paralysis. Just figure out what game you want to make, then figure out what you need to do and learn in order to make it. If it turns out to be too big for you, try again or try a simpler one. But you'll learn far more from even failing at a project than you ever will lurking around on forums fretting about what to make or what order to learn things.

 

I want to make games too but you have to crawl before you walk, walk before you run, etc.

 

I have a LOT of books, a very good one in C++ Primer, but I get sick of reading so quick that I am not really going anywhere.

0

Share this post


Link to post
Share on other sites

And it doesn't help the only games I can think of making are 3D.

 

AKA big projects that I shouldn't be focusing on as someone who hasn't really programmed squat in the 4-5 years I have been on/off programming.

0

Share this post


Link to post
Share on other sites

I think any game designer runs into this problem on a regular basis! 

 

First, there is good advice given by the previous posters about "just go for it". Expecting too much of yourself is usually counter-productive so you do have to just see what you can currently do and go from there...

 

Second, if you want to learn 3D then I recommend starting with a ray-caster engine.  If you're using C++ then I'll assume you are a windows user and suggest you forget about all these game libraries and just use the WindowsAPI. So long as you can draw a single dot on the screen, get keyboard & mouse input, then you can do 3D programming. Its then a question of how good your maths and software development skills are! happy.png

 

Third, whatever you do - good luck - but just start off small. Make a simple game in 3D and see it through to the end. As already said - it doesn't need to be perfect, just a start and something to show to others.  You will get some who say its shit, but hey, we can't all be Elves from Rivendale, can we? happy.png

 

"Brother, I would spare you that pain..." Ramirez, Highlander

 

When I first started out, I spent about six months learning C and skimming over C++. After a quick command-line RPG game, I went straight into the bells and whistles of DirectX. There was something called WinAPI and GDI along the way, which I spent a few pages on, and went charging into API-madness like a bull in a china shop. To be honest, I really didn't have a clue what I was doing and it was painful, and whilst I managed to make a 2D blaster or two, I came away with the conclusion that I needed to go back and learn C++ PROPERLY, and even then, a few games later, I realised that skimming WinAPI and GDI was a mistake. So, don't be in a rush. Spend time learning your language first, then whatever you need next.  You don't need to do everything all in one go...

Edited by Anri
1

Share this post


Link to post
Share on other sites

WinAPI and drawing dots with GDI? Sorry but I think that might be some of the worst ways to start with (3D) programming. If you start with a really high level toolkit like unity, then you can do things in minutes for which you might need years (if you have the endurance) going the way you have mentioned. Yes you won't understand what is going on in the background but you can learn that later or don't bother at all and continue making games.

0

Share this post


Link to post
Share on other sites

Learn what you need, as you need it, as you go along.

 

forget about object oriented C++ clasess. unnecessary overhead. unnecessary typing. and virtual methods are slower than non-virtual or regular code. use straight c code in a c++ compiler for the stronger compile time type checking.  Use the standard C++ libraries and DirectX, unless you're targeting an Open GL only platform. for most PC's, DirectX is whats on the user's machine. If you ever plan on making games to sell, not requiring installation of OpenGL is a positive selling point. Also, vidcard driver support for directx is probably greater overall than that for OpenGL. And odds are there are more games made with DirectX than openGL, so any future project you become involved with will be more likely to use directx than openGL. While both are similar, already being versed in the one you're going to use helps. So even at the very start of a gamedev career, market forces influence what you do. In this case what poly engine library to learn.

 

Stay away from other libs like GDI, STL, templates, frameworks, and all that kind of junk. none of that stuff is for games, and just mucks things up.

 

I've been building games for 25 years. over time, programmers collect algo's into their "bag of tricks". code that they rely on again and again to get the job done. for making games, i've consolidated that bag of tricks into just 3000 lines of code that is a thin wrapper over directx. directx is rather verbose with lots of long variable and function names, and requires a lot of typing. The thin wrapper makes it less work: aniso(onoff) vs D3DSetTextureFilterSomethngOrAnother(Blah,Blah,Blah.........).

the "library" provides wrappers for directx, file io, mouse, windows message processing, keyboard input, string conversion, and random number generation. all wrappers compile inline.

the "library" also adds the following capabilities to directX: timer system; popup menu system; mesh, texture, model and animation databases; a limb based animation system; and matrix and string manipulators.

but the most important technology in the library is the drawlist. the drawlist queues all drawing calls, then sorts them based on the optimal order directx desires, then sends them off to directx for drawing.

these are representative of the types of capabilities needed in a generic gamedev library. As you can see, WINAPI, STL, MFC, GDI, and all the rest of that !^#@#%^$#*&^#@*%@!!!! stuff have none of this.

 

A minimal amount of windows API will be required to create a window class, register it, create a window, then go 3d and kiss windows goodbye! (yeah!).

a minimal windows message handler and window procedure will be required for mouse input.

 

as for what game to make....

well, the answer is obvious:

you make what you want to play and isn't already out there!

if you don't want to play it, odds are others won't want to either.

if you don't want to play it, you won't be motivated. might as well be programming databases for all the thrill you'll get at the end when you can use what you've built. if you're not motivated, you won't CARE about the project with the same passion, and the quality of your work will show it.

if its already out there, you don't need to built it, you can just go buy a copy and play it. in this case, building it would simply be an educational exercise. Nothing wrong with that, but another team has a head start, and it would be more work to eventually compete against them commercially.

 

Since you're just starting out and this will be for learning, not profit (at least at first), don't worry about whether there is already a game out there like it. this can actually be an advantage, as it gives you a working game to study and use as a reference for what you want to do.  So simply decide what _FOR_YOU_ would be the coolest type of game to build, and go for it. I emphasize the "for you" because this will be key in keeping you motivated though the learning curve.

 

If the types of games you want to make are 3D games, don't waste time on learning how to make other types of games. there is very little in the way of game building knowledge from Tetris that transfers to Skyrim.

 

Also, if you want to BUILD games, don't waste time learning how to mod a game someone else has ALREADY built.  While modding can be a somewhat roundabout way to learn how 3d games are built, its not the same thing as building one yourself (think "pimp my ride" vs a hand-built high-end Ferrari). And you get locked into the mindset of the designer of the engine you mod, thinking all games should be made this way. many is the time i've lamented the fact that Wolf3D/DOOM/Quake (and every shooter like on tthem) uses "levels" (level maps). now everyone thinks of game environments in terms of level maps, and that level maps are the only way to make a game. For anything you want to do in a game, there's usually a number of possible algo's, each with its own advantages and disadvantages, and its own capabilities and limitations. Learning game design by modding only exposes you to the solutions chosen by the engine designer for their particular application. If you build it yourself, the first step is to learn what algo's are out there, then pick one or roll your own if none is suitable. By doing so you learn about all the ways something can be done, not just one that may or may not be appropriate for the project at hand.

 

keep your favorite C++ book at your side, your favorite DirectX book at your side, the directx docs on a shortcut on your desktop, and GO FOR IT!

 

you may be looking up every single word in a line of code at first, and it may take a whole day to get 5 lines to work right, but keep at it, and you'll get there. eventually, it all becomes easy, especially if you spend 12-18 hours a day thinking 3d.

1

Share this post


Link to post
Share on other sites

(1) watch the demoscene documentary and get inspired to create cool effects

https://vimeo.com/40192433

(2) make some demos!

(3) profit!  tongue.png

 

can start by doing a 4k intro doing pretty much just a GLSL or HLSL shader on fullscreen quad and go to demoparty (if you're in USA @party is in June http://atparty-demoscene.net/) and show it on the bigscreen and win fabulous prizes!

Edited by blackpawn
0

Share this post


Link to post
Share on other sites

Learn what you need, as you need it, as you go along.

 

forget about object oriented C++ clasess. unnecessary overhead. unnecessary typing. and virtual methods are slower than non-virtual or regular code. use straight c code in a c++ compiler for the stronger compile time type checking.  Use the standard C++ libraries and DirectX, unless you're targeting an Open GL only platform. for most PC's, DirectX is whats on the user's machine. If you ever plan on making games to sell, not requiring installation of OpenGL is a positive selling point. Also, vidcard driver support for directx is probably greater overall than that for OpenGL. And odds are there are more games made with DirectX than openGL, so any future project you become involved with will be more likely to use directx than openGL. While both are similar, already being versed in the one you're going to use helps. So even at the very start of a gamedev career, market forces influence what you do. In this case what poly engine library to learn.

 

Stay away from other libs like GDI, STL, templates, frameworks, and all that kind of junk. none of that stuff is for games, and just mucks things up.

 

I've been building games for 25 years. over time, programmers collect algo's into their "bag of tricks". code that they rely on again and again to get the job done. for making games, i've consolidated that bag of tricks into just 3000 lines of code that is a thin wrapper over directx. directx is rather verbose with lots of long variable and function names, and requires a lot of typing. The thin wrapper makes it less work: aniso(onoff) vs D3DSetTextureFilterSomethngOrAnother(Blah,Blah,Blah.........).

the "library" provides wrappers for directx, file io, mouse, windows message processing, keyboard input, string conversion, and random number generation. all wrappers compile inline.

the "library" also adds the following capabilities to directX: timer system; popup menu system; mesh, texture, model and animation databases; a limb based animation system; and matrix and string manipulators.

but the most important technology in the library is the drawlist. the drawlist queues all drawing calls, then sorts them based on the optimal order directx desires, then sends them off to directx for drawing.

these are representative of the types of capabilities needed in a generic gamedev library. As you can see, WINAPI, STL, MFC, GDI, and all the rest of that !^#@#%^$#*&^#@*%@!!!! stuff have none of this.

 

A minimal amount of windows API will be required to create a window class, register it, create a window, then go 3d and kiss windows goodbye! (yeah!).

a minimal windows message handler and window procedure will be required for mouse input.

 

as for what game to make....

well, the answer is obvious:

you make what you want to play and isn't already out there!

if you don't want to play it, odds are others won't want to either.

if you don't want to play it, you won't be motivated. might as well be programming databases for all the thrill you'll get at the end when you can use what you've built. if you're not motivated, you won't CARE about the project with the same passion, and the quality of your work will show it.

if its already out there, you don't need to built it, you can just go buy a copy and play it. in this case, building it would simply be an educational exercise. Nothing wrong with that, but another team has a head start, and it would be more work to eventually compete against them commercially.

 

Since you're just starting out and this will be for learning, not profit (at least at first), don't worry about whether there is already a game out there like it. this can actually be an advantage, as it gives you a working game to study and use as a reference for what you want to do.  So simply decide what _FOR_YOU_ would be the coolest type of game to build, and go for it. I emphasize the "for you" because this will be key in keeping you motivated though the learning curve.

 

If the types of games you want to make are 3D games, don't waste time on learning how to make other types of games. there is very little in the way of game building knowledge from Tetris that transfers to Skyrim.

 

Also, if you want to BUILD games, don't waste time learning how to mod a game someone else has ALREADY built.  While modding can be a somewhat roundabout way to learn how 3d games are built, its not the same thing as building one yourself (think "pimp my ride" vs a hand-built high-end Ferrari). And you get locked into the mindset of the designer of the engine you mod, thinking all games should be made this way. many is the time i've lamented the fact that Wolf3D/DOOM/Quake (and every shooter like on tthem) uses "levels" (level maps). now everyone thinks of game environments in terms of level maps, and that level maps are the only way to make a game. For anything you want to do in a game, there's usually a number of possible algo's, each with its own advantages and disadvantages, and its own capabilities and limitations. Learning game design by modding only exposes you to the solutions chosen by the engine designer for their particular application. If you build it yourself, the first step is to learn what algo's are out there, then pick one or roll your own if none is suitable. By doing so you learn about all the ways something can be done, not just one that may or may not be appropriate for the project at hand.

 

keep your favorite C++ book at your side, your favorite DirectX book at your side, the directx docs on a shortcut on your desktop, and GO FOR IT!

 

you may be looking up every single word in a line of code at first, and it may take a whole day to get 5 lines to work right, but keep at it, and you'll get there. eventually, it all becomes easy, especially if you spend 12-18 hours a day thinking 3d.

 

So I should forget OpenGL altogether?

 

I've been trying to figure out all of the crap I need to download aside from SDL for OpenGL.

 

I see a million things like FreeGLUT, GLFW, GLSL.

 

I figured DirectX was a microsoft only thing.

0

Share this post


Link to post
Share on other sites

So I should forget OpenGL altogether?
 
I've been trying to figure out all of the crap I need to download aside from SDL for OpenGL.
 
I see a million things like FreeGLUT, GLFW, GLSL.
 
I figured DirectX was a microsoft only thing.

DirectX is MS only, though Wine can offer emulation for other platforms.

This is a pretty complicated field you are looking to get into. It's not overtly difficult, per se; there are areas of computing that are more challenging than game development. Nevertheless, you are going to have to learn to deal with some complexity. Google is your friend. For instance, if you used Google properly you would know that GLFW, FreeGLUT and SDL all fall into the category of abstraction frameworks that make it easier to create a window and initialize OpenGL, so you only need one of those; while GLSL stands for the GL Shading Language and is the language you would use to write shaders. Forgetting OpenGL altogether won't remove from you the need to understand a technical framework (trade the GL API for the Direct3D one, trade GLSL for HLSL).

The other posters in this thread have offered some good advice: figure out what you want to do, then figure out the very simplest set of tools you need in order to accomplish it. Don't get overwhelmed worrying about all the latest 3- and 4- letter acronyms, the latest technologies, etc... Frameworks such as SDL and SFML offer abstractions so you don't have to worry (yet) about the deeper technical aspects of OpenGL or Direct3D. Move up to more advanced stuff once you have a good grasp of the basics.

And understand that nobody on this forum or any other is going to solve your problem for you. No amount of forum posting or question asking is going to replace the simple acts of closing your web browser and opening your IDE and applying your brain to the active process of learning by doing.
1

Share this post


Link to post
Share on other sites

blackpawn: while making demos sounds like fun, they do not help in teaching how to handle the interactive components that are present in games. Plus, a lot of demos involve generating procedural content on the fly, which can get pretty low level and therefor not as friendly for beginners (unless you're okay with your demo totalling several MB in pre-made assets).

 

My first experience with graphics programming was in SDL. I was able to get started sooner because I still haven't fully understood OOP at that time, but it wasn't necessary to make games with SDL.

 

I was still learning a lot about the C++ language with SDL, but I was able to make some basic scrolling shoot-em-ups (one with a ninja theme that I was proud of) and a Tetris Attack (Panel De Pon) clone with it. That puzzle game was coded sloppily and there were no menus, but it had a scoring system and game over condition that worked. To put it in perspective, the game was only one main.cpp file around 600 lines long. I could re-do it from scratch with a whole different approach, but the point is you don't have to be a big expert in any one area to make a playable game.

0

Share this post


Link to post
Share on other sites

sure, kinda depends where your interests are.  if you're interested in graphics and looking for something to make a game could turn into a massive undertaking involving not much of the fun graphics you were hoping to spend your time on. with small demos and intros near 100% of your time is on the visuals and cool stuff. code up a tunnel, add some glow, put some music to it with lots of bass, show it off to your friends and you may find that much more rewarding than mucking about on a more complicated project you may never finish and get that self motivating pay off from. all depends on personal interest i suppose but that's my recommendation for Bill. :)

 

blackpawn: while making demos sounds like fun, they do not help in teaching how to handle the interactive components that are present in games. Plus, a lot of demos involve generating procedural content on the fly, which can get pretty low level and therefor not as friendly for beginners (unless you're okay with your demo totalling several MB in pre-made assets).

0

Share this post


Link to post
Share on other sites

So I should forget OpenGL altogether?
 
I've been trying to figure out all of the crap I need to download aside from SDL for OpenGL.
 
I see a million things like FreeGLUT, GLFW, GLSL.
 
I figured DirectX was a microsoft only thing.

DirectX is MS only, though Wine can offer emulation for other platforms.

This is a pretty complicated field you are looking to get into. It's not overtly difficult, per se; there are areas of computing that are more challenging than game development. Nevertheless, you are going to have to learn to deal with some complexity. Google is your friend. For instance, if you used Google properly you would know that GLFW, FreeGLUT and SDL all fall into the category of abstraction frameworks that make it easier to create a window and initialize OpenGL, so you only need one of those; while GLSL stands for the GL Shading Language and is the language you would use to write shaders. Forgetting OpenGL altogether won't remove from you the need to understand a technical framework (trade the GL API for the Direct3D one, trade GLSL for HLSL).

The other posters in this thread have offered some good advice: figure out what you want to do, then figure out the very simplest set of tools you need in order to accomplish it. Don't get overwhelmed worrying about all the latest 3- and 4- letter acronyms, the latest technologies, etc... Frameworks such as SDL and SFML offer abstractions so you don't have to worry (yet) about the deeper technical aspects of OpenGL or Direct3D. Move up to more advanced stuff once you have a good grasp of the basics.

And understand that nobody on this forum or any other is going to solve your problem for you. No amount of forum posting or question asking is going to replace the simple acts of closing your web browser and opening your IDE and applying your brain to the active process of learning by doing.

 

that was...unnecessarily rude.

0

Share this post


Link to post
Share on other sites

WinAPI and drawing dots with GDI? Sorry but I think that might be some of the worst ways to start with (3D) programming. If you start with a really high level toolkit like unity, then you can do things in minutes for which you might need years (if you have the endurance) going the way you have mentioned. Yes you won't understand what is going on in the background but you can learn that later or don't bother at all and continue making games.

If Bill was to attempt something like COD in WinAPI and drawing Dots in GDI - then yes, you are correct. It would be bloody painful.  However, I was suggesting he start with a Wolfenstein-style ray-caster game, first.  That's is a gentle introduction to 3D before the likes of DirectX and OpenGL.  Windows API is readily available with minimum fuss, it only requires basic maths for raycasting and a knowledge of WinAPI allows one to make their own tool applications, which is of course useful for banging together level editors etc.  With that experience stuff like DX and OpenGL will be much easier to settle into and be more appreciative of them.

0

Share this post


Link to post
Share on other sites

I have a LOT of books, a very good one in C++ Primer, but I get sick of reading so quick that I am not really going anywhere.

 

Start doing its exercises and read what you need to complete them.. the exercises are normally complete programs that you can make so that answer you're initial question..

 

I didn't use to like reading books too much either.. When I read technical books I sometimes can't read more than one page.. other days I can read ten or even more, but I force my self to at least open them once every day so the last years I've read many.

 

As everyone else says, just get started..

0

Share this post


Link to post
Share on other sites

I plan to get started, using SDL/OpenGL.

 

Theres only a small issue though.

 

There are so many extentions/acronyms, that I don't know what I need/what I don't need.

 

People have said GLUT, FreeGLUT, are old/not to be used, which are like a smaller SDL, with better OpenGL support, instead use GLEW, there is GLSL (which I know is a shading language, which I assume is very important).

 

Someone also mentioned GLFW.

 

Problem with a lot of the tutorials I'm coming across, all use freeglut.

 

So I have no problem getting started, I just don't know what the heck I need TO get started.

0

Share this post


Link to post
Share on other sites

Don't worry about what you will use yet.. you need to spend time in front of your compiler and that C++ book of yours..

 

When you know a language you can move on to the question of what to use and it really doesn't matter.. write down all the alternatives on a paper and throw a dice if you have to.. just choose one and get some stuff up on the screen with it and play around with it.. If you want to make games faster you should probably look into using unity3d or something similar and C# instead..

 

If you really need someone to pick for you..

C++, SDL, OpenGL.. now, go on.. get started..

0

Share this post


Link to post
Share on other sites

And it doesn't help the only games I can think of making are 3D.

 

AKA big projects that I shouldn't be focusing on as someone who hasn't really programmed squat in the 4-5 years I have been on/off programming.

 

This, to me, is the telling sentence here.  I put in a full day of coding at my day job, then spend 2-3 hours a night working on my game project.  I live, eat, and breathe code, some of it which is as complex as game code, albeit in a different way.  I would imagine that most other coders here tend to live the same way.  If you're trying to pick up game programming at the same time you're trying to get back up to speed on coding, you're honestly fighting two battles.  You also didn't mention what your background and former work involved, so that factors into the choice of tools to use. 

 

I would suggest looking at using C#/XNA 4.0, along with Riemer's tutorials.  I have moved on from doing C#/XNA, but it was good to learn game coding techniques, and you can explore both 2D and 3D programming.  C# is a good general purpose language, too, and while MS seems to not be supporting XNA in the future, it's still good to learn with.  C++ is a whole other kind of beast and learning it while learning game coding techniques is honestly just asking to fail.

 

Start out with a Hello World sort of 2D game -- my first game was a cannon, guided by the mouse, that shot a cannonball at a moving target.  Simple, but enough to get a handle on input, game logic, game loop, etc.  Text-based games aren't going to help, and something 3D is probably too much at this point, so a simple 2D game is a good start.  You could even do a Frogger clone with a reasonable amount of work.

0

Share this post


Link to post
Share on other sites

And it doesn't help the only games I can think of making are 3D.

 

AKA big projects that I shouldn't be focusing on as someone who hasn't really programmed squat in the 4-5 years I have been on/off programming.

 

This, to me, is the telling sentence here.  I put in a full day of coding at my day job, then spend 2-3 hours a night working on my game project.  I live, eat, and breathe code, some of it which is as complex as game code, albeit in a different way.  I would imagine that most other coders here tend to live the same way.  If you're trying to pick up game programming at the same time you're trying to get back up to speed on coding, you're honestly fighting two battles.  You also didn't mention what your background and former work involved, so that factors into the choice of tools to use. 

 

I would suggest looking at using C#/XNA 4.0, along with Riemer's tutorials.  I have moved on from doing C#/XNA, but it was good to learn game coding techniques, and you can explore both 2D and 3D programming.  C# is a good general purpose language, too, and while MS seems to not be supporting XNA in the future, it's still good to learn with.  C++ is a whole other kind of beast and learning it while learning game coding techniques is honestly just asking to fail.

 

Start out with a Hello World sort of 2D game -- my first game was a cannon, guided by the mouse, that shot a cannonball at a moving target.  Simple, but enough to get a handle on input, game logic, game loop, etc.  Text-based games aren't going to help, and something 3D is probably too much at this point, so a simple 2D game is a good start.  You could even do a Frogger clone with a reasonable amount of work.

 

truth be told, I am sick of XNA/C#. I just can't keep interest in them.

0

Share this post


Link to post
Share on other sites

truth be told, I am sick of XNA/C#. I just can't keep interest in them.

This doesn't bode well...
0

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
Sign in to follow this  
Followers 0