next »

[M0ti]

This week I finally finished the last walk cycle animation (up) so my character finally walks. I’m sure that I would be redrawing it at least few times, but for now it’s satisfying. I think that the gifs from now one will get a lot more lively thanks to that.

The coding was simple. Firstly it updates the direction value based on the input. The direction value can be integer from 0 - 3.
Then it asks, if there is any movement speed in the direction the character is facing.
If there is, it runs walking animation. If there isn't, it uses the idle standing sprite for that direction.
Yesterday I also started working on the new asset. The hidden arrow thrower in the wall. I did three different samples and now I’m deciding which way to go.

Right now I’m thinking of using the right one for the arrow thrower and the left one could serve as a good hidden treasure spot.  

[M0ti]

Yesterday I’ve made a spike trap. When I started I had just two layers, the floor and the spikes. But when implemented, it looked really weird, as the spike were completly behind or in front of the hero. So after a while the trap ended to be composed of five objects.
The floor checks the collision and it has two sprites depending on if it ever was triggered or not.
And then four objects for the spike animations. They don’t do anything except to manage the animation and sets the depth based on their place in the room. That way the hero is overlaid only by the spikes beneath him.

[M0ti]

Any suggestions or recommendations with the 2D stairs?
At the end, the problem is just about how to properly simulate 3D behaviour in 2D game with layers. But because I still don’t know how to do it, I would like to describe my train of thoughts a little bit deeper.
There are few problems I kind of don’t know how to deal with.

The first one is about how to code the visual aspect of climbing the stairs. Because naturally, just by pushing the left button, not just the x value will change, but also the y coordinates should too as he moves higher.
The second problem is about how the staircase should switch hero between the layers and change the colliders/collision masks of objects accordingly.
When you are on the layer 0, the colliders will prevent you to go into the objects, but then, the staircase needs to decide, “it’s time for a change, he is definitely going up!” Then all related objects needs to disable the previous colliders and establish new, that will, for example, forbit the hero to fall from higher places. (because if he could fell down, it will kill me just thinking about how it code.)
The last question, mostly to the game maker audience, any good way how to make more collison masks for one object? Or how to make the one slant, as in the picture?

While I was writing it, I’ve got an idea about easy fix to the most of my problems and that’s the vertical stairs. With them I don’t have to bother with the change of the y value or with the slanted collision box. :D
But it will still be fine to found out, so if you have any suggestion or experience, I would be glad to hear it.

[KPas]

Perhaps you could split up the stairs into single steps? Each step would become a separate object.
There would be no slope at all. While changing the x value, the y value would perform discrete little jumps from object to object. And you could create steps with different width and assemble them into different looking stairs.
Hope this is kinda helpful!
Good luck!

[M0ti]

Perhaps you could split up the stairs into single steps? Each step would become a separate object.
There would be no slope at all. While changing the x value, the y value would perform discrete little jumps from object to object. And you could create steps with different width and assemble them into different looking stairs.
Hope this is kinda helpful!
Good luck!

Interesting idea, thank you. This could also solve the problem with the inclined collider. Each object will have only small horizontal colliders for their step. I'm a bit concerned about the possibility of the player constantly stucking in them, but that's something that will be easilly tested. :D

[M0ti]

I made kind of auto-tiling this week. It’s really simple. Each object checks it’s surrounding and creates a string like for example “EFF_FMF_EFE”. E means Empty, F means Full and M is for Me, as it's the center position. After that the string is simply examined in a lot of if statements, which decide the right sprite for the object.

[M0ti]

I wanted the animation of rising-up to be kind of organized between the individual tiles. That led me to conclusion that I would need to establish some kind of communication between them. The solution that I came up with, use the “outsider” to help them with it.

• 1. When higher ground tile is created, it register its id in the globally accessible list. (This will happen in the create event)
• 2. Obj_game, kind of manager of the global variables, then each step checks if the list is empty or not. If it’s not empty, new podium was created and it’s time to choose its leader. (This happens in the begin step event, which means that there will be no tile left behind)
• 3. Then it randomly picks one id from the list. Changes its leader value to true and gives him the list of all related tiles. After that it clears the global list, so that it can wait for another podium to be created.
• 4. Leader tile then allocate to each tile in random order a delay-time in its rise animation.

[M0ti]

In the January I tried to face the problem of giving manually too many instructions to the buttons when I wanted to create multiple instances at once.
The solution I came with back then was a script that could create multiple instances of the same object in the row. The script only needs the coordinates of the first and the last one.
Now, at the end of the March I need to address this problem once again, as this solution is still not optimal. At least not for the podium I’m working on right now. Here I will usually need to create dozens of instances in various and complicated shapes.
The solution came to me after seeing something similar here on TIGForum. The button only holds information of the top-left position and the name of the block in the .ini file.
The block in the file then contains strings representing the podium scheme in the grid. O means Open, F means Filled.
It's easy to edit and it also has the potential to create different objects as well. At least until I run out of letters in the alphabet. :D

[M0ti]

Nearest City Lore Bits Part 1 - Basic Layout

TOWER - The tower was created out of need in the center of the battlefield, so there was no intent in choosing its location. There is nothing around it, just a desert. No river, no trees, only mountains on the horizon.

FORTIFICATION - For decades the Tower was seen only as a thread and so the fortification around it was built. This made some typical city features upside down. Usually towns builds its fortification around, to defend from the unknown. When the city is developing further, the old center is in the fortification, while the newer buildings are constantly builded outside of it.
Here, because of this anomaly, the old and historical center is located outside, while newer and more luxurious buildings are finding their way into the space between the fortification and the tower.

GRAVEYARD - Graveyard is located behind the tower. Some folks are buried there, but most of the adventurers that died in the tower have no remainings to be buried. Their name is then carved in the wall of the Tower, which serves as a gravestone for all its victims.

[M0ti]

STAIRS! LET’S DO THEM!

After I outlined the problem before, I took some time to think about it, discussed it with friends and yesterday, after 8 hours of really unprofessional programming by trial and error method I made it.
For now I’m 100% satisfied with the vertical stairs alone, as they are much easier to make than the horizontal ones. I’m sorry that the colliders are mostly hidden beneath the objects, but I didn’t want to spend too much time rewriting it just for this post. I hope that with a bit of commentary it should be clear what you see. :D
First thing that you can see is that each tile has it’s kind of pinkish (red with 0.5 alpha) mask beneath its base, to simulate its presence in the 3D/2D space.
The stairs has one as well, but it also checks the green rectangle, which represents the first stair. Once you step on it, it disable its own mask and instead of it creates two borders on each sides.
Once you leave the green rectangle, it checks hero’s y coordinate. If he is above the green rectangle, it means that he is moving upwards and therefore it switch the global.current_layer from 0 to 1.
When the podium tiles notice the switch, they also disable their masks and create borders wherever are needed.
If after leaving the green rectangle hero’s y is not high enough, it assumes that he decided to go down and changes the global.current_layer to its own value, in this case 0.

Maybe not the most elegant way to do it, but it’s the best I could do right now.

[M0ti]

SEASONS OF THE TOWER

The Tower operates in similar way as an astronomical clock. Next to the obvious day-night cycle it also track and operates in weeks, months, years and many others. Which paths are open and which doors are accessible is all related to the cycles. The longest cycle that the Tower has is so-called “Closing”.
Each 180 years the Tower will shut down for around 50 years. The entrance will be barricade by solid object of the same thickness as the tower wall itself. At the same moment a countless magical barriers will rise to prevent some funny ideas as mining. And after that the weather in the desert around it will slowly change into never ending storm, which will prevent people to even approach the Tower in that time.
This doesn't mean the absolute end of the world, but it’s the end to the adventurers who were there before it. They could be still alive in the fifty years, but they will no longer be in the shape that will enable them another adventure.

And that’s exactly the danger the main character is facing. When he arrives in the Nearest City, everyone will be telling him, that he was born too late and that in few years the Tower will be closed.

[M0ti]

Hello everyone! (Interesting, it didn't occurred to me before, to address readers.)

I hope you had a fantastic week. My was not, but thankfully it didn’t stop me to get some things done.
In the last week and a half I did a lot of “non-gamedev” work, but still managed to make a huge leap in the project I think.
To start at the beginning. In the Brno, Czech Republic is going to to be a conference for game developers, with talks, indie-expo etc. And I got a little push from a friend, to participate in the exposition with this project.
So instead of programming or drawing assets I was forced to work on things like … finding a proper name for the project, as I needed it to buy a domain for the landing page.
Start making a promo art, as it’s going to be needed for the landing page, registration form for the indie expo and other places.
Write new synopsis for the project.
And today I even started making storyboards for the trailer, so I needed to start thinking about how to make the little I have presentable.
I would like to write a separate post about each of this stuff, probably through the weekend.
Btw, does anyone has any tip on a free program for capturing gameplay footage?

[M0ti]

The Game got a proper name! The Epocha Tower. It’s still just a working title, but at least it’s a proper working title now. :D
I’m not particularly good or even hyped when it comes to naming things. And I’m absolutely bad in making completely fictional words. But what can I do. There is a legendary tower that is surely subject of every second discussion between adventurers. There is absolutely no chance that this tower would remained without a name.

So the first thing was to search for the existing or legendary towers with a name. Nothing good came from it.
In the second research session I made a list of the most fitting keywords like: season, time, change, challenge, mechanical. And then translated them to every language google translate knows. Once again no usable result.
In my third run, when I was searching for the synonyms, I stumbled over the word “epoch” which I normally never use. Based of the gamerankings.com even games does not use it that often. And #epochtower was probably never used on the twitter.
So a decided to go with a Czech version “Epocha” which sounds more feminine and I see the tower as a she.
So … epochatower.com is reserved for the landing page, which is working but is still in the progress. And the #epochatower is just for me baby!

[M0ti]

[M0ti]

4. - 10.6 I will start an IndieGoGo campaign

I believe that in the last few weeks the progress on the project has been going pretty well. The picture of the game became clearer and that naturally helped me to focus on the right things at the right time.
But yesterday, when I took a few steps back to look at the project from afar, I became uneasy. A lot! Even though this happy "one step at the time" kind of development is heading in the right direction, it will not get me to my goal in time. And by "in time" I mean this year.
Because the plan is still the same. Getting resources for making the vertical slice and with it prepare a kickstarter campaign to fund the project.
So I decided to push myself by making public vow that in the week 4. - 10.6 I will start an IndieGoGo campaign to help me raise small amount of money as an aid in making the vertical slice and promo materials for this project.
I view the TIG forum as an friendly and most importantly supportive place, that's why I revealed this intention of mine here even before telling my wife.
If anyone has an experience with the crowdfunding, or if you just stumbled upon an article that you think it’s useful, please share. Or you know, if you have questions and doubts, share that too any input is desired.

I know that I will need

• Trailer
• Polished prototype
• Promo texts and materials
• And some PR plans

And I have 7 weeks to make it all possible.

[M0ti]

Wow, I neglected my devlog for almost two weaks? I should get back to it!
One thing that happened was Ludum Dare 41. My friend @jarnik visited me that weekend and in one day we created a small thing. The theme was to combine two genres.
Because of our limited time we decided to go with stealth + survival and made a game, in which you play as a homeless guy in the night zoo.

You can try it on my itch.io page.

The second biggest news is that the Epocha Tower has a Landing Page! Latest changes are not applied yet, but I think that it is already in a shareable state. :D

Official website

[M0ti]

I also made a lot of progress in those two weeks. So here is a quick summary.

• I finally implemented the sprite for the arrow thrower.
• I draw a shield pose for all directions and redid the shiled colider, as it was no longer funcioanl.
• The Hero got life and it’s visual representation so the game finally became dangerous for him.
• And when I was in it I also did death animation, programmed dead state which leads into the restart of the level.

I also made fall sprite and programmed the fall into the abyss.
In that moment I realized that I should somehow show to player that the craced floor is unsaved so I code into it the “example” mode. In this case the tile will break when the player is near.

[M0ti]

I’ve tried to order the next steps that I should undergo and the first spot on the list took the running. The main reason why I decided to prioritize this mechanic over every other is how many problems it solves at once.


 
First and the most simple one is that it allows the player to move faster. I’ve let one player to try it and he was missing run almost immediately. Especialy if I design some minor backtracking it would be helpfull.
The second problem, that is now solved by the running is how to handle traps like spikes or the crumbling floor. I thought about it a lot before. I knew that some fast movement is going to be necessary but I was thinking about roll, jump or dash. But now there is no need for any of that as the run is more than sufficient for that.

Small Level Design detail: It’s probably clear, but even though the spikes and crumbling floor work similarly (You can’t walk over it, but you can safely run over it.) there is a difference. You can walk over the spikes how many times as you want, but the crumbling floor is for one use only. It could be used for example in puzzles, where player needs to plan different route for and from the treasure.

[M0ti]

I did something wrong when I started making this game and this week I mustered all my courage to fix it.
The art I make is 16x16 but when I put it in the game it was really small! So as a complete newbie I exported everything on 300%, which means 48x48. So instead of just expanding it to desired size by code I exported each sprite larger than was needed.
But I need to change it, as my weak laptop was constantly reminding me, how bad decision it was.
Hopefully it took me only one day and that’s thanks to two factors.

• GameMaker has its own drawing tools so I didn’t have to search for all the files and shrink them outside.
• I had a created constant called tile_size which held the number 48 which I used frequently when I had to adjust the positions of objects.

By shrinking the sprites and changing this constant from 48 to 16 most of the game was functional within an hour.

[M0ti]

Next challenge that I decided to confront while I still have some time is the saving system. Thankfully I had previous experience with ds_map, ds_list etc. so it wasn’t so difficult to implement.
For Game Maker users I highly recomend both @shaunspalding and @jujuadams tutorials.






I succeeded almost immediately and was able to make a customized solution specific to my case right away.
But I have a lot of different objects and many of them holds some specific variables that needs to be saved. So it’s working but it’s not complete yet.