Wednesday, October 17, 2018

Eroico has been released on Steam

Eroico has been released on Steam:

If you download the demo, your unlock codes (Eroico or Noaika) can be placed in the game folder called "cloud", which will unlock the game as usual (uninstalling it may remove it from the libary though). If you've bought the game before and want a Steam code, email me and I'll see what I can do. However it might not happen right away, since I don't have the ability to create codes freely, they must be requested from Steam.

There have been a few minor updates:
-F1 now activates a cheat mode (the 1 key refills health and magic, 2 restarts the room for speed running practice.)
- New title screen
- The ending has different music, and is now animated.
- A few bug fixes.
- The Steam version should now automatically apply button mapping to Xinput controllers, which aren't supported normally in GM8.
- Cloud saves.

Edit: I'll be uploading the updated version to all the other platforms soon. (DLsite, Nutaku, Mangagamer, here.)

Wednesday, September 26, 2018

Eroico will be on Steam

With Steam opening it's doors to uncensored games, I ran out of reasons not to sell games there

I will probably release future games on Steam as well, assuming the doors don't get slammed shut after they realize crazy people keep coming in.

Would also be convenient if unlock codes purchased here unlock demos downloaded through Steam. Though I think that would probably be against some kind of rule, so I'll have to check.

Edit: Also, sorry for not responding to comments on previous posts as quickly. Blogspot hasn't been emailing me when people comment like it used to. Need update some settings.

Tuesday, August 28, 2018

Early GM2 template

I've said before that I want to do a GM template at some point, one that beginners with GM can use.

While this doesn't contain much yet, I figured I'd post it here anyway, since I happened to make a quick version for someone else. This doesn't contain what someone would need to make an entire game, obviously, but some people might find parts of it useful.

This contains
- Tile collisions
- A basic camera system with limiters
- Gamepad support
- Scripts for checking controls and collisions.
- Basic state system

It's rough around the edges since it's derived from the game I'm working on, so there's some stuff that isn't too clean, at the moment.

Anything in the project with blue icons represents files that I will update/add functions to later,
The goal being that the template could be updated without breaking a game project so long as game-specific code is not added to those files. The template could be updated by simply dragging the update into the GM project folder.

This isn't something I'm working on every day, but I want to add stuff to it every so often. Initially I will be refining how the system should work as a whole (since I want to be able to use it myself as a base for games later), but later I also plan on adding templates for things like the player and enemies. The end goal would be the ability to make a game without programming, for artists who just want to make graphics and design levels, while still having a system that programmers can modify to save some time.

I'm open to any suggestions, as far as adding stuff or how it should look from a usability standpoint goes. Will be a while before it can be used for anything by non programmers in a plug and play fashion, though.

Tuesday, July 17, 2018

Enemy states and formating

Sorry about the silence. Working on stuff, life stuff, etc.

I've talked before about making a template of some kind for people to use. While I'm not currently working on one directly, I am trying to streamline certain parts of my workflow, and that inherently means making something that's easy to use, but flexible.

Part of  the process of making a game is enemy behavior, or rather, the actions an enemy can perform. There are a few methods for making an entity "do" something in GM.

You can have every action as a different object,

Or all the code can be contained within one object, with each action/state being represented by a number.

Initially, I found it easier to use the first method, as when an object is created it has it's own set of events (create, step, animation end, etc). It also made it easier for me to debug games since an issue with an action could be easily isolated, and messing up an object wouldn't affect the rest.

However, it isn't really practical as games become more complex, and as I've become better at programming my original reasons for using it have become less relevant. GM also added #region which is very helpful for keeping code separated.

That said, for the second method everything an object can do is separated into a state. For example, a simple jump upwards might be state 5. So switching to a jump is essentially just;

state = 5

So, if you wanted a character to do this,

You can separate it into two states
- move until edge (1)
- wait and turn (2)

So, the object hits an edge, changes the state to 2, it plays out the state, and then it's built into state 2 that it returns to state 1 at the end.

This is basically the manual version of the method; every state does something very specific. However, despite the fact that "wait" and "turn" might be a part of other actions, they are combined, and only go back to state 1. This means that if I wanted to add a new move that involves waiting and turning before doing an attack, I need to make a separate set of states.


So instead, you can do things in a sequence. Let's say you have the following states;

- pace (1)
- wait (2)
 - jump back (3)
- jump forward (4)
- melee attack (5)
- neat pose (6)

If you wanted an enemy to jump back, do a pose, jump forward, attack, wait, and then go back to pacing. Instead of programming each state to lead into the next manually, we can program a system that plays them in order based on a simple sequence of numbers. This would be the above sequence.

sequence[0] = [3,6,4,5,2,1]

Thus, that "move" is sequence 0.

By doing this, you can set a sequence to play out, rather than a single state. This also comes in handy for cutscenes, where you need to be able to animate characters quickly and easily.


That said, the question becomes, how much control do I want/need, and how should it be formatted? If you have a state for "jump", what should determine how far, or the direction? For example, you could have each variation be a separate state;

-move around (1)
-shoot (2)
-low jump (10)
-high jump (11)
-low jump back(12)
-high jump back(13)

a low jump back and then shooting would be

sequence[0] = [ 12 , 2 , 1 ]

Or, you could be more complicated with the arrays, such as having modifiers included in the sequence. So instead it might be written like this;

sequence[0] = [[12,5,3],2,1]

With every state having a set of optional modifiers. In this case 12 would be the state, 5 could be jump height, and 3 could be horizontal speed.

In either case, the more more states you eventually have, the more difficult it would be to remember them all. It might make more sense to name states with strings;

sequence[0] = ["jump back", "shoot", "move around"]

Which I guess would looks like this with modifiers

sequence[0] = [["jump back",3,1],["shoot",bullet_1_ob,5],"move around"]

Yikes. Makes sense but probably looks intimidating.

Other formats
Instead of having everything in one array, you could also split controls into multiple optional arrays.

sequence[0] = ["wait","jump","shoot","wait","pace"]
sequence_xspeed[0] = [0,2,0,0,0]
sequence_sprite[0] = [0,0,0,pose_sprite,0]
sequence_time[0] = [10,0,0,50,0]

The first chooses the states to play in sequence,
The second chooses the xspeed modifier for each state,
The third overwrites the sprite that the state displays, with 0 using the default.
The fourth would change the wait time.

Using only sequence[0] with nothing else would use the states with defaults. Could also include states like "jump_back" so that there's a quick and dirty method if more control isn't required.

Of course, it's hard to say how useful so many options would be outside of making a template since; at the end of the day just programming what you want is generally going to be faster for things like enemy specific attacks. Where it would probably be the most useful for me personally is simply creating movement patterns, and for cut-scenes where you definitely need some kind of system.

Words words words...

Anyhow. Let me know if you know of any good standard practice for dealing with states. Maybe something that other engines like RPG maker do particularly well, or stuff you'd like to see when I do eventually make a template.

Back to work...