New model
I created a new model to look like the sprite placeholder that was being used for a while. I have now set this new model as the player's model, and moved the ghost model over to the enemy.

oozey mess
TMBGareOK. The Official They Might Be Giants tumblr

Jimmy Eat World
No title available
noise dept.
Interview Vampire Daily
Show & Tell

gracie abrams

ellievsbear
RMH
Sade Olutola

blake kathryn
Lint Roller? I Barely Know Her
No title available
Fieri Frames
𓃗
Today's Document
hello vonnie
Not today Justin
One Nice Bug Per Day

seen from United States
seen from Malaysia
seen from United States
seen from Indonesia

seen from United States

seen from United Kingdom
seen from United States
seen from United Kingdom

seen from Colombia

seen from India

seen from South Africa

seen from United States
seen from Russia

seen from United States
seen from Canada
seen from United Kingdom
seen from United States
seen from Spain

seen from United States

seen from Indonesia
@ga-wsc-fmp
New model
I created a new model to look like the sprite placeholder that was being used for a while. I have now set this new model as the player's model, and moved the ghost model over to the enemy.
Final Touch-ups
Now the functionality is (mostly) there, it's time to get rid of the default/placeholder-y look. Starting by making the overworld match the battle background better:
Next, it's time to replace the flat sprite of the hero with something 3D:
I was going to make something nicer for the enemy too, but I do not have the time as of writing, and may not have time before time is up.
One last push, stitching things together
I figured I'd try to stitch together the parts of the project that do exist to make the game at least "function" to a degree. As stated in my previous post I created an overworld area but did not know what to do with it, so abandoned it. However I've decided to simply add a low quality placeholder cube to act as an enemy of sorts. This "monster" does not do anything by itself, and it simply waits for the player to run into it before loading the battle level:
I also moved the camera on the third person character and displayed the sprite of the character used in the battle level:
Speaking of the battle level, I changed the enemy from being a sprite used in a previous project, to the placeholder cube used in the overworld (this doesn't look good but nor does the entire project so I don't see that it matters):
Next up, I added some quick and dirty functionality to some of the menu options in order to attack the enemy (This was actually already here, i thought I'd removed it when i was restructuring but i must've forgotten to remove this one):
I simply disabled the buttons I didn't have any time to add functionality for:
I then enabled the placeholder items to heal the player's HP:
Then I added a fleeing mechanic:
But then i felt like improving it a bit further, so I created a little sequence that plays out via widgets when attempting to flee:
Next, I wanted to make it so once the player selects an action, the widgets they're looking at disappear, however I struggled to do this in a clean way.
I tried making an array with all the possible widgets, and making it so once an action occurs, it clears any and all open widgets, however I found myself unable to connect the array to anything that seemed relevant:
The reason I didn't hard-code the widget to close itself after an action was selected, is that i needed the battle manager to know when a turn is concluded so it could add it back. If the widget handled this itself, I'd have to guess the timings, and since the widget wouldn't exist it wouldn't be able to run anything anymore. I ended up just scrapping this idea as I didn't have time. (Therefore removing the "turn based" nature completely, but it wasn't like i was going to get the enemy to attack when i have such little time remaining anyway.)
Last up, I put instructions into the battle manager to monitor the HP of the enemy, if it reaches 0 or lower, it opens the overworld level. This isn't a good way to do this due to performance, however with a project this small that won't be expanded upon, it seriously doesn't matter. if i were to do this properly, i'd set a health checking event when an attack lands:
No matter the outcome of battle, the result will always end with the overworld section of the "game" loading back up in the same way:
(I'll be removing the undertale battle music before handing in the project, since it's copywrited)
Ending Development
I'm done with this project. It's not worth trying to push it any further. I do not have the time nor motivation to attempt anything further with it.
I made a simple area I was going to have enemies spawn around, but i have no ideas for enemy designs, nor do i know how i'd go about remaking the battle system to be at least partially functional.
I'm calling an end to my development of this project, and will instead start preparing for my next project, in which i will make sure to plan in such a way that i avoid reaching the same problems i did with this one.
Future projects will require me to spend some time to plan structure before development. I can achieve this with the use of flowcharts, as well as drawing things out. I may also write a few paragraphs on what my plan is. All of these planning steps should help to catch any issues before they arise.
If I am given any reason to do anything further with this project before the deadline then perhaps i will, however it's more than likely that this will be where the project ends. An unfortunate result, but at least I've gained more experience and knowledge throughout, which i can take with me into the future to create more successful projects.
Working with the time left
I do still have some time left on this project, and it doesn't seem like a good use of my time to sit around doing nothing just because I've lost motivation for the project. So I may as well make the most of it and attempt to add a few more bits.
It's been established that the battle system at this point has been completely unfinished, and is far too complex. As much as I would've liked to see the original idea realised, it's simply not a realistic goal at this point.
I've decided I'm going to completely change the idea from an isolated battle system with complex mechanics into a small explorable world with monsters you can battle. The battle system will be SIGNIFICANTLY watered down from the original plan, and less time will be spent trying to make the battle system as modular & expandable as possible.
I plan for the new battle system at absolute minimum to provide:
A basic attack
Way to heal (Basic spell or Items, the former being far quicker to implement)
Fleeing
Nothing more than this is planned, meaning there will be no interesting abilities that can be cast. This may change if i have time, however said abilities would be incredibly simple and would be mostly hard-coded rather than being a dynamic/expandable system.
What I aim to achieve:
Create a small world to explore
Allow monsters to spawn on the surface
Make it so running into a monster triggers a battle
Be able to win, lose, & flee battles
It's not going to be particularly impressive, however it's the closest thing i'll be able to make to a playable game within the remaining time (less than 2 weeks).
I may look at asset packs on the Epic Games marketplace to help with creating this. Though consistency is important to me so I will need to find something that has most of if not everything I need to accomplish my goal. I may end up needing to create some assets myself otherwise.
Looking to the future
This project has failed to reach a good outcome, but that's ok. I've still learned from this and can take that into future projects. Some things I've learned include how to create and use structures and data tables in UE5 (granted I still have much to learn regarding how to use these well and what situations they are to be used in), as well as learning the value of properly pre-planning out a project before jumping in.
When I started this project I did a large amount of research and exploration around the given theme, however once this was over I failed to plan things out and instead jumped right into UE5 with my chosen idea at the front of my mind. This led to a poorly structured prototype that ended up needing a complete overhaul. By the time I finished this overhaul I realised I still didn't understand everything I needed to regarding how to store information. This made things a bit confusing when attempting to learn how to use data tables, as I had to fill in the missing gaps myself.
I also learned that I need my projects to engage me. If they fail to do that then I will end up losing interest and motivation, leading to a dead end in the project's development. Unfortunately this is what happened with this one, and I did not have the time left to change directions as such a change would require it's own planning which would take up too much time, leaving the actual development minimal at best.
I'm aware that the outcome of my project is only a small part of my grade, but that doesn't change the fact that I wish I could've completed something, or at least created a fun concept/prototype.
I think that, as much as I may enjoy playing jRPGs with turn-based combat, actually creating one is far more tedious, and it takes far too long to feel engaging that I struggle to maintain interest. I believe it would be wise going forward to spend more time planning out the structure and development cycle of my future projects, as I evidently did not spend enough time on that aspect with this one.
Despite my appreciation of 2D pixel-art styled games, I have also concluded that working with sprites in Unreal Engine is not an enjoyable experience in the slightest, and I would be best off keeping that to a minimum. I will likely stick to 3D games for the most part going forwards with few exceptions.
Airships 'N' Aliens is by far my favourite project that I worked on, and I believe it would be a good decision to look back on that project and take notes going forwards. For example I seem to do well creating a short yet charming gameplay loop, and allowing myself to have a little bit of fun with it certainly helps.
I took this project too seriously and wanted to add way too much to it. I mistakenly thought that due to being such a simple looking idea it wouldn't be too difficult to make. However the sudden introduction of multiple new aspects of the engine that I was previously unfamiliar with, paired with the fact I was not familiar with creating anything remotely similar to what I was aiming for was a recipe for disaster.
The biggest difference in this project as compared to my previous ones is the fact that it is almost entirely within a UI. Instead of what I was familiar with before, being the use of actors, I was instead creating multiple UI elements like widgets which created and destroyed each other, and pulled info from the highly unfamiliar data tables. It was simply too much new stuff to handle for such an unengaging project at such a late point in the FMP's timeline.
I hope that all the work I have put in so far will reflect well on my grade, even if the outcome was disappointingly cut short before it could even reach a satisfying prototype. Regardless of what happens though, I will use what I've learned in order to better plan future projects and create something that I can enjoy and be proud of.
Loss of motivation
This is the one project I really didn't want this to happen for, but If im being honest with myself for the past week or so I've lost my passion for this project. It seemed like a fun idea at first but as things have progressed I've found myself getting less and less motivated to the point I don't even want to work on it anymore.
Unfortunately, that's too bad for me as I simply don't have the time to change things up now. Even if my passion for this project is gone, I still need to keep working on it to provide a solid outcome.
It really sucks for this to happen, but sometimes things just don't turn out as you expect. And i certainly didn't expect a turn based battle system to be so complicated. Even after watching tutorials and getting help with some of it, I still struggle to wrap my head around all of it.
It's not just the complexity, with previous projects I've actually enjoyed playtesting it as it's gone through development. Whereas with this one I'd be lying if i said the same. Which I'd blame on the genre but I genuinely enjoy most turn-based combat games. So either I've done something wrong with mine, or my standards are too high.
My FMP is quite possibly the worst time for this kind of motivation loss to happen, especially this late in when I can't change direction. All I can hope for is that despite this, my work will still be enough for a good grade.
Learning how to dynamically add entries to a widget
The video I was watching before didn't help a whole lot, however it did introduce me to the "Uniform Grid Panel" widget component, which will hold the buttoms for each ability.
I will be moving on to this episode next which should be more relevant:
Today's Goal
Today's goal will be to create the abilities menu in such a way that it automatically creates entries based on what abilities you have access to.
Looking into how to create the ability selection menu
Following on from the previous video i followed, the same person made a follow up video where he takes the spells he made using a data table, and puts them into a spell book widget. This should be fairly similar to what I'm going for, just with a different style.
Creating structure for abilities
Following along with the video I sent in my previous post, I've created the nessecary components.
First i made an Enumerator for each ability's name:
Then i made another Enumerator for the types of abilities:
After that I then ccreated the Structure for the ability info:
Finally I created the data table, making sure I set the row structure as the "AbilityInfo_S" Structure in the content browser:
I filled out the nessecary info for 5 placeholder abilities using the Row Editor tab:
Now I've got the data table sorted, I next need to figure out the best way to implement this in blueprints. I'm afraid the previously sent video doesn't help me much in this regard, but there are some bits I can take note of. Namely node names that i'll need to use when pulling info from this data table:
I should also take note that apparently converting the spell name enum straight to a name will lead to it being a "long inconherent string" that "won't match our row name". It isn't explained why this happens but the solution is to simply convert it to a string first, and THEN convert that string into a name.
Just watched through this. Whilst this is for a different type of game, it's still highly relevant and shows how structures, enumerators, and data tables all work within UE5. I will be using this to help me create the abilities for my battle system.
At first I was a bit confused but once it all started coming together it made more sense.
The first half of this video is mostly relevant, however the latter half when he talks about creating a blueprint with physical attributes such as particles, collision, gravity, etc does not apply to me. This is because for this person's game it's a 3D game where the spells are to be aimed manually and are physical entities. For my project however, each ability is simply a set of instructions. An animation will play to accompany each ability, however all of the calculations for damage happen in the background.
Beginning big restructure
I need to begin the restructure before i start getting ahead of myself. If i hard code too many things now they're just going to end up being deleted or replaced anyway. So i've stripped the placeholder characters of their blueprints, and started moving stuff over to the BattleManager actor instead.
Right now it doesn't contain anything particually useful, but this is where most actions will be processed and where battle information will be stored going forwards:
I've also stripped the menu buttons of their functionality as that will need to be redone. So now none of the buttons do much except open up submenus. The spells menu was renamed to abilities to be more generic and reuseable.
I plan to avoid making too many "Temporary Placeholders" when it comes to button functionality, as i end up using the when creating even more placeholders which leads to a tangled mess of placeholders that become a nightmare to fix or work around.
Feels like i've taken multiple steps back by deleting so much stuff, but it also feels like it was absolutely the right thing to do as i can now make everything work cleanly and properly.
More UI pages have been created as well :
I could have put all of these into one single widget blueprint, however i find that too cluttered to work with and this works fine. Perhaps it's less performant but if that means i can work with it easier then that's a price im willing to pay.
There's still placeholder sprites, background, sounds, and music. But those will be phased out once i get around to actually working on them. For now they're good to keep as a visual.
Here's how it's all looking right now:
Trying to create a way to select character type
In order to test if my system works once it's created, i'll need at least 2 different characters you can play as, both having their own moveset. So i figured i oughta get some of that out the way now, however i'm struggling to figure out how to set the sprite.
So far i've got this stored inside the battle manager (an actor i made to handle certain events in battles):
And then in the character selection UI Widget, i have this:
I thought this would work but apparently it really doesn't like this. I tried just connecting the hero variable directly as the set sprite target but it wouldn't take that. I then tried getting a reference to the sprite inside the battle manager but even that wouldn't work. I'm pretty stumped here.
Trying it this way doesn't seem to work either:
I'm unsure what this error means so i've looked it up and it turns out i forgot to compile the hero actor. This was a whole lot of hassle over such a silly mistake, but at least it's fixed now:
This still isn't perfect as i really want as few bits hard-coded as possible so i can add, remove, and change characters in the future. But for the proof of concept build this should be fine. After all i probably won't have time to create a multitude of charactes.
Minor roadblock
I need to sort out the new system structure i mentioned in a prior post, however I am struggling to figure out the best way to do it. The one option I know i can work with is to create a blank actor to handle stuff, but I can't say I'm too fond of this approach. It feels messy and there has to be a better way.
I was informed about potentially needing do use some kind of spreadsheet table for parts of this project, and I'm thinking this may be what that was referring too, however I don't even know where to begin with that. I will need to look into this a bit in order to figure things out.
Reviewing my initial timetable
When beginning this project i planned out a timetable of the things i expected to get done each week. Here I will review the accuracy of this, and at the end I will create a new, updated timetable based on current progress.
Here's my original timetable:
Weeks 1-3 were all about research, and I did spend this time researching the themes, however I also got distracted trying to learn some Unity as well, since at the time I wanted to attempt to do this project in a different engine to challenge myself. This led to the intended 3 weeks to last much longer. In fact development only started during week 7. This is an unacceptably long amount of time, and meant i had spent over half of the project time just on the initial research stages, leaving me with only around 5-6 weeks to actually develop something. This was terrible time management on my part and I fear my grade will be affected as a result. I intend to use the remaining time as best as possible so I can end this project on a high note, even if it means I won't be able to do everything I initially wanted to do.
Weeks 4-6 were supposed to be prototype creation. Here i would create an incredibly bare bones concept version of the project, which would act as a way to showcase the general idea of the project. Unfortunately during these weeks I was still in the research stage. I have only recently begun actual development and as such I am still in this phase, just multiple weeks later than I'd hoped.
Weeks 7-8 (In week 8 at time of writing) were supposed to be the final stages of the MVP, finishing up any necessary extra menus and getting people to play test. Unfortunately as previously stated this was not met, and I am currently in week 8 about halfway through the prototype phase.
I am sorely concerned about my ability to come out of this with a finished project. I expect i may have to skip out on a lot of aspects I'd have liked to have completed, such as creating an in-depth example battle, as well as some nice assets.
Absolute worst-case scenario, I do still plan on developing this further even after the FMP is over. I would love to realise the initial idea i had planned, regardless of whether it contributes to a grade or not.
With this, we can safely conclude that my initial timetable was terribly inaccurate and needs a drastic rework. So here's a timetable for the remaining time that's hopefully more realistic:
Weeks 8-9: Finish basic menu's and actions, creating a solid prototype. Get some feedback on this and make any necessary adjustments accordingly.
Weeks 10-11: Polish out the prototype and add any other needed features. Also import some assets such as music, sound effects, sprites, UI elements, and backgrounds. If there is time then create some of these myself otherwise find free to use assets online.
Week 12: Finish any unfinished features, or discard them if there isn't enough time. Spend rest of time testing and bug fixing. Do NOT start creating new features beyond this point unless absolutely necessary as well as realistically and easily achievable. Week 13: Project should be in an acceptable state to hand in. Fix any drastic bugs if absolutely necessary, otherwise spend week creating an itch.io page for the project, as well as a game play video and working on needed documents to review the project. Also make sure Tumblr blog is all up to date and any drafted posts are finished and posted.
Hopefully this timetable should be more accurate. I will need to discipline myself these remaining weeks and avoid any distractions. I will set myself schedules and reminders to keep me organized to the best of my ability. I should be minimizing my leisure time for the remainder of this project if I want a good outcome.