Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 [2] 3 4 ... 22

Author Topic: DrPoo's programming Jam, 100*C, a community project, that actually works.  (Read 42502 times)

Virex

  • Bay Watcher
  • Subjects interest attracted. Annalyses pending...
    • View Profile

Hold your horses people, remember that there's no profesional coder on this project, so complex physics and, well, basically anything complex are going to be a pipe dream.



I'm proficient with Java, Matlab and Common Lisp, but the language we pick shouldn't matter too much for me, I should be able to pick it up fairly quickly.



- Minecarts! Minecarts are awesome. Imagine an isometric view where you can place minecart tracks, with turns and ramps and stuff. There are doors and junctions that can be linked to pressure plates and levers. Oh yeah, and minecart derailings and collisions. Just make some sort of minecart sandbox, and if it's fun to play around with, make a game out of it.
Actually, some sort of mine simulator could be interesting. Feed and provide housing for your workers, buy equipment, build elevators and tracks for the mine carts. As you go deeper, you have to take flooding and ventilation into account. There could be horrible things lurking in the deep, but you're willing to face them all FOR GLORIOUS PROFITS!

That sounds AWESOME if you ask me, but then it would have to be about industry in general. Like a Dwarf Fortress, but with steam driven rusty robots instead of dwarves.
Yeah, that was kind of the inspiration, DF meets Transport Tycoon. My idea was to put the emphasis on building minecart and elevator tracks, with the ore just providing an incentive to build ever more elaborate mines.
Your idea of steam-driven rusty robots actually adds an interesting aspect to the game. The miners and prospectors could be robots that run on steam. They only have a limited amount of steam in their tank and have to get back to a refueling station after expending their steam. The refueling stations themselves are fueled from the boiler works (which need coal, a second resource you can mine, and water) through steam pipes. But steam pipes can only have a certain length before the steam starts to condense. So to expand your mine, you also need to figure out where to place boiler works and how to keep them fed with coal (which may come from a completely different part of the mine).
A second part would be smelter works, which also run on coal. They'd process the ore to tools for your robots, spare parts to repair damaged robots, components for constructions and trade goods for GLORIOUS PROFITS. A third kind of robot, the engineer, would operate the boiler works, smelters and the smithies where robots are repaired and retrofitted with new equipment.
« Last Edit: April 17, 2012, 06:54:31 pm by Virex »
Logged

dreadmullet

  • Bay Watcher
  • Inadequate Comedian
    • View Profile

That seems like a better idea the more I think about it.

However, there are a few things:

- I'm still not clear on which view the game is played from. Top-down or side-on?
Either way, I think if it were 2D at all it would really limit the game. With a top-down view, there wouldn't be any inclines for minecarts, which is no fun. With a side-on view, minecarts don't really make sense. For instance, how would they change direction? How would they derail?
I suggest that we go with either a fixed isometric view or a full-on 3D view of some sort. It will definitely make development more difficult, but I think it would make the game much more fun. If nobody thinks it's a good idea to go with 3D, I think the best alternative would be a top-down view with multiple Z-levels. But then it would seem like we were just copying Dwarf Fortress.

- The digging element of the game seems complex to develop.
Think about this really hard: What happens when a miner is digging into the ground? What goes on in the code, and what do the graphics look like?
Logged

Kofthefens

  • Bay Watcher
  • Keep calm and OH GOD CAPYBARAS
    • View Profile
    • Marshland Games

I like that idea. Perhaps we could add in cave-ins, and a need to build supports against those. We could also export ore off-world to buy specialized parts, and demand for ore and other prices could fluctuate based on how much you are buying / selling.

If we wanted to go down a more military path for the game, we could add in raiders, who try to steal ore and weaponry to drive them off.

I suggest that we go with either a fixed isometric view or a full-on 3D view of some sort. It will definitely make development more difficult, but I think it would make the game much more fun.
I agree with this. As to what digging would look like, each cube would have 5 or so different pictures (or more later on) for each stage of how dug it was. The miner robots could have a little animation where they spit dirt and tailings out the back.
Logged
I don't care about your indigestion-- How are you is a greeting, not a question.

The epic of Îton Sákrith
The Chronicles of HammerBlaze
My website - Free games

qwertyuiopas

  • Bay Watcher
  • Photoshop is for elves who cannot use MSPaint.
    • View Profile
    • uristqwerty.ca, my current (barren) site.

Hold your horses people, remember that there's no profesional coder on this project, so complex physics and, well, basically anything complex are going to be a pipe dream.

Nothing demands that someone here has to code the physics. Consider Box2D or some other existing physics library, which would already exist and handle all of the complex calculations...
Logged
Eh?
Eh!

DrPoo

  • Bay Watcher
  • In Russia Putin strikes meteor
    • View Profile

I would say that we do it either Simcity style with isometric view, this is just where i ask: how are we going to do the physics? Are we like making a 3d map and translating it to an isometric view?

Also i thought that later in development we add a "Moon mode" where you mine on the moon, the only water you could find would be in the form of frozen ice and comet strikes. Transporting goods for trade would require a rocket(maybe building one would be required before even going there). I thought it would be interesting.
Logged
Would the owner of an ounce of dignity please contact the mall security?

Virex

  • Bay Watcher
  • Subjects interest attracted. Annalyses pending...
    • View Profile

I was originally thinking of a side-on view, because that makes some calculations significantly easier (pathing and tunnel collapsing comes to mind). Besides that, when working with a mine, 3D is a little harder to implement, because a lot is going to be hidden from sight.


One way to handle this would be to have the rock be transparent in the main view mode. You'd then essentially be looking at a 3D floor and piping plan of the mine. If we do this we need to spend a lot of time making navigation feel natural and obvious though. A secondary view would present the user with a space-filling model of the known ore density around your mine tunnels.


Digging could be handled with voxels, assuming we have the processing power available to do so. The world would be divided in cublets with a certain size (I was thinking about 1/2 of a robot in either direction). A robot digging would destroy a cublet, which generates debris. This debris is then dumped into a mine cart and once the cart is full it's sent off to the refinery, which extracts the ore or coal. The rest is just waste, which is dumped into a mine cart to be sent to a landfill on the surface.
Logged

DrPoo

  • Bay Watcher
  • In Russia Putin strikes meteor
    • View Profile

I was originally thinking of a side-on view, because that makes some calculations significantly easier (pathing and tunnel collapsing comes to mind). Besides that, when working with a mine, 3D is a little harder to implement, because a lot is going to be hidden from sight.


One way to handle this would be to have the rock be transparent in the main view mode. You'd then essentially be looking at a 3D floor and piping plan of the mine. If we do this we need to spend a lot of time making navigation feel natural and obvious though. A secondary view would present the user with a space-filling model of the known ore density around your mine tunnels.


Digging could be handled with voxels, assuming we have the processing power available to do so. The world would be divided in cublets with a certain size (I was thinking about 1/2 of a robot in either direction). A robot digging would destroy a cublet, which generates debris. This debris is then dumped into a mine cart and once the cart is full it's sent off to the refinery, which extracts the ore or coal. The rest is just waste, which is dumped into a mine cart to be sent to a landfill on the surface.

That sounds awesome too!

So.. is this what we are going to do? Who are still with us?
Logged
Would the owner of an ounce of dignity please contact the mall security?

Scelly9

  • Bay Watcher
  • That crazy long-haired queer liberal communist
    • View Profile

I'm still in, although I might not be much help.
Logged
You taste the jug! It is ceramic.
Quote from: Loud Whispers
SUPPORT THE COMMUNIST GAY MOVEMENT!

Virex

  • Bay Watcher
  • Subjects interest attracted. Annalyses pending...
    • View Profile

I'm obviously still in.


Assuming we've got a decent layout for the game, I'd propose we start working on our toolchain and the game design document.
The first question is obviously: How are we going to synchronize everything? I think using a version control system would be the easiest, assuming we can get some hosting space (many options here, but it depends on how big the team is, what version control we're using and if the project is open-source). Dropbox is an option, but I'm not too fond of how it handles multiple people working on the same project. If two people work on the same file and save it to the dropbox server, the second one to commit is overwriting the work done by the first one. More advanced version control systems such as SVN or Git would merge the files (semi)automatically in such a case.


Second question is of course the programming language. Now, I'm without preference when it comes to languages, so it depends on what people here prefer most.


Third question is the GDD itself. I propose roughly the following setup:
-Short description of the game
-More elaborate description of the game, detailing all the buildings, minecart and robot physics and AI, as well as the economic model and other bits and pieces I'm sure to have forgotten
-Art direction. How the robots and buildings look and how the interface looks.
-Technical details. The programming language used and the formats used for graphics and resources.
Logged

dreadmullet

  • Bay Watcher
  • Inadequate Comedian
    • View Profile

I think the art style should be steampunk, as was suggested before. I can't stop picturing the robots looking like this, i.e. a tall human robot with steampunk elements. Their color is the metal they're made from, and the quality of the metal affects how good they work. For example, copper robots are the generic peasant, and the shiny titanium robots are like the super elite.

If we're going the 3D route, my suggestion is to use Unity. It is simply awesome. I've used it a lot before, mostly just messing around with stuff. I've never made a complete game with it. But it will make things eleventy times easier than developing our own engine. Unity does come with its limitations, but I think it would work well for the game.

If we use Unity, it supports 3 languages: C#, Javascript, and Boo. The best language by far is C#, which is the language I know best. I haven't used Unity for a long while, though.
Logged

Scelly9

  • Bay Watcher
  • That crazy long-haired queer liberal communist
    • View Profile

Some ideas I thought up:

Below ground:
Dirt: Soft, doesn't take long to dig through.
Stone: Generic stone, takes longer than dirt, but progresses at a nice pace.
Water: Found in lakes or rivers, also below the surface in caves or aquifers. Can flood mines and usually requires a pump to deal with. Transformed to steam with enough heat.
Aquifers: a layer of dirt or gravel in which water is flowing. Can be pumped to the surface, but replentishes eventually.
Bedrock: Extremely hard, quite slow to mine.
Magma: Below bedrock there lies a sea of molten rock. Be careful not to dig in the wrong place, you could unleash the wrath of the volcano.

Above ground:
Rivers: A nearly un-ending supply of water right at your fingertips.
Spring: An above ground spring that usually feeds from an aquifer.

Buildings:
Smelter: Can be used to transform ores into bars of metal.
Grinder: Used to grind ores to create metal powder, this allows you to get more out of your ores.
Pump: Used to draw water out of a spring, aquifer, or a tunnel filled with water.
Housing: Used as a house. You need these for more workers.

Minerals/items:
Crystals: Several different types, ranging from only useful as sales to required for robots.
Coal: Required to smelt metals and run robots, should be fairly plentiful.
Wood: Can be turned into coal, trees grow back after a while.
Ores, various: What you get when you mine a vein of metal. Can be either sold or changed into bars.
Metal Bars: Smelt ore, you get this. Can be sold for more than the raw ore or used in robots or other contraptions.
Food: I'm iffy on this one. We could either do a more realistic game where you need to plant farms and such or we could go the easy route and just assume they get their own food.

Anyway, I'll have more coming sometime. Too many ideas now.
Logged
You taste the jug! It is ceramic.
Quote from: Loud Whispers
SUPPORT THE COMMUNIST GAY MOVEMENT!

dreadmullet

  • Bay Watcher
  • Inadequate Comedian
    • View Profile

Food?! Robots don't need food, they're robots!

Along with steam, robots need booze to get through the working day. Otherwise their joints become stiff and they work slower. Booze can be imported from spaceports or processed at a still from plants.

Forges. All robots are the same, i.e. they don't have huge drills for arms or anything, so they need a way to make tools. Metal can be made into picks for digging. There are also giant powered drills of some sort, since only having picks wouldn't make sense.


Here's something that could be done by anyone right now: concept art! What do the robots look like? Draw it!
Logged

Virex

  • Bay Watcher
  • Subjects interest attracted. Annalyses pending...
    • View Profile


I think housing would be unnecessary. They're robots after all.

Along with steam, robots need booze to get through the working day. Otherwise their joints become stiff and they work slower. Booze can be imported from spaceports or processed at a still from plants.

The booze is there for the spirit that controls the robot. You need to keep them happy (and most of all, sedated) or they'll stop working.

Quote
Here's something that could be done by anyone right now: concept art! What do the robots look like? Draw it!
I suck at drawing, so instead I'll steal someone else's work. I was thinking of using Big Daddy from Bioshock or Robo from Chrono Trigger as inspiration:
Spoiler: Reference art (click to show/hide)
To me, the sturdy, roundish shape fits better with steampunk aesthetics than the more modern rendition linked by dreadmullet.


Other important parts:
Infrastructure
Steam pipes: Used to distribute steam from the boiler works to the structures that need it.
Water Pipes: Water is pumped through these. Usually ends in a boiler works or on the surface.
Refueling station. Robots can refuel here. Requires steam.
Rail Tracks: Mine carts roll along these.
Pulley: Used to pull mine carts up hill. Need steam to work.
Monorails: Roof-mounted pulley system to carry robots and mine carts across chasms. Needs steam.
Cart Terminal: Stores mine carts for later use.
Elevators: Used to move goods vertically.
Breaking Claws: Used to slow down mine carts going downhill.
Section Dividers: Automated breaking claws that stops mine carts from passing it if there is another mine cart between this divider and the next. Needs steam.
Switch: Causes a mine cart to change tracks depending on it's contents. Requires steam.
Bulkhead: Can be used to close off a section of the mine in case of emergency. Comes in manual and automated variant. Manual variant is operated by a robot, automated variant is operated by the controller and needs steam.
« Last Edit: April 18, 2012, 02:41:27 pm by Virex »
Logged

DrPoo

  • Bay Watcher
  • In Russia Putin strikes meteor
    • View Profile

Food?! Robots don't need food, they're robots!

Along with steam, robots need booze to get through the working day. Otherwise their joints become stiff and they work slower. Booze can be imported from spaceports or processed at a still from plants.

Forges. All robots are the same, i.e. they don't have huge drills for arms or anything, so they need a way to make tools. Metal can be made into picks for digging. There are also giant powered drills of some sort, since only having picks wouldn't make sense.


Here's something that could be done by anyone right now: concept art! What do the robots look like? Draw it!

I actually made some concept art. In my head we have several kinds of robots, many of them dedicated to their tasks, then an all-round application, somewhat weaker more expensive to maintain humanoid robot. Ill get to uploading it when i am done with it.

Currently working on:
Engineerbot - Humanoid robot, the dexterity of a human hand is required to maintain machinery
Spiderbot - Spider like millitary bot, use theese to defend your bases.. and ahem.. clear out your embark spot should it already be inhabited by.. other corps.

Peasantbots are humanoid little steambots that has many applications, because of their size and lack of any special strength or utility, they are easy to make, but they break easily too, and require alot of maintainence. Steam of course, but also alot of oil to keep their joints going, and spare parts to replace damaged/worn out parts.

I also thought of enemies:

Junkbots, rogue spring driven robots, starts out with a random set of limbs, theese things will steal parts from moving as well as rusting robots. You have to watch out for theese, imagine one stealing the gun from a spiderbot, that would create havok.
Scramblers, theese are remnants from an ancient civilisation, subterrenean machines, they drill through the planet in search of metals, they usually feed on whatever they find in the earth, but if they can smell delicious alloys, they will attempt to get that.
Tentacles, the limbs of a lovecraftian horror living in the core of the planet, it likes to screw up things, and eat souls
Technophobes, Technophobic natives, they will hunt down your machinery and tear it into pieces, having their heads on stakes at your mine entrance will scare them off.
Logged
Would the owner of an ounce of dignity please contact the mall security?

Virex

  • Bay Watcher
  • Subjects interest attracted. Annalyses pending...
    • View Profile


Quote

If we're going the 3D route, my suggestion is to use Unity. It is simply awesome. I've used it a lot before, mostly just messing around with stuff. I've never made a complete game with it. But it will make things eleventy times easier than developing our own engine. Unity does come with its limitations, but I think it would work well for the game.


Sounds like a good idea. The fact that you know how to work with it is great and C# is a nice language as well.
Quote
I actually made some concept art.
Post it!

I think the use of a bot should depend on it's equipment to some extent. I imagine that robots can be retrofitted by engineering bots in a smithy, so you could equip a spider bot with a gun and then later replace his gun with a worker arm to build a monorail across a chasm. Different robots would have different initial stats, which makes them more apt for certain tasks. For example, some spider bots can walk on walls but have low strength and a small steam reservoir, while another kind of bot could be a very accurate shoot, making it most useful for military applications.
« Last Edit: April 18, 2012, 02:53:23 pm by Virex »
Logged
Pages: 1 [2] 3 4 ... 22