Welcome, Guest. Please login or register.

Pages: [1] 2
Print
Author Topic: Progressing the code  (Read 11743 times)
icelus
Guest
« on: March 22, 2009, 05:06:09 PM »

There seems to be a request for more guidance regarding things to do short term. There are two issues.

1/ How do we move toward the first demo?

First of all we need some kind of design document outlining the various classes. A good start would be to read

http://wiki.parpg.net/Proposal:Code_Structure

and offer comments. This covers the core (model) logic. We also need to think about the system logic (gui interaction, interaction with fife). This would be a worthy project for someone to start to make notes on. We can't really code anything meaningful without some idea of what we're coding.

2/ Short term coding tasks

What can be done without a design? Well, we can enhance and extend RIo to get a feel for how FIFE interaction works. We can play with adding self-contained components in the hope that some will be carried over to the main project.

Obviously we can't code PARPG itself until we know what we're trying to code, so the work that needs doing right now is primarily design. If this is unappealing, learning about FIFE and pychan is probably the best way to get the skills we'll need to build the game.

If you have a different view, please sharei t here.
Logged
maximinus
Community member

Posts: 694



View Profile Email
« Reply #1 on: March 22, 2009, 05:41:17 PM »

I would prefer NOT to move on from the Rio demo.

Unfortunatly, I cannot be more positive than this in the short term. I am currently working on making my own 'PARPG demo' but mainly this consists of fighting to understand Fife and understanding where Rio ends and Fife starts.

It would be helpful if we could utilise the writers and produce a very basic script for a first demo level.

And yes, I did mean basic....
Logged

Science is open-source religion
tie
Community member

Posts: 77


View Profile Email
« Reply #2 on: March 23, 2009, 05:11:22 PM »

I was initially in favor of building on Rio, but can't relaly make my mind atm Smiley I can see why you would prefer to ditch Rio altoghether.

If you are eager to make a new FIFE client from scratch, you don't really need a script from the writers, not even a basic one. Until the Story Engine interface is sorted out, implementing scrits may be more harmful than useful.

What you need to do is simply reproduce the functionality that is currently available on Rio in the new client. That is, having a map, movable player characer, 1-2 NPCs, right-click pop-up menu, and some basic control menu.

This is still a lot of work, if it is to be done (and documented!) properly. I guess we need to decide if we should bite the bullet and do it, or we should continue hacking Rio apart.
Logged
maximinus
Community member

Posts: 694



View Profile Email
« Reply #3 on: March 24, 2009, 02:41:20 AM »

No harm in approaching the problem from 2 different directions  Smiley

So far I have a map and a character, next to add some GUI elements. You can follow my progress on the wiki: http://wiki.parpg.net/Reference:FIFE:Minimal:Introduction

It's all a learning process at the moment, really
Logged

Science is open-source religion
maximinus
Community member

Posts: 694



View Profile Email
« Reply #4 on: March 26, 2009, 02:51:42 PM »

What you need to do is simply reproduce the functionality that is currently available on Rio in the new client. That is, having a map, movable player characer, 1-2 NPCs, right-click pop-up menu, and some basic control menu.

The more I think about this the the more I disagree (sorry tie!  Embarrassed )

I have a map and a PC, just like RIO. Now I *could* go and start to implement NPC's, but that starts to lead me down the design path, as does the implementation of a GUI. But then, if I did all that (probably a couple of weeks of learning), it might never be used.

What I'd like is to have some sort of base to work from, so that we can say *THIS* is the current state of PARPG, like it or not. Then we can choose what we want to be working on. For example, I might be interested in implementing the NPC's, so I could go and read all that we written so far, implement some stuff, get feedback and so on. At least I would feel that I'd be working on PARPG, not just my personal tech demo.

I know that sometimes programmer philosophy can mean that coders can see things in a different light. I'm a bottom-up coder, which means I always like to start with some code and build up towards a design, so it's always in my nature to want some base code to start with.

Tomorrow I'll upload my basic tech demo to SVN so you can take a look to see if could be used as a base. It's a VERY spartan version of the Rio demo. It is my view that if we used the Rio demo we'd end up cutting a lot of the fat out anyway and end with something like what I have - so we may as well start with that  Wink
Logged

Science is open-source religion
maximinus
Community member

Posts: 694



View Profile Email
« Reply #5 on: March 31, 2009, 10:46:46 AM »

Been some time since this thread has been active, and something big has happened - one of the coders, icelus has left us  Sad

Anyhow, it looks like we are very close to finalising the ground floor tile size, and also I have now almost finished the base map class (I'm sure we will add to it in the future, the the core functionality is almost there).
This means I am now keen to develop some core code for PARPG. We're also close to agreeing some kind of interface for the inventory, so I suggest the following plan to 'get on with' PARPG and produce something:

* I will add the map class to my current 'Rio stripped bare' demo and upload to SVN.

* We use this as a base to experiment with the GUI

* We build a demo that implements all the pychan widgets and document their use

* Using this knowledge, and the map class, we enable the character to pick up and drop items

* In the same time frame (a month?) hopefully the artists can come up with some tiles and maybe a character

So we would end up with a demo that had a character who can move around, pick up and drop items, and we have a GUI on top of all this. This would be the first 'tech demo' as it were, to show the world that we have a start, and also we enable us to visualise the game (perhaps we could also 'skin' the GUI....)

I believe all of this is do-able and wouldn't close any future avenues. Comments etc... are all welcome 
Logged

Science is open-source religion
maximinus
Community member

Posts: 694



View Profile Email
« Reply #6 on: March 31, 2009, 02:51:35 PM »

I couldn't help myself and had to upload a little picture:



This may be the first screenshot of a great RPG! It sucks as a game right now though   Roll Eyes
Logged

Science is open-source religion
zenbitz
Community member

Posts: 1164



View Profile
« Reply #7 on: April 01, 2009, 04:10:48 PM »

Yes... missing something.,...  HEXES!
* zenbitz ducks and runs
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
Lamoot
Community member

Posts: 161


View Profile
« Reply #8 on: April 01, 2009, 04:46:05 PM »

How can you duck / crouch and run, it doesn't make sense..


Wink
Logged
maximinus
Community member

Posts: 694



View Profile Email
« Reply #9 on: April 02, 2009, 05:11:15 AM »

How can you duck / crouch and run, it doesn't make sense..


Wink

Lets not start that debate again!  Cheesy
Logged

Science is open-source religion
zenbitz
Community member

Posts: 1164



View Profile
« Reply #10 on: April 03, 2009, 08:24:52 PM »

what are you guys talking about?
You DUCK first - to dodge the item thrown at you.  Then you turn and RUN...

Sheesh.
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
maximinus
Community member

Posts: 694



View Profile Email
« Reply #11 on: April 06, 2009, 03:42:39 PM »

I have added my current demo code to SVN.

It's not big, and it's not clever. But it IS stripped down and ready to use as a base. And it works. Also, it uses the graphics seen on these boards.

There are many things to move on from here, but I'd like to here from the developers here... any comments?

BTW, the code is in /trunk/demo
Logged

Science is open-source religion
Fierc3
Community member

Posts: 6


View Profile
« Reply #12 on: April 07, 2009, 02:51:42 PM »

Wow, i've sure missed a bunch...icelus left eh?

Anyways, great work Maximinimus, i'm gonna be busy for maybe the rest of the month getting ready to move in with my GF but i'll try and be around a little more than i have been. I'd like to sink my teeth into some coding like you've been doing, PM me with some things that need work!
Logged
maximinus
Community member

Posts: 694



View Profile Email
« Reply #13 on: April 07, 2009, 03:16:29 PM »

Wow, i've sure missed a bunch...icelus left eh?

Things move fast in the open source world!

I've put a simple programming road map up at the wiki: http://wiki.parpg.net/Programming_Roadmap that we can use for moving on from here.

I hope that things will have moved on by next month so get back to me when you're free again. But basically, pick something that interests you *and* has been talked about here to some degree - no point implementing something that is very likely to change.
Logged

Science is open-source religion
maximinus
Community member

Posts: 694



View Profile Email
« Reply #14 on: May 11, 2009, 03:28:52 PM »

Here's the latest news from this dept.

In this last week, a lot of the code had been re-structured to fit a better a data model or, in plain English, a lot of behind the scenes shuffling has gone on. The end result has changed very little when you run the code, but now it may be easier for new programmers to start. So here are the biggest problems in PARPG that need to tackled, or are being looked at:

  • The way buildings are to be split up, and how we enter them
  • What an NPC does, apart from just stand there
  • Making some sort of GUI other than the pychan default
  • Integrating the new inventory code with the game

Firstly, buildings need to split up into separate tiles, purely for z-order rendering purposes. This won't effect the gfx dept much, it's more a coding thing. This is not hard to program on the logic side  but it's just a bit fiddly and awkward (and boring).
Second, we need to decide how we deal with entering buildings. This is a design issue than can be guided by the programmers. I personally think that building internals as a separate map is a lot easier.

Next: At the moment the NPC just stands in one position. But surely they need to move about, or DO SOMETHING, otherwise it looks really bad - they may as well be objects. A lot of this could be solved by adding animations, but we also need to add some interactivity. We also need to start thinking about how we add dialog.

Then there's the GUI. Pychan comes with FIFE, but I think it looks a little ugly, and it certainly seems to be hard to skin. So I would try and minimize the GUI in the game right now. what do we need, a front end to the game, the inventory and maybe the dialog display: let's keep things simple. If you look at the screens for OpenAnno you'll see that this approach is certainly possible.

Finally, we need to start adding some test suites and make sure the epydoc stuff is good. Not doing this could bite us later on. I'll admit to being lazy on this front.

OK, report out. Chins up - we all knew this was going to be a difficult task to start with, and we slowly approach the distant goal step by step!
Logged

Science is open-source religion
Pages: [1] 2
Print
Jump to: