Hello UDK Community!
This is my first post, but I'll do my best to explain what we're trying to accomplish, and hopefully this wonderful community can look through it and let me know what will need to be custom coded and/or what roadblocks I might run into, as the game concept me and a few friends want to work on is definitely not an FPS.
Technical setup:
Level Design
Our basic idea for level design is to have an auto-generated 3d grid of cube-like pieces to create a terrain, which is first step of playing the game (think Minecraft, but not procedural, and not endless). Basically, nothing will be a traditional level, it is a game that is generated and locked to the size you select. The user will then passively control a collective of units that are mostly autonomous, so the camera moves around like an RTS, and there is no 1st person perspectives.
Just as an example, we would love the "grid" to be made of blocks roughly 8x8x8ft that are placed next to one another and will likely end up being in the millions (including vertical air space). Basically, the gamespace might be something like 256*256*64 worth of reused meshes of different kinds.
Controls
Besides basic camera controls, digging/mining and constructions such as doors and walls need to be designated via Mouse controls. Basically, you designate areas to be mined, and miners will dig the area out when they aren't doing something else, like eating and sleeping. The same goes for walls and stairs and doors. Also, workshops can be built that allow for the creation of items, such as armor and weapons, crafts for trade, ingots made from ore, food, etc.
Keyboard buttons will control Z-Level movement as well, since we really want a 3d-experience.
Display
At any one time, the user will not be looking at a render of the entire map, for obvious performance reasons, so there is definitely a need to only render portions at a time. Hopefully that won't be too difficult. To change what you are looking at, you move the camera around on the current level, and traverse Z-Levels using a keyboard command and/or a menu button most likely.
Time
We are planning on having a turn-based style of gameplay that appears more or less real-time. It's a 'tick' system that gives ever actor a 'turn' each tick. Many tasks will take longer than a single 'tick,' but I think you get the idea. If you have any questions, let me know and I'll try to explain better or provide a simple example.
Screw it, here's an example:
There are two unit on the gamespace. Unit 1 is an Orc and Unit 2 is a Dwarf. Based on some calculation, an order is determined when more than one actor is allowed to take a new action on the same tick, as it matters who goes in what order (Think of a Dungeons and Dragons-style ruleset). The Orc goes first and is one square away from the Dwarf, so he moves to the square adjacent to the Dwarf, which takes 3 ticks (The move is instantaneous, as are most actions, but the Orc is now 'delayed' 3 ticks). The Dwarf is free to do what he wants, so he attacks the Orc, who is now adjacent. The Dwarf attacks immediately, and is now 'delayed' 4 ticks. In three ticks, the Orc can now make a decision, and he decides to attack. The Orc attacks and kills the Dwarf, and the Orc is delayed 4 ticks. After 4 ticks, the Orc can now decide what to do next.
This might change a bit if issues come up, but the basic principle is to have an action queue that delays the unit after an action is taken. I think this kind of system will be easier for us to manage and balance, as we are very much in a Dungeons and Dragons mindset when it comes to rules, especially combat rules.
Thank you for your time, and if anyone has any ideas that are better and/or simpler to accomplish the same goal, feel free to point us in the right direction. We are really ready to learn the UDK and get something moving in the right direction.
This is my first post, but I'll do my best to explain what we're trying to accomplish, and hopefully this wonderful community can look through it and let me know what will need to be custom coded and/or what roadblocks I might run into, as the game concept me and a few friends want to work on is definitely not an FPS.
Technical setup:
Level Design
Our basic idea for level design is to have an auto-generated 3d grid of cube-like pieces to create a terrain, which is first step of playing the game (think Minecraft, but not procedural, and not endless). Basically, nothing will be a traditional level, it is a game that is generated and locked to the size you select. The user will then passively control a collective of units that are mostly autonomous, so the camera moves around like an RTS, and there is no 1st person perspectives.
Just as an example, we would love the "grid" to be made of blocks roughly 8x8x8ft that are placed next to one another and will likely end up being in the millions (including vertical air space). Basically, the gamespace might be something like 256*256*64 worth of reused meshes of different kinds.
Controls
Besides basic camera controls, digging/mining and constructions such as doors and walls need to be designated via Mouse controls. Basically, you designate areas to be mined, and miners will dig the area out when they aren't doing something else, like eating and sleeping. The same goes for walls and stairs and doors. Also, workshops can be built that allow for the creation of items, such as armor and weapons, crafts for trade, ingots made from ore, food, etc.
Keyboard buttons will control Z-Level movement as well, since we really want a 3d-experience.
Display
At any one time, the user will not be looking at a render of the entire map, for obvious performance reasons, so there is definitely a need to only render portions at a time. Hopefully that won't be too difficult. To change what you are looking at, you move the camera around on the current level, and traverse Z-Levels using a keyboard command and/or a menu button most likely.
Time
We are planning on having a turn-based style of gameplay that appears more or less real-time. It's a 'tick' system that gives ever actor a 'turn' each tick. Many tasks will take longer than a single 'tick,' but I think you get the idea. If you have any questions, let me know and I'll try to explain better or provide a simple example.
Screw it, here's an example:
There are two unit on the gamespace. Unit 1 is an Orc and Unit 2 is a Dwarf. Based on some calculation, an order is determined when more than one actor is allowed to take a new action on the same tick, as it matters who goes in what order (Think of a Dungeons and Dragons-style ruleset). The Orc goes first and is one square away from the Dwarf, so he moves to the square adjacent to the Dwarf, which takes 3 ticks (The move is instantaneous, as are most actions, but the Orc is now 'delayed' 3 ticks). The Dwarf is free to do what he wants, so he attacks the Orc, who is now adjacent. The Dwarf attacks immediately, and is now 'delayed' 4 ticks. In three ticks, the Orc can now make a decision, and he decides to attack. The Orc attacks and kills the Dwarf, and the Orc is delayed 4 ticks. After 4 ticks, the Orc can now decide what to do next.
This might change a bit if issues come up, but the basic principle is to have an action queue that delays the unit after an action is taken. I think this kind of system will be easier for us to manage and balance, as we are very much in a Dungeons and Dragons mindset when it comes to rules, especially combat rules.
Thank you for your time, and if anyone has any ideas that are better and/or simpler to accomplish the same goal, feel free to point us in the right direction. We are really ready to learn the UDK and get something moving in the right direction.
Comment