Contact Info / Websites
Ender Story 2! We've made some good progress once again.
-More content has been added in; things like cutscenes, areas, objects (things like chests/barrels), and npcs.
-The first set of new tracks have been completed; they sound great!
-Nothing new on the programming end yet unfortunately/fortunately :P.
This is Rambia Forest, one of my favorite areas in the game due to the new tileset!
Two new things here. New set and style of portraits and chickens!
Is that a familiar face I see?
Of course, no development ever happens without bugs. This NPC casually disobeys collision areas and walks where he wants.
Note: This image is a bit old - the barrel background 'bug' has been long fixed :P.
Next time I'll be showing off some of the more exotic areas, and perhaps a bit more of the cutscenes/portraits as well :D.
Ender Story 2 has been making strides in progress lately so it's time for another preview. There are also some small new features that will make a big difference in the experience of the game.
A new town! This town, Ominan, marks the first of many desert-themed areas as Erion travels across a desert. At first, you might find that this is not an important town, but there's a powerful secret to be found in here!
A new deadly cave that already has a lot of victims :P.
1. You probably noticed that new box outline in the new screenshots which is showing which tile the player is placing their mouse over. This was added to show that you can now click on a tile to automatically walk towards it! Now, it's possible to play Ender Story with only the mouse - instead of having to constantly switch between keyboard & mouse.
2. In ES1, the game would lag when opening any sort of object - bookshelves, chests, barrels, or skeletons. This is because the game was saving this interaction to the hard drive in order to update the player's inventory. Now, the game has been adjusted to save only in-between different screens, so there will be no lag in opening objects anymore, making for a smoother experience.
3. The third significant change is the addition of an input buffer. This is something heavily used in fighting games, but I had not realized that it was something useful to add to all types of games. Thanks to playing some Super Smash Bros. Melee, the idea came to me to add this in.
So what is an input buffer? In ES1, you might notice that trying to move Erion with the keyboard controls is a bit difficult - he won't respond to changes in directions that well. To be precise, it's coded so that it ignores input until he's done walking. So the player has to wait for him to take a step, and then press a new direction key. This makes his movement very stuttered, and hard for the player to control. Players will often press the direction key right before Erion actually stops walking, causing him to stand still, unresponsive.
So an input buffer simply holds the input that a player pressed while Erion is moving, and then waits for the first possible moment where Erion is out of his walking animation, and then reads the input. This makes it easy for the player to execute frame perfect movements (more fighting game lingo :P), and overall it makes it more natural to control Erion now.
If you're a game-dev, the take away is:
- Only save the game in between screens/levels, or at save points - these are places where the player expects the game to pause and won't be surprised if there's lag.
- If the controls of your game are unresponsive, you should look into adding an input buffer.
Here are some bugs that I came across while developing the ES2.
I walked inside a house... and was put into a wall.
Something's up with that barrel?
Hope you enjoyed the teasers & insights to changes in ES2! Since I am programmer, you can expect more bugs/programming related stuff from me rather than the content of the game. I'll still be doing some area previews, since it's fun to add teasers. 'Till next time!
Hello all :D. I've been working on Ender Story 2, and I thought that I may as well start posting some pictures of it during development. The pictures will consist of new features/additions, weird bug, and teasers :P.
Erion... the son of god? Unfortunately he is not supposed to be walking on water; it was a bug that made the water walk-able.
New feature: You can now play as different characters in the Overworld. Here I'm playing as Krat while inspecting a locked door.
...Something's over there?
Hope you enjoy this small ES2 teaser. I plan to do this kind of thing more often, so stay tuned!
About this Post
Hi there! This is little post-mortem on Ender Story 1, which I just released recently. Since I did only the programming, this will be covering strictly the programming aspect of its development. I won't be covering everything about it, since Ender Story is too huge, but let me know in the comments if there's something in particular you want to know about.
This section covers the tools I used to program Ender Story. Some info right off the bat:
-Programming Language: AS3
-Libraries: Flixel (as a game engine), TweenMax (for animations), Apache Flex
I avoid using Adobe Flash Professional's GUI and work strictly with code by using FlashDevelop. The reason being is that code gives more flexibility in terms of what can be done. Also, as a programmer, I have more experience in developing applications without using GUIs.
Flixel is a library for flash games made by Adam 'Atomic' Saltsman. I used it as Ender Story's engine because it simplifies some tasks: user input, sprite display and animations, and state management. Honestly, I did not take advantage of its features as well as I could have, and ended up writing some engine code myself alongside with using Flixel. For example, the overworld camera and the save file systems were things that I could've had Flixel handle, but I handled it personally (I didn't know that Flixel could handle it at the time =P). Still, using Flixel saved me quite a bit of time, and I got experience with learning how to use game engines at the same time.
TweenMax is a tweening library by GreenSock. It's both easy to use and very powerful; it is responsible for any sort of movement you see in Ender Story. I'd highly recommend using it. Some specific examples are:
- Moves the main character and NPCs in the Overworld
- Moves spell animations
- Handles screen transitions (fading/unfading to black, and the 'swiping' battle transition)
I started Ender Story when this account was made, so it took around ~23 months or just about 2 years to get the first chapter out. Keep in mind that Ender Story is designed specifically so that we can re-use the code for its sequels, so the next games will take significantly less time to release. I expect ES2 to take no more than a 3-4 months to finish, maybe add a month for testing since it will be a much larger game.
The codebase of Ender Story is gargantuan for a one programmer project. Here's a screenshot for the line of code counts for my project:
The 'src' folder contains all of the code that I wrote for Ender Story. Basically, the game is composed of ~20.5K lines of code. It also uses the help of a few libraries (which are both over 50K lines of code, heh.) There are a lot of classes and tons of functionality packed within Ender Story, so it makes sense that the project has that many lines of code. Note that some of those lines are not *actually* code, but are actually a part of the game's database.
The game's database is stored across many .as files; the gist of it is that I store data in public static arrays and access them in other classes. This is not a conventional method of storing data, nor is it one I recommend. It would have been much wiser to use something like SQL. Still, this method isn't *too* bad, because there is no parsing involved so it allows you to simplify the data accessing process quite a bit. It does have a ton of cons though, one being that arrays being too dynamic and flexible which can causes runtime errors stemming from small typos.
Also, this database only works because I do not write to it at runtime. This is because it only contains data used to initialize various parts of the game – it doesn't store save data for example, that is handled by using Flash's SharedObject.
The underworkings of the overworld of Ender Story are actually quite interesting. It may not be obvious, but the levels you see are actually just straightup .PNG images (as opposed to using a tileset). For example, observe the "level image" used for Shorik:
That is the very image used to create the Shorik level in-game. You might wonder "How the heck do the boundaries and objects in the level work?" Well, for each level in the game, there is a second image which is used to define these things. Take a look:
This is known as the image's "alpha". It uses colors to give meaning to the level image. If you look at this image and the actual Shorik image, you should be able to deduce what each colour means. I won't spoil it, so try to figure it out yourself :D.
So to generate a level in Ender Story, all you need are two images: the background, and an alpha. There's also some smaller details, such as which music to play, or where to spawn NPCs, but I won't go too deeply on that. It may be cool to know that these levels are stored in the Database I talked about earlier.
This method of generating levels is fairly modern, and the main advantage is that it gives control to the level design entirely to the artist. It's not something done in the past since using an image for each level would take up way too much space, however nowadays the file size saved from using a tileset versus a background image is negligible with today's internet speeds.
So that was just a bit of a taste of what Ender Story is like behind the scenes I suppose. I hope this post was useful to new developers out there. There's a lot more to learn from Ender Story in terms of its architecture, but I stopped myself from writing too much of an essay :P. If you have any specific questions, feel free to post them in the comments :)