How Do You Keep Challenging Yourself?
I'm taking a really slow class at my university this semester- I didn't realize that it would be over a month of review. Not sure when we're actually going to start covering new material, but feeling stuck is driving me insane. What do you guys do to stay focused and keep challenging yourselves?
I'm in the same boat. That's when I decided to go and start making my own data structures.
closed account (S6k9GNh0)
You create something. I've been bored after work lately so I started implemented the qpNetwork (query parser network which was supposed to abstract things like the mumble and teamspeak server query protocol with a lite, intuitive protocol, now its just something that connects to the server to do stuff lol).
I'll Agree with L B, although what I find is when you making a game you end up practicing more things indirectly related to C++ like openGL or SDL oppose to a pure C++ console window text adventure (Which I have a very hard time making because of the monotony; if anyone has found a way to make text adventures more interesting, please post it).
Rogue RPGs are awesome. If you choose to put in advanced world generation you'll also delve into some pretty neat programming concepts!
Just being me is challenging enough for me ;).
Joking aside, I've been thinking about making a game, but can't decide on what I want to do.
Joking aside, I've been thinking about making a game, but can't decide on what I want to do.
| pure C++ console window text adventure (Which I have a very hard time making because of the monotony; if anyone has found a way to make text adventures more interesting, please post it). |
Text adventure games are no more monotonous than any other kind of game if you design them properly. Harder? Possibly. Less fun for make and play? Definitely. But not necessarily more monotonous.
I went over some very basic ideas in another thread a long while back. Start reading the thread at this post:
http://www.cplusplus.com/forum/beginner/71141/#msg379639
The thing that makes adventure games so tricky is that they're so event heavy. Nearly everything is a special case... so it makes it hard to make an engine that is generic yet dynamic enough. That's where the real challenge (and fun) is.
If you find it monotonous, you're designing it wrong.
Last edited on
closed account (3qX21hU5)
| Nearly everything is a special case... so it makes it hard to make an engine that is generic yet dynamic enough. |
Now I agree with everything you posted Disch, but feel I should comment on the quote and make clear for other people that are considering making their first game or don't have much experience with game making.
For some reason whenever someone decides to go into game programming (myself included) they think they need to have a game engine. Well to put it plainly you don't and it goes much more smoothly when you skip the engine and just write the game. Now this doesn't really apply to AAA quality game only indie type games, but then again I don't think beginners would be creating AAA quality games anyways (No offense :P).
The reason why is that since they are just starting they have no idea what should go into a game engine and what should be left out, what code is going be to reusable and what code is pointless in a engine. The 99% of the time when someone creates a game engine it ends up one of two ways.
1) They spend days, months, even years on the engine and never actually start building their game code and just end up giving up. So they have a half complete engine that is just laying around and no game to speak of.
2) They actually do finish the engine and even the game, but it took 3 or 4 times as long as it should have (Because you made you engine). The game is also usually not what it could have been because you spent so much time on the engine itself. And the worst part of it all is most likely you are left with a engine that is built around a specific game and can not be used in the creation of other games.
The point of this is that they don't need a game engine to make a game, and it doesn't necisarilly make the game better if they use a engine.
Now I'm not against ever using a game engine, the complete opposite in fact. All I'm saying is if you are just beginning in game programming it would be much better to skip the game engine all together until you gain more understanding of what goes into a game and what is commonly reused. The whole point of a game engine is for it to be reused on variety of projects.
Now if you are still keen on writing a game engine while you just learning whether it be for learning purposes or to create a amazing game I ask you to just try this.
Instead of writing that game engine create 5 little games. In all them games start pulling out snippets of code that you tend to reuse or that you think would be helpful in other projects. Put all them codes into a library or something for safe keeping. Then after you finish them 5 projects go through all them snippets of code and look to see what ones you reused a lot on your projects. This will give you the starting blocks for your engine and also show you what should be in a engine and what shouldn't be.
Sorry for hijacking this thread with my post I have just been seeing a lot of people lately on forums asking how to make a game engine and also saying they need a engine for their game.
Also here is a article that puts what I was saying into much better words and is much easier to understand then my rambling.
http://scientificninja.com/blog/write-games-not-engines
Last edited on
| The reason why is that since they are just starting they have no idea what should go into a game engine and what should be left out, what code is going be to reusable and what code is pointless in a engine. |
What would you need for something to be an engine, in your context?
I make something interesting. Currently I'm doing my own eroge game project (with a free art source and voice) then when I get a bit bored of my erotic imagination I switch on webpage scripting. If all breaks down to boredom I switch to modding my Red Alert 2 game with a bit of assembly.
Engine seems to be a bit of a buzzword here and open to interpretation at that.
I understand that different people have different opinions of what constitutes an engine and that's fine. That said, depending on what you want to do with a game, in most cases it would be prudent to make use of one of the many available libraries out there.
My general advice for game projects:
If you're making a console (er, command line that is, not PS3) the good luck to you. It's not a bad place to start making games and it was the starting point on my university course (Computer Games Software Engineering, as it happens). However, it was mainly to teach basic C++ concepts more than anything else. If you're making a console game, you have to accept the limitations and understand that it's not what the console was made for.
If you're going 2D then fantastic. It's not as hard as you think, especially with the wealth of 2D libraries out there. For myriad reasons that I'll not go into here, I'd recommend SFML. If you're worried about the maths side of things, then get used to it; fact is that games programming relies heavily on maths, whether it's simple geometry to complex matrix math, it's going to be in there somewhere. Libraries such as SFML will usually cover rendering, sound and inputs, as well as some other features such as event handling which, by its very nature, C++ doesn't do all that well.
If you're going 3D then I'd say it is best to have some idea of what's going on under the hood. Yes, there are some nice 3D libraries out there (OGRE, for example) but I feel that it'd be of benefit to have some idea of how 3D transformations and translations etc work. To me, if you're thinking of making a 3D game then you've already decided to commit a fair amount of time to the project and, in that case, you might as well take a look at OpenGL/D3D (personally, I'd going for OpenGL).
Eventually the "engine" will write itself. If you write your code properly, you'll find that you can reuse it in other project.
I appreciate that this thread has become somewhat tangential to the original point and in to bring it full circle (and much of the reason I wrote this post) I'd agree with LB; make a game.
I understand that different people have different opinions of what constitutes an engine and that's fine. That said, depending on what you want to do with a game, in most cases it would be prudent to make use of one of the many available libraries out there.
My general advice for game projects:
If you're making a console (er, command line that is, not PS3) the good luck to you. It's not a bad place to start making games and it was the starting point on my university course (Computer Games Software Engineering, as it happens). However, it was mainly to teach basic C++ concepts more than anything else. If you're making a console game, you have to accept the limitations and understand that it's not what the console was made for.
If you're going 2D then fantastic. It's not as hard as you think, especially with the wealth of 2D libraries out there. For myriad reasons that I'll not go into here, I'd recommend SFML. If you're worried about the maths side of things, then get used to it; fact is that games programming relies heavily on maths, whether it's simple geometry to complex matrix math, it's going to be in there somewhere. Libraries such as SFML will usually cover rendering, sound and inputs, as well as some other features such as event handling which, by its very nature, C++ doesn't do all that well.
If you're going 3D then I'd say it is best to have some idea of what's going on under the hood. Yes, there are some nice 3D libraries out there (OGRE, for example) but I feel that it'd be of benefit to have some idea of how 3D transformations and translations etc work. To me, if you're thinking of making a 3D game then you've already decided to commit a fair amount of time to the project and, in that case, you might as well take a look at OpenGL/D3D (personally, I'd going for OpenGL).
Eventually the "engine" will write itself. If you write your code properly, you'll find that you can reuse it in other project.
I appreciate that this thread has become somewhat tangential to the original point and in to bring it full circle (and much of the reason I wrote this post) I'd agree with LB; make a game.
closed account (3qX21hU5)
| What would you need for something to be an engine, in your context? |
Now that I reread what I posted I realise I being kind of vague since there are plenty of different types of engines (Physics, Graphics, Audio, and so on).
What was I talking about was a Game Engine which is usually defined by having multiple different engines wrapped up into one. Some examples are the Unity Game Engine, Unreal Engine, ect.
Last edited on
| Ive been making a hobo simulator with sdl. |
Huh? Does it get drunk and ask the user for spare change?
More importantly do they carry bindles made with colorful polka dotted material and what's the chance they get kicked off a train on a given trip?
Topic archived. No new replies allowed.