turn based strategy game ... how to start?

Started by
6 comments, last by greentiger 12 years, 9 months ago
I'm not a great programmer, indeed I can only program PHP and MySQL.
I have attempted to learn python in the past but still haven't managed that hurdle yet--I was going to see if I could fiddle and come up with something like GalaxyMage.
Is there anyone out there that likes to guide burgeoning programmers? or are there tutorials that would teach me how to create something like GalaxyMage at my own pace?
I'm sure that once I get something tangible going I'll be able to get more people involved, but getting started is the hardest part.
Are there any books that help teach how to build something like GalaxyMage?
Any help would be appreciated.
Advertisement
I don't know if there are any books that deal with this specifically, but most of what is required is somewhere on the net. You need to break it down to basic parts : rendering, logic, sound, etc. You will need to figure out how you want the game to look and play first, then you should be able to find some tutorials/engines that deal with these particular problems. The rest is building on them to glue it all together.
Developer for Novus Dawn : a [s]Flash[/s] Unity Isometric Tactical RPG - Forums - Facebook - DevLog
I agree. It's all about breaking it down and building the small bits of it. I doubt you'll find an in-depth tutorial on how to make the game _______, but there are tons of tutorials that teach little bits of it.

I would start by picking a language and an engine (for python, pyGame and panda3D are always good choices). Then I would start asking questions. For example, what goes into galaxyMage? You see a 2D menu system, drawing sprites in 3D space, a 3D tile-based map, lighting, and etc. Well there you go, already you have some google keywords to start you off. :)
not sure this will help, but you could check out "Going to War, creating computer war games" by Jason Darby
Before you even type your first line or think of an engine you need to DESIGN every aspect of your game. Everything! Think out every single character, item, menu, enemy, level, storyline, setting, sound. Then I suggest you scope the project out to a small tiny little prototype. This prototype should have every "functional" piece of the game in it in as small a package as possible. After you have your design down and your prototype thought out you need to DESIGN your code. Plan out all the interfaces, classes, subsystems and their most important interactions. After your finished designing the game THEN you start coding!!

You need to get the whole thing thought out on paper before you try to put it together. You don't build a house without a blueprint right?

Maybe start with a smaller project like a pong clone and go through designing the whole thing and coding it before moving up.

Before you even type your first line or think of an engine you need to DESIGN every aspect of your game. Everything!



Could be that I've developed bad habits from making games under such tight deadlines, but I disagree.
You can start writing a lot of code as soon as you know if you want the game to be in 2D or 3D, and while developing your engine there's no need to know which classes will handle the AI.


This is especially true for your first attempt. Ending up with clumsly designed code is a lot better than getting bored and quitting without even writing your first line of code.
The most important thing is to plan AI before physics and physics before graphics. Otherwise you might never finish your game by making a physical problem that the AI can't solve or designing something that your physics can't simulate fast enough.

Make a simple pathfinding prototype in Visual Basic or Java to get an idea about what things that need to be destroyable.
In my strategy game, I spent months on a 2000 line pathfinding algorithm based on Dijkstra's just to find out that my game would be more fun and dynamic with A* written with about 20 lines. :o

Use a visual representation of the things that you are debugging and assert all assumptions and preconditions that are easily defined.

I don't know if there are any books that deal with this specifically, but most of what is required is somewhere on the net. You need to break it down to basic parts : rendering, logic, sound, etc. You will need to figure out how you want the game to look and play first, then you should be able to find some tutorials/engines that deal with these particular problems. The rest is building on them to glue it all together.



I agree. It's all about breaking it down and building the small bits of it. I doubt you'll find an in-depth tutorial on how to make the game _______, but there are tons of tutorials that teach little bits of it.

I would start by picking a language and an engine (for python, pyGame and panda3D are always good choices). Then I would start asking questions. For example, what goes into galaxyMage? You see a 2D menu system, drawing sprites in 3D space, a 3D tile-based map, lighting, and etc. Well there you go, already you have some google keywords to start you off. :)


Well I'm trying retackle the problem with Python. I've set myself up with Python 2.5, pygame, numpy, numarray, and pyopengl. I'm familiar with the concept of a game loop and breaking them up. Funny you should mention GalaxyMage since I was volunteering for designer for that project before he left for Real Life (though I never got involved with GalaxyMage Redux). I was hoping to break down the source files into the components themselves: main for the main loop, sound.py, video.py, menuing.py, etc ... (but I was hoping for a basic this is how you should build type X game thing. I really wish I had the early source of GalaxyMage where it was a tile drawing proving ground.


not sure this will help, but you could check out "Going to War, creating computer war games" by Jason Darby



Before you even type your first line or think of an engine you need to DESIGN every aspect of your game. Everything! Think out every single character, item, menu, enemy, level, storyline, setting, sound. Then I suggest you scope the project out to a small tiny little prototype. This prototype should have every "functional" piece of the game in it in as small a package as possible. After you have your design down and your prototype thought out you need to DESIGN your code. Plan out all the interfaces, classes, subsystems and their most important interactions. After your finished designing the game THEN you start coding!!
....


The design document I have is fairly detailed and thought out (although not everything is covered) and is about 22 pages long. Have a good design document, I agree, is important. I will probably check out the book (Going to War) this fall if this attempt fails :-).


The most important thing is to plan AI before physics and physics before graphics. Otherwise you might never finish your game by making a physical problem that the AI can't solve or designing something that your physics can't simulate fast enough.
....


Definitely something to consider, I will look into this.

This topic is closed to new replies.

Advertisement