Sign in to follow this  
Rich Brighton

Strategy Game: Language and other questions

Recommended Posts

[size="3"]I’m interested in making a simultaneous movement, hex based, grand strategy game. However my first major goal is much more modest: to create a basic, simultaneous turn/segment strategic movement and combat programme. I want to separate the UI from the core process. The UI will initially be kept to an absolute minimum. For starters it may not even be graphical, certainly not 3D just enough for me to develop the core functionality. Data will be copied to the UI. The UI should have no access to the internal data of the core at all and should only interact through messages. How easy is it to set up the UI as a separate process? Am I right to say that for Windows a process is different from a thread? In the long term I want to have multiple UIs, but the core will interface with the user, the same regardless of, whether it is an AI or a UI for a human user.[/size]

[size="3"]I had initially started some coding earlier in C++, DirectX 11 and got caught up in the graphical interface. I became doubtful that C++ was the right language to use for my project. I’m now, thinking of using C#. I would like bounds checking and higher level functionality. As I understand it in C++, a library function, whether written by oneself or from whatever source can potentially over write code and data just about anywhere, including the operating system. Is this correct? Making bug finding a potential nightmare. Is this also true for C#? However I’m sceptical that the object orientated paradigm is the right one for strategy games or for my natural programming style. Although I hope to produce something that is innovative in terms of game play, I can’t imagine that I need anything particularly innovative in terms of programming. My brief exploration of C++, windows programming and Directx left me repeatedly feeling that I was reinventing the wheel. I was thinking of using XNA, until I found out that it still doesn’t support 64 bit and seems to be designed around making things for old hardware. I’m not interested in complicating things or limiting things by catering for 32 bit processors, pre DirectX 10 hardware or operating systems.[/size]

[size="3"]So any thoughts about programming language, libraries, or any other aspect of this project, would be much appreciated.[/size]

Share this post


Link to post
Share on other sites
" I became doubtful that C++ was the right language to use for my project."

Given that much of the world successfully uses C++ to do engineering projects far far in excess of the complexity of what you're trying to achieve, I think you're casting aspersions without much weight to back them up.

Having said that, C++ is a many-edged blade. It takes a long time to go from a standing start to proficiency with it.

C# is actually not much of an improvement on this front.

Might I suggest, under the circumstances, looking at something involving Python. It's not exactly my favourite programming language, but it does have the advantage of being easier to learn than C++/C#. You could fairly easily write both halves of your game in it -- PyGame for the interface and normal python for the server.


Share this post


Link to post
Share on other sites
I've gone for C#. I realised if I put the human interface(s) in a separate process, then i could build the main app as 64bit and still use XNA for a relatively quick and dirty GUI. (Quick in terms of programming not in terms runtime.) I'm using Andrew Troelsen's Pro C# 2010 and am really enjoying it.

My first task is to implement the terrain. The obvious path is to create a Hex class, with various fields: terrain, altitude, population etc and then instantiate a two dimensional array of Hex objects. However if most of the operations on the Hexs are performed on a single field of multiple Hexes, will this not be very inefficient in terms of utilisation of memory cache? Would it be better to create a class/ struct for the whole world with fields of two dimensional arrays, a 2 dim array of terrains, a 2 dim array of populations etc? In c# structs are passed by value, while arrays are passed by ref. If I have a struct that consists of arrays will this be passed by ref or value, or is such a struct illegal? Presumably this question of data organisation must be common to most game programmes?

In essence is a windows process identical to a an instantiation of an application? Is their a high over head for using multiple processes over multiple threads? Supposedly Processes can't share memory resources. Is this totally correct? When using DirectX buffers for example isn't your programme and the Windows system Graphics driver process both using the same memory?

Edit, I think I'm beginning to understand processes. Basically what the ordinary user of windows thinks of as an application doesn't have much significance in terms of the windows operating system? The windows operating system deals in processes? But then what do the entries in the application tab of the Windows task manager mean? If I have multiple windows of fire fox or Microsoft Word it list them as separate applications.

[b]
[/b]

Share this post


Link to post
Share on other sites
This has me interested as I've started several 2d hex-based strategy games in C#, then I ditched hexes and made a game using free-form regions, and just last week finished a small hex-based strategy game again.

[quote]Would it be better to create a class/ struct for the whole world with fields of two dimensional arrays, a 2 dim array of terrains, a 2 dim array of populations etc?[/quote]
I'm really not sure here. How many hexes are you thinking of? When I made my first hex game engine, I made a very simple Hex struct that had the math in it, and an ID number. This was used for connecting the hexes together. Then my game's hex objects with terrain etc were in a simple 1d array, accessible using the ID from the hex struct.

Depending on how many hexes there are, it might not really matter. If your hex objects are all created once, you won't have to worry about GC slowing anything down.

For graphics rendering in one project I used SlimDX which was great, and in my most recent I used plain GDI+, partly because I wanted really easy deployment and fast loading. SlimDX took 1/2 second to initialize, and required a 10mb download and installation. Granted the download and installation were automated in my other project, it really wasn't a hassle using it. I don't recommend GDI+, it just was convenient for what I had to do.

[quote]If I have a struct that consists of arrays will this be passed by ref or value, or is such a struct illegal? Presumably this question of data organisation must be common to most game programmes?[/quote]
Your "Main" class that contains the arrays of game objects should be a class not a struct. When you have an array of structs and you access one, it copies it. Then if you want to change parts of it, you have to assign your copy back into its place in the array. I only really use structs for tiny data containers that I only read the data from during the game.

Regarding processes/threads, your game will only need to be a single process. You can have multiple threads in one process. In my DirectX game I have one thread doing the rendering and another handling user input and doing everything else. The rendering thread has read access to all of the game variables and data, and it just draws everything in its current state each frame.

Finally, I wouldn't worry about performance unless it actually becomes an issue, and then use the Stopwatch to find exactly where the slowdown is. The only place performance ever became an issue for me was rendering certain things in GDI+. It depends on the scale of your project, but if it's your first attempt at a strategy game, you might not run into any performance issues at all.

Share this post


Link to post
Share on other sites
I decided to go for a two dimensional array of objects of a class hex. However I'm stuck as to how to access them, the dimension sizes are not known at compile time. The array can be created at runtime using 'new'. but how do I access it from outside of the method that constructs it? In C++, I just created a global pointer to a Hex object, which could then be set to point to the array by the function that actually creates the array when then the dimensions are known. I can use pointers in C# of course, but is there anyway to avoid pointers and do this while maintaining the safe managed environment?

Share this post


Link to post
Share on other sites
[quote name='Rich Brighton' timestamp='1302351924' post='4796306']
[size="3"]I’m interested in making a simultaneous movement, hex based, grand strategy game. However my first major goal is much more modest: to create a basic, simultaneous turn/segment strategic movement and combat programme. I want to separate the UI from the core process. The UI will initially be kept to an absolute minimum. For starters it may not even be graphical, certainly not 3D just enough for me to develop the core functionality. Data will be copied to the UI. The UI should have no access to the internal data of the core at all and should only interact through messages. How easy is it to set up the UI as a separate process? Am I right to say that for Windows a process is different from a thread? In the long term I want to have multiple UIs, but the core will interface with the user, the same regardless of, whether it is an AI or a UI for a human user.[/size]

[size="3"]I had initially started some coding earlier in C++, DirectX 11 and got caught up in the graphical interface. I became doubtful that C++ was the right language to use for my project. I’m now, thinking of using C#. I would like bounds checking and higher level functionality. As I understand it in C++, a library function, whether written by oneself or from whatever source can potentially over write code and data just about anywhere, including the operating system. Is this correct? Making bug finding a potential nightmare. Is this also true for C#? However I’m sceptical that the object orientated paradigm is the right one for strategy games or for my natural programming style. Although I hope to produce something that is innovative in terms of game play, I can’t imagine that I need anything particularly innovative in terms of programming. My brief exploration of C++, windows programming and Directx left me repeatedly feeling that I was reinventing the wheel. I was thinking of using XNA, until I found out that it still doesn’t support 64 bit and seems to be designed around making things for old hardware. I’m not interested in complicating things or limiting things by catering for 32 bit processors, pre DirectX 10 hardware or operating systems.[/size]

[size="3"]So any thoughts about programming language, libraries, or any other aspect of this project, would be much appreciated.[/size]
[/quote]

Ok, a few questions

1) Why are you concerned with using a 64-bit capable library?
2) Why do you wish to use multi-threading?
3) What level of graphical fidelity are you looking for in the final game?
4) Why don't you think OO will be appropriate or useful for your project?

Using C++ is not going to destroy your computer or anything of the sort. I'm not an operating systems architecture expert, but I'm pretty sure most modern OS's sandbox memory spaces so an application can't just start overwriting memory all over the place. To attempt to do so will produce a seg-fault (segmentation fault) and kills the offending program before it does any damage.

Your concern stems from pointers. Pointers are a very common language feature that allow you to create variables that "point" to a specific address in memory. Using the pointer, you can access and modify values stored at that memory address. Pointers are mutable, meaning you can change the address that they point to to darn near anything you want. This can cause errors and weird behavior if you start overwriting the wrong section of memory. Often, these errors aren't strictly deterministic and can be very cryptic, but you get a feel for them and debugging them becomes not that bad.

A language like C# largely abstracts pointers away from you. They're still mostly there, but hidden and called "references" instead of pointers. The safety stems from making it way harder for you, the programmer, to re-define memory addresses directly. It also has a garbage collector, which takes care of disposing the memory pointers point to when it's no longer in us (C++ requires you to manually manage memory). While this makes things easier to work with, you can still screw up with C# plenty. You still need to know how pointers work, otherwise references (which are basically the same thing), are going to be fairly confusing. Even migrating to C# will not save you from pointers. The difference is that C++ hands you a loaded gun with the hammer cocked, while C# gives you a gun with the safety on. You can shoot yourself in the foot with both, but you have to work at it more with C#.

[quote name='Rich Brighton' timestamp='1303484004' post='4801631']
I decided to go for a two dimensional array of objects of a class hex. However I'm stuck as to how to access them, the dimension sizes are not known at compile time. The array can be created at runtime using 'new'. but how do I access it from outside of the method that constructs it? In C++, I just created a global pointer to a Hex object, which could then be set to point to the array by the function that actually creates the array when then the dimensions are known. I can use pointers in C# of course, but is there anyway to avoid pointers and do this while maintaining the safe managed environment?
[/quote]

[code]for(int i = 0; i < array.length; i++) {
for(int j = 0; j < array[i].length; j++) {
array[i][j] = //Do stuff
}
}[/code]

That will iterate over the each element in the 2D array not matter what its specific size is.

What you seem to be confused about is scoping.

Every variable exists within a scope. That scope determines its lifetime (when the program will destroy the variable) and is visibility (what can access the variable). The top level scope is the Global namespace. Everything in the program has visibility of variables in the global namespace, but it is generally considered poor practice to put lots of stuff in the global namespace. The only things that should exist in the global namespace are those that really need to be accessed by any object at any time. If you put lots of stuff in the global namespace, it becomes hard to keep track of what's being used where, and it becomes more likely that you're going to cause a naming conflict (two variables with the same name cannot exist in the same scope, but may exist in different scopes). Beyond that, scope for C# largely is defined by two things.

Object scope
Function scope

Every object that's created has its own private scope. That's why you can make two instances of a class [i]Car [/i]that contains the array [i]wheels[/i]. Even though there are two variables with the same name ([i]wheels[/i]), they're in separate objects so they're in separate scopes and do not conflict with each other.

A function also has its own scope. You can declare [i]int time[/i] in a million different functions if you want, and C# won't bat an eyelash. If you declare [i]int time[/i] twice in the same function, you have a problem.

There's also class level scope. A class can have variables that exist outside of functions, which makes them class-level. These variables can be freely accessed by any function within the class. This is almost like a mini-global namespace specific to that class.

So, in order to access that array in other parts of your program, you should probably make it a class-level variable. You can then refer to it freely in any part of that class, or through an object instance of that class.

Share this post


Link to post
Share on other sites
The games that I have enjoyed been inspired by are Medieval Total War and Rome Total War, the strategy part, I get bored by the battles, the civilastion serieses, the opertational art of war and the Paradox interactive games, particularly Eurpa Universalis, Victoria, and Hearts of Iron. What I'm interested in making is probably closest to the Paradox games in that they have simultaneous movement. They also have a large number of independent entities, nations, provinces, characters etc. Their games are processor limited. When you have two hundred odd countries checking their relations with 199 to other countries, you can soon start to burn serious numbers of CPU cycles. 32 bit is the past, 64 bit is the future, so I'd just like to start cleanly with 64 bit and not have to mess around at some time in the future trying to convert and recompile from 32 to 64.

I want the fundamental design to be able to leverage future increaseing processing capacity, which means more cores rather that faster cores.

I don't know if this project will catch other peoples imagination or not, I think it might, I've spent a fair amount of time on strategy game forums and have had friends who are into strategy games going back to the precomputer days of Squad leader, the Europa series, the Longest day, Third Reich and Fortress Europa, so I'm hopeful that might be on target for something that will appeal to Strat heads not just myself. The project will only get so far with just me. I want to make the easiest User interface that I can. But I want to design the system so someone can completly indepdendantly write a UI and plug it straght in.

I just don't like having OO forced on me. I think I'm one of those people who needs to learn by their own mistakes. Maybe I will be come an OO fan, I'm just not fully convinced yet. I can see how encapsulation can be really, really useful if you're writing a library, I'm not so sure that you need so much of it for a non libray project, partciularly where you are the only programmer.

I had done some coding in C++. I didn't get far enough into it to get to grips with the containers from the STL, but I think the best practice would have been to use a vector of vectors to implement the 2-D array. I find pointers very easy to use, and understand. The problem is that its so easy to introduce bugs in to the code with pointers, bugs that can be particularly difficult to track down. The best way to reduce bug finding time is to minimise their number in the first place, by very strong type checking and bounds checking.

Share this post


Link to post
Share on other sites
[quote name='Rich Brighton' timestamp='1303500603' post='4801712']
The games that I have enjoyed been inspired by are Medieval Total War and Rome Total War, the strategy part, I get bored by the battles, the civilastion serieses, the opertational art of war and the Paradox interactive games, particularly Eurpa Universalis, Victoria, and Hearts of Iron. What I'm interested in making is probably closest to the Paradox games in that they have simultaneous movement. They also have a large number of independent entities, nations, provinces, characters etc. Their games are processor limited. When you have two hundred odd countries checking their relations with 199 to other countries, you can soon start to burn serious numbers of CPU cycles. 32 bit is the past, 64 bit is the future, so I'd just like to start cleanly with 64 bit and not have to mess around at some time in the future trying to convert and recompile from 32 to 64.

I want the fundamental design to be able to leverage future increaseing processing capacity, which means more cores rather that faster cores.

I don't know if this project will catch other peoples imagination or not, I think it might, I've spent a fair amount of time on strategy game forums and have had friends who are into strategy games going back to the precomputer days of Squad leader, the Europa series, the Longest day, Third Reich and Fortress Europa, so I'm hopeful that might be on target for something that will appeal to Strat heads not just myself. The project will only get so far with just me. I want to make the easiest User interface that I can. But I want to design the system so someone can completly indepdendantly write a UI and plug it straght in.

I just don't like having OO forced on me. I think I'm one of those people who needs to learn by their own mistakes. Maybe I will be come an OO fan, I'm just not fully convinced yet. I can see how encapsulation can be really, really useful if you're writing a library, I'm not so sure that you need so much of it for a non libray project, partciularly where you are the only programmer.

I had done some coding in C++. I didn't get far enough into it to get to grips with the containers from the STL, but I think the best practice would have been to use a vector of vectors to implement the 2-D array. I find pointers very easy to use, and understand. The problem is that its so easy to introduce bugs in to the code with pointers, bugs that can be particularly difficult to track down. The best way to reduce bug finding time is to minimise their number in the first place, by very strong type checking and bounds checking.
[/quote]

Hmmmmmm.

Ok, I'm not a computer engineer, and my CS education did not dip tremendously far down into hardware, so my further advice will carry a disclaimer of "I'm not 100% sure but this is how I believe things work."

A 64-bit processor is just a processor that is capable of utilizing 64-bit memory addresses natively. That's it. It's not going to run any faster. There's no need to use it unless you are working with HUUUUUUUUGE (like 4gb) chunks of data, which you probably won't be. 64-bit processors run 32-bit code natively with no performance degradation, and in most cases, a 64-bit program is not going to significantly outperform a 32-bit program unless you're dealing with memory and register operations that greatly favor 64-bit code.

Multithreading is not easy to do, and not always directly applicable to games. It has its uses, and might actually be fairly appropriate for a real time strategy game if you're doing things like checking relations between a bunch of countries.

However.

Do not underestimate the modern PC. Modern computers are very fast. Super duper fast. You can still run into performance issues most def, but a dude making an indie game and coding it well can get away with a lot before he starts to bust out the multi-threading, especially considering your game is unlikely to be performing complex physics simulations, advance collision detection, or other functions that historically murder the CPU. If you're balking over relying on pointers and using C++ because of the introduction of hard to debug errors, you're going to have a hell of a time when you start trying to debug multithreaded programs. They're a lot harder to deal with. if you're finding pointers so easy to use, but are introducing crippling bugs you can't track down, then I don't think your grasp on pointers is as solid as you believe.

I'm confused about you insistence on 64-bit programming and multithreading, but your aversion to C++. You are probably going to get the most performance using C++ for the core of your game(depends on what you're doing, but for lots of games it is an incredibly powerful and efficient language to use). It might be harder to develop in, but that language is a boss. To shy away from it, then insist on 64-bit programming and multithreading (which aren't straightforward in their own right) is a very strange dichotomy.

There's a famous statement by someone whom I can remember that goes something like this.

"Premature optimization is the root of all evil."

It's very much true. Optimizing code is time intensive and hard to do. If your game runs at 60fps most of the time on your target platform, you're done! No more work needed! Write your code well, yes, and optimize when it doesn't take any considerable effort, but don't expend real effort optimizing code unless it's needed. I think by diving headfirst into 64-bit coding and multithreading, you might be jumping the gun on optimization.

Your statement about object oriented programming doesn't make much sense to me either. Languages and programming styles are tools, not poetry. No one's saying you have to use the OO style exclusively, you shouldn't, but by golly it's really useful. It can make big projects much more manageable, make code a lot cleaner, increase development speed, and facilitate re-use for the future. Refusing to learn OO is like saying, "Guys I want to be a lumber jack, but I don't want to use chainsaws because I don't like them." Suit yourself, but good luck cutting down that forest with an axe. Also, C# is pretty darn object oriented by nature, it's very much built into the framework. You kind of have to go out of your way to avoid it, which would be a strange thing to do.

The more languages you know, the more programming styles you know, the more tools you have at your disposal to write programs. No one really cares how you get there at the end of the day so long as you can rapidly develop a maintainable piece of code that performs adequately. If the best way for you to do that is by not using a lick of OO, hats off to you. I am, however, pretty darn skeptical given how useful OO programming is for games. You will do yourself a tremendous disservice by refusing to learn it on principle.

Encapsulation is useful for two reasons. For one, it's not just hiding data from people, it's also what provides objects with their own scoping and packages variables + functions into discrete objects. That's pretty big right there. Two, by setting the appropriate access modifiers for a variable, you are providing as hints to both yourself and the compiler as to how this variable should be used. Trust me, after you've spent months or years on a project and come back to a venerable piece of code, it will be wooly and strange to you, and those hints as to a variable or function's purpose are quite valuable. You praise strong type checking and bounds checking as being ways to reduce frustrating errors, this is just another layer of compile-time checking at your disposal.

Edit: I don't mean to sound harsh, but I'm worried you're pursuing ideas on principle rather than taking a good look at their real merits. OO is nothing to be scared of, and who cares if someone forces it upon you? If it's useful it's useful. C++ is a great language, very powerful and widely used for programming games even with the messiness and danger of pointers. Multithreaded programming's hard to do, quite hard in fact, and may not even be needed. If you want to pursue these ideas because you like them, then that's fine, but be aware you could be wasting a lot of time here and I don't want you to be kicking yourself a couple years down the road, or worse yet, get discourage with game development and give up on it.

Share this post


Link to post
Share on other sites
I was typing a lot of the same things as prophetic edge earlier until I got sidetracked and ended up closing my browser before posting. Anyway, don't worry about performance until after you have a fun game. You probably won't have to worry about it at all on your first game, unless you write something dumb by mistake or without knowing, but you can fix that.

C# does lend itself to "OO". I don't stick to OO on principle, I just tend to do whatever makes practical sense, so my code is not strict OO, but parts of it are. It's really the ideas that are useful and often come naturally when writing classes in C#. Mainly my utilities library is OO, that's where I'll put code that could be useful in any game or project and doesn't need to be specifically tailored to a single project. That's the code where I really focus on structuring and commenting it properly, because I know I'll see it again down the road. A lot of game logic code is just there and all I care is that it works, since I'll never use it in another game I don't worry as much about principles.

[quote]I find pointers very easy to use, and understand. The problem is that its so easy to introduce bugs in to the code with pointers, bugs that can be particularly difficult to track down.[/quote] Yeah the concept isn't hard, but if you don't need to deal with these issues, I don't see why you should. You could make as big messes in C#, but you aren't likely to do so accidentally.

I only used multithreading to separate the rendering thread from the main thread. The rendering thread just keeps rendering each frame, and has read-only access to all of the game objects so it can see what is where and draw it accordingly, without changing anything. The main thread handles user input, all the logic calculations and the AI. Even with a totally unoptimized AI using LINQ queries to make most of its decisions, if I let the AI just play all nations in the game from start to finish without waiting for user input, it's over in less than a second. I really didn't expect that, but it's led to me mostly ignoring performance until an actual issue crops up. I could have spent days optimizing my AI so it didn't make tons of wasted comparisons and queries, but it would have made zero impact on the final experience.

Share this post


Link to post
Share on other sites
Thanks for the thoughts and comments.

I'm trying to work with a gigantic long term vision but hopefully a very modest short term achievable goal: a Hex based simultaneous strategic movement combat system. I'm hoping just playing around with this modelling may be of interest to people. I've got a number of old mates who are gamers, but have spent decades in the programming industry, who I can re-contact for starters, when I've got something up and running. The thing I feel no capability for: is writing AI, I'm not even sure how I'd go about writing a path finding routine. So I want to avoid dealing with AI for as long as possible. That does mean that even to play around in the most crude way it needs to be multi human player, which means that the proto game must run on multiple machines across the internet. So my thinking was: if I need to be able to run a human UI on another machine, why not separate the UI in to a separate process right from the start. I wasn't intending to use more than one thread per process at this stage.

The UI can then use 32 bit XNA, or indeed could be written in a completely different language altogether. I'm aware that early optimisation is a complete waste of time, but going 64bit only requires a few clicks in the project options, so why not do it, is my attitude.

OK so lets say my programme starts up and I call my WorldInitialisation() procedure (function/ method). The procedure gets the world size from user input/ a file/ whatever then I could:

Hex [,] hexs = new Hex [numOfHexX, numOfHexY]; // The Hex class is defined at the top level of the name space , numOfHexX and Y are variables

How do I access this array outside of the scope of the WorldInitialisation() procedure? Can I attach methods to an array? Ideally I'd like to put the array inside a "World class". But the problem is I can't dynamically create a class can I?.

Edit: I think I've solved that last problem:

[source lang="csharp"]
namespace CoreCre
{
enum Terrain { Plain, Forrest, Sea, Hill }
public class Hex
{
Terrain terrain;
}
public class World
{
public static int test;
public static Hex[,] hexs;

}
class Program
{

static void Main(string[] args)
{
WorldCreation();
Console.WriteLine();
Console.ReadLine();
}
static void WorldCreation()
{
World.test = 4;
World.hexs = new Hex[4, 5];
Console.WriteLine("World Creation");
}
}
}
[/source]

Share this post


Link to post
Share on other sites
I know virtually nothing about AI, but I do know that the A* algorithm is widely used for path finding.

http://en.wikipedia.org/wiki/A*_search_algorithm

Fortunately, there is an AI board for whenever you're ready to tackle that problem.

Share this post


Link to post
Share on other sites
[quote name='Rich Brighton' timestamp='1303463847' post='4801546']
My first task is to implement the terrain. The obvious path is to create a Hex class, with various fields: terrain, altitude, population etc and then instantiate a two dimensional array of Hex objects. However if most of the operations on the Hexs are performed on a single field of multiple Hexes, will this not be very inefficient in terms of utilisation of memory cache? Would it be better to create a class/ struct for the whole world with fields of two dimensional arrays, a 2 dim array of terrains, a 2 dim array of populations etc? In c# structs are passed by value, while arrays are passed by ref. If I have a struct that consists of arrays will this be passed by ref or value, or is such a struct illegal? Presumably this question of data organisation must be common to most game programmes?
[/quote]

First, as others posted: premature optimization is the root of all evil. Just implement what you need and later on if you need to refactor it, then do so.

I'm working on a similar project using hexes and I would recommend a slightly different approach.

The Hex class should only concern coordinates. As you implement more of your game you'll have to worry about distances, pathfinding, and AI. You'll need to decide on what coordinate system to use. Will you use barycentric coordinates? It can get pretty confusing and these issues alone will mean that the Hex class will be more than big enough.

[code]
class Hex {
int i;
int j;
}
[/code]

For the terrain I would then create a world with the following interface:

[code]
World.getTile(Hex) returns Tile
[/code]


As long as you implement this interface, then the actual storage of all your tiles can be anything: lists, arrays, whatever. You can always change it later.


Tile contains a location (Hex), altitude, terrain, etc.:

[code]
class Tile {
Hex loc;
int altitude;
int terrainType;
...
}
[/code]


Your tile data can be pre-loaded from your game maps on start-up because I assume that their data will remain constant.


Then for your mobiles, armies, population, etc. should be their own classes and each contains a location (Hex). As the number of units is probably a lot less than the number of tiles, the units can be stored in a list.

Share this post


Link to post
Share on other sites
[quote name='loom_weaver']The Hex class should only concern coordinates. As you implement more of your game you'll have to worry about distances, pathfinding, and AI. You'll need to decide on what coordinate system to use. Will you use barycentric coordinates? It can get pretty confusing and these issues alone will mean that the Hex class will be more than big enough.[/quote]
Had a look at Wiki, couldn't quite work out the problem that barycentric coordinates were a solution for. I've decided on 10 km hexes. So it will be a flat world for a very long time to come. I'm not planing to have any pathfinding or AI within the game core. My Hex class will have no GUI information. Each Hex will be an entity and so it will need a list of all units currently within the Hex, as well as knowing who its Hex neighbours are. It may also need to know what units are in its neighbour Hexs.

[quote]As long as you implement this interface, then the actual storage of all your tiles can be anything: lists, arrays, whatever. You can always change it later.[/quote]
I'll have to think about this, but currently I'm thinking being able to use all the functionality of the c# array class could be useful.

I'm feeling I need to implement some kind of GUI just for developing the core functionality, before I go any further. Console is very slow for testing a programme. I'm thinking of using Windows Presentation Foundation. Does anyone have an opinion about WPF?

Also I've had a look at Windows Communication Foundation. Trying to comprehend WCF makes learning Directx 11, the Windows API and C++ look like a doddle. Are there any better / easier alternatives for communicating with processes, on the same machine and across LANs and the Internet?

Share this post


Link to post
Share on other sites
Why the hell are you looking at WCF?

And why would you use WPF just to make a basic editor for your game. Why not use forms?

[quote]Trying to comprehend WCF makes learning Directx 11, the Windows API and C++ look like a doddle.[/quote]
Eventually it gets to a point where it's just learning the library or API. None of those things are difficult to learn or comprehend...not to me. :o

Anyways, I think you are really far off from making any type of game. Looks like you need to make programs like:

1. Equation solvers or an advanced type of calculator.
2. Software where users can write movie reviews and share them w/ other users
3. basic chatroom
4. basic stock trading software
5. Program that can encrypt and decrypt text amd store it.

...atleast until you fully comprehend programming. ;o

Share this post


Link to post
Share on other sites
I don't know if I've gauged it right, but my impression is that Microsoft are going to concentrate on developing WPF rather than forms from now on. So my thinking was that as I need to learn which ever one I use I might as well learn the newer technology.

Share this post


Link to post
Share on other sites
[quote][color=#1C2837][size=2]C# is actually not much of an improvement on this front.[/quote][/size][/color]
[color=#1C2837][size=2]
[/size][/color]
[color=#1C2837][size=2]I beg to differ. I came from having worked mainly with BASIC dialects to C#, it took me about a month to grasp fully. Well, 'fully' is a relative term, but... after the first month of coding I was quite proficient. In order to really program games you want to learn an API like XNA as well, which takes additional time, but... yeah... I'd say around 1 - 2 months is what you need to become familiar with C#, depending on your background.[/size][/color]

Share this post


Link to post
Share on other sites
Yes which is easier using C# arrays or C++ vectors? And then can you trust that everything in the STL is always safe? Lots of people seem to say give Boost a wide birth. Although I have seen some doubt cast on whether the C# foreach loop is always safe. My fundamental issue with C++ is not whether there is a steep learning curve, but whether the language is any good. No matter how much of a beginner one is, when experts disagree one has to make ones own judgement. Amongst other things, I've read through quite a bit of Yossi Kreinin's "Frequently Questioned Answers." Anyway the conclusion I've come to is that C++ was mis-designed at its inception as a marketing ploy to provide pseudo compatibility with C. C++ never was a superset of C and couldn't have remained so even if it had been. So my own thoughts on languages from my limited research and understanding.

Main Game language:
C++: The main industry language, but maybe that's due to legacy code, and no really good alternative to switch to.

C#: Pretty Good, .net, lots of support for beginner, better intellisense than C++. Negative: as far as I can make out, you can code down to the metal with C#, but it doesn't have the documentation/ tutorial support that C++, has for low level work. Even Microsoft documents the Windows API with C++.

D Looks good, it would be great if the Game Development Community really embraced it but its no use for a beginner and probably not for an intermediate becasue of lack of support.

Python: Although it was a long time back, I did a modest amount of programming in C and more recently I've done a bit of C++, so for me going over to C# is easier. Also Learning c# through Visual Studio is very straight forward, so much help and support for beginners and intermediates that, I can't imagine that overall learning Python would be easier.As far as scripting languages go Lua seems to be the language of choice for the gaming industry. Python is a lot slower than Lua. Its notable that Civilisation dropped Python for Lua when they went from IV to V.

Share this post


Link to post
Share on other sites
[quote name='Rich Brighton' timestamp='1303463847' post='4801546']
I've gone for C#. I realised if I put the human interface(s) in a separate process, then i could build the main app as 64bit and still use XNA for a relatively quick and dirty GUI. (Quick in terms of programming not in terms runtime.) I'm using Andrew Troelsen's Pro C# 2010 and am really enjoying it.

My first task is to implement the terrain. The obvious path is to create a Hex class, with various fields: terrain, altitude, population etc and then instantiate a two dimensional array of Hex objects. However if most of the operations on the Hexs are performed on a single field of multiple Hexes, will this not be very inefficient in terms of utilisation of memory cache? Would it be better to create a class/ struct for the whole world with fields of two dimensional arrays, a 2 dim array of terrains, a 2 dim array of populations etc? In c# structs are passed by value, while arrays are passed by ref. If I have a struct that consists of arrays will this be passed by ref or value, or is such a struct illegal? Presumably this question of data organisation must be common to most game programmes?

In essence is a windows process identical to a an instantiation of an application? Is their a high over head for using multiple processes over multiple threads? Supposedly Processes can't share memory resources. Is this totally correct? When using DirectX buffers for example isn't your programme and the Windows system Graphics driver process both using the same memory?

Edit, I think I'm beginning to understand processes. Basically what the ordinary user of windows thinks of as an application doesn't have much significance in terms of the windows operating system? The windows operating system deals in processes? But then what do the entries in the application tab of the Windows task manager mean? If I have multiple windows of fire fox or Microsoft Word it list them as separate applications.

[b]
[/b]
[/quote]


You won't be needing multiple processes. Multiple threads is just fine. Threads (usually) run within a process. The threads can have their own memory, but they can also make used of memory shared by the entire process they are in. Generally, in Windows, when you make an application/service, this is just 1 process. That 1 process can have many threads, or just 1, as you desire.

However, keep in mind that it IS in fact possible for an application to span multiple processes, but this is very, ehm, arcane. You mostlikely won't ever need something like this. While yes it is possible for different processes to access eachothers memory (through security permissions, contracts and the like), you won't be needing this ever. This would be arcane stuff, usually only used by specialized system software. And yes, it is also possible for processes to share a thread (to some extend), but once again: arcane. You could even dynamically inject code into other processes. But you won't be needing this at all.

In general: your application is A process. In this process you can have multiple threads, or just 1.

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