RogueLike in facebook

[Holloweye]

Looks like your dungeon has suffered an earthquake

Ye, font and dungeon fixed.

[Holloweye]

Another milestone reached. Now the Javascript application downloads the map from server. When downloaded the map it can display it on a canvas. Perhaps the dungeon generation is ugly but it was just something I put together in some minutes to have something to work with for starters.

[Holloweye]

If anyone is interested to help with this little project message me. I put it on github ( https://github.com/Holloweye/RogueLike/blob/master ), then can add you so you have full access.

[requerent]

You're going to need to outline clear production goals if you expect any serious help. I still have no idea how you plan on making it interesting.

[Alex E]

Another milestone reached. Now the Javascript application downloads the map from server. When downloaded the map it can display it on a canvas. Perhaps the dungeon generation is ugly but it was just something I put together in some minutes to have something to work with for starters.

At least you got the map to download! I'm interested in seeing where this goes.

[Holloweye]

Another milestone reached. Now the Javascript application downloads the map from server. When downloaded the map it can display it on a canvas. Perhaps the dungeon generation is ugly but it was just something I put together in some minutes to have something to work with for starters.

At least you got the map to download! I'm interested in seeing where this goes.

Yeah, I'm taking tiny steps forward. Else all stuff might get over my head. Next objective is to figure out a good structure for the classes. I always find it difficult to be satisfied with a design.


Entity (Stuff that appears on map.)
->Unit
->Item
->Object (furniture, barrels, ...)

Inventory (Each unit has a inventory, when killed the inventory is accessible by other Units.)

Item (Stuff that exist on inventory and characters can/or have equip/ed.)
->Helmet
->Armor
->Pants
->Weapon
-->Melee
-->Ranged
->Shield


I would like some input if possible.

[Holloweye]

You're going to need to outline clear production goals if you expect any serious help. I still have no idea how you plan on making it interesting.

I just put it out there if there is anyone feeling that they could contribute with something that they are most welcome.

It would be difficult to imagine if a game would be interesting or not (without actually trying out how the basic idea would go). That's why I want the basic structure so I can try out and tweak the game-play.

[Holloweye]

Now the server side save the data into a MySQL database.

The client <> server communication looks like this:

[requerent]

You're going to need to outline clear production goals if you expect any serious help. I still have no idea how you plan on making it interesting.

I just put it out there if there is anyone feeling that they could contribute with something that they are most welcome.

It would be difficult to imagine if a game would be interesting or not (without actually trying out how the basic idea would go). That's why I want the basic structure so I can try out and tweak the game-play.

It is difficult, but then again that's why there are dozens of methodologies and guidelines in existence to help you with that. that isn't to say that arbitrarily producing technologies is a lot of fun.

[Holsety]

I would like some input if possible.

Maybe consider having a full design document done BEFORE you start coding.
It's all too easy (especially nowadays) to jump into actually doing work on a(ny) project, but 99.9999% of the time if you don't have your design decided from start to finish beforehand you're going to give up.

[Holloweye]

I would like some input if possible.

Maybe consider having a full design document done BEFORE you start coding.
It's all too easy (especially nowadays) to jump into actually doing work on a(ny) project, but 99.9999% of the time if you don't have your design decided from start to finish beforehand you're going to give up.

I guess it all depends on the person and what goals you have with the project. As this is a project I maintain on my free-time I like to get stuff done before I get bored with a project. Because what usually happens with me is that I get bored after trying to make a complete UML design. Just that part can takes hours and hours of work. That is why I decided to just go with the flow on this one and actually get something done and playable. I don't have that much time on this project as I would like to have but I got to make the most of it. And doing actually coding I find the most fun. This is my project and if I make something playable or not is yet to see. Also you never finish a program only stop working on it.

[requerent]

I would like some input if possible.

Maybe consider having a full design document done BEFORE you start coding.
It's all too easy (especially nowadays) to jump into actually doing work on a(ny) project, but 99.9999% of the time if you don't have your design decided from start to finish beforehand you're going to give up.

I guess it all depends on the person and what goals you have with the project. As this is a project I maintain on my free-time I like to get stuff done before I get bored with a project. Because what usually happens with me is that I get bored after trying to make a complete UML design. Just that part can takes hours and hours of work. That is why I decided to just go with the flow on this one and actually get something done and playable. I don't have that much time on this project as I would like to have but I got to make the most of it. And doing actually coding I find the most fun. This is my project and if I make something playable or not is yet to see. Also you never finish a program only stop working on it.

That's awfully naive. A GDD and a UML are vastly different things. You at least have an idea as to what you want to accomplish and perhaps a reason why the implementation would be fun.

You posted this in a public forum inviting others to help if they wanted to. Saying that you don't seem to care about the game's design is a bit of a contradiction.

You indicated previously that you have a 'basic structure' in mind- what is that structure? Even if it's not very concrete and flexible, that's your GDD. So- what is your game? What is this basic structure? It's more or less impossible to help another person code something if you don't know what they're trying to accomplish.

[Holloweye]

I would like some input if possible.

Maybe consider having a full design document done BEFORE you start coding.
It's all too easy (especially nowadays) to jump into actually doing work on a(ny) project, but 99.9999% of the time if you don't have your design decided from start to finish beforehand you're going to give up.

I guess it all depends on the person and what goals you have with the project. As this is a project I maintain on my free-time I like to get stuff done before I get bored with a project. Because what usually happens with me is that I get bored after trying to make a complete UML design. Just that part can takes hours and hours of work. That is why I decided to just go with the flow on this one and actually get something done and playable. I don't have that much time on this project as I would like to have but I got to make the most of it. And doing actually coding I find the most fun. This is my project and if I make something playable or not is yet to see. Also you never finish a program only stop working on it.

That's awfully naive. A GDD and a UML are vastly different things. You at least have an idea as to what you want to accomplish and perhaps a reason why the implementation would be fun.

You posted this in a public forum inviting others to help if they wanted to. Saying that you don't seem to care about the game's design is a bit of a contradiction.

You indicated previously that you have a 'basic structure' in mind- what is that structure? Even if it's not very concrete and flexible, that's your GDD. So- what is your game? What is this basic structure? It's more or less impossible to help another person code something if you don't know what they're trying to accomplish.

I come up with ideas while I'm coding and write them down in a simple document. I done this in many other projects with other people. Working in the Agile iterative working environment. Before each iteration we discuss the features and ideas that come up during the previous iteration. If they should or should not be implemented. This way of working had good results for minor projects in the past in my experience. If you disagree that's your problem. But this is how I like to work. If anyone would like to help in some way. We would discuss the current status, features to implement and how I currently would like the project to progress. Working Agile is good because you can get the feel of the game and change it quick if you notice a negative user experience.

Latest update: Got send/receive and accept invites working. Accepting an invite will start a new game with that user. Everything is based on facebookIds so no need to register accounts and such.

[konijn_]

Another milestone reached. Now the Javascript application downloads the map from server. When downloaded the map it can display it on a canvas. Perhaps the dungeon generation is ugly but it was just something I put together in some minutes to have something to work with for starters.

At least you got the map to download! I'm interested in seeing where this goes.

Yeah, I'm taking tiny steps forward. Else all stuff might get over my head. Next objective is to figure out a good structure for the classes. I always find it difficult to be satisfied with a design.


Entity (Stuff that appears on map.)
->Unit
->Item
->Object (furniture, barrels, ...)

Inventory (Each unit has a inventory, when killed the inventory is accessible by other Units.)

Item (Stuff that exist on inventory and characters can/or have equip/ed.)
->Helmet
->Armor
->Pants
->Weapon
-->Melee
-->Ranged
->Shield


I would like some input if possible.

Greetings,

I would say if you are going agile, keep in the back of your mind containers ( Objects with Inventory ), doors and portals. This is typically stuff that can get you stuck if you dont think about this in advance.

Also, you should have document a little more about what 'map' consists of.

Cheers,
T.

[requerent]

I would like some input if possible.

Maybe consider having a full design document done BEFORE you start coding.
It's all too easy (especially nowadays) to jump into actually doing work on a(ny) project, but 99.9999% of the time if you don't have your design decided from start to finish beforehand you're going to give up.

I guess it all depends on the person and what goals you have with the project. As this is a project I maintain on my free-time I like to get stuff done before I get bored with a project. Because what usually happens with me is that I get bored after trying to make a complete UML design. Just that part can takes hours and hours of work. That is why I decided to just go with the flow on this one and actually get something done and playable. I don't have that much time on this project as I would like to have but I got to make the most of it. And doing actually coding I find the most fun. This is my project and if I make something playable or not is yet to see. Also you never finish a program only stop working on it.

That's awfully naive. A GDD and a UML are vastly different things. You at least have an idea as to what you want to accomplish and perhaps a reason why the implementation would be fun.

You posted this in a public forum inviting others to help if they wanted to. Saying that you don't seem to care about the game's design is a bit of a contradiction.

You indicated previously that you have a 'basic structure' in mind- what is that structure? Even if it's not very concrete and flexible, that's your GDD. So- what is your game? What is this basic structure? It's more or less impossible to help another person code something if you don't know what they're trying to accomplish.

I come up with ideas while I'm coding and write them down in a simple document. I done this in many other projects with other people. Working in the Agile iterative working environment. Before each iteration we discuss the features and ideas that come up during the previous iteration. If they should or should not be implemented. This way of working had good results for minor projects in the past in my experience. If you disagree that's your problem. But this is how I like to work. If anyone would like to help in some way. We would discuss the current status, features to implement and how I currently would like the project to progress. Working Agile is good because you can get the feel of the game and change it quick if you notice a negative user experience.

Latest update: Got send/receive and accept invites working. Accepting an invite will start a new game with that user. Everything is based on facebookIds so no need to register accounts and such.

Even for Agile, "Facebook + Roguelike" is vacuous, especially since it's all about the end-user experience. If you're insistent, I'd recommend looking at component based systems to avoid compromising flexibility in the future.