I'm pretty sure you're supposed to plan and design before you write code to implement your ideas.
Correct!
We already have an engine (GameMaker).
GAMEMAKER IS NOT AN ENGINE! IT IS WAY TO GET AROUND CODING!
We should do a engine first,as we need to know what the engine can do before we throw awesome sounding themes around.
It all depends on how you describe 'engine'. The game mechanics aren't there yet, but the means of implementing them are, and can be implemented within a day.
It would take a lot more than a day to make a roguelike engine in Gamemaker.
You can flesh out a basic one in a day. No game is ever finished.
What on earth do you even describe as an 'engine'?
The program that processes input, displays images, and produces sound. Without having specifications, it's hard to design an engine to do anything with it since you don't know what your limits are.
You could write one with high limits and plenty of memory allocated, but it's going to be slower and use a lot more memory than if you knew what you wanted before writing it.
You need to know how big the models will be (if it's 3D, tile and map sizes and bit depth if it's 2D), how detailed the textures will be (so you know how much memory you need to allocate to each texture), what format the sounds will be in, and a bunch of other things that are hard to do without specifications.
Note that while Gamemaker does sounds and images pretty well by itself, it wasn't really design to create a rougelike game, so random map' etc, and the ast, vast amoujt of text needed could mess it up.
That's another problem with using a stock engine. You have to work around the things it was made to do.
Starting out with something like this might be a good start.
Okay, to all the people bitching about there not being an engine yet, I'll say this for the last time.
The engine of a game depends nearly entirely on the concept of the game.
I thought I'd made that clear in any one of about four posts by now. Roguelike covers a lot of basic gameplay functions, but others, such as combat, tile size, statistics and monster body structure depend entirely on the concept of the game.
Feel entirely free to complain about the fact that you haven't seen any development work yet - that's a perfectly acceptable thing to do. I haven't had as much time to devote to it today, so I apologise for that, but expect to see something later tonight, even if it's just a to-do list and a complete run-down of the combat, statistic and experience system.
P.S. - Gamemaker does suck at handling lots and lots of text quickly, I can grant you that. But a graphical, IVAN-style roguelike does not need lots of text, just one long message log (of which only about 6/7 lines are displayed at any one time) and doesn't need to handle it quickly at all - just generate and display some new lines every turn.
The engine of a game depends nearly entirely on the concept of the game.
No way motherfucker. This idea comes from the same camp that believes Fallout3 will resemble Oblivion just because it uses the same engine. In theory, an engine should be so well designed it should be capable of serving as the engine for many different games. Some engines may be more specialized than others, example: A dwarf fortress style engine versus Nethack, but at the core the engine should have parts that are very independent from ANY game concept.
This basically means, you need to create something that can generate sprawling terrains and levels, allow for movement, storing items, keeping track of stats, movement of NPCs, networking, etc...
Later on you can worry about what those levels, items, stats really are, and then of course add layers of code on top of the engine's foundation to allow special game specific functions.
And really, thats what this thread should be about. Building an engine to serve as a foundation. Optimizing all the shit.
In theory, an engine should be so well designed it should be capable of serving as the engine for many different games. Some engines may be more specialized than others, example: A dwarf fortress style engine versus Nethack, but at the core the engine should have parts that are very independent from ANY game concept.
This basically means, you need to create something that can generate sprawling terrains and levels, allow for movement, storing items, keeping track of stats, movement of NPCs, networking, etc...
Well, here's the problem. I don't think you thought that little list out very well, and I think you're underestimating how many massive choices depend entirely on what kind of game you're going to make - the concept.
Generating sprawling terrains and levels? That's pretty exclusively for a random level generator, so you're already narrowing it down to a game which has random terrain. Allowing for movement assumes that you are a player character that can move, and not just that, assumes a specific mode of movement. Can you move diagonally? Is the game based on tiles or free-roaming? Is it a turn based system? If so, you already have to decide at least generally the kind of timing system you're gonna implement. Keeping track of stats, yeah, there has to be a framework. But you have to have an idea of the kind of stat system you're gonna have to get anywhere with that.
Do you at least understand what I mean? In order to approach any level of engine-ness, you have to at least have an idea of the kind of game you're going to make. Or you try to make an engine which can encompass a massively wide variety of ideas.
But why would I do the latter, when we can narrow down what kind of game we're going for, then produce it much quicker? You seem to want some kind of generic system you can lay a wildly different design onto and have it work, but shit, that's not what we're doing here. If you want to do that, find your own thread.
tl;dr: we're not going to build an Unreal Engine for you. Sorry.
The engine of a game depends nearly entirely on the concept of the game.
This idea comes from the same camp that believes Fallout3 will resemble Oblivion just because it uses the same engine. In theory, an engine should be so well designed it should be capable of serving as the engine for many different games.
Yeah, if you're using a middleware engine or using the same engine for different games, as Bethesda is doing. This is different because Zetetic doesn't have an engine to even work with, so he's developing one from the ground up. Now he has a good idea what he needs it to do, and thus can tailor-make it to do just those things.
EDIT: I don't really like where this thread is going. We have people that are gung-ho for the concept in hand, and others that are going critical mass.
I think it should be established where we are at this point. Are we still in the uh, negotiations phase here, or is the concept pretty well set in stone?
In theory, an engine should be so well designed it should be capable of serving as the engine for many different games. Some engines may be more specialized than others, example: A dwarf fortress style engine versus Nethack, but at the core the engine should have parts that are very independent from ANY game concept.
This basically means, you need to create something that can generate sprawling terrains and levels, allow for movement, storing items, keeping track of stats, movement of NPCs, networking, etc...
Well, here's the problem. I don't think you thought that little list out very well, and I think you're underestimating how many massive choices depend entirely on what kind of game you're going to make - the concept.
Generating sprawling terrains and levels? That's pretty exclusively for a random level generator, so you're already narrowing it down to a game which has random terrain. Allowing for movement assumes that you are a player character that can move, and not just that, assumes a specific mode of movement. Can you move diagonally? Is the game based on tiles or free-roaming? Is it a turn based system? If so, you already have to decide at least generally the kind of timing system you're gonna implement. Keeping track of stats, yeah, there has to be a framework. But you have to have an idea of the kind of stat system you're gonna have to get anywhere with that.
Do you at least understand what I mean? In order to approach any level of engine-ness, you have to at least have an idea of the kind of game you're going to make. Or you try to make an engine which can encompass a massively wide variety of ideas.
But why would I do the latter, when we can narrow down what kind of game we're going for, then produce it much quicker? You seem to want some kind of generic system you can lay a wildly different design onto and have it work, but shit, that's not what we're doing here. If you want to do that, find your own thread.
tl;dr: we're not going to build an Unreal Engine for you. Sorry.
You do realize what you've described has absolutely 0 to do with whatever the concept of the game is?
I didn't say it had to be random terrain, I just said you need a way to display terrain, period. If the function that displays terrain then relies on either a fixed source or a random generator that is a completely different story. If you properly encapsulate all the functions the map generating function won't give a shit about where the map layout comes from, that's not it's job.
If you don't want it turn based then the timing function won't use turns. If you want to use turns then the function will use them, and if you want 500 days or 5 days to pass in between each turn then that should be capable within the same function.
I think you should step back and ask what the fuck it is you really ARE doing in this thread?
The good thing is that roguelikes don't require a lot of processing power, so gamemaker is both quick and hella easy for this kind of stuff. In fact, once we know where we're headed, I can probably get a prototype up in a day or less, provided I can find somewhere to host it.
The good thing is that roguelikes don't require a lot of processing power, so gamemaker is both quick and hella easy for this kind of stuff. In fact, once we know where we're headed, I can probably get a prototype up in a day or less, provided I can find somewhere to host it.
So where's the prototype of this zombie ninja shit then.
The good thing is that roguelikes don't require a lot of processing power, so gamemaker is both quick and hella easy for this kind of stuff. In fact, once we know where we're headed, I can probably get a prototype up in a day or less, provided I can find somewhere to host it.
So where's the prototype of this zombie ninja shit then.
First of all, change your title or I'm going to punch you in the vagina.
Secondly, it's "once we know where we're headed." We didn't know at that point and we still don't know. Can you read?
I hate to be a naysayer but I've been playing with the gamemaker 7 engine and it seems relatively limited for what you are trying to do. Also, Gamemaker is an engine... its just an oversimplified engine where its basically simple object oriented programming with cute little icons for each task instead of chunks of code.
JamesDM on
If you have any complaints about this poster then feel free to: Иди на хуй, Сучьи
Steam, PSN, XBL, Xfire and everything else JamesDM
I hate to be a naysayer but I've been playing with the gamemaker 7 engine and it seems relatively limited for what you are trying to do. Also, Gamemaker is an engine... its just an oversimplified engine where its basically simple object oriented programming with cute little icons for each task instead of chunks of code.
I hate to be a naysayer but I've been playing with the gamemaker 7 engine and it seems relatively limited for what you are trying to do. Also, Gamemaker is an engine... its just an oversimplified engine where its basically simple object oriented programming with cute little icons for each task instead of chunks of code.
Uhh...you can use code.
Really? I must have missed something, unless you are talking about scripting, in which case I will sit aside and see what you all can do.
JamesDM on
If you have any complaints about this poster then feel free to: Иди на хуй, Сучьи
Steam, PSN, XBL, Xfire and everything else JamesDM
I hate to be a naysayer but I've been playing with the gamemaker 7 engine and it seems relatively limited for what you are trying to do. Also, Gamemaker is an engine... its just an oversimplified engine where its basically simple object oriented programming with cute little icons for each task instead of chunks of code.
Uhh...you can use code.
Really? I must have missed something, unless you are talking about scripting, in which case I will sit aside and see what you all can do.
It has a scripting language, and it's SO much more powerfull than the click-and-drag buttons.
I hate to be a naysayer but I've been playing with the gamemaker 7 engine and it seems relatively limited for what you are trying to do. Also, Gamemaker is an engine... its just an oversimplified engine where its basically simple object oriented programming with cute little icons for each task instead of chunks of code.
I use 6.1 cos registering 7.0 with this new third party called YoYoGames apparently got my email addy leaked to spammers. I just trust the old one more.
Anyways, GM has basic inheritance stuff (event calls on objects, but no functions) so there's not really anything you can't do with it as far as roguelikes go. The graphics functions will save a lot of time.
Performance might be a problem if you're tracking a huge terrain. Making a separate object for each square will kill it. Making a separate tile (ie. just a static sprite) for each square or drawing the visible terrain from within one object seems fine.
And seriously. Use the real code, not the cute icons. :P
You do the complicated stuff like this with it:
Create event:
var ter;
ter = "################################"
ter += "#..............................#"
ter += "#..............#......#........#"
ter += "#####..........#......#........#"
ter += "#....#.........#......#........#"
ter += "#.....#........#......#........#"
ter += "#.....#........#.######........#"
ter += "#..#..#..........#.............#"
ter += "#..#..#..#########.............#"
ter += "#..#.....#.....#...............#"
ter += "#..#.....#.....#...#############"
ter += "#..#######..#..#...#...........#"
ter += "#..#........#..#...#...........#"
ter += "#..#...######..#...............#"
ter += "#..#....#......#.###############"
ter += "#..#....#......#...............#"
ter += "#..#....#......#..############.#"
ter += "#..#....#......#..#............#"
ter += "#.......#.........#............#"
ter += "################################"
for (j=0; j<20; j+=1)
{
for (i=0; i<32; i+=1)
{
k = string_char_at(ter, 1 + i + 32*j);
terrain[i, j] = 0;
if k == "#" then terrain[i,j] = -1;
}
}
waterDir = 1;
extraJ = 0;
Step event:
extraJ -= 1;
if extraJ < 1 then extraJ += 2;
//if extraJ >= 5 then extraJ -= 4;
//
for (jj = extraJ; jj <= 18; jj += 2)
{
// Calculate flows for the squares... from bottom to top
waterDir = 1; // Change horizontal preference each tick
if random(2) < 1 then waterDir = -1;
var k, t, total;
// Compress down
//for (j = 18; j >= 1; j-=1)
j = jj;
{
waterDir = -waterDir;
for (i = max(1, 30*waterDir); i < 31 and i >= 1; i-=waterDir)
{
if terrain[i, j+1] >= 1 or terrain[i, j+1] < 0 then
{
// Is there water here? Is target square good to receive water?
if terrain[i,j] > 0 and terrain[i+waterDir,j] >= 0 and terrain[i+waterDir,j] < 19 then
{
if terrain[i,j] > terrain[i+waterDir,j] then
{
terrain[i,j] -= 1;
terrain[i+waterDir,j] += 1;
}
}
// Is there water on the other side? Is that square good to receive water?
if terrain[i,j] > 0 and terrain[i-waterDir,j] >= 0 and terrain[i-waterDir,j] < 19 then
{
if terrain[i,j] > terrain[i-waterDir,j] + 1 then
{
terrain[i,j] -= 1;
terrain[i-waterDir,j] += 1;
}
}
}
// Is there water here? Is target square good to receive water?
if terrain[i,j] > 0 and terrain[i,j+1] >= 0 and terrain[i,j+1] < 19 and terrain[i,j] >= terrain[i,j+1] then
{
terrain[i,j] -= 1;
terrain[i,j+1] += 1;
}
} // Next i
} // Next j
// Expand sideways
//for (j = 1; j <= 18; j+=1)
j = jj;
{
waterDir = -waterDir;
for (i = max(1, -30*waterDir); i < 31 and i >= 1; i+=waterDir)
{
// Is there water here? Is target square good to receive water?
if terrain[i,j+1] > 1 and terrain[i+waterDir,j+1] >= 0 and terrain[i+waterDir,j+1] < 19 then
{
if terrain[i,j+1] > terrain[i+waterDir,j+1] then
{
terrain[i,j+1] -= 1;
terrain[i+waterDir,j+1] += 1;
}
}
// Is there water on the other side? Is that square good to receive water?
if terrain[i,j+1] > 2 and terrain[i-waterDir,j+1] >= 0 and terrain[i-waterDir,j+1] < 19 then
{
if terrain[i,j+1] > terrain[i-waterDir,j+1] + 1 then
{
terrain[i,j+1] -= 1;
terrain[i-waterDir,j+1] += 1;
}
}
} // Next i
} // Next j
// Expand up
//for (j = 18; j >= 1; j-=1)
j = jj;
{
for (i = 1; i < 31 ; i+=1)
{
// Is there water here? Is target square good to receive water?
if terrain[i,j] >= 3 and terrain[i,j-1] >= 0 and terrain[i,j-1] < 19 then
{
if terrain[i,j] >= terrain[i,j-1] + 2 then
{
terrain[i,j] -= 1;
terrain[i,j-1] += 1;
}
}
} // Next i
} // Next j
// Add a bit of "rain" at the start
r = floor(random(2));
if keyboard_check_pressed(vk_enter) then terrain[1+r,1] = 15;
}
Draw event:
var k, c;
draw_set_font(fTerrain);
draw_set_color(c_black);
for (j=0; j<20; j+=1)
{
for (i=0; i<32; i+=1)
{
k = terrain[i, j];
x = 0 + i * 16;
y = 0 + j * 24;
c = "."
if k >= 1 and k <= 19 then
{
draw_set_color(c_aqua);
c = string(k);
if k >= 10 then c = "~";
}
else if k < 0 then
{
c = "\#";
draw_set_color(c_gray);
//if j mod 8 = extraJ - 2 then draw_set_color(c_ltgray);
}
else
{
draw_set_color(c_dkgray);
}
draw_text(x, y, c);
}
}
Anyone who has problems with the current thread of discussion, please stop telling Zetetic what this thread should be about. He's the OP, he outlined what he wanted to discuss in the first post, and he's the one doing the programming. I think I should defer to him when I wonder what the thread is about.
Lighten up!
@everybody who isn't being a jerk:
Some of the ideas are completely ridiculous, but that can be a good thing depending on where you want to go. Do we really want a funny-focused game? I say a game with references to Shaun of the Dead, Office Space and The Office (UK and US versions are both good) is a winner in my book, but we have to specify that we're dedicating ourselves (i.e. Zetetic) to making the game funny.
Extra bonus points if you can change joke references by detecting the user's region and swapping out string tables.
Nice as it is to have a completely free reign of thinking, I reckon the OP (who is clearly the driving force behind the idea) should lay down some basic ideas of his own for everyone else to think inside. If we dont limit thinking a little bit then how can you arrive at a cohesive idea with so many 'cooks' (if you see my anology')
Even simple things like...
It will be set in the present
There can be magic
There will be a final goal, the game must be able to be completed
The protagionist is effectively invulnerable, but must still be able to lose the game and must still grow in power through it
The game will feature badgers and ninjas
Those are clearly silly ideas but I think just laying a few statements of intent down will allow the outline of a game to emerge far more swiftly and with less bickering.
The protagionist is effectively invulnerable, but must still be able to lose the game and must still grow in power through it
Man what? Half the fun of roguelikes for me is having my character get killed in bizzare and interesting circumstances.
I didnt mean that those should be the ideas we should use, I mean that a few ideas like those would be very useful to help facilitate the creation of an actual game.
The protagionist is effectively invulnerable, but must still be able to lose the game and must still grow in power through it
Man what? Half the fun of roguelikes for me is having my character get killed in bizzare and interesting circumstances.
I didnt mean that those should be the ideas we should use, I mean that a few ideas like those would be very useful to help facilitate the creation of an actual game.
I agree! This should be done if we are do make this!
How about a robotic roguelike (this idea my originally an idea I had for a MMORPG, but a good Roguelike is essentually a single player MMORPG anyway), wherein monsters drop random parts (arms, legs, torso, head, etc) that you can swap your own bodyparts out with in town. Kinda like legos, sorta. So you'd not only be scumming for weapons, but also for random body parts.
And there'd be body parts that are completely not humanoid. Like a torso with 4 arm equip points, or legs that are tank treads instead of actual legs, or even animalistic body types (i.e. a head, 4 legs, but no arms, but maybe a weapon equip point on the back, or on the face). Parts would have modular sockets as well, so you might find a weapon that you can equip a tank of gasoline on, to make it flaming, or armor that you can equip metal spikes on, or even odder things.
Like Ivan, each part would have it's own stats and hp, and when one part lost enough HP, it would become useless. If your head or torso lost it's HP, you'd die (Unless you had more than one head equipped, or some form of backup brain as a module, for example).
Various heads would give you extra bonuses, like Infranvision, "ESP", etc, based on the radar that particular head might have built in. (in the MMO I had planned, the UI and basic features would change, for example, a really great head statwise might only allow you to see in Black & White in game, or might not allow you to /con monsters; likewise, weaker helms might innately tell you the elemental weaknesses of the monsters you're targeting, or auto )
You could add onto this with modules, of course -- in a way, better heads have modules built in.
Of course, since we're talking about robots, we'd have malfunctions. Take too much damage on your arm or weapon, for example, and maybe the next time you try to shoot you weapon it fires wildly off target. Or shoots a huge AOE blast instead. Or just explodes, doing a huge AOE based on you and destroying the entire arm. Take damage to your head, and your radar (vision / UI) starts malfunctioning. Maybe the HP start showing up as letters. Maybe various poems start appearing in the background. Or large sections of the screen start getting replaced with snow like from a old TV that's off signal.
Posts
That's another problem with using a stock engine. You have to work around the things it was made to do.
Starting out with something like this might be a good start.
Can we really focus more on just turning this thread into making a roguelike engine from scratch? I kinda want to do this too.
Atleast have an engine before you start talking about this cliche zombie/pirate/ninja dogshit some people call a game.
Hell, you can't even call a pirate themed roguelike cliche, since I've never heard of a single one being made. Speaking of which, it would be awesome.
The engine of a game depends nearly entirely on the concept of the game.
I thought I'd made that clear in any one of about four posts by now. Roguelike covers a lot of basic gameplay functions, but others, such as combat, tile size, statistics and monster body structure depend entirely on the concept of the game.
Feel entirely free to complain about the fact that you haven't seen any development work yet - that's a perfectly acceptable thing to do. I haven't had as much time to devote to it today, so I apologise for that, but expect to see something later tonight, even if it's just a to-do list and a complete run-down of the combat, statistic and experience system.
P.S. - Gamemaker does suck at handling lots and lots of text quickly, I can grant you that. But a graphical, IVAN-style roguelike does not need lots of text, just one long message log (of which only about 6/7 lines are displayed at any one time) and doesn't need to handle it quickly at all - just generate and display some new lines every turn.
No way motherfucker. This idea comes from the same camp that believes Fallout3 will resemble Oblivion just because it uses the same engine. In theory, an engine should be so well designed it should be capable of serving as the engine for many different games. Some engines may be more specialized than others, example: A dwarf fortress style engine versus Nethack, but at the core the engine should have parts that are very independent from ANY game concept.
This basically means, you need to create something that can generate sprawling terrains and levels, allow for movement, storing items, keeping track of stats, movement of NPCs, networking, etc...
Later on you can worry about what those levels, items, stats really are, and then of course add layers of code on top of the engine's foundation to allow special game specific functions.
And really, thats what this thread should be about. Building an engine to serve as a foundation. Optimizing all the shit.
yes dude YES.
I personally don't care about the game, I want to make an engine.
Well, here's the problem. I don't think you thought that little list out very well, and I think you're underestimating how many massive choices depend entirely on what kind of game you're going to make - the concept.
Generating sprawling terrains and levels? That's pretty exclusively for a random level generator, so you're already narrowing it down to a game which has random terrain. Allowing for movement assumes that you are a player character that can move, and not just that, assumes a specific mode of movement. Can you move diagonally? Is the game based on tiles or free-roaming? Is it a turn based system? If so, you already have to decide at least generally the kind of timing system you're gonna implement. Keeping track of stats, yeah, there has to be a framework. But you have to have an idea of the kind of stat system you're gonna have to get anywhere with that.
Do you at least understand what I mean? In order to approach any level of engine-ness, you have to at least have an idea of the kind of game you're going to make. Or you try to make an engine which can encompass a massively wide variety of ideas.
But why would I do the latter, when we can narrow down what kind of game we're going for, then produce it much quicker? You seem to want some kind of generic system you can lay a wildly different design onto and have it work, but shit, that's not what we're doing here. If you want to do that, find your own thread.
tl;dr: we're not going to build an Unreal Engine for you. Sorry.
Yeah, if you're using a middleware engine or using the same engine for different games, as Bethesda is doing. This is different because Zetetic doesn't have an engine to even work with, so he's developing one from the ground up. Now he has a good idea what he needs it to do, and thus can tailor-make it to do just those things.
EDIT: I don't really like where this thread is going. We have people that are gung-ho for the concept in hand, and others that are going critical mass.
I think it should be established where we are at this point. Are we still in the uh, negotiations phase here, or is the concept pretty well set in stone?
You do realize what you've described has absolutely 0 to do with whatever the concept of the game is?
I didn't say it had to be random terrain, I just said you need a way to display terrain, period. If the function that displays terrain then relies on either a fixed source or a random generator that is a completely different story. If you properly encapsulate all the functions the map generating function won't give a shit about where the map layout comes from, that's not it's job.
If you don't want it turn based then the timing function won't use turns. If you want to use turns then the function will use them, and if you want 500 days or 5 days to pass in between each turn then that should be capable within the same function.
I think you should step back and ask what the fuck it is you really ARE doing in this thread?
I read it again.
Than make an engine and stop trying to shit all over the thread.
:arrow:
Good, now shut up or get out of this thread.
So where's the prototype of this zombie ninja shit then.
First of all, change your title or I'm going to punch you in the vagina.
Secondly, it's "once we know where we're headed." We didn't know at that point and we still don't know. Can you read?
Steam, PSN, XBL, Xfire and everything else JamesDM
Uhh...you can use code.
Really? I must have missed something, unless you are talking about scripting, in which case I will sit aside and see what you all can do.
Steam, PSN, XBL, Xfire and everything else JamesDM
It has a scripting language, and it's SO much more powerfull than the click-and-drag buttons.
Anyways, GM has basic inheritance stuff (event calls on objects, but no functions) so there's not really anything you can't do with it as far as roguelikes go. The graphics functions will save a lot of time.
Performance might be a problem if you're tracking a huge terrain. Making a separate object for each square will kill it. Making a separate tile (ie. just a static sprite) for each square or drawing the visible terrain from within one object seems fine.
And seriously. Use the real code, not the cute icons. :P
You do the complicated stuff like this with it:
Create event:
var ter; ter = "################################" ter += "#..............................#" ter += "#..............#......#........#" ter += "#####..........#......#........#" ter += "#....#.........#......#........#" ter += "#.....#........#......#........#" ter += "#.....#........#.######........#" ter += "#..#..#..........#.............#" ter += "#..#..#..#########.............#" ter += "#..#.....#.....#...............#" ter += "#..#.....#.....#...#############" ter += "#..#######..#..#...#...........#" ter += "#..#........#..#...#...........#" ter += "#..#...######..#...............#" ter += "#..#....#......#.###############" ter += "#..#....#......#...............#" ter += "#..#....#......#..############.#" ter += "#..#....#......#..#............#" ter += "#.......#.........#............#" ter += "################################" for (j=0; j<20; j+=1) { for (i=0; i<32; i+=1) { k = string_char_at(ter, 1 + i + 32*j); terrain[i, j] = 0; if k == "#" then terrain[i,j] = -1; } } waterDir = 1; extraJ = 0;Step event:
extraJ -= 1; if extraJ < 1 then extraJ += 2; //if extraJ >= 5 then extraJ -= 4; // for (jj = extraJ; jj <= 18; jj += 2) { // Calculate flows for the squares... from bottom to top waterDir = 1; // Change horizontal preference each tick if random(2) < 1 then waterDir = -1; var k, t, total; // Compress down //for (j = 18; j >= 1; j-=1) j = jj; { waterDir = -waterDir; for (i = max(1, 30*waterDir); i < 31 and i >= 1; i-=waterDir) { if terrain[i, j+1] >= 1 or terrain[i, j+1] < 0 then { // Is there water here? Is target square good to receive water? if terrain[i,j] > 0 and terrain[i+waterDir,j] >= 0 and terrain[i+waterDir,j] < 19 then { if terrain[i,j] > terrain[i+waterDir,j] then { terrain[i,j] -= 1; terrain[i+waterDir,j] += 1; } } // Is there water on the other side? Is that square good to receive water? if terrain[i,j] > 0 and terrain[i-waterDir,j] >= 0 and terrain[i-waterDir,j] < 19 then { if terrain[i,j] > terrain[i-waterDir,j] + 1 then { terrain[i,j] -= 1; terrain[i-waterDir,j] += 1; } } } // Is there water here? Is target square good to receive water? if terrain[i,j] > 0 and terrain[i,j+1] >= 0 and terrain[i,j+1] < 19 and terrain[i,j] >= terrain[i,j+1] then { terrain[i,j] -= 1; terrain[i,j+1] += 1; } } // Next i } // Next j // Expand sideways //for (j = 1; j <= 18; j+=1) j = jj; { waterDir = -waterDir; for (i = max(1, -30*waterDir); i < 31 and i >= 1; i+=waterDir) { // Is there water here? Is target square good to receive water? if terrain[i,j+1] > 1 and terrain[i+waterDir,j+1] >= 0 and terrain[i+waterDir,j+1] < 19 then { if terrain[i,j+1] > terrain[i+waterDir,j+1] then { terrain[i,j+1] -= 1; terrain[i+waterDir,j+1] += 1; } } // Is there water on the other side? Is that square good to receive water? if terrain[i,j+1] > 2 and terrain[i-waterDir,j+1] >= 0 and terrain[i-waterDir,j+1] < 19 then { if terrain[i,j+1] > terrain[i-waterDir,j+1] + 1 then { terrain[i,j+1] -= 1; terrain[i-waterDir,j+1] += 1; } } } // Next i } // Next j // Expand up //for (j = 18; j >= 1; j-=1) j = jj; { for (i = 1; i < 31 ; i+=1) { // Is there water here? Is target square good to receive water? if terrain[i,j] >= 3 and terrain[i,j-1] >= 0 and terrain[i,j-1] < 19 then { if terrain[i,j] >= terrain[i,j-1] + 2 then { terrain[i,j] -= 1; terrain[i,j-1] += 1; } } } // Next i } // Next j // Add a bit of "rain" at the start r = floor(random(2)); if keyboard_check_pressed(vk_enter) then terrain[1+r,1] = 15; }Draw event:
var k, c; draw_set_font(fTerrain); draw_set_color(c_black); for (j=0; j<20; j+=1) { for (i=0; i<32; i+=1) { k = terrain[i, j]; x = 0 + i * 16; y = 0 + j * 24; c = "." if k >= 1 and k <= 19 then { draw_set_color(c_aqua); c = string(k); if k >= 10 then c = "~"; } else if k < 0 then { c = "\#"; draw_set_color(c_gray); //if j mod 8 = extraJ - 2 then draw_set_color(c_ltgray); } else { draw_set_color(c_dkgray); } draw_text(x, y, c); } }Except hopefully without the spaghetti...
I stand corrected, I will dive into this a bit more and see what I end up with.
Steam, PSN, XBL, Xfire and everything else JamesDM
Lighten up!
@everybody who isn't being a jerk:
Some of the ideas are completely ridiculous, but that can be a good thing depending on where you want to go. Do we really want a funny-focused game? I say a game with references to Shaun of the Dead, Office Space and The Office (UK and US versions are both good) is a winner in my book, but we have to specify that we're dedicating ourselves (i.e. Zetetic) to making the game funny.
The harder the rain, honey, the sweeter the sun.
Does Dwarf Fortress count?
Oh that's right you could put the guards in squads.
I need to play that some more.
The harder the rain, honey, the sweeter the sun.
Even simple things like...
It will be set in the present
There can be magic
There will be a final goal, the game must be able to be completed
The protagionist is effectively invulnerable, but must still be able to lose the game and must still grow in power through it
The game will feature badgers and ninjas
Those are clearly silly ideas but I think just laying a few statements of intent down will allow the outline of a game to emerge far more swiftly and with less bickering.
I didnt mean that those should be the ideas we should use, I mean that a few ideas like those would be very useful to help facilitate the creation of an actual game.
The harder the rain, honey, the sweeter the sun.
And there'd be body parts that are completely not humanoid. Like a torso with 4 arm equip points, or legs that are tank treads instead of actual legs, or even animalistic body types (i.e. a head, 4 legs, but no arms, but maybe a weapon equip point on the back, or on the face). Parts would have modular sockets as well, so you might find a weapon that you can equip a tank of gasoline on, to make it flaming, or armor that you can equip metal spikes on, or even odder things.
Like Ivan, each part would have it's own stats and hp, and when one part lost enough HP, it would become useless. If your head or torso lost it's HP, you'd die (Unless you had more than one head equipped, or some form of backup brain as a module, for example).
Various heads would give you extra bonuses, like Infranvision, "ESP", etc, based on the radar that particular head might have built in. (in the MMO I had planned, the UI and basic features would change, for example, a really great head statwise might only allow you to see in Black & White in game, or might not allow you to /con monsters; likewise, weaker helms might innately tell you the elemental weaknesses of the monsters you're targeting, or auto )
You could add onto this with modules, of course -- in a way, better heads have modules built in.
Of course, since we're talking about robots, we'd have malfunctions. Take too much damage on your arm or weapon, for example, and maybe the next time you try to shoot you weapon it fires wildly off target. Or shoots a huge AOE blast instead. Or just explodes, doing a huge AOE based on you and destroying the entire arm. Take damage to your head, and your radar (vision / UI) starts malfunctioning. Maybe the HP start showing up as letters. Maybe various poems start appearing in the background. Or large sections of the screen start getting replaced with snow like from a old TV that's off signal.