For a while now I've been pretty demotivated, just trying to kill time day by day and working towards the weekend. Eat. Sleep. Work.
In the past I've been more creative in my free time and tried a lot of things, from video editing, to playing guitar, playing drums and more. Lately work has been quite straining and I lost all strive and just wanted to relax at home and get away from anything that seemed like work. I started to miss being creative, but could not force myself to do anything.
So recently I bought Black Ops 2 and now ended up making emblems more than I actually play the game. It felt really good to be creative again and fueled by that and my recent interest in small indie games, I got the idea for my own little game and try my hand at game creation.
I've been working as an application programmer for the past 9 years and have extensive knowledge in various programming languages, such as C, C++, C# (.NET), Delphi, Java. I never really tried to make games so far though and I reckon it's a whole different thing from application development, so that's where I'm not really sure if I can do it all.
I've researched a bit and was thinking about using Microsoft XNA for a first start, since it seems like a neat framework for beginners.
As for the game idea, I don't really want to say too much about it so far, but I was thinking to make a little space sim focussed on managing/upgrading your starship and crew, exploring the galaxy/planets, trading and combat. It is inspired by (the very awesome) FTL, but I'm planning to ultimatively go a different route of course.
I'll try to get started with getting to know the framework in the next days and then we'll see how I'll be able to progress from there. I know this will end up being a massive time sink and who knows if it'll ever be completed, but I'll at least try.
So anyone experienced with game development have any tips for a beginner?
Thanks for the encouragement and examples. They're both pretty awesome
So far I was going for 2D pixel sprite graphics, which are a little more within my abilities than full fledged 3D. If all fails I can still use some crude selfmade placeholder graphics for a start. Since I'm coming from the programming side that's probably my biggest focus for now.
You should probably use an existing engine, or take an existing engine and modify it, rather than write your own engine from scratch. It saves time and keeps you from "re-inventing the wheel": Unless you're making, say, a real time strategy game in which the engine is extremely important for unit behaviour, you should really just use an existing one.
Judging by the description of your game, I think an existing engine would work really well. Most games use existing engines, or modified versions of existing engines.
On November 27 2012 22:15 vOdToasT wrote: Some advice:
You should probably use an existing engine, or take an existing engine and modify it, rather than write your own engine from scratch. It saves time and keeps you from "re-inventing the wheel": Unless you're making, say, a real time strategy game in which the engine is extremely important for unit behaviour, you should really just use an existing one.
Judging by the description of your game, I think an existing engine would work really well. Most games use existing engines, or modified versions of existing engines.
It's a good idea to do some more research on existing engines and frameworks, that's right. I was thinking of doing a little more strategic approach, but most likely in real time.
On November 27 2012 22:29 Pandemona wrote: Make the game have Panda's in? :D
A race of spacefaring Pandas or a Panda planet, who knows, everything is possible :D
Take the advice of using a ready-to-go engine close to heart. It's easy for an inexperienced game developer to go too far trying to make an amazing engine, when they should have been focusing on making an amazing game. If you have previous development experience you may be more prone to this pitfall than those who are less inclined to code.
My advice is to get an engine that does a lot for you, I recommend Unity if you go 3D, and just make a game. Not a big commercial ready game, just a game. Allow the gameplay to be simple, but have all other aspects of the game be complete. Have a title screen, an intro, save/load, some music tracks and sound effects, and all the other stuff that "surrounds" the actual gameplay. Make the gameplay something like flying a ship around to collect some random objects then fly back to the start, or something simple like that. Just grab the sound effects off the internet, and the music too. Don't try to make it good, just complete. Only give yourself a week or two to do it, and don't worry about code quality or polish. Just get a game done.
Then up the stakes and make a prototype of the gameplay you have in mind for your real game. Don't worry about the extra "surrounding" fluff, just make something playable that represents what you have in your mind now. Pick the most defining characteristic of the gameplay and just get that working. Don't stop tinkering (again, don't worry about quality, just results) until you it's fun and you can see it working as a full game. Through even poor coding practice and hackish fix at it that you need to in order to get it functioning (not bug-free, just functioning) how you want the actual game to feel.
Just remember, it's much harder and more dangerous to make drastic tweaks to the gameplay in the real project than in a prototype. You can throw code all over the place and shoot yourself in the foot memory and performance-wise and still be successful if you end up with something fun to play. If you do that in the real project you're done for in the long run. Transferring from the prototype to the real project is usually very painless, because it's the concept of what you ended up with that is important, not how you got there. Consider that in a finished, polished commercial game, it's actually a rather small bit of code that is actually controlling the physics of the character. It's that perfectly tweaked bit of code that you're after in a prototype, not the implementation of it. Save figuring out a good implementation of it for after you know it achieves the effect you want. You may end up with a prototype that has 300 lines of code, where 295 are puke worthy garbage existing only to serve the remaining 5 lines that are actually golden and perfectly capture the way you want the player's ship to accelerate.
Once you have the experience of completing a game (or several, practice it in multiple engines), and you have reals, working, playable things as proof (prototypes) that you really can make a fun game out of your idea, that's when you start actually developing it.
Just remember to treat prototyping as a liberating experience. As a developer already you'll get the itch to make your code robust and really understand all the documentation, and so on. Set a specific goal for each prototype, and do only what is necessary to get that result. If you just dive into trying to make an engine for your big vision game right away, you'll end up spending almost all your time working toward an engine that does less than one that already existed, and very, very, very likely end up with gameplay that doesn't fit what you had in your head. Above all, focus on gaining experience before going for your big vision.
Thanks for the extensive advice, there's a lot of truth in there, some stuff which I actually still need to remind myself of on a daily basis at work.
I've checked out Unity before, but I'm not really sure if it fits my needs, or rather it's too powerful for what I need, but it's probably still worth to check out.
So far from what I have in mind I don't really need much apart from a simple 2D sprite engine that allows me to left/right-click somewhere and capture some basic key inputs. Overall the game will be quite static with a few animations and movements here and there. Keeping it simple for the first time around
Edit: Got a lot of conceptual work done today and I'll probably start to make a little prototype of the combat system later. It's actually not that much of a complicated part, but should be fun and quite insightful and a good test for the framework.
I think using an "engine" for a simple 2D sprite game will be counter productive when it comes to learning what's really going on. I just can't see what such a tool help anyone with: there's just not enough going on in a 2D world for a hand to need holding.
When I was into 2D stuff I got tonnes of mileage out of a library called Allegro. It's very simple and easy to use, there are a hundreds of examples and tutorials, and thousands of forum threads answering all possible questions you could think up. It made sprites and basic inputs a piece of cake.
The fact you have been programming and know C++ you should be able to learn game programming pretty easily I imagine. I would buy a book or something on game programming and since I imagine you understand C++ quiet a bit you should be able to understand the book.
I could be wrong, but that's what I would start off doing, also go to www.gamedev.net very great place for programming help or questions in developing games.
EPT
