Hi, Geril here.
This month we met a fellow artist who happened to be working on a FPS project.
He showed me their work, and although I liked the quality of the graphics, I thought the technology behind it was lacking. I made a deal with their team: we'll make an FPS project similar to theirs using their assets, but in Unreal; and if they like it, we'll be able to get on their team.
So this month we worked hard on making an FPS game from scratch. Of course because Unreal is excellent for shooter games, it was much easier than the other projects we have worked on, so we made rapid progress.
As of now, we have implemented:
– health and shield systems
– a basic enemy AI
– sprinting
– a weapon database with different weapon types (we made lasers, ballistic bullets, explosives and an energy beam for now)
– weapon sway and recoil for feedback purposes
– ammo logic
– weapon and ammo pickups
– a GUI directional hurt indicator
– different enemy types and a spawner
– a gore system (dismemberment and such)
– custom damage logic
– interruptible death sequences before ragdolling
– splitscreen local multiplayer
– switching to third person camera on player death
And some more, smaller stuff.
The team liked what we did in less than a month so they let us on the team!
As for now, we can't show you any images or videos, but we'll ask them if we could share some test footage here.
Showing posts with label development. Show all posts
Showing posts with label development. Show all posts
2019/07/31
2018/06/28
Beatmap editor in Unreal 4!
Hey there! This is Lussy.
We've been hard at work on our rhythm game projects, and we've managed to create a feature we've never thought we could do with Blueprints only, coupled with our current experience. But alas, it has happened.
We've created a beatmap editor inside Unreal 4 using only Blueprints and Rama's Victory Blueprint plugin (it's a godsend, check it out if you're using UE4!).
For the editor, we used osu!'s editor as a reference, and for now it can only create and edit Taiko type beatmaps. We plan to overhaul it almost completely for our own game, but first we had to try if it was even possible to create.
The editor uses .ogg files as music, and creates a text file with a matching name for each new .ogg file. The file contains BPM and title information, as well as all the beat objects or notes in the song - similar to how osu!'s .osz files work. We dubbed ours as .beatmap files though.
Once the file is created, the user can enter a BPM calibrator that lets them tap a button in time with the music. The editor then calculates based on those clicks the BPM of the song, or alternatively, the BPM can be input manually.
After this is done, the actual editor lets users put notes down on each beat of the song, change their colors around and then save the beatmap. The beatmap can then be played in play mode.
The whole thing is very raw right now, because we haven't had as much time to work on it as we wanted to, but it's getting there. This tool will be very useful for developing our rhythm games, and we plan to include it in the game too, so users can create custom content with songs they like.
At this point we're starting to feel like anything is possible in Blueprints with the right nodes and tools. Of course knowing C++ would help greatly, so we're going to get on that, too, but there's no rush.
We've been hard at work on our rhythm game projects, and we've managed to create a feature we've never thought we could do with Blueprints only, coupled with our current experience. But alas, it has happened.
We've created a beatmap editor inside Unreal 4 using only Blueprints and Rama's Victory Blueprint plugin (it's a godsend, check it out if you're using UE4!).
For the editor, we used osu!'s editor as a reference, and for now it can only create and edit Taiko type beatmaps. We plan to overhaul it almost completely for our own game, but first we had to try if it was even possible to create.
The editor uses .ogg files as music, and creates a text file with a matching name for each new .ogg file. The file contains BPM and title information, as well as all the beat objects or notes in the song - similar to how osu!'s .osz files work. We dubbed ours as .beatmap files though.
Once the file is created, the user can enter a BPM calibrator that lets them tap a button in time with the music. The editor then calculates based on those clicks the BPM of the song, or alternatively, the BPM can be input manually.
After this is done, the actual editor lets users put notes down on each beat of the song, change their colors around and then save the beatmap. The beatmap can then be played in play mode.
The whole thing is very raw right now, because we haven't had as much time to work on it as we wanted to, but it's getting there. This tool will be very useful for developing our rhythm games, and we plan to include it in the game too, so users can create custom content with songs they like.
At this point we're starting to feel like anything is possible in Blueprints with the right nodes and tools. Of course knowing C++ would help greatly, so we're going to get on that, too, but there's no rush.
2018/01/31
Still busy...
Hi!
Okay, the fact that we are busy hasn't changed since last month... But at least now I have some time to write about our latest Unreal 4 adventures.
We had to script a horseman. The horse mesh was given to us, complete with materials and animations. The challenge was putting an already heavily script-based human on top of the horse and syncing up their animations and movements.
We united the horse and human skeletons in Blender, and animated the human on top of the horse that way. We then exported the unified skeleton, along with the animations, and assigned the horse to that skeleton. An animblueprint was built for the unified skeleton that contains IKs for putting the rein in the human's hands and the stirrup on his feet (If the IKs relied on any variables outside of their respective animblueprint, they lagged behind about one frame).
Now comes the hacky part: we stuck the human on top of the horse, retargeted the riding animations of the merged skeleton onto the human's skeleton, then built the same animblueprint for its skeleton too, sans the IKs. We rigged the whole thing so that the merged skeleton's BP sends signals to the human's BP to change anim states, so the changes occur at the same time and the animations stay in sync. Occasional errors still occur once in a blue moon (oh crap, today's a blue moon!), but we suspect those are framerate-related.
This system feels bloated and makes any later changes risky, however, we couldn't come up with anything more stable at the moment, and under our current pressure. Do you guys have ideas on how to make such a system more stable?
Okay, the fact that we are busy hasn't changed since last month... But at least now I have some time to write about our latest Unreal 4 adventures.
We had to script a horseman. The horse mesh was given to us, complete with materials and animations. The challenge was putting an already heavily script-based human on top of the horse and syncing up their animations and movements.
The movement part was easy, we attached the human's pelvis to a socket on the horse's saddle. However the animations were a bit more tricky, and we still think the whole system could have been done better, but not sure how.
This was our solution:
This was our solution:
We united the horse and human skeletons in Blender, and animated the human on top of the horse that way. We then exported the unified skeleton, along with the animations, and assigned the horse to that skeleton. An animblueprint was built for the unified skeleton that contains IKs for putting the rein in the human's hands and the stirrup on his feet (If the IKs relied on any variables outside of their respective animblueprint, they lagged behind about one frame).
Now comes the hacky part: we stuck the human on top of the horse, retargeted the riding animations of the merged skeleton onto the human's skeleton, then built the same animblueprint for its skeleton too, sans the IKs. We rigged the whole thing so that the merged skeleton's BP sends signals to the human's BP to change anim states, so the changes occur at the same time and the animations stay in sync. Occasional errors still occur once in a blue moon (oh crap, today's a blue moon!), but we suspect those are framerate-related.
This system feels bloated and makes any later changes risky, however, we couldn't come up with anything more stable at the moment, and under our current pressure. Do you guys have ideas on how to make such a system more stable?
Labels:
animblueprint,
blueprint,
development,
horse,
horse riding,
horseman,
script,
ue4,
unreal 4
2017/04/29
Project Contrivance overworld progress!
We have lots of work unrelated to our own projects, and we've been networking with other artists. That slowed our progress with Project Contrivance considerably, but we haven't stopped completely.
We've been putting together the game's story for a while now, and I'll share the version we've liked the best.
The game plays out inside a person's head. The players play as two microscopic robots that are sent out to fix the person's faulty implanted chips and other artificial additions. We're already working on boss fights that explain the various things that happen inside the levels.


The overworld will be divided into multiple chunks that give players entry to the game's levels. Because of this division into multiple parts, we can play with the post process effects and color settings of each section. The overworld's fleshy appearance will likely be seeping into the levels themselves as well, through little cracks and damaged parts.

The design is very unfinished, background objects are absent, there are no gates for the levels, no puzzles, and the overworld is not the final size, but much smaller. But it's a start, and good enough for testing.
2016/09/30
Underrated games!
Hi!
We're deep in work. We're working on Lemniscate, sometimes OLP, and lots of other paid projects. While we can't update you with anything we're working on as of yet, we've had an idea. We usually only post work-related things on our blog, so today we'll look more on the fun side of things.
Both of us got into game development because we've spent our childhood and adulthood playing video games. We'll share some of our favorite games that are not widely known, or underrated.
Donkey Kong Country: Tropical Freeze
Dust: An Elysian Tail
This game has a similar gameplay to Castlevania and Metroid. It was mostly made by one person, Dean Dodrill.
It's so underappreciated that even I had no time to finish it. It has lots of references to Korean food and culture, and funnily, the last time I've played it was when I was on a 3-hour train ride across South Korea last year. If I'll ever have more free time... I'll finish it.
We're deep in work. We're working on Lemniscate, sometimes OLP, and lots of other paid projects. While we can't update you with anything we're working on as of yet, we've had an idea. We usually only post work-related things on our blog, so today we'll look more on the fun side of things.
Both of us got into game development because we've spent our childhood and adulthood playing video games. We'll share some of our favorite games that are not widely known, or underrated.
Donkey Kong Country: Tropical Freeze
I honestly don't understand how this game could go so far under the radar. In my opinion, this is one of the tightest and best platformers of this console generation. All the levels are varied and excellently designed, both gameplay-wise and graphically. What's more, almost all of them have their own music written by David Wise, resulting in a 4-hour OST that we listen to often while working on our games. I want to make OLP's controls feel as responsive as DKC: TF's do - when we were getting started with the controls, I would often turn on this game to get the jump height and speed right.
So if you've got a few hours to spare, DKC:TF will pull you right in with its cheerful atmosphere and catchy songs, and you'll soon be smiling smiles of pure joy.
Dust: An Elysian Tail
This game has a similar gameplay to Castlevania and Metroid. It was mostly made by one person, Dean Dodrill.
It's so underappreciated that even I had no time to finish it. It has lots of references to Korean food and culture, and funnily, the last time I've played it was when I was on a 3-hour train ride across South Korea last year. If I'll ever have more free time... I'll finish it.
Mario Kart: Double Dash
Anyone who's played a Mario Kart game knows why the series is loved by many. It's the perfect party game, ruining many friendships with some rather unfair moves.
Usually the most recent game is considered the best, and with good reason, but Double Dash was different from all the other entries in the series, and it is most often considered a misstep.
The main difference is the option to play co-op with two players sitting in one kart, one driving, the other using items. This is an aspect of the game that we'd like to implement in some of our games.
It's easiest to describe this game as the predecessor of the Bioshock games, but it had lots more possibilities. The graphics and the interface do not stand up to today's standards, and the story is also slow. We recommend playing the Steam version with someone else in co-op. It's recommended to play with someone who has at least as much patience as you do for these kind of games.
Enslaved: Odyssey to the West
Although the gameplay itself wasn't really satisfying (jumping from hotspot to hotspot, slaughtering enemies with a simple fight system), the story, the characters and the graphics are amazing even today. We want to include similarly fleshed out and believable characters in our own games. Although we probably won't be able to hire Andy Serkis to do the mocap and voice acting for us. Sigh..
Brütal Legend
We first came to like Tim Schafer's game through Grim Fandango, but he's risen to the rank of Legend for us with Psychonauts. Brütal Legend basically looks like every heavy metal fan's wet dream. The atmosphere is great, the characters are well designed and flexible. It seems like Tim Schafer mostly begins his games with simple ideas, then develops that simple idea until it gets really complex.
And that humor.
System Shock 2

This game has inspired us while building the abandoned spaceship of Lemniscate, and helped us pass some hours with its LAN multiplayer gamemode.
Please look forward to our updates next month!
Please look forward to our updates next month!
2016/06/11
IT'S HAPPENING!
Hey, it's Geril.
Okay, so a lot of stuff happened in the previous weeks, but we'll write about those in a later post. There is some paid work in our future.
Lussy finished her finals and got the best grade possible. For her exam, she presented some of OLP's assets which were quite unique compared to the average works presented there.
This is about it, see you next time!
The funniest thing is, we were looking at the Greenlight page last night and talking about how it might take some months for us to get greenlit (we were at 35%). Then this morning, an e-mail came that it happened. It was unusually easy to get out of bed afterwards.
The only question remaining is how to release the game legally while still making a profit. Regardless, we're happy that we made it even with our abysmal marketing skills.
A big thank you to everyone who helped us achieve this!
(we're working on the tutorial for the dynamic normal maps, but we're doing lots of other things, too, so please, be patient)
Okay, so a lot of stuff happened in the previous weeks, but we'll write about those in a later post. There is some paid work in our future.
Lussy finished her finals and got the best grade possible. For her exam, she presented some of OLP's assets which were quite unique compared to the average works presented there.
This is about it, see you next time!
...
Oh man, it almost slipped my mind..
LEMNISCATE HAS BEEN GREENLIT!
The funniest thing is, we were looking at the Greenlight page last night and talking about how it might take some months for us to get greenlit (we were at 35%). Then this morning, an e-mail came that it happened. It was unusually easy to get out of bed afterwards.
The only question remaining is how to release the game legally while still making a profit. Regardless, we're happy that we made it even with our abysmal marketing skills.
A big thank you to everyone who helped us achieve this!
(we're working on the tutorial for the dynamic normal maps, but we're doing lots of other things, too, so please, be patient)
2016/05/11
Dynamic facial normal maps!
Hiya!
We've been working on ideas for Lemniscate, and we were reminded of something we've wanted to try doing for a long time: dynamic facial normal maps tied to morph targets. You know: when a character pulls up an eyebrow and wrinkles appear on his forehead, and the like. It took us about a single workday to implement this using UE4 Blueprints (maybe eight hours including creating the normal maps).
We don't want to spoil anything of Lemniscate, so we've applied this technology to one of our characters from OLP, Beat. She hasn't had a singing video yet, so with this, all of the characters have lip-sync videos where they make fools of themselves.
This animation isn't final or fully detailed, the body animation is still in progress so this version is made of recycled, already existing animations. Oh, by the way, we've also made the texture based eyes work.
If you're interested, we can probably make a quick tutorial on how to make dynamic normal maps (EDIT: here it is) and texture based eye movement work in UE4 Blueprints.
We've been working on ideas for Lemniscate, and we were reminded of something we've wanted to try doing for a long time: dynamic facial normal maps tied to morph targets. You know: when a character pulls up an eyebrow and wrinkles appear on his forehead, and the like. It took us about a single workday to implement this using UE4 Blueprints (maybe eight hours including creating the normal maps).
We don't want to spoil anything of Lemniscate, so we've applied this technology to one of our characters from OLP, Beat. She hasn't had a singing video yet, so with this, all of the characters have lip-sync videos where they make fools of themselves.
This animation isn't final or fully detailed, the body animation is still in progress so this version is made of recycled, already existing animations. Oh, by the way, we've also made the texture based eyes work.
The quality of this gif isn't great, but you can hopefully see how the normal maps change. We should really make some older characters, this would look perfect on them.
If you're interested, we can probably make a quick tutorial on how to make dynamic normal maps (EDIT: here it is) and texture based eye movement work in UE4 Blueprints.
Just to make it clear, we're progressing with the development of Lemniscate. This is one of the rooms (the staff quarters):
2016/03/12
Feature Update!
Hi!
It's time for another update on how the development is going. We've, since the last update, added:

Objects that can be picked up and thrown, and if they are thrown with enough force, they break/explode. These are not using UE4's built in fracture mesh. They spawn gibs and particle meshes on impact, destroy themselves and of course, make noise, too.
We can't show you yet, but the monster can now react to noises. It's possible to distract him with throwing an object somewhere far, and if the monster is close enough to hear it (or it is loud enough), he will inspect the sound's location.
---
In other news, we're preparing for our Steam Greenlight campaign, and trying to find legal ways to release the game (we're in Hungary... it's not easy)
This is all for today, see you next time!
It's time for another update on how the development is going. We've, since the last update, added:

Objects that can be picked up and thrown, and if they are thrown with enough force, they break/explode. These are not using UE4's built in fracture mesh. They spawn gibs and particle meshes on impact, destroy themselves and of course, make noise, too.
We can't show you yet, but the monster can now react to noises. It's possible to distract him with throwing an object somewhere far, and if the monster is close enough to hear it (or it is loud enough), he will inspect the sound's location.
---
The doors also got an upgrade. The door system itself changed, now every door uses a certain color, and the corresponding colored card opens the door. They also got this flashy sign on the buttons that shows if they are locked or not.
---
We've added a note system to the game. Every in-game character has a Personal Assistant Device (P.A.D) that they use to take notes with. The P.A.D assigns these notes to the locations they were recorded at inside the ship. If you find someone's P.A.D, their notes will become visible and readable.
Like this poor fella's.
And this is how the note looks if you activate/deactivate the found P.A.D.
---
We've added visible points to the spine of the monster, so he can be seen from farther away.
---
One of the biggest features we've added is the fire detection system in the ship. If there is a fire, the sprinklers will activate (if the water system is active, of course), and put it out over time. The fire can also kill the player if he stays in it for long enough. Also, if the player stands under the sprinkler, he gets wet and the camera also gets an effect that makes it hard to see. It fades over time, but while he's wet, electric devices will be dangerous to him.
---
The last thing is the way the day ends. After a set amount of time, time resets, and we've added an effect that sweeps through the ship, representing the time loop starting everything over.
Also, related to this, we've made a clock that shows the current time. This will be the clock that wakes the player every day, and he can also use it to determine how much time he has left of that day.
We're still working on the interface, there are a lot of placeholders and debug stuff there, please excuse the messiness.
We're still working on the interface, there are a lot of placeholders and debug stuff there, please excuse the messiness.
In other news, we're preparing for our Steam Greenlight campaign, and trying to find legal ways to release the game (we're in Hungary... it's not easy)
This is all for today, see you next time!
2016/03/02
Project Blind story details!
Hi! It's Geril.
We haven't really talked about the story of Project Blind, because obviously, we don't want to ruin anything. But I'll try my best to give you an overview.
The game is set on a transport spaceship that carries supplies from and to a city-sized science base. In the game, there are also four people being transported on it, one of them being the player, an ex-engineer who had a severe accident and lost his vision, and therefore his job. He is in a coma after the surgery that replaced his eyes with a machine.
The other three people are a newly retired doctor, a scammer lawyer and an insane designer. All three of them leave messages in their portable devices, which the player can check to find out more about them.
The spaceship has a crew of five people who keep the ship in check, while the ship carries them through space on a predefined path.
Among the cargo, there is a military experiment hidden, the result of an ongoing gene-modifying project. This creature wakes up from cryogenic sleep for unknown reasons, and breaks free.
The player wakes up after this happens. Most of his fellow passengers are dead, and he can only find out what happened by discovering clues and reading writings on the wall. The only other survivor has locked himself in the surveillance room, watching the player through the cameras, and he is the one leaving the messages.
The loose monster isn't the only thing standing in the way of exploring and fixing the ship. About eight minutes after the player wakes up, the ship enters an anomaly that resets time and the player wakes up again. Time goes back by about one and a half days, but the player always wakes up in the last minutes. By that time, the other survivor has changed what he could in the ship based on his own experience and the player's actions, to help the player progress, and locked himself in. For example, if the player rearranges a room to get to a valve to turn off the heating in the room, then the next day, the other survivor will have already exposed the valve for him. Of course, he won't repeat everything the player does, but he tries his best to help. This is why he writes the notes on the wall, although those can be misleading sometimes.
Ultimately, it is up to the player how many times the day repeats, and what the ship's fate will be.
We're on Steam Concepts! (And soon Greenlight) Check it out!
***
We haven't really talked about the story of Project Blind, because obviously, we don't want to ruin anything. But I'll try my best to give you an overview.
The game is set on a transport spaceship that carries supplies from and to a city-sized science base. In the game, there are also four people being transported on it, one of them being the player, an ex-engineer who had a severe accident and lost his vision, and therefore his job. He is in a coma after the surgery that replaced his eyes with a machine.
The other three people are a newly retired doctor, a scammer lawyer and an insane designer. All three of them leave messages in their portable devices, which the player can check to find out more about them.
The spaceship has a crew of five people who keep the ship in check, while the ship carries them through space on a predefined path.
Among the cargo, there is a military experiment hidden, the result of an ongoing gene-modifying project. This creature wakes up from cryogenic sleep for unknown reasons, and breaks free.
The player wakes up after this happens. Most of his fellow passengers are dead, and he can only find out what happened by discovering clues and reading writings on the wall. The only other survivor has locked himself in the surveillance room, watching the player through the cameras, and he is the one leaving the messages.
The loose monster isn't the only thing standing in the way of exploring and fixing the ship. About eight minutes after the player wakes up, the ship enters an anomaly that resets time and the player wakes up again. Time goes back by about one and a half days, but the player always wakes up in the last minutes. By that time, the other survivor has changed what he could in the ship based on his own experience and the player's actions, to help the player progress, and locked himself in. For example, if the player rearranges a room to get to a valve to turn off the heating in the room, then the next day, the other survivor will have already exposed the valve for him. Of course, he won't repeat everything the player does, but he tries his best to help. This is why he writes the notes on the wall, although those can be misleading sometimes.
Ultimately, it is up to the player how many times the day repeats, and what the ship's fate will be.
2016/02/17
Features in Project Blind so far!
Hi! In this post, I'd like to show you some of the features we've added to the game this month. (Because we realized that the video showed nothing) So, let's go!
Using it, you can lock the doors. There are three security levels (three colored cards), each color adds a new level of security to the door. This helps keep the monster out.
We have an inventory system with 8 slots (controlled via the mouse wheel), with which you can pick up, use and drop items. You can even use items with other objects, like putting duct tape on something!
We'll try to update more frequently, as we're moving faster and faster in development. See you next time!
First, we have: automatic doors that open when you walk into their range.
The same doors can be closed/opened with access cards, here is one such card:
Using it, you can lock the doors. There are three security levels (three colored cards), each color adds a new level of security to the door. This helps keep the monster out.
We have an inventory system with 8 slots (controlled via the mouse wheel), with which you can pick up, use and drop items. You can even use items with other objects, like putting duct tape on something!
For the items, we have a fully functional vending machine. As you can see, all of the usable items are able to display their names and two info sections on the HUD.
We have two view modes in the game, one lets you see your near surroundings in black and white, the other lets you see electricity, other types of connections, and you can see much farther with it, although in significantly worse quality.
We have a power supply system, any item has the ability to run on electricity, there are power supplies that can be chained together, and switches to trigger each individual item, or multiple items at the same time. With these, we can build a full system, perfect for puzzles. Here you can see power cores that can be inserted into the sockets, which provide power for the circuits. There are other items that can be picked up and thrown as well.
The latest addition is the ability to climb into air vents. This has no animation or transition yet, so it looks weird, but it is also fully functional.
We'll try to update more frequently, as we're moving faster and faster in development. See you next time!
2016/01/31
Update 2016
Happy New Year!
(it's a little late, but it's still 2016, so.. we're still in time?..)
We've been silent for more than a month, and it's not because we abandoned the project or this blog. We're in a situation that.. wouldn't allow us for continuous and uninterrupted development on Project OLP. The fact is, we're not making any money with OLP, and with learning more about the whole development process better, we've realized that it's not going to be completed any time soon, especially not with only two of us working. ...This sounds like we're not continuing, but it is not the case. OLP is still in development.
In the meantime, we've come up with a game idea that doesn't require years to develop. We've gained a lot of experience in the past years with our hobby (developing), and we'd like to see if we could do this for a living. So, for the last month, we've been working all day, all night, continuously, developing that game idea, and we took it really far (of course, compared to the time, experience level and... we're still just two people). We'll reveal some of the info about it now.
As you can see, it is a first-person game, still using Unreal 4. The genre could be described as.. first-person horror adventure (the point-and-click kind)..? (Still not good at defining things)
You are someone who's lost his eyesight and now sees through an implanted machine. You wake up in a spaceship, trapped inside. You have to figure out how to solve the problems that come up along your way. But here's the catch:
When you die, you go back to the beginning of the day (think Groundhog day), but you're not alone. You'll remember the puzzles you need to solve, but things change, some events play out differently. You'll have to find the right chain of events to get to the end of the game.
This game is also part of the OL universe, although is a lot more early in the timeline than the other two.
A little more about the development process itself: I (Lussy) am making all the blueprints for the project (it is made with UE4 Blueprints only), and the technology itself is coming along nicely, but as Geril is working on all the assets almost alone (I help occasionally), the art part of the game is a lot less developed than everything else. This is why the game looks barren right now.
(it's a little late, but it's still 2016, so.. we're still in time?..)
We've been silent for more than a month, and it's not because we abandoned the project or this blog. We're in a situation that.. wouldn't allow us for continuous and uninterrupted development on Project OLP. The fact is, we're not making any money with OLP, and with learning more about the whole development process better, we've realized that it's not going to be completed any time soon, especially not with only two of us working. ...This sounds like we're not continuing, but it is not the case. OLP is still in development.
In the meantime, we've come up with a game idea that doesn't require years to develop. We've gained a lot of experience in the past years with our hobby (developing), and we'd like to see if we could do this for a living. So, for the last month, we've been working all day, all night, continuously, developing that game idea, and we took it really far (of course, compared to the time, experience level and... we're still just two people). We'll reveal some of the info about it now.
As you can see, it is a first-person game, still using Unreal 4. The genre could be described as.. first-person horror adventure (the point-and-click kind)..? (Still not good at defining things)
You are someone who's lost his eyesight and now sees through an implanted machine. You wake up in a spaceship, trapped inside. You have to figure out how to solve the problems that come up along your way. But here's the catch:
When you die, you go back to the beginning of the day (think Groundhog day), but you're not alone. You'll remember the puzzles you need to solve, but things change, some events play out differently. You'll have to find the right chain of events to get to the end of the game.
This game is also part of the OL universe, although is a lot more early in the timeline than the other two.
A little more about the development process itself: I (Lussy) am making all the blueprints for the project (it is made with UE4 Blueprints only), and the technology itself is coming along nicely, but as Geril is working on all the assets almost alone (I help occasionally), the art part of the game is a lot less developed than everything else. This is why the game looks barren right now.
2015/09/28
September update!
Hi!
In this update, there actually is a lot to say.
Last week I (Lussy) started learning and making blueprints. As we are finished with all characters, Geril is progressing decently with the environment, so with though it would be best if I did Blueprints next to modeling. As a result, our game is finally starting to look/play more like a game - even more so than it did in Unreal 3.
Here is a video in which we demonstrate what we achieved up to now:
I still have a lot to learn about Blueprints, but I think I'm starting to get the hang of it. If I get more comfortable, we may try to make some tutorials. But for now, here are some of the features I added:
Sal cloth test:
Also, we were interviewed by Sketchfab! You can check the article out here.
That's all for today! Look forward to more updates, more game mechanics, and more comics!
***BONUS***
WTF moments:
In this update, there actually is a lot to say.
Last week I (Lussy) started learning and making blueprints. As we are finished with all characters, Geril is progressing decently with the environment, so with though it would be best if I did Blueprints next to modeling. As a result, our game is finally starting to look/play more like a game - even more so than it did in Unreal 3.
Here is a video in which we demonstrate what we achieved up to now:
I still have a lot to learn about Blueprints, but I think I'm starting to get the hang of it. If I get more comfortable, we may try to make some tutorials. But for now, here are some of the features I added:
Sliding
Falling from a height
Some gifs of the test maps:
The sandstorm
Inside the "house"
Sal cloth test:
Also, we were interviewed by Sketchfab! You can check the article out here.
That's all for today! Look forward to more updates, more game mechanics, and more comics!
***BONUS***
WTF moments:
After the video...
Subscribe to:
Posts (Atom)