At some point, but for now I have a lot if ai work to do on c2c, so probably not until towards the end of this cycle.
Possible Future Direction (personal view)
- Thread starter Koshling
- Start date
At some point, but for now I have a lot if ai work to do on c2c, so probably not until towards the end of this cycle.
rightfuture
Emperor
- Joined
- Mar 11, 2008
- Messages
- 1,649
Love the 'If you build it, they will come' idea, but remember to look and encourage that help as well. If you never ask then they might never know to come visit and become inspired. C2C has plenty awesome potential, once people get deep enough to see it for themselves. If you pitch the vision, you might find people who feel the same.
dexter_inside
Warlord
- Joined
- Oct 8, 2007
- Messages
- 141
The way I see it goes like this:
1) make a good proof of concept,
2) do a Kickstarter campaign out of it,
3) use the money to run it on the cloud (like Amazon EC2/Azure) and hire extra developers from Elance to work on it
4) release it as free to play / partially open source
5) charge money for premium in-game stuff
6) use extra money for hosting / further development
A proof of concept does not necessarily require a graphics engine. Just a good detailed design / master game document
xanhou
Chieftain
Status update with some stuff to discuss:
Im currently doing three things at the same time and after the weekend my lectures are starting again, hence less time for building the engine.
Im wrapping up my C# book, while learning my around MOgre by building a sample engine (that will also be able to show you guys what will be possible), while designing the full API of the square tiling engine.
While designing the API I came across two interesting problems.
1. The game engine assumes everything is atomic, the graphics engine needs time for everything to complete animations. Who is going to manage this transition? I think the best way of dealing with this is to simply stack all animations for units and play them in the order that the graphics engine received the orders. In the eyes of the code using the graphics engine, all actions stay atomic. There a few situations where this can cause trouble, mainly battles. If the player cannot select his unit anymore during a battle, he already knows he has lost the battle. Whatever solution I come up with allows for dozens of strange situations and room for weird bugs. The best so far: Remove the HUD/GUI, zoom in on battle, wait for animation to end, then zoom out and show HUD/GUI again. While this happens, all mouse clicks and button presses must be ignored, hence the UI thread is halted by the graphics thread untill the animation is over. Note that this entire problem is finding the best balance between immersion and amount of code work/maintenance. The solution I gave is best because it is an optional feature, that could be turned off by the user and is optional to implement for a fully functional UI.
2. Obtaining user input. MOgre is shipped with a library capable of obtaining mouse, keyboard and I believe even joystick input for any window on any thread. Hence the graphics engine/thread is not necessarily the place to handle user input. It could be that the graphics engine receives the user IO from the UI code. There is one restriction to this: If a GUI library for MOgre forces the mouse and keyboard input to be hosted in a specific way. To allow proper discussion on this topic I will investigate GUI libraries for MOgre asap after writing this post.
If you guys/girls have no idea what I'm talking about, that OK. Then you can view this as a statement saying I keep myself busy with stuff related to the graphics engine. If you think to have a well argumented opinion or think I'm overlooking something, then know I'm always glad to have people that think with me.
ps. I should put this stuff on a blog.
Im currently doing three things at the same time and after the weekend my lectures are starting again, hence less time for building the engine.
Im wrapping up my C# book, while learning my around MOgre by building a sample engine (that will also be able to show you guys what will be possible), while designing the full API of the square tiling engine.
While designing the API I came across two interesting problems.
1. The game engine assumes everything is atomic, the graphics engine needs time for everything to complete animations. Who is going to manage this transition? I think the best way of dealing with this is to simply stack all animations for units and play them in the order that the graphics engine received the orders. In the eyes of the code using the graphics engine, all actions stay atomic. There a few situations where this can cause trouble, mainly battles. If the player cannot select his unit anymore during a battle, he already knows he has lost the battle. Whatever solution I come up with allows for dozens of strange situations and room for weird bugs. The best so far: Remove the HUD/GUI, zoom in on battle, wait for animation to end, then zoom out and show HUD/GUI again. While this happens, all mouse clicks and button presses must be ignored, hence the UI thread is halted by the graphics thread untill the animation is over. Note that this entire problem is finding the best balance between immersion and amount of code work/maintenance. The solution I gave is best because it is an optional feature, that could be turned off by the user and is optional to implement for a fully functional UI.
2. Obtaining user input. MOgre is shipped with a library capable of obtaining mouse, keyboard and I believe even joystick input for any window on any thread. Hence the graphics engine/thread is not necessarily the place to handle user input. It could be that the graphics engine receives the user IO from the UI code. There is one restriction to this: If a GUI library for MOgre forces the mouse and keyboard input to be hosted in a specific way. To allow proper discussion on this topic I will investigate GUI libraries for MOgre asap after writing this post.
If you guys/girls have no idea what I'm talking about, that OK. Then you can view this as a statement saying I keep myself busy with stuff related to the graphics engine. If you think to have a well argumented opinion or think I'm overlooking something, then know I'm always glad to have people that think with me.
ps. I should put this stuff on a blog.
1. I agree that the UI should run asynchronously and hence queue events that need displaying in a way that need not concern the game engine (at that level it's just displaying what happens in the world, so logically it cannot influence the flow of that)
2. IMO the user input handling should be done by the UI (but not necessarily the rendering thread) for several reasons:
2.1. Only the UI can know what set of controls it is displaying (different UIs may have different sets of controls)
2.2. For user interaction we want to minimize latency, so round-tripping via a possible remote game engine should be minimized
2.3. It may well be more efficient to deal with user input in UI-centric (render/screen) coordinates, not game-engine virtual-world coordinates, so by having the input intimately coupled with the rendering we can avoid coordinate translation (e.g. - what tile is the mouse hovering over?)
I recommend google blogs - dead easy to set up (see the main blog coupled with this thread as an example)
One thing to note, we are intending for the topographical engine to be modular, so building that assumption into the graphics engine is probably a bad idea.
xanhou
Chieftain
Well that is the issue, should it be in the rendering thread/code or in the UI thread/code?
I think I have been unclear.
I'm designing the API between the UI code and the graphics code. This has nothing to do with the game engine. I'm sorry if this has been confusing.
So problem 1 asks whether the UI code/thread should handle the timing issues, hence it could stall any input or queu up animations for the graphics engine to execute, or whether this is the responsibility of the graphics code/thread. Letting the graphics engine handle this means the UI code becomes a lot cleaner and it is easier to write AI's, since they can assume all their actions that they send to the graphics engine (if they do so directly) are atomic in nature. On the other hand, letting the UI code manage this means we have more control on what is displayed. Example: you order a transport to a city then unload a unit and move the unit out of the city. What if graphics thread manages timings: 1. UI orders transport to move to the city, which results in an animation to start. Since this is an atomic action for the UI, it may instantly order the unload order, which spawns the land unit and oder the land unit to move. If done by an AI, the land unit is unloaded and starts moving while the transport is still moving to the city. If the UI was managing this, it would have to block user input at various times to allow the animations to finish. Imagine the trouble this causes when the AI has to apply moves. So both options make one problem easier to fix and an other harder.
For the second issue I have looked at the different GUI options. Note that with the GUI i means the buttons, text, ect ingame, with UI I mean the code between the graphics engine and the game engine that hosts either a human or AI player.
There are two good options: MyGUI and Miyagi. Miyagi is made for MOgre (C#) while MyGUI uses a wrapper for C# compatibility. This is basically where the advantages of Miyagi end as far as I have been able to figure out. MyGUI has more features, a bigger community, and, important, a WYSIWYG editor that results in a file that can be directly loaded from the code. Hence even a non programmer could design the GUI for the game, or modify it!
Anyway, both MyGUI and Miyagi desire direct user IO. So I think it is best if the graphics engine determines when button presses are related to text input (text field) or to possible hotkeys for unit actions, which need forwarding to the UI code/thread.
For keyboard IO it is pretty straight forward: if GUI takes control, don't notify UI of keypress (yes naming conventions are awkward here) otherwise send all keypresses through to the UI and let that code figure out whether to use the key presses or not. For the mouse movement the situation is slighty more complex. When the mouse is on top of the GUI, no problem, UI can be left unnotified. But what about hovering over units, selecting units, etc. Combine this with the issue that the UI may assume a unit is already removed from game which is still performing an animation (if UI assumes actions are atomic and lets graphics engine figure out the timing stuff) and you get some messy situations that need carefull thinking.
Ah, sorry - had the wrong end of the stick slightly
In the model I'd prefer the AI wouldn't be aware, since it would be output-only (i.e. - it would result in a sequence of game-state changes the UI needs to display, but which the UI cannot influence). This is important (and also applies to other players, which should be indistinguishable from AIs) because they may be (often will be in the player case) running remotely, with significant round-trip communications latencies. As such you really have to follow the queuing model, though you have the option of syncing it with local UI actions for the local player (only) to give them a lower-latency visual feedback path for non-committed actions (e.g. - display of possible paths before the actual choice is made and issued as a game-state changing command)
Depends where you place your order queue. If you maintain a local display-state cache, that caches the states of entities only in so far as the properties needed to render them are concerned (position and type essentially), and have both the render AND UI threads operate against this state, but the state-cache update fed asynchronously by a queue from a state update pipeline sourced from the game engine, then you achieve both goals:
1) Synchronicity of state between UI and render thread for the local player (only)
2) Asynchronous coupling to the actual game state, and therefore any AIs/other players
Now, in the absence of simultaneous turns, the only thing that can update the game state is a user action (during the player's turn) or a game-engine-sourced change (during other players' turns). This means that (absent simultaneous turns) the cached state will only ever change due to EITHER a game-engine-sourced change (via the async queue) OR a local player action (via the UI), so if you force flush the queue at the start of the player turn (i.e. - make them wait for any remaining queued updates to finish playing animations etc.) then there can never be a clash between the changes the UI thread seeks to make to the cached state, and changes that are asynchronously occurring in the game engine.
Once we introduce simultaneous turns things get more complex and the UI must be capable of coping with issued user commands failing to commit, but we can leave that for another day and just implement sequential turns first (note - that 'sequential' at this level doesn't preclude all-AIs simultaneously, it just precludes human actions overlapping AI or other human actions)
xanhou
Chieftain
Ah, sorry - had the wrong end of the stick slightly
In the model I'd prefer the AI wouldn't be aware, since it would be output-only (i.e. - it would result in a sequence of game-state changes the UI needs to display, but which the UI cannot influence). This is important (and also applies to other players, which should be indistinguishable from AIs) because they may be (often will be in the player case) running remotely, with significant round-trip communications latencies. As such you really have to follow the queuing model, though you have the option of syncing it with local UI actions for the local player (only) to give them a lower-latency visual feedback path for non-committed actions (e.g. - display of possible paths before the actual choice is made and issued as a game-state changing command)
Depends where you place your order queue. If you maintain a local display-state cache, that caches the states of entities only in so far as the properties needed to render them are concerned (position and type essentially), and have both the render AND UI threads operate against this state, but the state-cache update fed asynchronously by a queue from a state update pipeline sourced from the game engine, then you achieve both goals:
1) Synchronicity of state between UI and render thread for the local player (only)
2) Asynchronous coupling to the actual game state, and therefore any AIs/other players
Now, in the absence of simultaneous turns, the only thing that can update the game state is a user action (during the player's turn) or a game-engine-sourced change (during other players' turns). This means that (absent simultaneous turns) the cached state will only ever change due to EITHER a game-engine-sourced change (via the async queue) OR a local player action (via the UI), so if you force flush the queue at the start of the player turn (i.e. - make them wait for any remaining queued updates to finish playing animations etc.) then there can never be a clash between the changes the UI thread seeks to make to the cached state, and changes that are asynchronously occurring in the game engine.
Once we introduce simultaneous turns things get more complex and the UI must be capable of coping with issued user commands failing to commit, but we can leave that for another day and just implement sequential turns first (note - that 'sequential' at this level doesn't preclude all-AIs simultaneously, it just precludes human actions overlapping AI or other human actions)
Ok. Naming conventions are really starting to confuse now.
Before trying to talk about anything again, lets establish a some keywords based on the structure of the engine.
I extended your diagram of the data model to reflect the different components of the UI:
A few notes on the diagram. The Networking layer mimics the same API as the game engine, hence is invisible for the UI, and forwards calls from and to remote UI's making it look like those UI's are on the same machine from the perspective of the game engine. Leaving the networking layer out of the picture results in a still working game!
Note that it is vital for the connection layer to receive notification when certain changes are made to the game state, so it can start animations on the graphics thread.
In simple words the diagram would read as follows, from top to bottom, skipping the internal working of the game engine:
The graphics engine exists of a GUI and a render engine. It can generate certain callbacks based on user input, but makes no (significant) state changes on itself. The connection layer is responsible for processing the callbacks of the graphics thread and is responsible for synchronizing the state of the graphics engine with that of the game engine. The networking layer is responsible for synchronizing game states between different computers and does so by intercepting all traffic between the UI's of this pc and the game engine running on this pc. The game engine on it's turn is responsible for keeping track of the game state and handling any queries on this game state.
Now. The problems I discussed are related to the little arrow between the connection layer (previously called UI) and the graphics engine.
As it turns out, the graphics engine will control user input, hence the connection layer must register listeners. (GUI demands this).
In my opinion, it is certain that the connection layer is responsible for processing GUI button presses. Example: User presses: increase research. The GUI library calls the callback of the graphics engine (same thread), which adds the event to the queu of "increase research" events to process for the connection layer. Once ready to process the event, the connection layer processes the event and makes a call to the game engine to change the research of the player. If the call returns succesfully, it means the state of the game has actually changed, hence this method may take a while if playing over the net. If the call was succesfull, the connection layer makes sure all values are also updated in the graphics engine. It could for example be that the connection layer has given a function pointer to the graphics engine and let the it poll the game engine directly, hence automatic updating of the values from the perspective of the connection layer.
Now come the two interesting questions.
First of all: does the connection layer knows about the time it takes to execute an animation, or does it also asume atomic behaviour when dealing with the graphics engine? (irrelevant for the AI) If so, the graphics engine will have to deal with orders that can stack up faster then it can display these events. Note that during the AI turn, the connection layer may receive dozens of state changes which result in animations.
Implementing it as atomic makes life easy at first, but makes other options, such as viewing enemy movement, harder to implement. Since enemy movement would be an atomic action in the eyes of the connection layer, dozens of enemy units may start moving in the same frame, hence you cannot follow all of them...
Secondly, even though it is clear the GUI callbacks are generated from within the graphics thread, this may not need to be the case for unit selection. We have a choice there: Either let the graphics engine make requests to the connection layer to select a unit or let it just forward any non GUI mouse clicks and let the connection layer figure out what to do. Basically: how much work related to unit (and city) control is done inside the graphics engine and what is done in the connection layer?
There is one thing we could do significantly different then described in the diagram I made if we dicide the connection layer asumes all interaction with the graphics engine is atomic: Instead of hosting a single foreground thread for the connection layer, we can use background threads that simulate all the behaviour of this thread. This is possible because all methods called from these threads to the game engine or graphics engine must be made thread safe anyway and there is no direct need for state information. Although possible, it may be preferable to lift some (or as mush as possible) responsibiliy regarding state information from the graphics engine to the connection layer, hence it I believe it is easier to create a single thread with a loop. That keeps track of the currently selected unit, whether you are zoomed into a city, etc.
xanhou
Chieftain
Good news everyone.
I finally had some time again and completed a simple way of creating the map.
Currently each tile is just a flat image and all of them have the same texture, but it's a start.
However, my approach is the most resource wasting one ever, yet it runs on good frame rates, given that you do not zoom out too much.
This means I can focus on other features first, before optimizing the engine.
I created a blog and put some of the discussed material on it:
http://www.trolls4life.com/blog4-gerard/
(don't mind the link name. It's the domain name of a friend
)
I also set up an svn, with public read access so anyone can download the project.
It should work out of the box, if not please report.
It is a visual studio 2012 project, so I'm not sure if 2010 users can open it.
https://gm.trolls4life.com/svn/AXXXXE
If it keeps nagging for a username/password. Use the name "anon" and leave password open.
This brings me to a new problem. As an IT student on my university, I can use every version of visual studio I like because of the student alliance thingy of microsoft. I assume not everyone has this luxery. So my question is: should I use a specific version of VS? The express version of 2012 is released, so that should be no problem. Still, better discuss this right now.
I finally had some time again and completed a simple way of creating the map.
Currently each tile is just a flat image and all of them have the same texture, but it's a start.
However, my approach is the most resource wasting one ever, yet it runs on good frame rates, given that you do not zoom out too much.
This means I can focus on other features first, before optimizing the engine.
I created a blog and put some of the discussed material on it:
http://www.trolls4life.com/blog4-gerard/
(don't mind the link name. It's the domain name of a friend
)I also set up an svn, with public read access so anyone can download the project.
It should work out of the box, if not please report.
It is a visual studio 2012 project, so I'm not sure if 2010 users can open it.
https://gm.trolls4life.com/svn/AXXXXE
If it keeps nagging for a username/password. Use the name "anon" and leave password open.
This brings me to a new problem. As an IT student on my university, I can use every version of visual studio I like because of the student alliance thingy of microsoft. I assume not everyone has this luxery. So my question is: should I use a specific version of VS? The express version of 2012 is released, so that should be no problem. Still, better discuss this right now.
Good news everyone.
I finally had some time again and competed a simple way of creating the map.
Currently each tile is just a flat image and all of them have the same texture, but it's a start.
However, my approach is the most resource wasting on ever, yet it runs on good framerates, given that you do not zoom out too much.
I created a blog and put some of the discussed material on it:
http://www.trolls4life.com/blog4-gerard/
(don't mind the link name. It's the domain name of a friend
I also set up an svn, with public read access so anyone can download the project.
It should work out of the box, if not please report.
It is a visual studio 2012 project, so I'm not sure if 2010 users can open it.
https://gm.trolls4life.com/svn/AXXXXE
If it keeps nagging for a username/password. Use the name "anon" and leave password open.
This brings me to a new problem. As an IT student on my university, I can use every version of visual studio I like because of the student alliance thingy of microsoft. I assume not everyone has this luxery. So my question is: should I use a specific version of VS? The express version of 2012 is released, so that should be no problem. Still, better discuss this right now.
Use VS2012. As you say express version is available (I have MSDN access anyway myself), and the latest makes sense
I agree. I have the good version through my school (Dreamspark is awesome) so that works well for me too.
Hydromancerx
C2C Modder
Have you guys seen iontom's project?
http://www.iontom.com/2012/08/25/game-build/
He left some links and an invite in my visitor page.
Looks cool, but I wonder if its too ambitious.
http://www.iontom.com/2012/08/25/game-build/
He left some links and an invite in my visitor page.
Looks cool, but I wonder if its too ambitious.
Hi Folks,
Hydromancerx pointed me to this thread. I though I'd step in and say that I have a group on reddit right now dedicated to doing a very similar project to what you propose here. Except that we're working on it as a browser based JS 3D engine. It's going to be all open source and free to play.
We want as much as possible to be procedural and new. Rather than hardcoding dozens to hundreds of Civilizations we want to have each culture evolve and split and use linguistics to generate new names for things.
It's going to be like Civ meets Paradox games but much more procedural generation and it will start on Earth but expand into space later. But it will try to capture more of the story of humanity and collaboration, rather than just eternal warring nation states.
I really dig the UML you guys are doing in this thread. I'm a database specialist myself. T-SQL only though :\ I want to learn some noSQL storage layers and some type of distributed computation technology for rendering simulation content in the background possibly using BOINC. But all of that remains to be seen, we decided to just start with the engine.
The App: (use Chrome) http://webhexplanet.herokuapp.com/
The Github: https://github.com/rSimulate/WebHexPlanet
The Community http://www.reddit.com/r/simulate
Game Planning http://www.reddit.com/r/MetaSim (I'm planning on getting a forum soon)
My initial blog post: http://www.iontom.com/2012/08/25/game-build/
I you're interested, shoot me a message, email, or just join the github and reddit, thanks!
iontom (iontom@gmail.com)
Hydromancerx pointed me to this thread. I though I'd step in and say that I have a group on reddit right now dedicated to doing a very similar project to what you propose here. Except that we're working on it as a browser based JS 3D engine. It's going to be all open source and free to play.
We want as much as possible to be procedural and new. Rather than hardcoding dozens to hundreds of Civilizations we want to have each culture evolve and split and use linguistics to generate new names for things.
It's going to be like Civ meets Paradox games but much more procedural generation and it will start on Earth but expand into space later. But it will try to capture more of the story of humanity and collaboration, rather than just eternal warring nation states.
I really dig the UML you guys are doing in this thread. I'm a database specialist myself. T-SQL only though :\ I want to learn some noSQL storage layers and some type of distributed computation technology for rendering simulation content in the background possibly using BOINC. But all of that remains to be seen, we decided to just start with the engine.
The App: (use Chrome) http://webhexplanet.herokuapp.com/
The Github: https://github.com/rSimulate/WebHexPlanet
The Community http://www.reddit.com/r/simulate
Game Planning http://www.reddit.com/r/MetaSim (I'm planning on getting a forum soon)
My initial blog post: http://www.iontom.com/2012/08/25/game-build/
I you're interested, shoot me a message, email, or just join the github and reddit, thanks!
iontom (iontom@gmail.com)
xanhou
Chieftain
After looking at your project a bit I think there is one vital difference between the projects. This however, does not take away the fact that we could work together.
From what I have read from Koshling, AXXXXE intents to remove various restriction of the Civ IV engine, make it more modular and make it easier to add content.
Your project, on the other hand, seems to resolve around the concept of procedural generation. You try to create a procedural universe and add some gameplay to that. While an interesting concept, I believe that if you manage to make it work, you will end up with a completely different kind of game.
While skimming though the wall of text on your initial blog post I could not even find whether you wanted the game to be turn based!
However, if you restrict yourself to a turn based game, we could try to develop a common base engine and split up when it comes to content.
Koshlings idea of the engine was very generic, so that should be possible.
The biggest advantage would be that we have the strength of two teams working on the same engine.
The biggest disadvantage is that we need to agree on the technology used to create this engine.
We basically demand the use of .NET for a very simple reason. The .Net environment can be accessed from dozens of programming languages, including java script. This means that different components can be made in different languages.
The only disadvantage of .NET is that various components and third party libs are not well supported on linux/mac.
What I do not know is how this works when you take the web into account. I also have no idea what the difference is between java script and JScript (.NET version of java script). Only that the syntax is the exact same.
If you do want to work together there is one other component which we can work together on: the graphics engine. The graphics engine does not have to know much about the underlying game. It only knows the type of tiling (square(cylinder/donut/flat) or hex (cylinder/donut/globe with pentagons)) and the fact that there will be entities on that map. These entities could be anything: units, cities, etc.
If we design an API for each type of tiling that can be used by both games, we can develop graphics engines that can be used by both games.
strategyonly
C2C Supreme Commander
In my opinion, i like modular ALOT, and it should be incorporated.
Hi, yes I am familiar with the .NET framework as vendor to MSFT, but for our project we've been using rails since everything so far is setup that way and the primary dev prefers it. .NET should be able to access our API later though.
I want procedural everything but that doesn't affect the engine. ProcGen calls could just as easily be replaced with standard asset loading. I just think it would be awesome to play as completely alien cultures, plus you get tons more content and much less stored data.
Yes, the engine should be non-specific and mutable to developer needs. We're starting on the core API now, aiming to keep both MP and SP in mind. If you're interested in talking about the API go here: http://www.reddit.com/r/metasim and ask a question and aaron_ds will tell you more details. It's on Google Docs for now but we will push to a wiki soon.
Cheers
I want procedural everything but that doesn't affect the engine. ProcGen calls could just as easily be replaced with standard asset loading. I just think it would be awesome to play as completely alien cultures, plus you get tons more content and much less stored data.
Yes, the engine should be non-specific and mutable to developer needs. We're starting on the core API now, aiming to keep both MP and SP in mind. If you're interested in talking about the API go here: http://www.reddit.com/r/metasim and ask a question and aaron_ds will tell you more details. It's on Google Docs for now but we will push to a wiki soon.
Cheers
The ultimate objective is to build a web gaming platform that looks comparable to desktop applications, and make it easy to create modular content for. Also, it's open source, which makes it 100x more flexible than a standard game.
One example goal we have is: you create a procedural planet/solar system/galaxy in the space engine. Then a Minecraft style game gets created and can take place on any of those planets. Same action data, different engine, shared gameplay.
But right now we're starting with just the planet-space module. Which really only covers 1500 AD onwards.
What would be your thoughts on a non-linear technology web? Something that looks like the Skills tree from Path of Exile. How would you design something like that?
Cheers
Could you please do this? (I hate to quote myself, but hosting on Sourceforge will greatly improve my peace of mind and our development process)
