Possible Future Direction (personal view)
- Thread starter Koshling
- Start date
That's not my forté so no, I'd probably build it up so it was functional, but I doubt I could ever get it to look nice. I might switch to DirectX rendering of the map for performance reasons, but that's about it. I'm much more interested in the architecture and design of the code.
You can skin XAML UIs though, so its possible to make it look less bland.
You can skin XAML UIs though, so its possible to make it look less bland.
@Lant6, square were used as they were easier, as you are saying, but we this engine's purpose should be rather to do thing better then easier, I believe. Hex are much better solution as they allow proper moving. With squares units are moving faster when they perform slanted (what word do you use for lines which are not horizontal nor vertical?) move.
And another thing, is that I would oppose AXXXXE's idea to use C#. It may be good solution, when we have a simple game with not too much calculations, but for things like C2C I would use any possible evaluation power and C++ is still faster. Sometimes very significant. -- I implemented once an algorithm which should be logarithmic in time, but C# was doing something strange in the middle, and the time was in the end linear. Despite that when I've put counters in the code the number of operations was indeed logarithmic and all those operations, except memory allocations, were primary ones (assignments, comparisons, bitwise operations).
And another thing, is that I would oppose AXXXXE's idea to use C#. It may be good solution, when we have a simple game with not too much calculations, but for things like C2C I would use any possible evaluation power and C++ is still faster. Sometimes very significant. -- I implemented once an algorithm which should be logarithmic in time, but C# was doing something strange in the middle, and the time was in the end linear. Despite that when I've put counters in the code the number of operations was indeed logarithmic and all those operations, except memory allocations, were primary ones (assignments, comparisons, bitwise operations).
True. But hexes allow you to do this:
http://forum.unity3d.com/threads/156601-HexGlobe-Hex-based-planetary-globes-for-strategy-games
I don't disagree that hexes are better, just that they make a lot of things harder.
1. Art resources are in a square format, so you will have to convert them somehow to a hex.
2. Once converted you will have to have knowledge of the hex template to position the hexes so they tessellate properly.
3. Once you have these positioned you have the complexity of working out when your mouse hits that tile.
Currently you can just load a square png, tell XAML to put it at these coordinates and you get the hit testing for free from the framework.
Its all well and good to say they are better, its another thing to develop a GUI that uses them (and its another thing to pay for an engine which will complicate licensing and ownership). Although I would prefer them.
Also @n47 I'd disagree with C# being slower than C++ by too much. It could be the case that you developed an algorithm using idiomatic C++, rather than idiomatic C#. Also C# has a number of features (async, lazy evaluation of enumerables, better tools, faster built time, ...) that makes it faster (in those cases) and more convenient than C++. I started out developing this in C++, and gave up because actually implementing things starting getting too difficult (mainly due to long compile times).
What is idiomatic C++ and C# in terms of operations like bitwise shifts on ints, ints comparisons, ints assignments, new-s, reference assignments? No, I think that could be rather something like pessimistic case for memory management. And yes in most cases, C# can be almost so fast as C++, but there are also cases where it just needs to be 3-4 times slower (at least). It is implicated by GC and its strong type system. And another thing is, in C++ you can use some dirty tricks which can significantly improve speed. And as I said with such heavy evaluations like in C2C or even heavier (for example, I have a concept of a game hundreds times more demanding) I would do not resign from any available computation power, even it speeds development up 3 times.
I would agree that C++ compilation time is a problem, but
async -- is it not enough? http://en.cppreference.com/w/cpp/thread
lazy evaluation of enumerable -- you can do it by your self in one day
better tools -- don't be so rushy, have you already checked those thousands tools created for c++, so you can be sure?
And another thing is -- are you aware of C++11? It makes C++ much much more friendly.
Depends on what the algorithm is
if you are bitshifting for the hell of it then there isn't going to be as much difference. But if you are doing something like mapping a key to a value, you'd obviously agree that a std::map vs a List<KeyValuePair<K,T>> would be an unfair comparison. Or not using the fact that C# has stack data types.Obviously there are some areas that C++ just excels at. .NET startup time is typically poor and there is no way to block allocate memory for classes:
Code:
C * ptr = ::operator new (sizeof(C) * 100);
for (int i = 0; i != 100; ++i) new (ptr++) C(i);Do you have a link to the source for any of the C2C code that would be wholly infeasible in C#?
std::thread is not async, the two are completely separate. The ConcRT is closer but still different. And while you could write a lazy evaluation iterator in C++ the yield syntax of C# is much easier to develop with.
Yes I am, have been following it an C++14. I wish more of Boot was included within it. Lambdas are great as are std::shared_ptr and std::unique_ptr as well as move semantics.
Visual Studio simply has better tools for .NET languages: better intellisense, better profiler, better refactoring, extra tools like Code Contracts (which would be nigh impossible to implement with C++).
IronPython/IronLua makes exposing everything to scripting instant and painless rather than using SWIG or Boost:
ython (seriously I wrote plenty of BP bindings in C++, IronPython needs none to be written).Anyway this probably isn't the place for this kind of talk...
Have you meant this http://msdn.microsoft.com/en-us/library/vstudio/hh156513.aspx ? I thought you are just saying about asynchronicity.
Aren't you forgetting about the garbage collector? This little fellow will not allow you C++ and C# be speed equivalent, if only your memory isn't (almost) static.
There is some chance, there would be something in AI. But I am fresh with this code, so it is not serious to ask me. Still even that algorithm which I mentioned could be used here, as it was some graph algorithm -- little theory cheating, as it assumed, we can fit each node's index into CPU word, but it was insanely faster then traditional algorithms. Still, C# have been broking it somehow. And I've viewed this code with one another academical worker and we could not find any sensible reason.
For me they do not speed up development too much.
And one more thing. Take in account, that I am not a big fan of C++. Quite the contrary, I consider this language quite not nice. But IMO here it should be used.
Actually whole this forum is pretty chatty, so probably no one will shoot us.
When you're working with C# you can still implement certain speed critical parts in C++ and link it/wrap it. One important question is if you'd manage to find people with enough skills (or willing to acquire them) to actually get this project done. Then it would probably be advantageous to use C#, as it is somewhat simpler to use.
Well, if we would talk about Windows, then yup, we can link C++ and C#. But for other OSs we would probably need CXXI, which does not look like is going to be finished. And I would not do a favour to MShit and help making Windows-only solution.
And do not discard C++ so much. We have a guy here, who can't add, but can write C++ code.
And do not discard C++ so much. We have a guy here, who can't add, but can write C++ code.
Hydromancerx
C2C Modder
@Hydro, you do not believe in my creativity.
Actually I've thought about something somehow similar, but with more -- enigmatically saying, but I can't sell my ideas for free just like that -- points of view. Where the first of them, I wanted to be something like c2c. I also wanted to simplify the world to make it easier to evaluate. So there would be for example no fixed set of resource. Planets' creation would be simulated and new chemical elements/compounds would be created. Then their properties would be evaluated and ... oh again I would say too much. But yeah, I have an idea for something probably even bigger then this virtual universe.
Actually I've thought about something somehow similar, but with more -- enigmatically saying, but I can't sell my ideas for free just like that -- points of view. Where the first of them, I wanted to be something like c2c. I also wanted to simplify the world to make it easier to evaluate. So there would be for example no fixed set of resource. Planets' creation would be simulated and new chemical elements/compounds would be created. Then their properties would be evaluated and ... oh again I would say too much.
But yeah, I have an idea for something probably even bigger then this virtual universe.
Thunderbrd
C2C War Dog
Well, if we would talk about Windows, then yup, we can link C++ and C#. But for other OSs we would probably need CXXI, which does not look like is going to be finished. And I would not do a favour to MShit and help making Windows-only solution.
And do not discard C++ so much. We have a guy here, who can't add, but can write C++ code.
I heard that.
A bit of an overstatement to say I can't ADD wouldn't you say?
It's no walk in the park getting C++ code to work across different OSes either. It's something you have to decide on as a goal at the very start of the development, and it restricts your options when it comes to libraries. It'd also either force you to choose either x32 or x64, or put in extra effort to have it work on both. If cross OS compatibility is a major goal, Java might be considered - though I truly dislike that language.Well, if we would talk about Windows, then yup, we can link C++ and C#. But for other OSs we would probably need CXXI, which does not look like is going to be finished. And I would not do a favour to MShit and help making Windows-only solution.
And do not discard C++ so much. We have a guy here, who can't add, but can write C++ code.
That looks like a possibly awesome game.
Thunderbrd
C2C War Dog
I've been thinking along similar lines I think. So you may well be able to consider me 'in'.@Hydro, you do not believe in my creativity.
Actually I've thought about something somehow similar, but with more -- enigmatically saying, but I can't sell my ideas for free just like that -- points of view. Where the first of them, I wanted to be something like c2c. I also wanted to simplify the world to make it easier to evaluate. So there would be for example no fixed set of resource. Planets' creation would be simulated and new chemical elements/compounds would be created. Then their properties would be evaluated and ... oh again I would say too much.
But I'm very interested to see where AXXXE may take us as well... Someday... someday. So much to do here so little time.
No. The restriction are libraries, but if you can use C++ correctly here -- like encapsulate platform-dependent code and maybe sometimes use templates -- then no, you do not need the supported platforms set to be decide at the beginning.
Is JavaCPP finished? Or is there an another Java-C++ bridge, which I am unaware of?
Have you even tried? I just compiled 3 big libraries for x32 and x64 from the same sources.
The main problem is not "so little time", but "- oh, AXXXXE, what a great idea! - ok, so who is in? - well, it is so big, it needs too much time, we do not have graphic guy, it doesn't make sense". Well, or at least I have such impression.Thunderbrd said:
