October 3
Fiddling with vs2010 trying to upgrade the project. Gave up. Not worth wasting the time on. Back to visual studio 2005. Played with some graphics for the photo identification panels. This panel shows the Nexus agent's photo on screen so you know who you are speaking to.
October 05
Working on graphics layers for the photo panel.
October 06
Working on graphics layers for the photo panel.
October 08
Set up the class code for photo panels.
October 10
Setting up the code to be able to hide and reveal photos or the "no signal" image.
October 11
Added dissolve in and out for the photo identification panel.
October 12
Fixed a bug where a guard could attack you from outside a room. Added the first concept of a N.E.X.U.S. agent. Even though they are what the game is essentially about, they haven't been considered until now. Their uniform colour is restricted to green. Guard use any other colours remaining. The code base is now very solid. Changes to the game core is very easy now due to how it is organised. So I expect the development to accelerate as I go along.
October 13
A new music artist is onboard working on the in-game music. Nexus agents now wander the corridors minding their own business. The stun gun can now be activated or de-activated through the menus.
October 17
Worked on the player being able to "see" the closest people nearby in order to identify them. Placed the first of my photo models into the photo panel. These are photos of real people who will be identified as NEXUS agents..
October 21
Worked on the interface layout. For now, this is a mixture of the old interface with new elements placed. It's still very rough and needs a lot of work to make it modern, but with a 70's twist. I hope.
October 23
Still on the interface layout.
October 25
Still on the interface layout.
October 27
Re-factoring code. Splitting out code from the main code unit and moving it to new files to tidy up the code base. Mainly concentrating on the paneling system. There are so many panels that contain small controls. Their definition and logic was all in the main file and it was getting pretty bloated.
October 28
Still re-factoring.
October 29
Still re-factoring.
October 30
Trying to get my project into CodeLite on Windows.
October 31
Still trying. Hassles with Codelite versions, MingW versions... GCC versions... uggghhh.
So this month it has mainly been about making the photo panel control, updating graphics & cleaning up code.
I think I might be aiming for March 2012 as my deadline. That's probably a safer bet at this stage.
This month has been extremely unproductive. I still got things done but there have been many commitments sidelining the effort.
November 01-04
Messing around trying to get orx to compile under codelite so that I can move off the microsoft IDEs and compilers.
November 05
Got it working and even got my own project working under a codelite template. Looking good. Discovered a couple of bugs under the new compiler, and sorted those out ok. But I can't debug and set breakpoints. Nor can I run the app from inside codelite. I have to run the .exe manually.
November 06
Got debugging working, and can run from within codelite. It was old incorrect compiler switch causing the problem. If anyone has trouble setting up a windows version of codelite for orx, I might be able to help.
November 07
Fully committed to the codelite IDE. Ported the project over and fixed another bug to do with painting the floors. So now it's back to the actual work.
November 08
Colour selection panel was created which shows when an agent offers a security pass colour choice to the player
November 09
Implemented the logic for a nexus agent to offer a colour choice to the player.
November 12
Added logic for guard to observe the players security pass colour and react accordingly.
November 15
Fixed a problem with the colour arrays. Sometimes wrong colour was being assigned.
November 19
Guard now asks what the player wants when he approaches. Guard will warn the player if he is in a restricted zone and employ some patience to allow him to leave.
November 20
Guard will now relax his mood if the player leaves the restricted zone that the guard is on. Guard will also become hostile if he is alarmed and the player gets too close and personal.
November 22
Discovered that entering a room was crashing. A problem since moving to codelite. A good thing because it wasn't being picked up in Visual Studio's compiler. Fixed and working again.
December 10
Set to work getting rooms that have been searched to show their door in red.
December 11
Got searched red doors working nicely. Noticed however that my doors no longer display a closing animation when leaving the room. Need to sort that one out.
December 12
Started modeling the outside building structure in blender for use on the map. Might be used for a screen title. Not sure yet.
December 12
Continued modeling on the buildings.
December 13
Finished modeling the buildings (well, good enough for now) and replaced the existing placeholder in the game. Also fixed the map indicator locations. There's a flashing dot on the map to indicate where you are.
December 14
Started work on the floor preview control. This shows the player whats coming up offscreen: enemies, nexus agents, doors and elevators. Kind of line a map, but only for the current floor.
December 16
Continuing on the floor preview control graphics. Modelling the various elements that make up the control.
December 17
Finished all objects for the control and started building code to house it. Positioned it onscreen. Realised its time to start putting the real controls into their proper positions as opposed to test positions.
December 20
Worked on moving graphic elements and controls in proper positions.
December 21
Continuing work on the photo panel to allow it and all it's sub elements to move to other positions.
December 22
Floor preview panel is in place and elements generate along it, however no logic implemented as yet.
Another month with low productivity. But some bits got done at least. December is a difficult month. January is shaping up to be similar.
This post has been edited to include a shot of the Building Map Panel graphics. This panel shows your location in the entire floor plan:
I know it can be frustrating to have unforeseen factors slow the work on a project. Glad to see this is still active, though. Do you have any new screenshots?
Thanks, acksys. No screenshots again as not much has changed, though this month there will be a shot to show off the floor preview control. But that might be all a this stage.
Well... I'm back. Sorry for the delay. Had to deal with some issues, one being finishing up at my old work. Shook the dust from my sandals there and all is now sorted.
But I am still studying for some exams so I'll be back on the game at half pace.
I had better backtrack and show some things that got achieved in January/February, even though it wasn't much.
January 15 - 20
Graphics and layout code for the Colour Selection Panel. This is a new control to allow the player to choose a colour card when asked by a Nexus agent.
January 20 - 25
Implemented logic for the nexus agent to offer a colour choice when greeted by the player.
January 25 - 31
Implemented logic for guard to observe the players pass colour and react accordingly.
That's all for January. Below is a shot of one of the panels. Only basic graphics, the panels need dolling up. There are many menu panels like this one.
February 01 - 03
Fixed colour arrays. Some colours are not offered for passes and there are more colours for floors than passes. I forgot about this and so my indexes got screwed and I couldn't see why come colours wouldn't work properly.
February 04
Got pass colours assigned correctly. A few more sync problems.
February 05
Guard now asks what the player wants when he approaches. Guard will warn the player if he is in a restricted zone and employ some patience to allow him to leave.
February 06 - 20
Spent the last while working on the Floor Preview Panel, and trying to put the logic together with some difficulty. It's a tricky control. But below is the shot in progress.
Green blocks show nexus members, the white is the player and grey are the doors.
Most of the elements start out as a type of sketch in Blender. But everything ends up in the Gimp for cleanup or for further hand drawn editing.
Not sure if I covered the player sprite in another post but I took the animation of me on a treadmill and then rotoscoped my blender character on top. These frames are then rendered out using toon-styled settings.
These settings took a long time to get right. The frames are rendered in full size and then are laid out in strips and resized down in the Gimp. This is supposed to give the impression of hand drawn sprites.
The formula works for the most part and I have the luxury of being able to generate as many pose frames as needed and maintain consistency throughout.
April 23
Rather than writing code, I spent the evening taking a good look at what I had implemented for the Floor Preview Panel. But more than that, I worked out all the rules to the logic. I should have done this from the start rather than hacking away for days on end and getting it wrong. Ended up with a complete set of rules and I feel I now have it right. Coding it in tomorrow night.
April 24
Didn't get it done. More complicated than I give it credit for.
April 28
Man! Still didn't get it done.
April 29
Still Didn't get it done. Hack hack hack.
April 30
Thought I had it but no.... Ok, taking it back to the drawing board and re-plan it. So many moving parts and scenarios.
Ok, boring I know. But I do crack it in May I can report. :ohmy: :blink:
Nah it's ok, I appreciate that. You'd have to spend a lot of time playing the original game and watching the floor preview control to see how it behaves. But I'm pleased to say that I now have it going on the right track.
May 01 - 26
After working on and off on this, I finally have the player preview control behaving correctly, both with the player's tracking across the corridors, and also the indicator bar, which is a small bar that contains 10 blocks. These block represent the 10 map blocks currently on screen.
And that's it for the month. Not totally finished the control, but I am quite sick of it and will be moving to more interesting parts in June so I can at least make some better progress. Below is the shot of the control working.
The white block is the player, grey is elevators, between the black and the red is the current screen contents.
I thought it might be a more interesting update to show off the structure of the project which also makes this diary entry more ORX-centic.
There are currently 10 pairs of code units (.cpp & .h). I'll only illustrate the .cpp files but there is always an accompanying header file.
nexus.cpp
=========
This file contains the initialisation of maps, error checking, screen painting routines.
There are quite a few clocks used in the project contains in this file:
* One for when a player stays still for a period.
* One for a traveling elevator. (player must wait like we all do in life)
* One to change from floor to floor slowly when inside an elevator.
* Three to manage the amount of delay when interacting with menus.
* One for general animation updates.
* One for managing animation delays on characters.
* One for managing animation on the photo reveal panel.
* One for updating the LCD communicator lines when talking to characters.
Map corridor data, floor colour data & searchable room data is all contained in the code here rather than using the config system. Screen drawing routines are kept here to draw and redraw the screen based on where the player is or what he is doing. All player input is handled here. Event handlers are all here to take care of the ORX animation triggers. Positions are compared to the triggered frames as a method of collision detection as the physics engine is not used.
All testing of player actions/inputs/menu system and guard movements/AI updates are all done from here.
character.cpp
=============
This file contains and controls a vector of character objects. The object wraps and extends an orxObject. A character can be a player, guard or nexus depending on the properties set for each. The are over 60 methods to test for character positions, getting/setting an animation, testing for special tiles they are on, responding to external events from nexus.cpp, sending speech commands to the lcd panel, changing moods and behaviours, who can see who, how far away another character is, and testing for collisions.
elevator.cpp
============
The elevator file keep control of a vector of elevator objects that represents one for every elevator specified on the map. There methods here to allow an elevator button to be called, retrieve the status of an elevator position, and if it's ready to use.
enemyai.cpp
===========
This file contains routine to update complex behaviour patterns for characters. For example, if a guard is aggressive, he will need to perform a string of actions, eg: look for the player, roll or run towards the player, check if he is close enough to attack, if he is, attack or run back and pause. Attack again etc. Also handles strings of actions for curious guards and nexus members that have been greeted by the player.
lcdmessenger.cpp
================
This class operates the on screen lcd control which is used by guards and nexus members to communicate information to the player. The control itself is made up of several orxObjects and uses a font. There are up to four lines used and the class controls the scrolling and painting of the messages. Some of the borders of the control are painted with orxObjects and the z-depth is used to hide the scrolling lines as they appear and disappear. The class also controls the colour of the current pass held by the player.
panelcontrols.cpp
=================
This class contains many small objects that wrap orxObjects to make up widgets, which are then used to make larger panels for the menu system. The widgets defined here are: Score Objects, basically two textbox with a label for displaying scores or information; Panel Text Object, similar but only one textbox; Arrow Control, an arrow with or without a label.
panels.cpp
==========
This class contains the definition and initialisation of every panel used in the interactive menu system. It makes up panel controls using the widgets defined in panelcontrols.cpp.
photopanel.cpp
==============
Again, this is a class that uses layers of orxObjects to represent a rusty old panel with a dirty glass overlay encasing a video screen that reveals the photo of a nexus member that is in viewing range. Like lcdmessenger.cpp, this object makes extensive use of z-index positioning of the orxObjects and alpha channels to fake effects in and out.
previewcontrol.cpp
==================
The bane of my existence. This is a complex control that uses it's own painting routine to take the position in the map of the player and to paint 48 tiny orxObject blocks across the control. Each block represents a tile on the map, or the position of a guard, nexus, player, elevator or door. Rather than move the existing 48 blocks, I destroy and re-paint each update. Not sure if this is a memory leak magnet, but we'll see down the track.
rumours.cpp
===========
Contains the vector of rumour objects and the routines to scramble, manage and see if the rumours are solved. Also contains the puzzles hard coded in.
Thanks for taking the time to share all these details about your work.
So, a couple questions about the nexus module you mentioned:
- What are the reason(s) behind putting data in code here rather than in Orx config?
- This is obviously a big module. I, for one, have noticed I have trouble working with large modules and always do better to split them up in too many files. Just a personal preference. Do you get advantages from having a large module in this case?
Hi Acksys, I did go through the pros and cons of doing to the map data in the config but I wanted to pull from my own internal arrays in the code rather than do it the way the config needed it done.
Just a comfort thing really.
With the nexus module, you're totally right. This file has grown way too large and needs to be broken up. Stuff like the keyboard input will be eventually brokwn out into it's own code file because there are pages and pages of orxInput_IsActive and orxInput_HasNewStatus calls, and this alone would cut down the file nicely.
A busy month for me in June with a lot of side projects, but I managed to get the following done...
June 02
Fixed a bug where only walking or running off the screen edge updated the screen map. Rolling or jumping off the screen edge meant the player walked right off the display.
June 04
Fixed a bug where a player could call an elevator and then run into a room before the elevator opens and the program would crash due to the elevator no longer being onscreen. Basically a null pointer exception trying to orxObject_SetCurrentAnim. Added a check.
June 05
Fixed a bug where the player could open a door, and if knocked over during the door opening, the player would enter the room while lying on the ground. Also fixed a missing animation frame in the door open animation. Finally, fixed the animation for a searched door (door wasn’t closing).
Also added a new animation. Player now faces the object that is being searched or inspected, or if a terminal is being used.
June 17
Fixed a bug where aggressive guards could knock the player over while inside an elevator.
June 20
Started work on the bridge tiles. A bridge is an area that spans the gap across buildings. These areas are neutral, colour cards don’t matter here, and you won’t be harassed here. Unless of course you tick someone off. Then they’ll chase you here as well anyway.
June 25
Finished the main bridge tiles and in place. Next to work on the logic for it.
I was attending a conference in July and got quite a few hours downtime. Gave me a chance to work on some stuff, but overall a slack month. Also distracted with another project idea.
20th July
Started work on the floors & bridge logic so that the guards will check your pass card colour when you come off a bridge into their view.
21th July
Improved guard moods in regards to bridges. They relax now when you go back to a bridge or move back down the corridor.
That's about it, though I have put out a new video update. It's been months since the last one. Shows off a lot of new work mentioned from the last few months.
The preview below is only 400x300. To get a better view, right click on the video below and choose "Watch on Vimeo"
New features shown:
* Searched rooms now display a red door. Unsearched rooms remain green.
* Bridges. Safety zones where you are not checked for a card colour.
* Merged floor carpet colours.
* Talking to a N.E.X.U.S. member and obtaining a new colour pass card.
* Guard colour card checking and warnings.
* Basic GUI elements shown.
* Working level preview control shown. Grey blocks are elevators and doors, white is the player.
* New map graphic when showing the player's location.
Comments
October 3
Fiddling with vs2010 trying to upgrade the project. Gave up. Not worth wasting the time on. Back to visual studio 2005. Played with some graphics for the photo identification panels. This panel shows the Nexus agent's photo on screen so you know who you are speaking to.
October 05
Working on graphics layers for the photo panel.
October 06
Working on graphics layers for the photo panel.
October 08
Set up the class code for photo panels.
October 10
Setting up the code to be able to hide and reveal photos or the "no signal" image.
October 11
Added dissolve in and out for the photo identification panel.
October 12
Fixed a bug where a guard could attack you from outside a room. Added the first concept of a N.E.X.U.S. agent. Even though they are what the game is essentially about, they haven't been considered until now. Their uniform colour is restricted to green. Guard use any other colours remaining. The code base is now very solid. Changes to the game core is very easy now due to how it is organised. So I expect the development to accelerate as I go along.
October 13
A new music artist is onboard working on the in-game music. Nexus agents now wander the corridors minding their own business. The stun gun can now be activated or de-activated through the menus.
October 17
Worked on the player being able to "see" the closest people nearby in order to identify them. Placed the first of my photo models into the photo panel. These are photos of real people who will be identified as NEXUS agents..
October 21
Worked on the interface layout. For now, this is a mixture of the old interface with new elements placed. It's still very rough and needs a lot of work to make it modern, but with a 70's twist. I hope.
October 23
Still on the interface layout.
October 25
Still on the interface layout.
October 27
Re-factoring code. Splitting out code from the main code unit and moving it to new files to tidy up the code base. Mainly concentrating on the paneling system. There are so many panels that contain small controls. Their definition and logic was all in the main file and it was getting pretty bloated.
October 28
Still re-factoring.
October 29
Still re-factoring.
October 30
Trying to get my project into CodeLite on Windows.
October 31
Still trying. Hassles with Codelite versions, MingW versions... GCC versions... uggghhh.
So this month it has mainly been about making the photo panel control, updating graphics & cleaning up code.
I think I might be aiming for March 2012 as my deadline. That's probably a safer bet at this stage.
This month has been extremely unproductive. I still got things done but there have been many commitments sidelining the effort.
November 01-04
Messing around trying to get orx to compile under codelite so that I can move off the microsoft IDEs and compilers.
November 05
Got it working and even got my own project working under a codelite template. Looking good. Discovered a couple of bugs under the new compiler, and sorted those out ok. But I can't debug and set breakpoints. Nor can I run the app from inside codelite. I have to run the .exe manually.
November 06
Got debugging working, and can run from within codelite. It was old incorrect compiler switch causing the problem. If anyone has trouble setting up a windows version of codelite for orx, I might be able to help.
November 07
Fully committed to the codelite IDE. Ported the project over and fixed another bug to do with painting the floors. So now it's back to the actual work.
November 08
Colour selection panel was created which shows when an agent offers a security pass colour choice to the player
November 09
Implemented the logic for a nexus agent to offer a colour choice to the player.
November 12
Added logic for guard to observe the players security pass colour and react accordingly.
November 15
Fixed a problem with the colour arrays. Sometimes wrong colour was being assigned.
November 19
Guard now asks what the player wants when he approaches. Guard will warn the player if he is in a restricted zone and employ some patience to allow him to leave.
November 20
Guard will now relax his mood if the player leaves the restricted zone that the guard is on. Guard will also become hostile if he is alarmed and the player gets too close and personal.
November 22
Discovered that entering a room was crashing. A problem since moving to codelite. A good thing because it wasn't being picked up in Visual Studio's compiler. Fixed and working again.
No screen shot this month. Till next month...
December 10
Set to work getting rooms that have been searched to show their door in red.
December 11
Got searched red doors working nicely. Noticed however that my doors no longer display a closing animation when leaving the room. Need to sort that one out.
December 12
Started modeling the outside building structure in blender for use on the map. Might be used for a screen title. Not sure yet.
December 12
Continued modeling on the buildings.
December 13
Finished modeling the buildings (well, good enough for now) and replaced the existing placeholder in the game. Also fixed the map indicator locations. There's a flashing dot on the map to indicate where you are.
December 14
Started work on the floor preview control. This shows the player whats coming up offscreen: enemies, nexus agents, doors and elevators. Kind of line a map, but only for the current floor.
December 16
Continuing on the floor preview control graphics. Modelling the various elements that make up the control.
December 17
Finished all objects for the control and started building code to house it. Positioned it onscreen. Realised its time to start putting the real controls into their proper positions as opposed to test positions.
December 20
Worked on moving graphic elements and controls in proper positions.
December 21
Continuing work on the photo panel to allow it and all it's sub elements to move to other positions.
December 22
Floor preview panel is in place and elements generate along it, however no logic implemented as yet.
Another month with low productivity. But some bits got done at least. December is a difficult month. January is shaping up to be similar.
This post has been edited to include a shot of the Building Map Panel graphics. This panel shows your location in the entire floor plan:
But I am still studying for some exams so I'll be back on the game at half pace.
I had better backtrack and show some things that got achieved in January/February, even though it wasn't much.
January 15 - 20
Graphics and layout code for the Colour Selection Panel. This is a new control to allow the player to choose a colour card when asked by a Nexus agent.
January 20 - 25
Implemented logic for the nexus agent to offer a colour choice when greeted by the player.
January 25 - 31
Implemented logic for guard to observe the players pass colour and react accordingly.
That's all for January. Below is a shot of one of the panels. Only basic graphics, the panels need dolling up. There are many menu panels like this one.
February 01 - 03
Fixed colour arrays. Some colours are not offered for passes and there are more colours for floors than passes. I forgot about this and so my indexes got screwed and I couldn't see why come colours wouldn't work properly.
February 04
Got pass colours assigned correctly. A few more sync problems.
February 05
Guard now asks what the player wants when he approaches. Guard will warn the player if he is in a restricted zone and employ some patience to allow him to leave.
February 06 - 20
Spent the last while working on the Floor Preview Panel, and trying to put the logic together with some difficulty. It's a tricky control. But below is the shot in progress.
Green blocks show nexus members, the white is the player and grey are the doors.
In other news, my wife got an android fancy-phone so I'll be interested at some point to try and compile a test for that.
That'll do for now. I'll look at the codebase again from tomorrow.
Not sure if I covered the player sprite in another post but I took the animation of me on a treadmill and then rotoscoped my blender character on top. These frames are then rendered out using toon-styled settings.
These settings took a long time to get right. The frames are rendered in full size and then are laid out in strips and resized down in the Gimp. This is supposed to give the impression of hand drawn sprites.
The formula works for the most part and I have the luxury of being able to generate as many pose frames as needed and maintain consistency throughout.
April 23
Rather than writing code, I spent the evening taking a good look at what I had implemented for the Floor Preview Panel. But more than that, I worked out all the rules to the logic. I should have done this from the start rather than hacking away for days on end and getting it wrong. Ended up with a complete set of rules and I feel I now have it right. Coding it in tomorrow night.
April 24
Didn't get it done. More complicated than I give it credit for.
April 28
Man! Still didn't get it done.
April 29
Still Didn't get it done. Hack hack hack.
April 30
Thought I had it but no.... Ok, taking it back to the drawing board and re-plan it. So many moving parts and scenarios.
Ok, boring I know. But I do crack it in May I can report. :ohmy: :blink:
This is the story of my programming life so far
In any case, good luck!
May 01 - 26
After working on and off on this, I finally have the player preview control behaving correctly, both with the player's tracking across the corridors, and also the indicator bar, which is a small bar that contains 10 blocks. These block represent the 10 map blocks currently on screen.
And that's it for the month. Not totally finished the control, but I am quite sick of it and will be moving to more interesting parts in June so I can at least make some better progress. Below is the shot of the control working.
The white block is the player, grey is elevators, between the black and the red is the current screen contents.
I thought it might be a more interesting update to show off the structure of the project which also makes this diary entry more ORX-centic.
There are currently 10 pairs of code units (.cpp & .h). I'll only illustrate the .cpp files but there is always an accompanying header file.
nexus.cpp
=========
This file contains the initialisation of maps, error checking, screen painting routines.
There are quite a few clocks used in the project contains in this file:
* One for when a player stays still for a period.
* One for a traveling elevator. (player must wait like we all do in life)
* One to change from floor to floor slowly when inside an elevator.
* Three to manage the amount of delay when interacting with menus.
* One for general animation updates.
* One for managing animation delays on characters.
* One for managing animation on the photo reveal panel.
* One for updating the LCD communicator lines when talking to characters.
Map corridor data, floor colour data & searchable room data is all contained in the code here rather than using the config system. Screen drawing routines are kept here to draw and redraw the screen based on where the player is or what he is doing. All player input is handled here. Event handlers are all here to take care of the ORX animation triggers. Positions are compared to the triggered frames as a method of collision detection as the physics engine is not used.
All testing of player actions/inputs/menu system and guard movements/AI updates are all done from here.
character.cpp
=============
This file contains and controls a vector of character objects. The object wraps and extends an orxObject. A character can be a player, guard or nexus depending on the properties set for each. The are over 60 methods to test for character positions, getting/setting an animation, testing for special tiles they are on, responding to external events from nexus.cpp, sending speech commands to the lcd panel, changing moods and behaviours, who can see who, how far away another character is, and testing for collisions.
elevator.cpp
============
The elevator file keep control of a vector of elevator objects that represents one for every elevator specified on the map. There methods here to allow an elevator button to be called, retrieve the status of an elevator position, and if it's ready to use.
enemyai.cpp
===========
This file contains routine to update complex behaviour patterns for characters. For example, if a guard is aggressive, he will need to perform a string of actions, eg: look for the player, roll or run towards the player, check if he is close enough to attack, if he is, attack or run back and pause. Attack again etc. Also handles strings of actions for curious guards and nexus members that have been greeted by the player.
lcdmessenger.cpp
================
This class operates the on screen lcd control which is used by guards and nexus members to communicate information to the player. The control itself is made up of several orxObjects and uses a font. There are up to four lines used and the class controls the scrolling and painting of the messages. Some of the borders of the control are painted with orxObjects and the z-depth is used to hide the scrolling lines as they appear and disappear. The class also controls the colour of the current pass held by the player.
panelcontrols.cpp
=================
This class contains many small objects that wrap orxObjects to make up widgets, which are then used to make larger panels for the menu system. The widgets defined here are: Score Objects, basically two textbox with a label for displaying scores or information; Panel Text Object, similar but only one textbox; Arrow Control, an arrow with or without a label.
panels.cpp
==========
This class contains the definition and initialisation of every panel used in the interactive menu system. It makes up panel controls using the widgets defined in panelcontrols.cpp.
photopanel.cpp
==============
Again, this is a class that uses layers of orxObjects to represent a rusty old panel with a dirty glass overlay encasing a video screen that reveals the photo of a nexus member that is in viewing range. Like lcdmessenger.cpp, this object makes extensive use of z-index positioning of the orxObjects and alpha channels to fake effects in and out.
previewcontrol.cpp
==================
The bane of my existence. This is a complex control that uses it's own painting routine to take the position in the map of the player and to paint 48 tiny orxObject blocks across the control. Each block represents a tile on the map, or the position of a guard, nexus, player, elevator or door. Rather than move the existing 48 blocks, I destroy and re-paint each update. Not sure if this is a memory leak magnet, but we'll see down the track.
rumours.cpp
===========
Contains the vector of rumour objects and the routines to scramble, manage and see if the rumours are solved. Also contains the puzzles hard coded in.
So, a couple questions about the nexus module you mentioned:
- What are the reason(s) behind putting data in code here rather than in Orx config?
- This is obviously a big module. I, for one, have noticed I have trouble working with large modules and always do better to split them up in too many files. Just a personal preference. Do you get advantages from having a large module in this case?
Just a comfort thing really.
With the nexus module, you're totally right. This file has grown way too large and needs to be broken up. Stuff like the keyboard input will be eventually brokwn out into it's own code file because there are pages and pages of orxInput_IsActive and orxInput_HasNewStatus calls, and this alone would cut down the file nicely.
It's one of those todo things.
Thanks for answering. I read every book and opinion I can find about software design..
A busy month for me in June with a lot of side projects, but I managed to get the following done...
June 02
Fixed a bug where only walking or running off the screen edge updated the screen map. Rolling or jumping off the screen edge meant the player walked right off the display.
June 04
Fixed a bug where a player could call an elevator and then run into a room before the elevator opens and the program would crash due to the elevator no longer being onscreen. Basically a null pointer exception trying to orxObject_SetCurrentAnim. Added a check.
June 05
Fixed a bug where the player could open a door, and if knocked over during the door opening, the player would enter the room while lying on the ground. Also fixed a missing animation frame in the door open animation. Finally, fixed the animation for a searched door (door wasn’t closing).
Also added a new animation. Player now faces the object that is being searched or inspected, or if a terminal is being used.
June 17
Fixed a bug where aggressive guards could knock the player over while inside an elevator.
June 20
Started work on the bridge tiles. A bridge is an area that spans the gap across buildings. These areas are neutral, colour cards don’t matter here, and you won’t be harassed here. Unless of course you tick someone off. Then they’ll chase you here as well anyway.
June 25
Finished the main bridge tiles and in place. Next to work on the logic for it.
Bridge shot 2. This is a neutral zone that guards don't enforce.
I was attending a conference in July and got quite a few hours downtime. Gave me a chance to work on some stuff, but overall a slack month. Also distracted with another project idea.
20th July
Started work on the floors & bridge logic so that the guards will check your pass card colour when you come off a bridge into their view.
21th July
Improved guard moods in regards to bridges. They relax now when you go back to a bridge or move back down the corridor.
That's about it, though I have put out a new video update. It's been months since the last one. Shows off a lot of new work mentioned from the last few months.
New features shown:
* Searched rooms now display a red door. Unsearched rooms remain green.
* Bridges. Safety zones where you are not checked for a card colour.
* Merged floor carpet colours.
* Talking to a N.E.X.U.S. member and obtaining a new colour pass card.
* Guard colour card checking and warnings.
* Basic GUI elements shown.
* Working level preview control shown. Grey blocks are elevators and doors, white is the player.
* New map graphic when showing the player's location.
I can't wait to try it though I think it'll take me some time to understand how to play it.