| Engine : Unreal Engine 4 Coding : Blueprints Basic game design : Turn based strategy, Logistics, 3D environment, movement in 2D grid Setting : Futuristic dystopia References : XCOM 2, Rimworld, Vietnam War, Korean War, World War II, Mana Khemia, Anime Cinematography Developed by : Me Introduction As of present, I want to make a TBS game that concerns with all aspects of combat including logistics and hopefully, mimics closely to present real world battles. Strategy over RNG is the motto of this game. Each unit however will be represented as a cube. Invalid and old introduction: If you have questions or things you want to see in this game, feel free to post in this thread. |
worldeditor11Aug 7, 2016 9:55 PM
| Hrm... I think this would fit a gaming board or dev website, since I doubt many people who browse this particular board is into gaming but whatever. When a player is set into melee intercept, why must he have a specific unit or target? Why can't it be used on the first enemy unit to enter the allied unit's melee range? |
 |
worldeditor11 said: Hrm. Does the same mechanic apply to enemy units? It looks like you're gonna have to make a very complex AI if the entire game is based on predictability with detour from RNG to not make the game easy but fair to the player.TR-8RCaim said: Hrm... I think this would fit a gaming board or dev website, since I doubt many people who browse this particular board is into gaming but whatever. You are right but I want to start small first before I start spamming my idea everywhere. An alpha build of the idea at least. Furthermore, I find it easier to communicate with you guys. TR-8RCaim said: When a player is set into melee intercept, why must he have a specific unit or target? One word : Control I have this problem of my units shooting all over the place, attacking the furthest or the strongest instead the weakest or the closest. This is frustrating when most of the squad cant even get a shot into an alien skull due to this fact. The major complain I have found against Overwatch is its reliance towards RNG. Melee intercept aim to ease this problem but limits the potency. Then, you must understand your unit actually moves from one square to another. What if your unit moves into a location that jeopardise both his/her safety and squad? The target setting is to limit movement and allow players to predict his movement. IF you targeted wrongly, that will be your fault, not the game. Not something uncertain like RNG or hey maybe this guy will move first. Even in real life, using basketball as an example, coaches make his players to mark certain players to limit an opposing player movement. TR-8RCaim said: Why can't it be used on the first enemy unit to enter the allied unit's melee range? You can but that will be under phase 2 or 3. Phase 1 will be implementing the flow above. Phase 2 is to trim out any features that are bad and adjust it till it works. Phase 3 is implementing Overwatch Melee Edition. I am giving players more strategic choices to make, not limiting them. Do you want your units to act once an enemy unit moves or act once your targeted enemy unit moves? The former is great in ambushing and guarding an area while the latter is great in limiting an enemy unit movement. |
|
| I do agree that RNG is an awful mechanic when it comes to creating difficulty because often times it's just a handicap added for the sake of bringing one's success rate down with no regard to superior skill and execution; but I do think it holds an important place in game design. Replayability and forcing the player to think of new and creative tactics to adapt to his circumstances for example. What do you think of the game SuperHot? While it doesn't exactly look like a tactical turn-based game, it pushes game mechanics that are very similar to the ideas you're putting out right now. It has this whole mechanic that focuses on player prediction skills to make careful and precise actions that also complement movement. |
|
| [Dev Diary Entry #1] For the past few days since thread creation, I have developed a few basic components in a TBS game. They are: Main Camera - Haven't implemented the boundary yet. So the camera will "fly" beyond the map. Otherwise, it will work with WASD keys to move up,down, left and right, camera rotation by holding right mouse button and map scrolling through the mouse wheel. Map - Procedural generated level as of now. Each tile contain data about the tile itself such as type. This will increase as I implement pathfinding later which is a pain. Contain the algorithm for tiles that are available for selected character movement as well. Plan to separate this as another object once I have a better picture. Unit - So far consists of base stats, derived stats and basic movement behaviour. The base stats are Strength, Magic, Intelligence, Endurance, Willpower, Perception, Agility, Speed, Personality and Luck. Usual stuff in RPG. If you have any other stats you want to add, I might consider. HUD - Yeah... Nothing much other than 2 useless buttons as placeholders and your standard bars for health, magic points and stamina points respectively. Subject to change dramatically whenever I have the creative light bulbs lighting up in my head. Game Mode - Spawn everything above and make sure they work as intended. Images of pre-Alpha build   |
| Wait, if you can't animate and can't create 3D models then how are you supposed to add them scifi weaponry stuffs? Or are there already models and effects in unreal that you can use for that? I'm wondering since I'm going to be using unreal myself pretty soon too. |
worldeditor11 said: JohnnyMcG said: Wait, if you can't animate and can't create 3D models then how are you supposed to add them scifi weaponry stuffs? Or are there already models and effects in unreal that you can use for that? I'm wondering since I'm going to be using unreal myself pretty soon too. You get them for free from the internet (.fbx). It's not that I can't create a 3D model at all, it's just that I don't have the time to model an elaborate one. Like the ones you see in AAA games. I don't think one guy can finish this game within the given time period. It's just not practical considering my circumstances. And I still haven't touch upon the textures... The AI... The GUI... Pathfinding... Core game mechanics... Unreal is nice considering it is free and has a visual scripting builtin for "programming." Wait... what, so I can get a lazer gun firing effect for free on the internet... damn I wish I knew that sooner. Anyways, why would you make an elaborate one in the first place? I mean if their just simple cubes I don't think you would need fancy-shmansy guns for them, wouldn't a simple cylinder be good enough with slight variations between the different types like if the only difference was the colors: red for laser gun, green for plasma gun, gray for normal gun, and so on. So you can just focus more on the other things and it won't look too out of place. Another thing is since its all cube based why not get creative with that, maybe the cubes can stack up on each other giving each one going up a larger attack range or you can place certain cubes in certain places which allows special interaction giving some sort of puzzle elements and stuff... or did you already have something like that in mind? And yeah, that blueprints feature seems pretty nice, I don't feel like programming everything nor do I think I can, which is what made unreal my first choice (other than the fact that it is mostly free). |
worldeditor11 said: You can't lol. I meant it as you can get 3D models like gatling guns or any weapons for free in the internet. The effects are done in the engine itself using the particle system. Well that's even better to know! Sorry about my ignorance, I haven't actually got to touch the engine yet so such functions and capabilities are still unknown to me. But its good to know that the effects for this are already present in unreal, I could make the weapons easy(ish) but I had no idea how I would add the effects. worldeditor11 said: Elaborate as in human and monster 3D models like you see in other TBS grid based games lol. Sorry about that, I thought you were talking about the weapons, I somehow made the connection. worldeditor11 said: I don't want it to be a puzzle. What I am trying to prove with this game is the melee intercept system as stated in my first post, resource management or logistics and AI. Of course, I did think of making the game more cube-centric (cube facing, combining, transforming, cubes vs triangles, etc.) but that's not the vision I have for the game. For now, game mechanics that are cube exclusive will be in my backlog. My current goal is to create more core TBS game rules that provide more options for players to use as practical tools for strategy. Fair enough, I kind of got a little of board for that, I was just wondering if that was something you had in mind already. Finish what you have in mind and if you feel like giving a little more into it with the same base in mind and think such things would be appropriate then implement them if not then just leave it be. Well, for some reason every time I ask someone what engine should we use or what engine do they use, I usually get unity, which kind of made me confused on which engine I should use since when I asked about unreal they gave me strange looks, but then I looked in a little deeper into unreal and concluded: why the hell would I use something else... and besides, I only (partially) understand C++ so far (don't understand any other programming languages) and unity can't support the 3d models I make as well as unreal. |
| [Dev Diary Entry #4] I felt lazy to write every single damn thing I did so I skipped it for the past few months. Anyway, to summarise what I did, they were mostly paperwork per course requirements but I did make a few breakthroughs in various departments. For every Monday from now on, I will post updates on development for my keep sake. Developed: + Implemented pathfinding Currently using Greedy with no checks against unit occupying a tile. This means that a unit will go through another unit to reach its destination. Note: I spent hell a lot of time developing this one. + Implemented turn based system Each cycle consists of turns. Turns are calculated based on unit Speed. + Each tile now store data Generate the level map based on this data. + Implemented computer generated units Generate player unit stats from a predetermined range of numbers. + Implemented spawn points Spawn points are represented as individual tiles where units will spawn around it. + Implemented a base cube unit The basic building block for all future cube unit classes. Contains mostly everything that is needed for your basic turn based rpg unit. Supports equipment. + Implemented game graphics settings Only supports player manipulation of overall graphics quality of the game.  Next week objectives A "living" camera - My idea for this is to make a camera as a living entity in the world, not just a simple "glasspane" that allows player to view the game level. A dynamic unit HUD stats - Only display stats whenever applicable or not obstructing the player view. A Mana Khemia styled turn based system - Might not make it if I have no idea on how it works by the end of this week's Friday. In summary: Updates on mostly back-end stuff. |
| [Dev Diary Entry #5] New dev entry came early by a day cause I am having plans for tomorrow. Changelog: + Pathfinding now checks against occupied and non-walkable tiles. This means no more overlapping units while moving to destination. + Unit HUD stats are now dynamic by nature. It only appears when hovered over a unit or clicked upon. Then, displays no more than 10 seconds before fading out. (*Completed one of last week's objective) (Image below) + Removed both HP and Power bars and replaced them with text numbers. + Enable unit self-rotation. + Unit now can only perform Move once per turn. + Camera smoothing. + Spawn location is an Actor now, not just a particle effect. + Implemented enemy spawn point. + Tons of animation bug fixes.  Next week objectives: 1. Last Week's Overall Progress: A "living" camera + Implemented camera smoothing. + Made a TV static noise material. - Failed to make it immersive yet reactive to the real world as an actual entity. - Do not have any specific plans on how to achieve this. Note: Needs more research on game immersion, cinematography and GUI designs. 2. Enemy unit AI The biggie after pathfinding. I suppose another few days of sleepless nights to figure this shit out. 3. Blueprint optimisation/cleaning Perform housekeeping on my visual scripts to make it properly documented and viewed. Backlog: 1. Conditional Turn Based System On my research of Mana Khemia turn based system, this is what I have found out. Easy to implement but rather difficult to balance. This will be on my top priority to be implemented once I have laid down all of the foundation necessary for a TBS 2D grid game. (*One of last week's objectives) |
worldeditor11Aug 14, 2016 7:31 AM
More topics from this board
» Share Your YouTube Channel/Videos! ( 1 2 3 4 5 ... Last Page )nin-tendo - Dec 16, 2022 |
362 |
by nin-tendo
»»
Yesterday, 11:56 AM |
|
» Protect or punish?DollzchanAi - Apr 18 |
4 |
by DollzchanAi
»»
Yesterday, 6:15 AM |
|
» BL reference in Tomodachi LifeKinspie13 - Apr 24 |
4 |
by Kinspie13
»»
Apr 24, 9:41 PM |
|
» How to Export/Backup Your Anime List Automatically! (TamperMonkey Script)hacker09 - May 18, 2020 |
3 |
by Vapor_AU
»»
Apr 24, 8:41 PM |
|
» advice for someone returning to artCrystepsi - Apr 4 |
5 |
by haaku-san
»»
Apr 24, 4:21 PM |