After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 509692 - Gnobots makeover in Python (aka gnobots3)
Gnobots makeover in Python (aka gnobots3)
Status: RESOLVED OBSOLETE
Product: gnome-games-superseded
Classification: Deprecated
Component: gnobots2
unspecified
Other All
: Normal enhancement
: ---
Assigned To: GNOME Games maintainers
GNOME Games maintainers
Depends on:
Blocks:
 
 
Reported: 2008-01-15 16:48 UTC by Andreas Røsdal
Modified: 2009-03-29 20:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed screen mockup for gnobots3 (328.26 KB, image/png)
2008-01-17 21:02 UTC, Andreas Røsdal
Details
3D-ish mockup (92.96 KB, image/png)
2008-01-18 07:12 UTC, Nicu Buculei
Details

Description Andreas Røsdal 2008-01-15 16:48:05 UTC
I'd like to give gnobots a rewrite in Python, and in the process bring the game up  to more "modern" standards with respect to usability, look-and-feel, graphics and maintainability. I'll post notes on the progress here. Therefore it would be great if people could post suggestions about what they would like to see improved in the next version of gnobots. If everything goes accoring to plan, then I'd like to commit the new version at the beginning of the 2.22.x development cycle (after March 12). Suggestions?
Comment 1 Thomas Andersen 2008-01-17 03:22:22 UTC
Python bindings for the games library would be really sweet. This would also allow sudoku to use the high score code in the library. 

Other than the untranslatable strings and the bad graphics I think gnobots is doing pretty okay. If you can make it feature par with the current and pick the improvements from bug #80240 it will be really nice to have it refactored in python.

For all the code that is shareable with the other games I hope you will use the library.
Comment 2 Andreas Røsdal 2008-01-17 21:02:59 UTC
Created attachment 103091 [details]
Proposed screen mockup for gnobots3
Comment 3 Andreas Røsdal 2008-01-17 21:09:20 UTC
I've attached a proposed screen mockup for gnobots3:

- A randomly generated gradient map. I created the map with the GIMP, but Ihave a pretty good idea about how do reneder such a map with cairo.

- Better-looking robots are needed. I also think the game needs some other artifacts, buildings etc.

- Minimap in top-left for overview of larger maps.

- A new planet area, to add some more sci-fi aspects to the game.

- Status-information in bottom-left area.
Comment 4 Nicu Buculei 2008-01-18 07:08:43 UTC
This does look really cool (and I like the graphics :p ) but the game is still "Robots"or a different new one? In nothing wrong with a different game (your mockup look like something I could play and probably like to contribute graphics) but maybe we should call it so.
Comment 5 Nicu Buculei 2008-01-18 07:12:48 UTC
Created attachment 103121 [details]
3D-ish mockup

An old mockup I made (attached as PNG, the SVG is too large)
Comment 6 Nicu Buculei 2008-01-18 07:15:32 UTC
And I attached an old mockup I made a couple of years ago, it touches only the look, it was more of a personal study about how the game can look.
However, the mockup from Andreas look more like something *I* could play.
Comment 7 Andreas Røsdal 2008-01-18 22:22:45 UTC
Yes, I remember that mockup, it could probably be done with an isometric map.

I think the core of the game should still be Robots, but to improve the game I don't think it hurts to add some new concepts on top of the existing.
Comment 8 Thomas Andersen 2008-01-18 22:49:08 UTC
I think balancing the gameplay may take some work when you add buildings and such to the game but I like the concept. Getting the game on feature par with the old one before adding new stuff would seem wisest IMO.

Things that could be fun:
- weapons. Picking up e.g. a laser that you can shoot the robots with from distance. EMP's to kill robots with 2 fields. 

- mines that trigger when stepped on and explode e.g. two turns after that.

- portals from one stop to another on the map.

- immobile cannons that fire slow moving bullets(1 field pr. turn) when something crosses the line of fields it is looking at.

- limited time for each move. 
Comment 9 Nicu Buculei 2008-01-21 08:01:29 UTC
I was thinking about "power-ups" like a dynamite which kill all the robots in a certain radius and maybe dynamite pack, which kill all the robots, effectively ending the map.
Another power-up can be a "safe teleporter", which guarantee the next teleport will end in a "safe" area of the map. Another one - maybe access to a "bonus" planet and so on.

Another thing I was thinking of is about continents: the terrain is randomly generated and looking at your mockup is possible to get "continents" or "islands". Do robots are able to move from one islands to another? (if they are robots, they may not, but it they are flying UFOs...). Or do you always generate a map consisting of one single continent?
Another implication of such a complex shape of the terrain it that the game will need AI for the robots. In the current version of the game they simply move towards you. On a game map like the mockup they will need to calculate a path and do not get stuck in a peninsula.

How about teleportation? It will be posible to teleport over water (and die instantly) or you will teleport always over land?

I am not sure I understand the part about planets. They are like game levels? If so, once a level (planet) was cleared and you advance to the next, is possible to revisit a planet? If so, it will have the same difficulty level?
Comment 10 Andreas Røsdal 2008-01-21 19:54:48 UTC
> weapons. Picking up e.g. a laser that you can shoot the robots with 
> from distance. EMP's to kill robots with 2 fields. 

I like the idea of weapons, especially laser weapons. How should Electomagnetic pulse weapons work?

>mines that trigger when stepped on and explode e.g. two turns after that.

Cool.

> portals from one stop to another on the map.

Isn't this the same concept as the current teleportation?

> immobile cannons that fire slow moving bullets(1 field pr. turn) 
> when something crosses the line of fields it is looking at.

How would this work?

> limited time for each move. 

Yes, each turn could have a timeout, eg. 60 seconds. The timeout could be related to the difficulty.


>Another thing I was thinking of is about continents: the terrain is randomly 
> generated and looking at your mockup is possible to get "continents" 
> or "islands". Do robots are able to move from one islands to another? (if they 
> are robots, they may not, but it they are flying UFOs...). Or do you 
> always generate a map consisting of one single continent?

It is possible to generate continents, and make the robots move from one continent to another, eg. using teleportation.


> Another implication of such a complex shape of the terrain it that the 
> game will need AI for the robots. In the current version of the game they
> simply move towards you. On a game map like the mockup they will need 
> to calculate a path and do not get stuck in a peninsula.

Yes, the AI would have to use a pathfinding algorithm to avoid obstacles. I've seen GPL implementations of this that we can re-use.

> How about teleportation? It will be posible to teleport over 
> water (and die instantly) or you will teleport always over land?

I think teleportation should be possible across water as well. 


> I am not sure I understand the part about planets. They are like game
> levels? If so, once a level (planet) was cleared and you advance to the
> next, is possible to revisit a planet? If so, it will have the same 
> difficulty level?

The idea about planets hasn't been thought all that well through yet, it's just an idea on a mockup...

One possibility is that each planet represented a level in Robots. So after the player completes one level, then he owns that planet. For the next level, a different planet has to be chosen.

The planets could also be a high-level game of "Konquest" (part of KDE Games),
where each individual battle of a planet in "Konquest" represents a game of Robots.



Comment 11 Vincent Povirk 2008-01-22 23:13:05 UTC
Is anyone really volunteering to take the time to rewrite this in python, or is it just something you'd like?
Comment 12 Nicu Buculei 2008-01-23 06:45:29 UTC
As I understand, Andreas is volunteering to rewrite the game. If so, I would like to try to help with the graphics..
Comment 13 Nicu Buculei 2008-01-23 07:33:30 UTC
Here are a couple of ideas about how I see the game graphics:

1. have 4 types of terrain (temperate, desert, jungle and frozen, defined by gradient colors), 4 types of buildings/artifacts (contemporary, sci-fi, fantasy and another one) and 4 types of robots graphics (different groups of sprites). Each planet is a *random* combination of those, so we get a fairy large number of distinct looking combination.

2. a more laborious approach, create complex sets of tied terrain/buildings/robots, so for a frozen planet the buildings are customized, covered in snow and for a fantasy world the robots are also customized (iron golems?). The sets can be derived one from another, but it would imply a lot more work.

Maybe start with 1. and leave 2. and an option for later?
Comment 14 Andreas Røsdal 2008-01-24 22:43:38 UTC
As a reply to comment #11, this originally started with me expressing my intent to possibly give gnobots a big makeover, iff the proposal is accepted and other people show interest in helping out as well.

Vincent, on the other hand has already said that he is skeptical to it, 
so that makes it more likely that gnobots will not be improved any more during the next 10 years than it has in the past. So much for the naysayers... 
Comment 15 Thomas Andersen 2008-01-27 23:21:15 UTC
"I like the idea of weapons, especially laser weapons. How should Electomagnetic pulse weapons work?"
Like the dynamite idea. Kill all within a radius of e.g. 2 fields.

"Isn't this the same concept as the current teleportation?"
No. These should be teleportation holes that are always open. It would make it harder to get an overview of the shortest path around the map.


"immobile cannons" & "How would this work?"
Hard to explain. I could draw the idea if you want to work on this.

"Yes, the AI would have to use a pathfinding algorithm to avoid obstacles. I've
seen GPL implementations of this that we can re-use."
I have been talking to my former adviser at my university. If we could come up with some good ideas for the students to program and write a report about they would like to cooperate. This could be an interesting thing to work on I think.


Nothing or nobody should stop you from implementing this. I too have some concerns about balancing the gameplay as this is hard. But if we start out by implementing what we have currently and move on from there we have nothing to worry about.

And as Vincent writes another place it could be good to do this in a way where we can share code with other similar games. But you should work on whatever you like and we'll take a look at have the outcome is.
Comment 16 Vincent Povirk 2008-01-28 00:21:31 UTC
For the record, I fully endorse the last two paragraphs of comment #15.
Comment 17 Thomas Andersen 2009-03-26 00:23:38 UTC
Andreas is this still work in progress?
Comment 18 Andreas Røsdal 2009-03-29 20:24:08 UTC
No, there isn't any work being done on this now...