Hey guys, what's a good free starter website maker I can use before I eventually delve into one that requires a monthly fee?
I think WordPress.com has options for a free blog. Here you can use "pages" to craft links like "about, contact, etc" using these pages as "tabs". The front page runs just like any other blog. Plenty of designs to choose from or roll your own.As soon as possible, as I want to start putting up lore/gameplay updates and such on it. Only thing with Tumblr is that it doesn't really have 'tabs' does it?
Okay what is this and when can I buy it?
Your game is gorgeous! I'm looking forward to playing it.
Wow, that is stunning. This game just keeps looking more and more incredible.
Everytime I see your game it reminds me of Adventureland at Disneyland. And thats a marvelous thing to remind me of.
I think WordPress.com has options for a free blog. Here you can use "pages" to craft links like "about, contact, etc" using these pages as "tabs". The front page runs just like any other blog. Plenty of designs to choose from or roll your own.
They have paid options, too.
That humble bundle with game maker and android plugin is over now, yes? I was thinking of getting back into my own programming and relearn my skills I've left dormant for too long :/ But I don't know where to start on pc games now that xna is "dead", feels dumb to ask. Maybe unity? I have a 2d project up on google play but I'm on my own this time and I'd like to code it all in visual studio if possible
Edit: Actually, while I do want to use visual studio and do most things from scratch, I do have a book on game programming, that might have some suggestions. Stencyl sounds like fun too and I really ought to learn ue4 too. But if I just want to code some basic 2d game, where should I start?
:lol It's okay, deserved. I did check it slightly, thus the edit I'm on my phone, gonna re-check it tomorrow.I don't want to sound like an ass, but have you looked at the OP of this thread? It has a lot of valuable information that will answer your questions.
Looks awesome. Is the whole game gonna be in Japanese?
That's me. Progress is slow, but I'm trying to dedicate more time to working on the game. It's just hard since at the end of the day I'm extremely tired. However, if I'm going to meet my deadline of Q1 2016, then I have to speed up the process and not let my fatigue win out. Generally, I take about 30 to 40 minutes to unwind, then get started and work for 4 or 5 hours. These days I'm working longer since I have to meet my deadlines. Juggling everything is just hard, but bills have to be paid.
I think I will use it. Thanks.
Also...
Before I try and animate the walk, I thought I probably should get down an idea of how I make the characters facing each direction.
Also others on previous pages were asked about game titles... So I've been thinking about... The Red Horizon or The Blood Horizon, which might invoke a bit more of the idea of battle or war... I mean to be honest, I don't think trying to make a unique named title for the sake of being unique will help at all. If anything I feel like it might drive people off.
Just wanted to say that you've improved a lot of stuff really quickly, really like the direction the sprites are going compared to the original.
But I do think you should slow down a bit, you're pumping out iteration after iteration after iteration, and while it's totally great progress on your end, I'm thinking it might rushing too hard into things. Let things simmer a bit, maybe plan out all the mechanics if you haven't already, and experiment. Try out distinct visual styles rather than small tweaks, maybe really dive into animations if that's what you want to tackle next but settle in and really get the feel for how a character will be animated.
Sit down and chew on the steak. I'm seeing you toss things around a bit too much like a salad, let the pot boil for a bit and figure out how much longer the souffle is going to take to rise. Challah bread. I like food metaphors.
At this stage I would recommend dropping everything else and focusing on combat AI.I still think the biggest thing holding my progress back is the AI. Without the enemy AI, I'm not sure I can start on my combat system. Which is really the biggest thing I need to figure out.
Since there is little to no documentation on how to make AI for a Tactics RPG. I just need to get to that point where I can simply put stuff in the game. You know?
At this stage I would recommend dropping everything else and focusing on combat AI.
You'll need to define a set of rules for enemy options, add a weight system to each ability that they can use that gives more weight to move X when player healh is low or move Y when your health is low, etc. Start small with attack, heal, run. Add on to that with more abilities.
Use flowcharts. Design it on paper first. Test your system with some dice, picking random playing cards, etc. From there, program.
If you will be unable to create a combat system and AI then there is little point to creating all sorts of artwork and cutscenes.
For example, for my game the most important hurdle to development, for me, was physics and collision. The first thing I did when I set out to make my game? Physics and collision. You need to make sure you or someone can handle the meat and potatoes of the game before actually making the game. Cutscenes, menus, all that stuff is nonessential until the end or until it has to be shown. Hell, we have our story and cutscenes planned out since last year and only last week we drew sprites for one of our cutscenes to showcase it because it was necessary. I can't stress enough how important it is to make sure you can actually make the game you want before sinking time into the nonessentials of development.
Just my .02
Yeah, I don't use formal flow charts either. I just figure out stuff on the fly. I've never been very good at writing pseudocode or illustrating dummy art either. For me, at least, it feels like a waste of effort to work things out separately and then have to redo it all.
But I was also the kid who never showed her work on math in school. I would just write the answer down because I did the problem in my head, and the teachers often thought I was cheating.
I think we skip the flow chart for very different reasons, because I'm no math prodigy. I'm really a fucking idiot. I just bumble around and experiment. If I made a plan it'd likely change as I tinkered and iterated anyway. I work by many small iterations, starting only from a general concept in most cases.
(unless we're talking about simple purpose-built obstacles or enemies, e.g. this thing hops back and forth forever)
I iterate on concepts out loud or on paper until I can conceptualize the way the game will play in my head, it's hard to explain but there's a moment where I just feel confident in the decisions. This means I don't use a lot of complex written documentation, though if I'm programming it I will often write a bunch of super haphazard pseudo code like "blah bit goes here" etc.
I do use flowcharts for figuring out menu flow and behavior though, because I can't account for all of the edge cases in my head and it's usually more for other peoples benefit.
Do you do all the enemy design in Cactus? I'm curious how your team shares that load.
Ha, fair enough. Although I should say that most of the enemy behavior I've been working on recently is fairly simple, especially since there's no pathfinding involved.
Tim and I share all the design work in Cactus, I tend to focus on things like enemy behavior concepts, level design, iterating on design & and tuning all things to make it all really cohesive.
At one point I did map out our enemy plans on a spreadsheet indicating things like their rough hitpoints, role, physical size etc. Just to make sure we weren't over covering areas or missing any key areas.
A few of the enemies/bosses/npcs in Ghost Song have a range of decisions they can make as events change, it's a bit scary -- and in each case the more days away from last working on the thing the more impenetrable it becomes to me.
The majority of enemies are relatively simple, of course.
So most of our walls and ceilings and floors (which I will refer to as "level geo") is actually constructed in the editor using ProBuilder. It allows you to drop in highly editable cubes and other primitives and start building maps. This tool also allows you to apply textures in a number of ways, so we have a few different tileables (made in Photoshop) that get applied to the level geo. Here is a demo where I drop in a cube (CTRL + K), go into edit mode (G), and move some vertices around. In the end I drag on a tileable texture I already had made (a tiling wood panel texture).
Detail props like food, equipment, furniture, etc I still model in 3ds Max and then export to Unity.
Edit: Just saw your edit! The most important thing to get the pixelated textures on 3D is to use Point Filtering/Nearest Neighbor filtering on your textures. This renders them as 100% crisp and no interpolation is preformed to smooth them out. Use a texture resolution of like 128x128 with point filtering and you're on your way.
I kind of like skeleton with a spear, skeleton with an axe, and skeleton with a sword, though.
Incidentally, that's another thing I want to do next time. Enemies that are more interesting because elements of them (for example, their weapon) are dynamic.
I understand where you're coming from, and I appreciate that. I'm not sure if the example I used was the best to explain my point. I guess it depends on design imperative. Sometimes little things like that are changed to keep that one enemy type from being exactly the same encounter each time, and that's alright. And sometimes little things like that are changed because the dev(s) didn't have time to implement substantially different characters, so those tiny differences are treated like whole new enemy classes.
Maybe a better way to put it would be that I don't mind minor variation in enemy types as long as it doesn't detract from the implementation of major variation in enemy types.
A lot of what I do next time will be a direct response to my experiences this time.
One of those things is enemies and how I think about enemies. In Ghost Song, enemies are largely treated as little bumps, little obstacles, purpose built to their surroundings. Most enemies are not particularly smart, and an overall approach of placing emphasis on quantity has been taken. I felt as though I needed lots of enemies, new enemies in each area, otherwise I feared the player would get bored because there's not something different to shoot.
I'd like to take a different track. Each enemy should be able to exist and behave just about anywhere, and each enemy should be interesting and diverse in itself. Each enemy should be to some degree unpredictable and fun to encounter. The game should have a focus on quality, dynamism, depth and variety within each individual enemy rather than just trying to have a huge roster of shallow enemies. I want a smaller roster, but a far better one.
Are you thinking all the way like Shadow of the Colossus? Or is there a less severe example you have in mind?
There are a surprising number of games where you can run by most of the enemies if you play well enough. Most of the time this is only countered by literally gating the player.
What you're describing sounds interesting for sure, but I don't think it's the one true design imperative. I enjoy a healthy spread of minor enemies in most games.
No, nothing like SOTC. I want the enemy encounters to be heftier, for sure, but it wouldn't be a bosses only game at all.
I think I've talked a little about my idea before, but it's been brewing in my mind for the better part of a year now. Emphasis will be placed on a living world and dynamic elements -- Imagine certain aspects of Don't Starve or Animal Crossing merged with Dark Souls, with most likely a dark fantasy setting.
Oh, okay. I guess I thought Dark Souls might be categorized as shallow since most of the enemies are humanoids that can be run right past.
The guys who do Extra Credits videos started a Let's Play of Dark Souls a few months ago (link). There's not been a lot of progress, but it's been pretty interesting all the same having a game designer and a professional animator tear it apart.
A couple of things they noticed in particular were interesting to me. For example, that Dark Souls enemies keep you on your feet by having a number of slightly different attack animations. A lesser (or at least simpler) design would only have one attack pattern per enemy, so circumventing it becomes rote rather than agile and reactive. That's something I want to influence future enemy design that I do.
Nice find, I'm checking it out.
What I'd add to your comment about running by enemies is that this is not terribly productive unless you already know where you're going and what you're doing. If you don't, it's chaos that often ends badly. There are also cases where you are gated in (namely, bosses) and in some cases, at least in the sequel, there are things you can only do if you clear the enemy(s). For example, switches come up that open a path or make something easier and those switches can't be accessed unless the enemy is out of the way.
Yeah, that's what I meant by some games literally gating the player. It's an interesting thing to balance. You don't want your game to be too easy, but that can actually be a very empowering moment if the only people who are running past mobs are seasoned pros.
...
For example, for my game the most important hurdle to development, for me, was physics and collision. The first thing I did when I set out to make my game? Physics and collision. You need to make sure you or someone can handle the meat and potatoes of the game before actually making the game. Cutscenes, menus, all that stuff is nonessential until the end or until it has to be shown. Hell, we have our story and cutscenes planned out since last year and only last week we drew sprites for one of our cutscenes to showcase it because it was necessary. I can't stress enough how important it is to make sure you can actually make the game you want before sinking time into the nonessentials of development.
Just my .02
I can't believe I missed this one:
I did actually wonder if you were using ProBuilder, that asset is an absolute marvel. I assume you're also using it to build other specific static geometry bits such as the railings? It'd probably be fairly easy to use it to build the various simple models as well.
I do the flow charts in my head and as I work, possibly because I never really knew the right way of doing anything. What made sense to me, as a person with no programming experience and just working within the range of things I knew how to do in stencyl, was thinking of the ai as reaching a decision point and then making a decision -- completing the loop and keep going. As conditions change you can make their behavior change because each decision point checks multiple things. There are certain aspects I still struggle with, but on the whole it's a bit amazing how much I've managed to accomplish with my limited abilities. I was making state machines before realizing what a state machine was.
Most important of all is iteration.. I patiently work with my enemy behavior just getting things working one bit at a time, one foot in front of the other. Patience rules the day.
In my next game I'd like to do legitimate pathfinding and other things I know are beyond my programming abilities, which is one of the several reasons I doubt I'll be doing another game alone.
In object-oriented programming, I think the normal practice would be to have say, an "Actor" class that's a general type. Then "PlayerCharacter" and "Enemy" would be subclasses, and they would have their own variables and methods.I think also my biggest issue is how exactly do I tell what object is an enemy or not. By that I mean, how does the Enemy overview AI that works like this...
Choose the enemy. Do I have a variable in each of the enemy objects?
In object-oriented programming, I think the normal practice would be to have say, an "Actor" class that's a general type. Then "PlayerCharacter" and "Enemy" would be subclasses, and they would have their own variables and methods.
If "Enemy" objects have a variable called "enemyType", then you can just check that while looping through stuff. Or "Actors" could have a variable called "actorType", and you could check whether actorType == ACTOR_ENEMY_SWORDPERSON.
var enemy = true;
var enemyType = ENEMY_SWORDSMAN_LV1
I'm not sure I understand..?
So say I have 2 enemies (objects.)
Bandit 1 and Bandit 2.
Bandit_1
Creation
Code:var enemy = true; var enemyType = ENEMY_SWORDSMAN_LV1
And repeat for Bandit_2.
So... would the code check if "enemy" = true and use the "enemyType" to figure out it's AI code pattern?
But how does that go and check Bandit 1 and 2? Do I need a new AI for each level to specifically check those enemies?
Just make a parent object called objEnemy or something and make your bandits be children of that parent. You can read a lot more about object parentage in the manual.
Okay. Though I suppose that does mean I will need a new AI for each level, correct? I doubt I want one objEnemy that is the parent of every enemy in the game.
objEnemy
- objBandit
- objBandit1
- objBandit2
- objSlime
- objSkeleton
- objSkeleton1
- objSkeleton1king
- objSkeleton2
Please forgive me if you're already familiar with this -- but if not, I recommend doing a bit of reading about object-oriented programming. I'm not sure of a good reference to recommend, but I feel becoming familiar with the concept of "classes" "objects", and "member variables" would make your task a lot easier.Okay. Though I suppose that does mean I will need a new AI for each level, correct? I doubt I want one objEnemy that is the parent of every enemy in the game.