Hello Guest, please login or register.
Did you miss your activation email?
Login with username, password and session length.

Pages: [1] 2 3   Go Down

Author Topic: Getting Started  (Read 8034 times)

0 Members and 1 Guest are viewing this topic.
Getting Started
« on: March 24, 2009, 01:28:45 am »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
To those who are able and to those who will be able to see the board shortly, this board itself may seem a little dead even with there being some life in it. I decided to let some of you see this board in the hopes that some stuff could get started.

Anyway, beyond that here are the top things we have to figure out:
- Having a system such that we can make updates to a Link object via updating GML script files
- Having some of Link's abilities that appear at the beginning of Link's Awakening ready to go

Also, if there is someone who you think I have included yet early who would be helpful to these early stages, feel free to mention someone. The current list of those brought on is:
- Scooternew: helped out with the previous community project, worked with MC graphics
- Xfixium: has worked with Game Maker and has attempted Link's Awakening
Logged
Re: Getting Started
« Reply #1 on: March 24, 2009, 10:13:43 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Wow, up sooner than I thought. Excited to get going here. I know Scooternew was involved with the last community project. So I'm guessing he has a basic framework in mind considering it was Minish Cap styled also. So I guess we should wait for his lead on this.

My general suggestions are to have discussion about certain game aspects. Like global variables that will be save and loaded. Desired game resolution. That sort of thing. Again, I'm new to this whole team idea, so if I step on toes and such, or I'm just plain out of line, don't be afraid to let me know. I'm not all that hard to get along with or reason with.

I'm not totally sure how it worked in the previous project, but I'm working on a room editor that allows for the editor's room to be exported to a GM project. This might be helpful for people working on this project. As they could submit their room files to the team to add to the main project.
Logged
  • Pyxosoft
Re: Getting Started
« Reply #2 on: March 24, 2009, 10:32:08 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
Yeah, one of the reasons that I brought you in to help with the beginning stages is that you thought outside the box on stuff. In the previous crack at Link's Awakening you had, the way in which you had some of the level loading seemed to be pretty good in terms of resource management.

Beyond what I already mentioned though, there is something that needs to be worked out in terms of reducing stored image size - something to tackle would be redundant images. For example, Link walking down without a cap, Link walking down with a cap, Link without a cap holding something and walking down, and Link with a cap holding something and walking down. All of these have the same legs. Having the animations sawed in half so to speak for images such as this wouldn't be that difficult I'd think.

About the desired game resolution, it would likely be either 240 x 160 or 480 x 320 in a window, and probably 480 x 320 full-screen as well.

Specifically in regard to global variables, do you feel that it is better for many of Link's variables to be global, or in general any game's main player, because the game practically revolves around that character?
Logged
Re: Getting Started
« Reply #3 on: March 24, 2009, 10:48:58 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Well, we could use the GBA resolution. I had tried that awhile back when I was looking for a good resolution to match the original. The only problem I had is trying to get the "widescreen"  resolution to have the same feel visually as the original. I found myself with alot of filler width-wise. Your thoughts on that?

Basically, with the globals, my suggestion is to store what we absolutely need to have written and read. Stuff that is specific to Link like his facing, state, speed and such should stay as member variables. Basically anything to do with his animations and movement behaviors. Does this sound reasonable?
Logged
  • Pyxosoft
Re: Getting Started
« Reply #4 on: March 24, 2009, 10:57:38 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
The engine for this project is attempting to mirror the Minish Cap, while the game part uses the engine and tries to best work with it to fit Link's Awakening. There have been some maps for at least the Oracle games which seemed to be alright graphically updated for Minish Cap. What I think about when the screen size is reduced is that the buildings and trees and stuff in the Minish Cap will look cramped in a smaller size.

As for global variables, that would be alright - in a lot of cases, just referring to objLink.facing is just as easy to do as global.facing in an enemy or object's code - might even be more appropriate to work with locals. You are right though, the essentials that would be global variables would likely be the stuff that needs to persist when those having them go poof. If the room management thing I mentioned before of yours did not involve multiple rooms in a Game Maker context of rooms, you may not have needed it.
Logged
Re: Getting Started
« Reply #5 on: March 24, 2009, 11:13:49 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Well, the code is very old. I started it in the middle of 07. I worked on it for several months. All I know looking back on it, is that it could have been done better. lol I basically had one gigantic overworld map sectored out in a grid of 16 X 16 rooms. I loaded objects and collision masks on the fly when transitioning to a new sector. Was this the best way to handle it? I haven't a clue. While I thought that was a creative solution, it introduced different problems.

I'm also sorry if my terminology is a bit weird for GM. I say member variables because it reminds me of public c styled member variables. As in a declared variable within the creation event can be seen by other objects. I usually use the term "local variables" for temporary variables that are only within the scope of a script. Just so people do not get confused on what I am saying.
« Last Edit: March 24, 2009, 11:16:49 pm by Xfixium »
Logged
  • Pyxosoft
Re: Getting Started
« Reply #6 on: March 24, 2009, 11:24:13 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
My terminology is a bit off as well because I am taking a C++ and Unix class right now which is going over shell scripting. Anyway, would you recommend that anyone else be brought in early to help with this from the list of those who applied in the News/Updates board? So far it is just me, you, and Scooternew.
Logged

Xiphirx

wat
Re: Getting Started
« Reply #7 on: March 24, 2009, 11:36:25 pm »
  • Xiphirx
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3007
I COULD help but I am not sure. I mean I only used GM5.3a for 4 years and we are probably using GM7.0...

Concept programmer? XD
Logged
  • For The Swarm
Re: Getting Started
« Reply #8 on: March 24, 2009, 11:37:53 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
I think the recruiting should be left to people other myself. :) Not too familiar with the people that want to help so far.
Logged
  • Pyxosoft
Re: Getting Started
« Reply #9 on: March 25, 2009, 03:27:59 am »
  • *
  • Reputation: +0/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1635
I will help whenever needed and do more of the complicated GM programming if anyone needs help with this, but I'm going to be taking a backseat for the most part (mainly because I have little spare time lately, and also because I disagree with the direction the CP has headed).
Logged
Re: Getting Started
« Reply #10 on: March 25, 2009, 07:48:32 pm »
  • Doesn't afraid of anything
  • *
  • Reputation: +42/-0
  • Offline Offline
  • Gender: Male
  • Posts: 7002
I'll help with programming as well.
Logged



i love big weenies and i cannot lie
Re: Getting Started
« Reply #11 on: March 25, 2009, 09:48:18 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Well, I think we've got everybody. Or close to it. What's the next step? Specifically, how are we organizing this?
Logged
  • Pyxosoft
Re: Getting Started
« Reply #12 on: March 25, 2009, 10:33:31 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
As I was mentioning in the topic in News/Updates, this stage of the engine is mainly to get the initial setup of the engine ready. All the engine does is emulate to the best of its abilities what goes on in the Minish Cap in terms of Link, NPCs, enemies, rooms, etc.

There are only two key ways Link's Awakening plays a role in the engine's progress overall. The first being that since the Community Project's game is Link's Awakening, the engine should try and prepare for what is going to happen in that game as it is being remade. This keeps the engine development focused as there is some priority as to what to do and makes sure that the stagnation levels on the Community Project's game in relation to its programming are reduced.

I first think that we should start on getting a Link object which has its primary events run as script files. This goes back to something I said earlier in which we could just update the GML scripts prior to public releases of the overall GM file so we would not be updating the project amongst ourselves by having to save and upload an entire big file each and every time. If we use GML script files, this allows us to also use things like Assembla to manage different versions of the source code.


So, here is where we will start in terms of coding stuff:
- Programming a workable Link object that utilizes scripts in its main events
  - making sure that there isn't unnecessary redundancy in animations (e.g. hat/no-hat/run/hold)
  - the main events are pretty much in terms of gba are a, b, l, r, start, and select and create/step/draw/animation end
    - we'll probably be using keyboard keys a, s, z, x, enter and backspace
  - at least getting some of the beginning Link's Awakening Link actions into the engine.

The organization once it goes public is going to be such that a group of coders who know what they are doing - probably all you guys - are going to handle the stable releases. People will be able to contribute to the engine and since it is open source they may submit their own, but as for it being added to what is the official release, what they submit will have to be screened to see if the code is good and if it will work with the project.

As for what people contribute (assuming the code is good), if it is an object like an enemy, there will be a separate GML file set up with just that enemies stuff in it (the code, sprites, etc). The user will also be required to make sure to mention what other GML files are needed for the file to work with the latest stable release. Other users will have the option of downloading that user-made enemy and merging into their version of the stable release. This will hopefully foster some creativity in those making things - it's not hard to do a little or to make a little contribution.

Of course though, in the Community Project's engine, there will be parent objects so that the enemies, NPCs, etc. that users create will have to work with the variable names of the parent objects. This further keeps their code in line with ours.

Logged
Re: Getting Started
« Reply #13 on: March 27, 2009, 02:09:42 am »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Okay, got some things going here. I'm going to use this test project as a discussion piece so that I may have a clear idea how the more experienced people want the work to flow. I have a project attached with some basics thrown together.

What it contains.

Basic movement (Goodnight's movement engine used)
Link can blink randomly
Toggle screen size with the "Q" button for now

Some things I should note, I have several coding conventions I use:

For constants:
Constants are all capitalized: eg. CONSTANT

For Member variables:
Member variables start with capitals for each word: eg. MemberVariable
I also use the "self." keyword when referencing a member variable. This makes the code more easy to read.

For Local variables:
Local variables always start lower cased. eg. localVariable.
I also declare every local at the top by prefixing "var" keyword at the top of the script.

For Globals:
Same a member variables: eg. global.GlobalVariable
The seperate themselves with the "global." keyword. I also declared each global on it's own line to comment what they represent.

For resources:
All lower case with underscores for separation. Also prefixed with a resource acronym:
eg. scr_set_something (A script resource) .

Whether or not these conventions are acceptable can be discussed. We should come up with a uniform way to code amongst one another, whatever it may be.
« Last Edit: March 27, 2009, 12:57:26 pm by Xfixium »
Logged
  • Pyxosoft
Re: Getting Started
« Reply #14 on: March 27, 2009, 02:01:50 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Look, I know not everyone is enthusiastic about this project, but a little feedback would be nice. XD Maybe my post update got wiped when this board got moved. *shrugs*
Logged
  • Pyxosoft
Re: Getting Started
« Reply #15 on: March 27, 2009, 03:27:45 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
I am sorry, I have been busy with college classes and trying to help my friend Zahnle get his C++ homework to work (odd in that it compiles fine in Dev-C++ but Unix is giving it errors). I will look at this over the course of the day and weekend.
Logged
Re: Getting Started
« Reply #16 on: March 27, 2009, 03:37:33 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Understandable, you take your time. I will continue to get some more things done.
Logged
  • Pyxosoft
Re: Getting Started
« Reply #17 on: March 28, 2009, 05:03:21 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
An updated version, with dialog box functionality. I've tried to make it pretty generic. It all happens with a call to scr_create_dialog which accepts; a background resource, x, y, width, height and text string. It also supports some simple tags.

Code: [Select]
Color tags:
[col=aqua]
[col=black]
[col=blue]
[col=dkgray]
[col=fuchsia]
[col=gray]
[col=green]
[col=lime]
[col=ltgray]
[col=maroon]
[col=navy]
[col=olive]
[col=orange]
[col=purple]
[col=red]
[col=silver]
[col=teal]
[col=yellow]

Special MC specific color tags:
[col=item]
[col=place]
[col=event]
[col=name]

Close color tag:
[/col]

New line tag:
[b]

LA specific image tags:
[img=yoshi]
[img=ribbon]
[img=dogfood]
[img=bananas]
[img=stick]
[img=honeycomb]
[img=pineapple]
[img=hibiscus]
[img=letter]
[img=broom]
[img=fishhook]
[img=necklace]
[img=scale]
[img=lens]
Quite honestly this could probably be made even more customizable. That would be going above and beyond. It may be unnecessary. Of course that's up for debate.

EDIT: The continue prompt is not done yet. Also you can draw the text fast with the "X" button.
« Last Edit: March 28, 2009, 05:08:18 pm by Xfixium »
Logged
  • Pyxosoft
Re: Getting Started
« Reply #18 on: March 28, 2009, 05:10:34 pm »
  • *
  • Reputation: +8/-0
  • Offline Offline
  • Gender: Male
  • Posts: 6604
About shadows, in the actual Minish Cap game, do Link/enemy shadows blend against the environment or do they stay a solid color?

As for some of this coding though, I am having a minor issue in that some of it is GM 7 Pro, so I cannot fully observe it (although I am able to understand the data structures part since I work with them in my C++ class currently). I know that there is also a way in which to have a  text engine that can be run effectively in GM 7 Lite too but if Pro has a better system then it might be good to go with it. A thing to consider is the difference between those who have GM7 registered or not.
Logged
Re: Getting Started
« Reply #19 on: March 28, 2009, 05:34:39 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
They are a solid color. However, the color changes depending on the pallet it seems. This is seen when Link enters different areas of the game. I mimic this behavior by having a base white shadow sprite, and have a global shadow color that can be changed anywhere in the game. It's probably best to change this when the room changes. The color is used to blend with the shadow sprites in the game. That way it's one sprite, that can be blended to any color the global shadow color is.

Hmmm, I see your point. If we wish to reach everyone with it, it'd have to be lite. That makes me a sad panda. Unfortunately it will be a more convoluted route to use the Lite version. Data structures unfortunately make things faster in GM. The whole color blending with the shadow sprites would be dashed. I also used scaling and a surface for the dialog box. I used scaling on Link also. Well, whatever is decided. If we must make it Lite, so be it. It just won't be as efficient.
Logged
  • Pyxosoft
Pages: [1] 2 3   Go Up
« previous next »

 


Contact Us | Legal | Advertise Here
2013 © ZFGC, All Rights Reserved


Page created in 0.072 seconds with 78 queries.

anything