I set up a new website for OpenArthurian, development of the engine will be posted there. The site also contains dedicated pages for:
- About: What is this project
- Project Status: How far along are we
- Project Plan: Detailed progress on the plan
- Instructions: To create games using the engine
- Contact: Send me spam.
Making the enemies being able to attack the player with ranged weapons required two things: first was allowing defining initial inventory for mobs (so that they could have ammunition for the weapons).
This was already possible for NPCs, but not for MobTypes. I considered merging this data together but rather decided against it so that you could have NPCs share MobTypes without having to duplicate data. So now you can define initial inventory for both (and it will be added together).
After modifying the “base” mobs tileset to handle two types of soldiers (swordSoldier and xbowSoldier) with different weapons and inventory, I ran into problems with the process of embedding the tileset on the tiled map. It just doesn’t seem possible to update the embedded tileset with modifications (Once embedded it’s copied into the map, and I couldn’t find a way to replace it without deleting the tiles that were already using it).
However, on a second thought, I think it makes sense for the mob types and NPCs to be used in a given map to be embedded as tiles on its tileset. This means I’m ditching the idea of a “master” external tileset for the mobs, instead, each map will have tiles with custom properties for it.
Once that was in, I implemented some basic AI for the enemies, if they have a ranged weapon and there’s a clean LOS, they will fire instead of bump-attacking. This worked well, however, I hit a problem with the hybrid realtime-turn based model since the combat mode was not being kicked until the projectile animation was over, it was possible to affect the flow just by moving around evading the projectile while on exploration mode.
Plans for M1 are looking good, this is the list of pending tasks:
- Implement “triggers” in combat based on a number of turns passing.
- Transport to another map via trigger outcome
- Fix bug: NPC interaction depending on having pressed a key
- Fix bug: Crash when all party members killed
- Add indicator for party member’s HP (New)
- Fix conflict between party members and friendly NPCs in combat
All this should be done by the end of the week.
I’m also in the process of setting up a website for the project. This includes it having a logo, so if you think you can contribute with a cool looking logo, please let me know 🙂
Back to development!
Added a mask for the celestial bodies on the skybox, tried first with a sprite mask but then realized a simple rectangular mask would work just as well.
Next up was sky color, dug up a very old sky color calculator thing done originally for Pixal in 2009
Also found these notes which seems I used to code it :
atmosphereBase: Universe is black always, right?
lightStrengthForTheHour (Sun)0.0 ----------> 0.3 0.7 0.9 ------> 1.0 ------------------> 1.0 ------> 0.9 0.7 0.3 ---------> HOUR 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
baseLight: Stars emit white light.
It seems like the core of the tool is an interpolation function for these values, coupled with some research on how light works in the atmosphere (over-simplified of course). I went ahead and used the original old source code (probably one of my first works in JS) and transformed it into a decent module. It’s now integrated into the engine, in theory, this would allow to change some attributes of the atmosphere and have the color of the sky respond (small details, but it’s fun).
Also allowed defining items for the NPCs, which allows Shamino to fire arrows.
Been considering how the UI should work (full-screen map vs. a layout similar to U6). For now, I think I’m going to continue on the route to create an exult/nuvie-like layout with floating windows. This also means much smaller reliance on the events log/messages window for things like combat, the damage will instead be shown on screen, for starters.
Another thing I’m considering is merging MobTypes and NPCDefinitions, I see a lot of overlap there, and it’s causing the code to be more complex than it should, what I’m thinking is a single list, so you’ll be able to define what a generic skeleton is, and in the future make spawners for them, but in the same set of definitions you would have for example Shamino, including his full dialog and initial equipment the current way things are laid out you reference a mob type from the npc definitions, but I’m finding out that most of the times you will not reuse an existing mob type….
Unless maybe if we need to have a lot of NPCs, reusing the same basic definition for a “townsman” or “children”… gotta think about this more before making the moves in the code
The source code for OAX6 can now be checked out by campaign backers as defined in their perk level.
It is still early, but even at this stage, a simple game could be created! I hope some of them get to play around with it and come back with suggestions. Of course, as development continues it will become easier (ultimately providing editing tools for this) and more complex games will be able to be created.
The instructions have been posted at the OpenArthurian website
Still not there but it’s been a lot of work. As I worked towards the goals for Milestone 1 I found quite a bit of work was needed on the dialogs and the mobs AI.
- “The Law of Virtue” scenario
- New test map (Forest clearing)
- Asteroth conversation
- Shamino conversation
- Scenario setup
- Read starting map, starting time of day and starting player position from Scenario Info
- Allow placing NPCs and Mobs on the tiled map
- Added support for simple “Cutscenes”, that is sequences of text dialogs to tell the story.
- Support multiple fragments of dialog per keyword
- Add variants per keyword based on player flags
- Add support for “triggers” executed inside the conversation
- Add triggers to join the party, end conversation and set player flag
- Fall back to “unknown” dialog if no match on variant
- Merge triggers into the dialog as objects so they happen sequentially
- Add support for dialog qualifiers (in addition to normal dialog lines)
- Dialog interruption: for other NPCs to participate in.
- Event: For event descriptions
- Add support for keyword synonyms
- Allow NPCs to start a dialog when getting closer
- Make friendly mobs act differently than party members
- Make unfriendly NPCs have a minimum range before chasing
- Implement intents for mobs
- seekPlayer: Do nothing waiting for the player to be on sight
- waitCommand: Do nothing.
- Implement subintent logic based on intent.
- Use direct LOS to define if can track player.
- Speed up combat
- Added Shamino and Soldier Mob appearances
Funders with early source access privileges will be given access to the source code repository on request starting now!
Note that some work was done offline, of course.
Almost one year ago, I lay down a general plan for the development of the engine, lots of things happened since the campaign was funded, and there has been progress, but not at the pace I expected.
But now, I have much greater control of my work schedule, and it’s time to get serious. I also spoke with my friend Exodus Destiny Dragon, and he’s up to continue pushing the development
I still believe the original model, based on “capabilities” and “engine aspects”, is the way to go to get to the first release. I will include an additional facet: a plotline, for a game using the engine.
You may wonder, why is this important? and I believe it comes down to… motivation. It is hard to keep a constant influx of motivation when working on an engine, it’s cool to see things come together, but it’s too easy to lose direction if there isn’t something tying everything together.
From that initial plan, we have covered the following:
- Move around the map
- Pick up an item from the map
- Talk with a NPC
- Check the inventory of a party member (Some progress)
- Drop an item on the map
- Enter and leave combat mode
- Attack an enemy within melee distance
- Attack a far away enemy
- Day and Night Cycle: Some progress
- Follow player
How does the plotline affect this plan? all the items will be steered towards the construction of the scenario supporting it.
When the game starts the intro is displayed as follows:
- The Avatar has been summoned back into Britannia, arriving during the night in a forest near Yew.
- He finds Shamino and talks with him, learning about what has happened on Britannia.
- They decide to head back into a safe place but are suddenly attacked by a group of soldiers led by Lord Asteroth of Empath Abbey.
The game starts in a forest clearing at night in combat mode (Similar to Ultima VI)
- The Day/Night skyline indicator is visible, showing night.
- The party is the Avatar and Shamino, they take turns to attack the enemy.
- While in combat, the party members can move around
- The Avatar is armed with a sword so he can do melee attacks
- Shamino is armed with a bow so he can do ranged attacks
- The enemy soldiers attack the party members using melee and ranged attacks
After 2 turns, Shamino is shot by a magic bolt by Lord Asteroth and is taken out of combat. Cutscene unfolds:
- Out of nowhere, Iolo appears along with a band of resistance members
- He shots Lord Asteroth with his crossbow and forces the soldiers to flee.
- Then they disband leaving the party alone.
- Iolo says they must seek refuge on his hut to the west.
- Party is transported to Iolo’s hut.
Inside Iolo’s hut, the Avatar can:
- Save the Game, Exit and Restore
- Examine Iolo
- Talk to Iolo using keywords
- Ask Iolo to join the party
- Open and close its main door
- Read a book containing Iolo’s notes during the Quest of the Avatar
- Get a key and use it to open an inside door going into his workshop
- Go to the second floor
- Examine a wall finding a secret lever (Revealed by Iolo in conversation)
- Use the lever to open a hidden door into a room with a mystic sword.
- Switch main character to Iolo
- Get Mystic Sword
- Examine Mystic Sword (in Inventory)
- Get Magic Axe
- Get a bag
- Switch main character to Avatar
- Check Avatar’s inventory
- Check Iolo’s inventory
- Put Mystic Sword into bag
- Put Magic Axe into bag
- Take Mystic Sword out of bag
- Give Mystic Sword to Avatar
- Make Avatar Use Mystic Sword (Wear)
- Get yellow and blue potion
- Drink Yellow potion, recover 5 HP
- Drink Blue potion, recover 5 MP
- Get lute
- Use lute (go into instrument mode, can play using numbers)
- Exit instrument mode
- Use torch in the wall (put it off)
- Use torch again (light it)
- Get torch
In the area surrounding the hut, the Avatar can
- Move around, having the party members follow him.
- Examine the trees around
- Examine a rock laying around
- Get the rock
- Drop the rock
- Examine crate (Has some corn inside)
- Move rock into crate
- Examine crate, pick corn from crate
- Use corn, be less hungry
- Read a gravestone
- Check the status of Shamino
- Talk with Shamino, ask him to leave the party.
- Talk with Shamino, ask him to join the party.
- Get bucket, drop next to cow.
- Use Cow (bucket gets filled with milk)
- Attack Cow (Switch to combat mode)
- Cow flees (peaceful animal AI)
- Switch off combat mode
- There are two friendly NPCs around (resistance members). They are hiding at Iolo’s
- The friendly NPCs sleep at night in the barn, go to the fields during the morning, and have lunch at home at noon.
The party travels south
- Smooth transition into another map segment (forest)
- Time goes on into dawn and morning.
- Party attacked by headlesses group. (Switch into combat mode)
- Cannot switch out of combat mode.
- When a headless is killed, he drops a corpse
- After killing all headless, combat mode is automatically turned off
- Corpses of headless can be examined as containers, they can have a club or not.
Or the party can be defeated…
- If the headlesses or the soldiers kill the party, it’s game over
While implementing this flow doesn’t ensure the engine is completed, I believe iterating over it making it progressively better and more flexible every time will push forward the development of the engine.
Now comes the question about the dates. The idea is to produce biweekly builds and the plan is to have a working version of this flow within 20 work weeks, as detailed here.